LAN-to-LAN VPN Tunnel Fragmentation Issue

Unanswered Question
Aug 3rd, 2007

I have a LAN-to-LAN vpn tunnel issue. Basically this connection has been working fun up until last Sunday evening. Monday morning rolls around and the site is no longer able to send any packets larger than 538 bytes (payload).

None of my other sites beyond this one have any issues with the same config attached. The site is connected via an Ambit cable modem from Time Warner (business class service).

TW of course claims there is nothing wrong with the service. I have replaced the hardware at the site, and even reconfigured the original hardware to test the tunnel here via DSL and it works fine without issue.

So, ICMP works fine until you tell it to send something larger. Services such as RDP do not work at all.

It appears to be a fragmentation issue. Suggestions on where to start? DF bit is set to clear, MTU and MSS sizes have been adjusted. Config for device is attached.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
hadbou Thu, 08/09/2007 - 10:15

In order to encrypt a packet, it would need to create a new packet with all of the header information, the ipsec hash, and the ESP or AH information. Normally this averages out to be 56 bytes of the 1500 total size, making the maximum MSS at least 1444. I think On TCP packets there is a packet header called Don't Fragment. When this attribute is set, the packet can not be fragmented from its original size. So when a router, or some firewalls sees this set, the packet can not be adjusted.

rselmecz Fri, 08/10/2007 - 22:45

Hi,

Do I understand well that if you send bigger ICMP packets through the tunnel, those are dropped as well?

If it is true it looks like this is a pure

fragmentation issue.

In this case there is nothing to do with MSS and

"df-bit clear".

Only fine tuning the "fragmentation" could help.

Can you please check the output of:

show ip traffic

and look for the fragmentation part to see are there any errors, or not ( enter command 2, or 3 times during problematic traffic )

Also you may try to enter the following command in global configuration mode:

crypto ipsec fragmentation after-encryption.

Check this doc as well:

http://www.cisco.com/warp/public/105/pmtud_ipfrag.html

Probably the ISP started to drop ICMP ?

HTH

// Roland

Actions

This Discussion