Hey all
This might not be 100% the correct place to ask this but since the SBB contact form didn't yield any results, I'll try here. Maybe someone from SBB who knows someone who can do something about this reads the list.
There are A and AAAA records for sbb.ch:
$ dig AAAA sbb.ch +short 2a00:4bc0:ffff:9::c296:f58e
$ dig A sbb.ch +short 194.150.245.142
However, on port 80 and 443 I only get a response on IPv4, a 301 to http(s)://www.sbb.ch. On IPv6 it just times out without any response:
$ curl -6 https://sbb.ch -v * Host sbb.ch:443 was resolved. * IPv6: 2a00:4bc0:ffff:9::c296:f58e * IPv4: (none) * Trying [2a00:4bc0:ffff:9::c296:f58e]:443... * connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from 2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out * Failed to connect to sbb.ch port 443 after 133922 ms: Could not connect to server * closing connection #0 curl: (28) Failed to connect to sbb.ch port 443 after 133922 ms: Could not connect to server
tcpdump doesn't show any response packets at all.
This is mainly an issue on our IPv6-only clients where we use DNS64/NAT64. So the preferred solution would be for someone to fix IPv6. However, removing the AAAA DNS record would also solve the issue because then the resolver generates a DNS64 response and we connect to IPv4 over NAT64.
Hope someone can help. It's a bit of a shot in the dark. Let me know it this is completely inappropriate to be posted on this list.
Thanks and regards
Beni
On 22 Mar 2026, at 14:13, Beni Keller via swinog swinog@lists.swinog.ch wrote:
[..]
$ curl -6 https://sbb.ch -v
- Host sbb.ch:443 was resolved.
- IPv6: 2a00:4bc0:ffff:9::c296:f58e
- IPv4: (none)
- Trying [2a00:4bc0:ffff:9::c296:f58e]:443...
- connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from
2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out
Note that it is says "timed out", which means it did connect.
Do you have an odd MTU maybe? or some other MTU related issues.
They got a fun WAF thing, thus even a mere 'wget' gets rejected.
But I recall in the past that they also had MTU issues which is more likely your problem.
At the moment and in my usage in last years though it has just worked over IPv6.
Definitely run a wireshark in the background and then open the website in a normal browser and check what packets you see there; that might just give you the hint that some packets go out and others do not come back.
Greets, Jeroen
% wget https://www.sbb.ch/robots.txt --2026-03-23 09:08:10-- https://www.sbb.ch/robots.txt Resolving www.sbb.ch (www.sbb.ch)... 2600:9000:20a5:6600:2:5597:5ac0:93a1, 2600:9000:20a5:8800:2:5597:5ac0:93a1, 2600:9000:20a5:4800:2:5597:5ac0:93a1, ... Connecting to www.sbb.ch (www.sbb.ch)|2600:9000:20a5:6600:2:5597:5ac0:93a1|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-03-23 09:08:10 ERROR 403: Forbidden.
Sending a 403 on a robots.txt as one wants to block robots will just have the adverse effect of robots having no robots.txt guidance and.... guess what: robots.txt is empty thus they will proceed with their fun....
% wget -U "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36" https://www.sbb.ch/robots.txt --2026-03-23 09:07:55-- https://www.sbb.ch/robots.txt Resolving www.sbb.ch (www.sbb.ch)... 2600:9000:20a5:6600:2:5597:5ac0:93a1, 2600:9000:20a5:8800:2:5597:5ac0:93a1, 2600:9000:20a5:4800:2:5597:5ac0:93a1, ... Connecting to www.sbb.ch (www.sbb.ch)|2600:9000:20a5:6600:2:5597:5ac0:93a1|:443... connected. HTTP request sent, awaiting response... 200 OK Cookie coming from www.sbb.ch attempted to set domain to sbb.ch Length: 2984 (2.9K) [text/plain] Saving to: ‘robots.txt’
robots.txt 100%[===========================>] 2.91K --.-KB/s in 0s
2026-03-23 09:07:55 (41.8 MB/s) - ‘robots.txt’ saved [2984/2984]
btw: User-agent: Mediapartners-Google Disallow: # auf allen Seiten erscheint Werbung
Really.... never seen that because of a simple Web-User-Agent-WAF called an ad blocker ;)
User-agent: * Disallow: # alles darf indexiert werden
Disallow without a path will not make everything be allowed, it is magic that SBB shows up in search engines at all... guess as that is a broken thing, most robots just ignore it.
But bit odd to block things based on UA in the WAF level but then not actually have explicit rules in robots.txt.... oh well ;)
hi,
On Mon, Mar 23, 2026 at 09:12:35AM +0100, Jeroen Massar via swinog wrote:
On 22 Mar 2026, at 14:13, Beni Keller via swinog swinog@lists.swinog.ch wrote:
[..]
$ curl -6 https://sbb.ch -v
- Host sbb.ch:443 was resolved.
- IPv6: 2a00:4bc0:ffff:9::c296:f58e
- IPv4: (none)
- Trying [2a00:4bc0:ffff:9::c296:f58e]:443...
- connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from
2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out
Note that it is says "timed out", which means it did connect.
Uh, wat? Who are you, and what did you do to Jeroen...?
*Connection* timed out is exactly this - it did not connect.
At the moment and in my usage in last years though it has just worked over IPv6.
From here (5539) and right now, sbb.ch port 443 is not reachable over IPv6...
$ telnet sbb.ch 443 Trying 2a00:4bc0:ffff:9::c296:f58e... telnet: connect to address 2a00:4bc0:ffff:9::c296:f58e: Operation timed out Trying 194.150.245.142... Connected to sbb.ch. Escape character is '^]'.
(using telnet as a lowest-level connection setup tool - there can not be anything MTU related here, before the first actual data packets flow, and telnet will signal that phase with "Connected to...")
Gert Doering -- NetMaster
On 23 Mar 2026, at 10:27, Gert Doering gert@space.net wrote:
hi,
On Mon, Mar 23, 2026 at 09:12:35AM +0100, Jeroen Massar via swinog wrote:
On 22 Mar 2026, at 14:13, Beni Keller via swinog swinog@lists.swinog.ch wrote:
[..]
$ curl -6 https://sbb.ch -v
- Host sbb.ch:443 was resolved.
- IPv6: 2a00:4bc0:ffff:9::c296:f58e
- IPv4: (none)
- Trying [2a00:4bc0:ffff:9::c296:f58e]:443...
- connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from
2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out
Note that it is says "timed out", which means it did connect.
Uh, wat? Who are you, and what did you do to Jeroen...?
*Connection* timed out is exactly this - it did not connect.
The delta between coffee and not :)
That is what one skips over when debugging a CT setup for too long ;) [see threads on the other lists]
At the moment and in my usage in last years though it has just worked over IPv6.
From here (5539) and right now, sbb.ch port 443 is not reachable over IPv6...
$ telnet sbb.ch 443 Trying 2a00:4bc0:ffff:9::c296:f58e... telnet: connect to address 2a00:4bc0:ffff:9::c296:f58e: Operation timed out Trying 194.150.245.142... Connected to sbb.ch. Escape character is '^]'.
(using telnet as a lowest-level connection setup tool - there can not be anything MTU related here, before the first actual data packets flow, and telnet will signal that phase with "Connected to...")
so... if we are being pedantic a bit, do remember that telnet does control characters and tries to do negotiation when it connects, thus if the server sends certain chars it could detect you are doing telnet instead of the much cleaner netcat :)
Also, on Mac they removed telnet, which I indeed aliased to 'nc -v' cause like you, we all do port testing still with telnet even though we know the above tidbit. My other friend for it is 'openssl s_client' though as so much is TLS nowadays.
Regards, Jeroen
Hi,
On Mon, Mar 23, 2026 at 10:48:18AM +0100, Jeroen Massar wrote:
My other friend for it is 'openssl s_client' though as so much is TLS nowadays.
Yeah, definitely. Whenever I need to do "so it connected, but does it really work?" this is also my tool of choice (... and if you have MTU issues, that's where you'd see them ;-)).
Enjoy your coffe,
Gert Doering -- NetMaster
Hey Jeroen
Thank you for your reply. I don't think you are correct that the connection did come up, though. Curl seems to report a timeout if no packets are received. We tried from a host which has a guaranteed MTU of 1500 and don't see any back traffic at all, not even a SYN ACK. That's the tcpdump while curl was trying to connect:
tcpdump -n host 2a00:4bc0:ffff:9::c296:f58e dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens2, link-type EN10MB (Ethernet), capture size 262144 bytes 10:07:57.491780 IP6 2a09:b240::16.55742 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1544255297, win 28800, options [mss 1440,sackOK,TS val 1557641517 ecr 0,nop,wscale 7], length 0 10:08:02.654381 IP6 2a09:b240::16.47342 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1266028447, win 28800, options [mss 1440,sackOK,TS val 1557646679 ecr 0,nop,wscale 7], length 0 10:08:03.699776 IP6 2a09:b240::16.47342 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1266028447, win 28800, options [mss 1440,sackOK,TS val 1557647725 ecr 0,nop,wscale 7], length 0 10:08:05.747755 IP6 2a09:b240::16.47342 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1266028447, win 28800, options [mss 1440,sackOK,TS val 1557649773 ecr 0,nop,wscale 7], length 0 10:08:09.779758 IP6 2a09:b240::16.47342 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1266028447, win 28800, options [mss 1440,sackOK,TS val 1557653805 ecr 0,nop,wscale 7], length 0 10:08:17.971759 IP6 2a09:b240::16.47342 > 2a00:4bc0:ffff:9::c296:f58e.https: Flags [S], seq 1266028447, win 28800, options [mss 1440,sackOK,TS val 1557661997 ecr 0,nop,wscale 7], length 0
As you suggested I also tried a normal browser and ran Wireshark. There it's excatly the same: All I see are are our outgoing SYNs. The MTU is unlikely to be the issue at this point of the connection. Tracerout suggests that we reach their end but not the target host itself:
traceroute 2a00:4bc0:ffff:9::c296:f58e traceroute to 2a00:4bc0:ffff:9::c296:f58e (2a00:4bc0:ffff:9::c296:f58e), 30 hops max, 80 byte packets 1 2a09:b240::2 (2a09:b240::2) 0.325 ms 0.309 ms 0.300 ms 2 2001:4b20:10:4100::1 (2001:4b20:10:4100::1) 6.382 ms 6.371 ms 6.340 ms 3 * * * 4 2001:4b27:ffff::4 (2001:4b27:ffff::4) 1.437 ms 1.413 ms 1.395 ms 5 2001:4b27:ffff::32 (2001:4b27:ffff::32) 1.241 ms 1.227 ms 1.210 ms 6 zch-b1-link.ip.twelve99.net (2001:2035:0:126a::1) 1.197 ms 1.614 ms 1.594 ms 7 ffm-bb2-v6.ip.twelve99.net (2001:2034:1:6c::1) 6.555 ms 6.643 ms 6.924 ms 8 ffm-b5-link.ip.twelve99.net (2001:2035:0:176::1) 7.448 ms 7.438 ms 7.584 ms 9 * colt-ic-355540.ip.twelve99-cust.net (2001:2035:0:176::2) 6.846 ms 6.992 ms 10 * * 2001:920:0:1::141 (2001:920:0:1::141) 8.985 ms 11 2001:920:0:1::141 (2001:920:0:1::141) 9.101 ms 2a00:4bc0:ffff:ff00::a (2a00:4bc0:ffff:ff00::a) 9.691 ms 2001:920:0:1::141 (2001:920:0:1::141) 9.216 ms 12 2a00:4bc0:ffff:ff00::a (2a00:4bc0:ffff:ff00::a) 9.651 ms 9.431 ms 10.476 ms 13 * 2a00:4bc0:ffff:ff00::1d (2a00:4bc0:ffff:ff00::1d) 10.428 ms * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *
However, Ping does not work, so this might not be relevant.
ping -6 sbb.ch PING sbb.ch(2a00:4bc0:ffff:9::c296:f58e (2a00:4bc0:ffff:9::c296:f58e)) 56 data bytes ^C --- sbb.ch ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8204ms
% wget https://www.sbb.ch/robots.txt --2026-03-23 09:08:10-- https://www.sbb.ch/robots.txt Resolving www.sbb.ch (www.sbb.ch)... 2600:9000:20a5:6600:2:5597:5ac0:93a1, 2600:9000:20a5:8800:2:5597:5ac0:93a1, 2600:9000:20a5:4800:2:5597:5ac0:93a1, ... Connecting to www.sbb.ch (www.sbb.ch)|2600:9000:20a5:6600:2:5597:5ac0:93a1|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-03-23 09:08:10 ERROR 403: Forbidden.
This wget is not relevant for our issue as it connects to www.sbb.ch, which works. It's only sbb.ch which does not work.
Regards
Beni
On 23 Mar 2026, at 10:28, Beni Keller swinog@hb9hnt.ch wrote:
[..]
% wget https://www.sbb.ch/robots.txt --2026-03-23 09:08:10-- https://www.sbb.ch/robots.txt Resolving www.sbb.ch (www.sbb.ch)... 2600:9000:20a5:6600:2:5597:5ac0:93a1, 2600:9000:20a5:8800:2:5597:5ac0:93a1, 2600:9000:20a5:4800:2:5597:5ac0:93a1, ... Connecting to www.sbb.ch (www.sbb.ch)|2600:9000:20a5:6600:2:5597:5ac0:93a1|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-03-23 09:08:10 ERROR 403: Forbidden.
This wget is not relevant for our issue as it connects to www.sbb.ch, which works. It's only sbb.ch which does not work.
That is the important distinction SBB vs Amazon.
Somebody forgot to update the apex IP addresses when offloading Swiss State Railways...
And indeed, the SBB network is either filtered or otherwise broken.
SBB's own network:
% dig +short sbb.ch 194.150.245.142 % dig +short sbb.ch aaaa 2a00:4bc0:ffff:9::c296:f58e
Versus Amazon hosted:
% dig +short www.sbb.ch a 143.204.55.72 143.204.55.76 143.204.55.87 143.204.55.102
% dig +short www.sbb.ch aaaa 2600:9000:20a5:ea00:2:5597:5ac0:93a1 2600:9000:20a5:3200:2:5597:5ac0:93a1 2600:9000:20a5:3a00:2:5597:5ac0:93a1 2600:9000:20a5:7c00:2:5597:5ac0:93a1 2600:9000:20a5:7e00:2:5597:5ac0:93a1 2600:9000:20a5:9e00:2:5597:5ac0:93a1 2600:9000:20a5:a400:2:5597:5ac0:93a1 2600:9000:20a5:d000:2:5597:5ac0:93a1
IPv4/SBB is responding, but not doing SSL on 443:
% openssl s_client --connect 194.150.245.142:443 Connecting to 194.150.245.142 CONNECTED(00000003) 0031130402000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:918:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent Negotiated TLS1.3 group: <NULL> --- SSL handshake has read 7 bytes and written 1522 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Protocol: TLSv1.3 This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 0031130402000000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2804:
Thus no real SSL there anymore either...
IPv6 is indeed completely unresponsive.
Regards, Jeroen
On Mon, 23 Mar 2026 at 10:44, Jeroen Massar via swinog swinog@lists.swinog.ch wrote:
IPv4/SBB is responding, but not doing SSL on 443:
% openssl s_client --connect 194.150.245.142:443 Connecting to 194.150.245.142 CONNECTED(00000003) 0031130402000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:918:SSL alert number 40
No, it just requires SNI, which you did not provide.
$ openssl s_client -servername sbb.ch --connect 194.150.245.142:443 CONNECTED(00000003) depth=3 C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2 verify return:1 depth=2 C = CH, O = SwissSign AG, CN = SwissSign RSA TLS Root CA 2022 - 1 verify return:1 depth=1 C = CH, O = SwissSign AG, CN = SwissSign RSA TLS DV ICA 2022 - 1 verify return:1 depth=0 CN = sbb.ch verify return:1 --- Certificate chain 0 s:CN = sbb.ch i:C = CH, O = SwissSign AG, CN = SwissSign RSA TLS DV ICA 2022 - 1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Jul 21 12:44:08 2025 GMT; NotAfter: Jul 21 12:44:08 2026 GMT 1 s:C = CH, O = SwissSign AG, CN = SwissSign RSA TLS DV ICA 2022 - 1 i:C = CH, O = SwissSign AG, CN = SwissSign RSA TLS Root CA 2022 - 1 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 29 09:27:46 2022 GMT; NotAfter: Jun 29 09:27:46 2036 GMT 2 s:C = CH, O = SwissSign AG, CN = SwissSign RSA TLS Root CA 2022 - 1 i:C = CH, O = SwissSign AG, CN = SwissSign Gold CA - G2 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 28 11:27:11 2022 GMT; NotAfter: Sep 22 11:27:11 2036 GMT --- [...]
Lukas
On 23 Mar 2026, at 10:57, Lukas Tribus lukas@ltri.eu wrote:
On Mon, 23 Mar 2026 at 10:44, Jeroen Massar via swinog swinog@lists.swinog.ch wrote:
IPv4/SBB is responding, but not doing SSL on 443:
% openssl s_client --connect 194.150.245.142:443 Connecting to 194.150.245.142 CONNECTED(00000003) 0031130402000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:918:SSL alert number 40
No, it just requires SNI, which you did not provide.
Good catch. I'll be getting another coffee [at least the sun is out to enjoy that with]
Indeed the redirect on IPv4/SBB + the SSL are fine.
And IPv6/SBB is just completely b0rked. Happened years ago also.
Fortunately due to happy eyeballs most of the time users will not notice as IPv4 will be tried and the IPv6 address marked as broken... and then the 301 remembered and thus not retried quickly.
Regards, Jeroen
Hey, I spent more than I would like to on debugging various IPv6 issues and the connection timing out pattern you have looks suspiciously similar to issues with MTU during SSL negotiation.
On the tcpdump you would see it as TCP handshake making it through because packets are small, but then the server sends a big packet with SSL certificate, this packets goes zombie and the connection hangs. What's frustrating is you as a client can't 100% confirm this (someone please prove me wrong!) because it's the server who first sends the big packet, so the ICMPv6 "packet too big" is sent back to the server (if at all, because some firewall somewhere may block it).
I never found an ultimate solution to this, but playing with MSS clamping on the client side was enough to prove MTU is an issue when that was the case.
Cheers, Mat
On 22/03/2026 14:13, Beni Keller via swinog wrote:
Hey all
This might not be 100% the correct place to ask this but since the SBB contact form didn't yield any results, I'll try here. Maybe someone from SBB who knows someone who can do something about this reads the list.
There are A and AAAA records for sbb.ch:
$ dig AAAA sbb.ch +short 2a00:4bc0:ffff:9::c296:f58e
$ dig A sbb.ch +short 194.150.245.142
However, on port 80 and 443 I only get a response on IPv4, a 301 to http(s)://www.sbb.ch. On IPv6 it just times out without any response:
$ curl -6 https://sbb.ch -v
- Host sbb.ch:443 was resolved.
- IPv6: 2a00:4bc0:ffff:9::c296:f58e
- IPv4: (none)
- Trying [2a00:4bc0:ffff:9::c296:f58e]:443...
- connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from
2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out
- Failed to connect to sbb.ch port 443 after 133922 ms: Could not
connect to server
- closing connection #0
curl: (28) Failed to connect to sbb.ch port 443 after 133922 ms: Could not connect to server
tcpdump doesn't show any response packets at all.
This is mainly an issue on our IPv6-only clients where we use DNS64/NAT64. So the preferred solution would be for someone to fix IPv6. However, removing the AAAA DNS record would also solve the issue because then the resolver generates a DNS64 response and we connect to IPv4 over NAT64.
Hope someone can help. It's a bit of a shot in the dark. Let me know it this is completely inappropriate to be posted on this list.
Thanks and regards
Beni _______________________________________________ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch
Mat,
MTU issues like you describe is usually caused by braindamaged IT adminstrators who think filtering away ICMP makes them more secure. Instead they break the fundamentals of TCP/IP.
Workaround is indeed to set MSS smaller at connection establishment (or modify it on the fly, like we do on Mikrotiks in the path). The issue we see here however is not this as no SYN ACK is even received.
To me it looks more like SBB has not set up IPv6 properly for the non www IP.
On 23.03.2026 09:48, Mat Kowalski via swinog wrote:
Hey, I spent more than I would like to on debugging various IPv6 issues and the connection timing out pattern you have looks suspiciously similar to issues with MTU during SSL negotiation.
On the tcpdump you would see it as TCP handshake making it through because packets are small, but then the server sends a big packet with SSL certificate, this packets goes zombie and the connection hangs. What's frustrating is you as a client can't 100% confirm this (someone please prove me wrong!) because it's the server who first sends the big packet, so the ICMPv6 "packet too big" is sent back to the server (if at all, because some firewall somewhere may block it).
I never found an ultimate solution to this, but playing with MSS clamping on the client side was enough to prove MTU is an issue when that was the case.
Cheers, Mat
On 22/03/2026 14:13, Beni Keller via swinog wrote:
Hey all
This might not be 100% the correct place to ask this but since the SBB contact form didn't yield any results, I'll try here. Maybe someone from SBB who knows someone who can do something about this reads the list.
There are A and AAAA records for sbb.ch:
$ dig AAAA sbb.ch +short 2a00:4bc0:ffff:9::c296:f58e
$ dig A sbb.ch +short 194.150.245.142
However, on port 80 and 443 I only get a response on IPv4, a 301 to http(s)://www.sbb.ch. On IPv6 it just times out without any response:
$ curl -6https://sbb.ch -v
- Host sbb.ch:443 was resolved.
- IPv6: 2a00:4bc0:ffff:9::c296:f58e
- IPv4: (none)
- Trying [2a00:4bc0:ffff:9::c296:f58e]:443...
- connect to 2a00:4bc0:ffff:9::c296:f58e port 443 from
2001:8e0:1426:1:47d6:12fd:bc19:5704 port 55992 failed: Connection timed out
- Failed to connect to sbb.ch port 443 after 133922 ms: Could not
connect to server
- closing connection #0
curl: (28) Failed to connect to sbb.ch port 443 after 133922 ms: Could not connect to server
tcpdump doesn't show any response packets at all.
This is mainly an issue on our IPv6-only clients where we use DNS64/NAT64. So the preferred solution would be for someone to fix IPv6. However, removing the AAAA DNS record would also solve the issue because then the resolver generates a DNS64 response and we connect to IPv4 over NAT64.
Hope someone can help. It's a bit of a shot in the dark. Let me know it this is completely inappropriate to be posted on this list.
Thanks and regards
Beni _______________________________________________ swinog mailing list --swinog@lists.swinog.ch To unsubscribe send an email toswinog-leave@lists.swinog.ch
swinog mailing list --swinog@lists.swinog.ch To unsubscribe send an email toswinog-leave@lists.swinog.ch
This particular MTU issue on sbb.ch has been there for many years.
I wonder if anyone from sbb can make a statement on how it is possible NOT to fix this within all that time.
Folks at SBB must have been aware of this, as it's not the first time reported publicly.
Cheers,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
I’ll have a look with my colleagues and keep you posted. Sorry for the inconvenience, but the teams may be still in kindergarten about IPv6. I’m actually unsure, where the different parts of the sites are running because everybody merges their systems around.
Regards, Urs
Von: Nico Schottelius via swinog swinog@lists.swinog.ch Datum: Montag, 23. März 2026 um 11:29 An: Andreas Fink via swinog swinog@lists.swinog.ch Betreff: [swinog] Re: sbb.ch unresponsive on IPv6 for HTTP(S)
This particular MTU issue on sbb.ch has been there for many years.
I wonder if anyone from sbb can make a statement on how it is possible NOT to fix this within all that time.
Folks at SBB must have been aware of this, as it's not the first time reported publicly.
Cheers,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch _______________________________________________ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch
Hey Urs,
feedback much appreciated. I guess you are very much aware that there are a few IPv6 enthuisiasts on the list, so if you need any help in fixing this so-many-years-open-issue including debugging from outside, do not hesitate to give a shout.
Everyone will be happier if they can actually find a train from an IPv6 only network with non-1.5k MTU.
Cheers,
Nico
-- Sustainable and modern Infrastructures by ungleich.ch
-
Andreas Fink -
Beni Keller -
Gert Doering -
Jeroen Massar -
Lukas Tribus -
Mat Kowalski -
Mueller Urs SBB CFF FFS -
Nico Schottelius