Mixing
NGINX SSL does not respond over IPv6
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
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...
nginx ssl ipv6
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
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...
nginx ssl ipv6
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
1
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output ofip6table-savewould be relevant.
– kasperd
4 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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...
nginx ssl ipv6
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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...
nginx ssl ipv6
nginx ssl ipv6
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 12 mins ago
asked 1 hour ago
j.kaspar
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
j.kaspar
1115
asked 1 hour ago
j.kaspar
1115
1115
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
j.kaspar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
1
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output ofip6table-savewould be relevant.
– kasperd
4 mins ago
add a comment |Â
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
1
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output ofip6table-savewould be relevant.
– kasperd
4 mins ago
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
1
1
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output of
ip6table-save would be relevant.– kasperd
4 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output of
ip6table-save would be relevant.– kasperd
4 mins ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
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.
answered 1 hour ago
kasperd
25k104996
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, trytraceroute6 --mtu www.google.comand look forF=####inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.
– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
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.
answered 1 hour ago
kasperd
25k104996
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, trytraceroute6 --mtu www.google.comand look forF=####inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.
– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
 |Â
show 1 more comment
up vote
3
down vote
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.
answered 1 hour ago
kasperd
25k104996
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, trytraceroute6 --mtu www.google.comand look forF=####inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.
– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
 |Â
show 1 more comment
up vote
3
down vote
up vote
3
down vote
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.
answered 1 hour ago
kasperd
25k104996
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.
answered 1 hour ago
kasperd
25k104996
edited 26 mins ago
answered 1 hour ago
kasperd
25k104996
answered 1 hour ago
kasperd
25k104996
answered 1 hour ago
kasperd
25k104996
25k104996
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, trytraceroute6 --mtu www.google.comand look forF=####inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.
– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
 |Â
show 1 more comment
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, trytraceroute6 --mtu www.google.comand look forF=####inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.
– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
1
1
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
Interesting. Thank you! Those error messages - I guess it is ICMP protocol... Is there a way to test it? The firewall on the server, and the firewall between the server and the internet, should be open for all ICMP communication.
– j.kaspar
53 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@j.kaspar What are the firewalls? How are they configured? How did you test them?
– Michael Hampton♦
47 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@MichaelHampton there is iptables firewall installed directly on the server. The second one belongs to the datacenter and I am able to manage it's rules. I don't really know how to test the ICMP. But the rules on both are set to anywhere<->anywhere allowed for ICMP
– j.kaspar
42 mins ago
@j.kaspar On a Linux server, try
traceroute6 --mtu www.google.com and look for F=#### inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.– Michael Hampton♦
32 mins ago
@j.kaspar On a Linux server, try
traceroute6 --mtu www.google.com and look for F=#### inserted into the output lines, or output lines where no response comes back at all. On second thought, just run it and edit your question with the output.– Michael Hampton♦
32 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
@MichaelHampton Done. However I am not sure how to interpret the result. Does that mean, that the communication doesn't pass the second hop at all?
– j.kaspar
8 mins ago
 |Â
show 1 more comment
j.kaspar is a new contributor. Be nice, and check out our Code of Conduct.
j.kaspar is a new contributor. Be nice, and check out our Code of Conduct.
j.kaspar is a new contributor. Be nice, and check out our Code of Conduct.
j.kaspar is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f935802%2fnginx-ssl-does-not-respond-over-ipv6%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Outside = Outside the network on a seperate LAN segment, or from a computer sitting on the same LAN segment?
– IceMage
15 mins ago
1
@IceMage Outside means from the internet. Outside of the network. I am going to edit the question to clarify
– j.kaspar
13 mins ago
Have you configured a firewall on the server? If the server is running Linux, then the output of
ip6table-savewould be relevant.– kasperd
4 mins ago