I have an SSL connection to a server (owner-api.teslamotors.com) that hangs with wget, curl or openssl s_client. I am showing the curl version as it gives the most debug messages:
# curl -iv https://owner-api.teslamotors.com
* Trying 18.203.70.200:443...
* Connected to owner-api.teslamotors.com (18.203.70.200) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
There it hangs after ClientHello. TCP connection establishes successfully (also confirmed with telnet/nc). Other network connection including any SSL connection I have tried works. Except owner-api.teslamotors.com:443.
I found this posting talking about MTU and it sounded far fetched. But I reduced the server MTU and it worked! It works with any MTU <= 1420.
The server connects using Ethernet (MTU 1500) to a Mikrotik router and from there the connection goes through a WireGuard tunnel (MTU 1420). I am aware that this may not be optimal as any IP packet from the server >1420 will need to be fragmented. However, this is agnostic of any L4 protocol. SSL over TCP should not care about fragmentation and MTU. Yet, this host does.
I ran a packet capture on the Mikrotik box and the traffic does not list anything abnormal to me:
The typical TCP handshake Num 1-3, then ClientHello (Num 4-5) and ServerHello (Num 6-7). No packet size comes close to the MTU and no other ICMP messages that would indicate issues with fragmentation etc.
Per comment, here is the tracepath output:
# tracepath owner-api.teslamotors.com
1?: [LOCALHOST] pmtu 1500
1: XX.XX.56.210 0.410ms
1: XX.XX.56.210 0.198ms
2: XX.XX.56.210 0.138ms pmtu 1420
2: XX.XX.56.185 151.394ms
3: no reply
4: 100.100.200.1 157.220ms
5: 10.75.0.193 154.068ms
6: 10.75.2.53 161.950ms asymm 7
7: decix1.amazon.com 152.107ms asymm 8
8: decix2.amazon.com 153.068ms
9: no reply
[...]
I am really lost what the heck is going on here.
Why does this one SSL connection fail?