cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

⁉️ Issues with IPv6 access to swisscom.ch website

lucaberta
Level 2
1 of 40

Hi everyone,

 

Over the last two/three days, I have been noticing having connection issues with the swisscom.ch website via IPv6, which is my default as I use a 6RD connection from my router, connected to the internet via a Swisscom VDSL2 line.

 

This is independent of the device and OS, since I am experiencing the issue on macOS, Windows, iOS and iPadOS.

 

My macOS laptop with Safari shows this error when trying to connect:

 

image.png

 

If I switch off wifi on my iPad, and pass via the 4G network, the page opens fine, as the 4G connection is only IPv4 as confirmed by the excellent test website:

https://ipv6-test.com/

 

On the other hand, this website https://community.swisscom.ch/ is not affected by the issue, and I can access it regularly over IPv6.

 

Am I the only one experiencing these connection issues with the swisscom.ch website?

 

Many thanks,

 

Luca

39 Comments 39
Biorn1950
Level 2
2 of 40

Hello @lucaberta ,

 

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

 

@LeylaGcould you report this issue?

Récompense des réponses utiles avec un like. Trouvé une solution? -> Accepter comme solution!
LeylaG
Level 2
3 of 40

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

Un like fait toujours plaisir 😉 Une réponse t'a aidé? -> Accepte-la comme solution!
A like always brings a smile 😄 Don't forget to accept helpful solutions
SkyBeam
Level 2
4 of 40

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.

Biorn1950
Level 2
5 of 40

@SkyBeam

 

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

 

 

Récompense des réponses utiles avec un like. Trouvé une solution? -> Accepter comme solution!
SkyBeam
Level 2
6 of 40

@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.

Biorn1950
Level 2
7 of 40

@SkyBeamthanks 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.

Récompense des réponses utiles avec un like. Trouvé une solution? -> Accepter comme solution!
SkyBeam
Level 2
8 of 40

@Biorn1950 wrote:

@SkyBeamthanks 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.

Biorn1950
Level 2
9 of 40

@SkyBeamit'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.

Récompense des réponses utiles avec un like. Trouvé une solution? -> Accepter comme solution!
lucaberta
Level 2
10 of 40

Thanks @SkyBeam for shedding a little light on this issue.

 

It looks like changing the MTU down to 1472 did not change things for me. I also tried 1460 in case of additional padding from other (which ones?) tunnels, but no luck, still.

 

Also, I am using a Zyxel router and I don't believe I can change radvd's configuration to advertise a smaller MTU to the clients on the LAN, I am afraid.

 

The question now is, why would Swisscom block important ICMPv6 frames altogether, when it's best practice to allow them?


There is an RFC which gives best practices on the topic:
https://tools.ietf.org/html/rfc4890

 

   On the other hand, most ICMPv6 error messages traveling end-to-end or
   any-to-end are essential to the establishment and maintenance of
   communications.  These messages must be passed through firewalls and
   might also be sent to and from firewalls to assist with establishment
   and maintenance of communications.  For example, the Packet Too Big
   error message is needed to determine the MTU along a path both when a
   communication session is established initially and later if the path
   is rerouted during the session.

 

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...

 

Any further comment is much appreciated.

 

Ciao, Luca

 

SkyBeam
Level 2
11 of 40

@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.

c.jaquier
Level 2
12 of 40

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 🙂

SkyBeam
Level 2
13 of 40

@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.

Biorn1950
Level 2
14 of 40

@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 😁

Récompense des réponses utiles avec un like. Trouvé une solution? -> Accepter comme solution!
lucaberta
Level 2
15 of 40

@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.


thanks @SkyBeam, I very much appreciate your comments!

 

Now things have finally clicked on why my score on

 

https://ipv6-test.com

 

could never go above 18/20!

 

image.png

 

Except that it is **NOT** my router or firewall. It's my ISP that's doing it!!! 😤😡🤬

 

I really wonder what can be done to fix this very annoying situation with Swisscom and their faulty IPv6 implementation.

 

I will ping my longtime friend Éric at Cisco, he is an IPv6 and security extraordinaire and author of multiple RFCs, and I should be getting some good comments from him.

 

Would any email thread on Swinog help too?

 

Bye, Luca

LeylaG
Level 2
16 of 40

Hello @lucaberta @biorn1950  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.

 

 

Un like fait toujours plaisir 😉 Une réponse t'a aidé? -> Accepte-la comme solution!
A like always brings a smile 😄 Don't forget to accept helpful solutions
Edited
lucaberta
Level 2
17 of 40

@LeylaG wrote:

 

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.


this is NOT your fault @LeylaG, it's an issue with the security architecture design which is flawed, as clearly demonstrated by @SkyBeam's excellent analysis.

 

And it's not an issue with the website, rather with the way the Swisscom IPv6 backbone deals with important messages such as ICMPv6.

 

If Swisscom is not willing to implement the best practices on ICMPv6 messages and firewalling, nicely described in RFC4890, then the issue is much higher than the support staff.

 

This sucks, and I am not sure how it could be further escalated, since Swisscom's IPv6 backbone is NOT correctly implementing best practices which will make the network run better.

 

And that's really too bad. 😤😡🤬

 

Bye, Luca

SkyBeam
Level 2
18 of 40

@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...

SkyBeam
Level 2
19 of 40

@lucaberta wrote:

Now things have finally clicked on why my score on

 

https://ipv6-test.com

 

could never go above 18/20!

 

image.png

 

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.

Edited
LeylaG
Level 2
20 of 40

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. 

Un like fait toujours plaisir 😉 Une réponse t'a aidé? -> Accepte-la comme solution!
A like always brings a smile 😄 Don't forget to accept helpful solutions
Back to top