MTU Problem with Ipsec Tunnel

[sema-atos]

hello,

I have a customer who finds random problems to be connected, through VPN IPSEC, to a remote web server. Below you can find router's log:

.Sep 8 12:24:52: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip->tl=1443, mtu=1384

.Sep 8 12:24:52: ICMP: dst (x.x.x.x) frag. needed and DF set unreachable sent to x.x.x.x

There is NAT overload with FastEth ip address. I think that the problem is MTU negotiation. ICMP unreachable is active on ours routers and firewalls and PMTUD is running on web server.

I have read http://www.cisco.com/en/US/tech/tk827/tk36...0d6979.shtml#t5

The situation is that one described in "scenario 8".

Can you help me?

Thanks

[hadbihas]

Try to set the tcp adjust-mss as well. I would change/add the following to the FastEth interface:

ip mtu 1435

ip tcp adjust-mss 1340

Let us know if it works,

Ihab

[hadbihas]

That should go on the remote side.

[sema-atos]

Hi,

I have added the parameters to the port but the result is not changed:

.Sep 13 14:53:24: ICMP: echo reply sent, src x.x.x.x, dst x.x.x.x

.Sep 13 14:53:24: CRYPTO_ENGINE: locally-sourced pkt w/DF bit set is too big,ip-

>tl=1443, mtu=1326

What do you think?

Thanks

[hadbihas]

In my case, the core has "Do not fragment prior to IPSec encapsulation; fragment prior to interface transmission" is set. The same can be done using IOS.

The remote side (client side), my above suggestion for the MTU and MSS should resolve the problem, however you'll have to keep trying by lowering the MTU and MSS values. Refer to this link:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00804247fc.html

Another good way to find out the necessary MTU size is by installing "Dr. TCP" on the remote machine and keep changing the MTU size on the same machine while failing to access the web server until you find out what size works ok.. then you set it on the router (and maybe use the above document to factor in the MSS size).

[fisko]

I have the same problem ...our provider using Layer 3 switch that is directly attached to our VPN equipment ....so wher provider put ip mtu on switch interface we solve the problem

[volkov]

Did you try

ip tcp adjust-mss

option?

[smith.jonathan]

I've had the same issue with our HQ VPN to foreign office, with the HQ VPN DF flag set like you described. If the web server is MS IIS try appling MS black hole detect reg edit. This resolved our issue.

[zubairjalal]

What is your VPN terminating device.

This is a fragmentation problem. The DF (Dont Fragment) bit is set to a high value. In cisco PIX, it is set by default to 24. i.e an interface with DF bit on will allow up to 24 fragmented packets.

Just check the output of

show fragment

You can disable fragmentation on any interace in pix by

fragment chain 1 outside(or inside)