1

I'm running Vyattagateway with a CentOS Linux behind, and IPSec tunnel in front.

Trying to display my setup:

PARTNER-NETWORK <--- IPSec (GRE, MTU 1420) ---> VYATTA (TUNNEL, MTU 1420 <> eth0, MTU 1500) <---> CentOS (eth0, MTU 1500) <---> internet (eth0, MTU 1500)

I see a lot TCP retransmissions, dublicates etc. and I guess it's because of different MTU/MSS - it's hard to debug :(

I've tried to add the folloing on my CentOS:

iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

But that doesn't seem to solve the problem.

How can I debug where the problem is exactly, and any idea on how to solve the issues?

Alfred Balle
  • 399
  • 2
  • 6
  • 22

1 Answers1

1

Are you sure you're allowing ICMP type 3 code 4 (i.e. Fragmentation Needed) messages from your gateway to both endpoints? And are the endpoints actually receiving them?

Since Windows 95, practically all operating systems have been using Path MTU Discovery. In practice, that means they will send all their TCP packets with the Don't Fragment flag set. If the packet turns out to be larger than the MTU of some hop in the packet's route, the router encountering the problem is supposed to send an ICMP message "Fragmentation Needed" back to the sender. From that message, the sender will know the exact MTU on that hop and will know to resize the packets accordingly. As a result, the endpoints will end up sizing their packets so that no router will need to fragment them at all. This improves performance.

But if someone is blocking the "Fragmentation Needed" ICMP messages, the Path MTU Discovery mechanism won't work. Since the recipient never gets the packet that was bigger than the MTU of a particular hop on the packet's route, the recipient never acknowledges it. Once the sender sees that a packet was not acknowledged, it will resend that packet - and since it has no clue that the MTU should be reduced for this particular connection, it will resend the packet exactly as it was: with the same MTU that was too large for one hop. So resending won't help in this case.

telcoM
  • 4,153
  • 12
  • 23