IPSEC over DSL MTU problems

[davidbuit]

I have an IPSEC between a pix 506 and an ASA5510. The tunnel is over DSL links and there is a problem with traffic not going through correctly. Initially I was trying to get a server remotely to join the domain across the VPN but this was timing out. I adjusted the MTU on the outside interfaces of the firewall to 1360 so that the IPSEC SA would negotiate 1360 MTU and this then enabled the server to join the domain but I am still experiencing problems where traffic appears to be dropping or packets getting stripped. I have tried to implement Exindas between the two sites to accelerate the traffic but initially these couldn't even talk to each other until I modified the MTU as above. The PIX 506 terminate the DSL line using PPPoE and at the remote site there is an 877 that terminates the line and then connects to the ASA.

I have also tried to use DES as apposed to AES but this has not effect.

Any ideas or thought most appreciated!

[davidbuit]

Further to this, I have tried to use ip tcp adjust-mss on the VLAN interface on the 877 but as this is after the tunnel it has no effect.

Thanks

[madun]

Hi David,

I am getting similar issues, when connecting an 878 to a Cisco 515E. Very poor performance, if any on certain applications.

Do you know what your mtu is ?

[davidbuit]

I have tried almost all MTU sizes between 1360 and 1460. If you do a 'show crypto ipsec sa' on the 515 it will tell you what MTU has been negotiated but this still isn't 100% correct. I found that I get best results at 1360 but I haven't been able to get all the traffic to work correctly. I am trying to get traffic acceleration to work using exindas but the traffic goes out with the added EXTUN header in the TCP packet but when it reaches the other side, the header disapears. This to me indicates that some data is getting lost. There are also a lot of nop,nops in the packets indicating that they have been padded out.

I started by doing pings and incremented the packet size. I noticed that as soon as I got to 1360 or 1370 I didn't get a response. That is why I tried an MTU of 1360. After setting the MTU to 1360 I was able to ping with any size packet.

I hope this helps.... but I have al but given up trying to get the Exindas to work across this link.

[mitchell.smith]

Hello, try reading this, it may help your problem, it has worked for me in the past:

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

[pruhnke79]

I would recommend against clearing the DF bits if at all possible. This along with setting the outside interfaces MTU down will only add more unnecessary load to all devices involved. Changing interface MTUs will also present problems with other traffic going though this interface as this change affects ALL traffic going though it, not a desirable situation. However if this is ADSL running PPPoE adjusting the MTU down to 1492 (8 bytes for PPPoE Header) would be appropriate if the PIX/ASA is not running the PPPoE service.

I have not had hands on time with a ASA device but I have significant experience with the PIX 500 line. If you are only hosting one tunnel an easy fix might be to use MSS adjustment on your tunnel using the sysopt command below. This will adjust all TCP sessions going though the tunnel to your defined MSS, which will prevent the need to clear the DF bit and cause unnecessary fragmentation.

http://www.cisco.com/en/US/customer/products/ps6120/products_command_reference_chapter09186a008063f101.html#wp1198279

However if you host more than one tunnel or have a large amount of UDP traffic coming across the tunnel I would suggest the following white paper. This suggests using GRE encapsulation before IPSEC encapsulation. This will allow you to deal with MSS adjustment and lowered tunnel MTU (for UDP traffic) on a per tunnel basis.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml