⁉️ Issues with IPv6 access to swisscom.ch website

Hello @lucaberta,

Effectively the ipv6 webserver swisscom.ch (2a02:a90:c400:4001::2) isn’t reachable.

@“x”#103702could you report this issue?

Hello @Biorn1950 @lucaberta

Thank you for your contributions.

I forwarded your reporting to our specialists.

Let’s wait for their answer.

Have a nice day

I have reported and resolved this already. See here.

Solution is to reduce your MTU from 1480 to 1472.

And yes, there is no technical reason and the issue is caused by Swisscom creating a blackholing by blocking the ICMP response packets from the hosts which would notify your host to reduce the MTU. Basically Swisscom services are unavailable on any IPv6 enabled internet connection with an MTU larger than 1472.

@SkyBeam

I just tried with mtu 1472 and the server still not answer.

---

@Biorn1950 wrote:

I just tried with mtu 1472 and the server still not answer.

---

Are you using any additional encapsulation? You might try even lower values then. However for me it works fine using MTU of 1472 on 6rd tunnel to 6rd.swisscom.com. Also make sure the MTU of 1472 is announced properly on your LAN devices (router advertisements). I am operating radvd on my LAN and use “AdvLinkMTU 1472” property.

@“x”#1560thanks for your answer.

Just to be sure, at this moment you have an answer if you: ping6 swisscom.ch?

Could you try it please and confirm me which ip is reached.

---

@Biorn1950 wrote:

@“x”#1560thanks for your answer.

Just to be sure, at this moment you have an answer if you: ping6 swisscom.ch?

Could you try it please and confirm me which ip is reached.

---

No. Absolutely not of course. This is part of the problem. Swisscom seems to filter all (yes all, not just echo-request/reply) ICMP traffic on swisscom.ch. So you will never get an ICMP echo reply. Even worse you will also not get ICMP error messages from the host’s you want to reach.

And exactly this is the problem:

• You are sending a package with a size larger than 1472 to the swisscom.ch host
• The host receives the package (or a router in between) but it cannot forward it due to an internal link having a maximum MTU of 1472 (6rd tunneling + PPPoE encapsulation). The router/host will reply with ICMP “Fragementation Needed” reply (Type 3, Code 4).
• Unfortunately the reply is also dropped on it’s way back to you.
• Your client will wait forefer or any response. It will neither get any TCP answer nor any ICMP fragmentation needed message. So you’re lost and the connection just times out.

The solution is to assure that your client will never even try to send a packet larger than 1472 bytes to the swisscom.ch host (TCP packets on Port 443) so it’s not getting dropped. Of course this is completely against any standard and a misconfiguration on the network but there are companies which still believe ICMP can be simply blocked and there is no real value of those information. Some of them only know ICMP type “echo request/reply” and think that’s not needed. But specifically with IPv6 it’s important also to forward ICMP traffic. So I am afraid that actually nobody using any provider which provides native or large-mtu IPv6 access will be able to reach any swisscom.ch services (with some exceptions like this community pages which seems to be on a host which can transport larger IPv6 packets (working with 1480 bytes MTU at least). But the majority of swisscom.ch services including MyCloud and the customer center simply will not work. The only workaround known to me is to announce a maxium MTU ofr 1472 bytes or smaller to your clients - at least for the path towards Swisscom services.

Perhaps they will fix it once in a while, but I wouldn’t hold my breath as I am facing this issue since years.

@“x”#1560it’s most clear now, that why I can’t get any answer with an mtu set to 1472 or below.

Thanks for your explanations, I was disturbed by the fact I could reach and diagnose while ping6 mtu size for community.swisscon.ch and not for the main domain.

Perfect, thanks again.

---

@lucaberta wrote:

I wonder if all these issues I am seeing would simply be solved by implementing the correct best practices at Swisscom, rather than zapping all the ICMPv6 frames altogether…

---

Sure it would be resolved. As written some host/router in between the client and the server will actually respond with an ICMP package indicating that it cannot forward the request due to its size. But as this response is dropped your client is waiting forever, not knowing the request has actually been silently dropped.

Actually it should be enough to lower the MTU of your 6rd tunnel on your gateway to 1472. Assuming your gateway does not suffer from the same issues (you don’t silently drop ICMP to your clients) then your gateway should actually tell your client to send smaller packages if it cannot forward them on the MTU-1472 6rd tunnel. So for your local network it would be sufficient. However it’s perhaps a bit less efficient if your RA messages advertise 1480 on your LAN and your clients will detect on each TCP connection establishment that the actual MTU for global-unique IPs are limited to 1472 so the request needs to be split and re-sent.

You can actually check the MTU on your client. On Linux just use ‘ip a’ command. On Windows open a command prompt and use the ‘netsh interface ipv6 show subinterface’ command to see the MTU advertised on your local link.

Likely this one is 1480 but if your gateway needs to forward it on a link with MTU 1472 it will tell your client to send smaller packets (via ICMP). Since you don’t block this (hopefully) it will work.

Not sure however if your settings on the gateway are properly done. I am using a Linux router with 6rd tunnel. I had to modify the init script to allow me to set a custom MTU (ip lin kset mtu 1472 <6rd-interface>). I guess your Zyxel perhaps allows to set a manual MTU on the 6rd tunnel. But you need to make sure it is in effect for the 6rd tunnel and not for any other interface.

I am still very convinced that this is exactly your problem but I can’t test your setup as I am not using any closed/embedded devices.

In regards to why Swisscom is blocking ICMP all over… I don’t know. I guess some “smart” security guy was living in the age where “ping of death” was a real thing and thought “why do we actually need ICMP? We just open TCP port 443, that’s enought as the service just listen on this port”. Well security engineers are usually not network engineers and I am sure there are many wrongly configured gateways, routers and hosts out there.

I’m on CATV (soon to move to Wingo DSL) and I’m using an IPv6 tunnel from HE.net. I was not able to connect to swisscom.ch or sbb.ch. That’s the main 2 websites that failed for me on IPv6, most others works fine. Reading this thread, I just lowered my MTU to 1472 on my tunnel interface in pfsense and I can confirm that I can now successfully access both website via IPv6

---

@c.jaquier wrote:

IPv6 tunnel from HE.net. I was not able to connect to swisscom.ch or sbb.ch.

---

Thanks for the feedback.

This does indeed confirm that the hypothesis is correct as well as confirming that also non-Swisscom IPv6 users will be affected.

I also believe that not only Swissco and SBB service are affected but actually there is a bunch of other services out there which suffer from the same problem. Although I guess many services are at least IPv6 and IPv4 dual-stacked and moving to IPv4 still provides a fallback. However it doesn’t leave a good impression if a potential customer willing to get information about Swisscom services will just not get any response from the official web pages. And the average user will not know the reason, but they will of course be able to surf to competitor pages.

For SBB it might be even worse as there is basically no way around their services when traveling with public transport.

Sad situation, but the solution actually needs to be implemented by these companies and they don’t even acknowledge the problem.

---

@SkyBeam wrote:

In regards to why Swisscom is blocking ICMP all over… I don’t know. I guess some “smart” security guy was living in the age where “ping of death” was a real thing and thought “why do we actually need ICMP? We just open TCP port 443, that’s enought as the service just listen on this port”. Well security engineers are usually not network engineers and I am sure there are many wrongly configured gateways, routers and hosts out there.

good summary

Yes that could be lots of things, miss configuration somewhere, issue with load balancing like ecmp, firewall, or a genius idea from a smart guy

Hello @lucaberta and thank you very much @SkyBeam for your help

According to our specialist, after an analysis with multiple tests, no IPV6 problems are visible on the swisscom.ch website.

I am sorry not being able to provide you more information.

---

@LeylaG wrote:

According to our specialist, after an analysis with multiple tests, no IPV6 problems are visible on the swisscom.ch website.

---

Sure, if you ask the team responsible for operating the web page they do not see a problem. They don’t even see any request packet flowing in larger than 1472 Bytes as every packet larger than this size is already dropped before reaching the web server. So sure for them it looks fine, they never get the requests.

Still the page looks “dead” to all the world out there.

Also clearly if Swisscom staff is testing this from their own home connections (on Swisscom internet box) they will not see a problem either as the internet box is setting a maximum MTU of 1472 Bytes.

But still MTU of 1472 is not the largest MTU other connections will offer (like IPv6 from other providers) and therefore they will face issues.

The bad thing about this is that in the future Swisscom will not even be able to offer competitive offerings to potential customers which would like to switch from another provider to Swisscom as basically they can’t even access the Swisscom web page to browse the offers and sign up. Sure you can ask them to go to the shop, but it’s a bit ridiculous…

---

lucaberta wrote:

Now things have finally clicked on why my score on

https://ipv6-test.com

could never go above 18/20!

Except that it is **NOT** my router or firewall. It’s my ISP that’s doing it!!!

---

To be honest I am not fully sure if here the ISP is to be blamed.

In fact this test will test the connectivity between the test-website and your local computer. This is unrelated to the issue trying to reach swisscom.ch services where the firewall protecting those servers seem to overdo their job slightly.

Swisscom does actually not filter ICMP in general. At least not ICMP echo requests as you can for sure ping your IPv6 address assigned to a LAN device from outside (from any other IPv6 internet connection).

However I did not test yet if the ISP/Swisscom network would filter some other ICMP types in general. Unfortunately also ipv6-test.com does not show any more details which type of ICMPv6 message they are testing. I don’t think this is ICMP echo request as echo requests to my LAN devices work just fine on IPv6 on Swisscom network. At this point I would be unaware about any (ICMP) filtering Swisscom applies to consumer connectivity. Also note that a firewall on your client machine can also be configured to block ICMP from/to the client directly.

At least I think we are looking for two different problems:

• ICMP responses from Swisscom internal networks for public services (like swisscom.ch or mycloud.ch web-pages) are dropped
• ICMP responses from customer access network to/from other public services might be dropped (not fully confirmed yet)

Edit: I am not 100% sure but I think there might be a general problem with ipv6-test.com regarding ICMP testing. First of all in the IPv6 section ICMP is reported to be “Not tested”. And also the Ping test they offer does not work for me - neither for IPv4 nor for IPv6. I am not sure yet if this is eventually blocked by browser policies recently too or it’s a service problem. I also don’t see any ICMP packets sent from my client when running any of those tests. So I think the test there is not reliable in regards to ICMP. Which supports my second point above - I don’t believe ICMPv6 is blocked on network side by the ISP/Swisscom. The problem is limited to Swisscom services being over-protected.

Dear @SkyBeam @lucaberta

I forwarded your concern to the specialist in charge.

I cannot do more at my level I am afraid.

Thank you for your understanding.