mjhjmtu

On a Debian server with nginx, I get no response from a web server over HTTPS and IPv6. HTTP works fine.

• netstat reports port 443 listening on IPv6 address


• firewall is opened, ipv6scanner.com reports port 443 open


• locally (over terminal) wget and curl receives a correct response, so nginx configuration is OK


• no sign of error from nginx error.log


• no record in access.log, when it fails, so the communication probably does not reach the web server


• DNS is fine. Translation works, and the connection does not work even when the IP address is accessed directly

Every attempt to connect from "outside" (meaning outside of the network, from the internet) fails (web browser, telnet, ipv6-test.com, curl...). There is no response at all.

Can be tested on www.ekasparova.eu . I am clueless. What else can I check?

edit:

the output of traceroute6 --mtu www.google.com is following:

traceroute to www.google.com (2a00:1450:4014:800::2004), 30 hops max, 65000 byte packets
1 * F=1500 * *
2 * * *
~
30 * * *

So it never reaches the end...

You have an MTU problem.

I tested wget -O /dev/null https://www.ekasparova.eu while observing the traffic with tcpdump. This is what I saw:

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 2857:3678], length 0

The first 3 packets is the handshake. Both ends announce mss 1440 which means they are capable of receiving packets with 1440 bytes of TCP payload, counting headers as well it totals to 1500 bytes of IP traffic, which is what Ethernet commonly supports.

The next 2 packets is client hello and acknowledgement it was received by the server.

The final 2 packets is where things get interesting. By default tcpdump shows relative sequence numbers, which in this case make the capture easier to read. In the packet from the server this is the interesting part seq 2857:3678. We see a jump from 1 to 2857 which means there is a gap of 2856 bytes which the client did not yet receive. 2856 bytes corresponds to two packets of 1428 bytes. The difference between 1440 and 1428 is the size of a timestamp option.

So, the server sent the server hello split across 3 packets. But the first two were too large for the network and were not delivered to the client.

In the final packet from client to server we see this sack 1 2857:3678. This is a selective acknowledgement sent by the client informing the server that there is a gap in the data it has received this far.

Likely the server keeps sending the two lost packets over and over again. But no matter how many times it retransmits the same two packets they remain too large for the network. And probably a router on the path sends an error message back to the server informing it the packets are too large and need to be retransmitted in smaller packets.

If the server received those error messages, it would retransmit the packets smaller as needed. And it would remember the smaller PMTU such that on subsequent requests it does not have to repeat this discovery step.

A possible explanation for all of this is that you have a misconfigured firewall which drops all of the error messages informing your server it needs to retransmit the data in smaller packets.