3DES ENcryption works fine (2600-to-2600 AH-ESP Private share key), on say small telnet key strokes -ping;
But, the encryption fails to display large Telnet directory, or large data transfer. The screen just hangs.
Any ideas ... Is it do with packets fragments ?
or transport - tunnel mode setting
How about too minimal memory or cpu utilisation to high? Of course Encryption uses some performance and might be have poor performance if the router is to busy.
C2611XM-2FE/VPN/K9 Cisco 2611XM/VPN bundle, AIM-VPN/BPII/2FE/IOS FW/IPSec 3DES, = 128 MB DRAM
In my experience symptoms where applications with typically small packets like telnet work ok but applications with typcially large packets like file transfers hang are most often reflect problems with packet fragmentation.
Adding the headers for IPSec increases the packet size and increases the chances that some segment of the network will need to fragment the packet. If the packet has the Dont Fragment bit set then the application appears to hang.
Path MTU Discovery is designed to help prevent this problem. But in many networks it does not work properly - especially because someone along the data path is filtering out the ICMP responses that are necessary to make Path MTU Discovery work.
At a customer site where we encountered this issue we added the ip tcp adjust-mss command and it worked much better for us.
This command has helped me in situations similar to the one you are describing:
crypto ipsec df-bit clear
After enabling this on both sides of the IOS VPN Tunnels, large packets were no longer dropped, but properly fragmented, allowing applications that pass data in full packets to work.
Hope this helps,
I don't know if your routers are encrypting over their ethernet interface, in which case the default mtu for you is 1500.
use the "show crypto ipsec sa " command to see your mtu size with the endpoint.
Over the Internet connection, mtu size of 1500 is too high. Therefore you should reduce this on each router.
ip mtu 1452
! most common value but you can go bellow
ip tcp adjust-mss 1300
! start from here and increase up to the mtu size
I recently read somewhere on cisco.com that the IP TCP ADJUST-MSS command only works when NAT is enabled.
I've used the feature to resolve MTU issues, but that solution also required NAT, at the time I wasnt aware that the MTU adjustment feature would only work with NAT.
Did this feature resolve the problem and if so were you using NAT?
I can say from live experience that ip tcp adjust-mss does work in situations that do not involve NAT. I have a customer with a fairly large deployment of IPSec VPN (currently almost 80 remote sites connected to redundant head end routers). We do not do NAT and we do use ip tcp adjust-mss and it works quite well for us.
Could you tell me which IOS version is in use, I have a problem to fix that needs the MSS adjust feature without NAT running on the (837) router.
I enabled it but it didnt work as expected. So I read up some more on Cisco.com, which is where I found the information regarding NAT.
These are 1720 & 1721 running 12.3(4)T1. Works great for us.
Can you tell me how you applied it and what behavior you saw?
I looked at this again, after a recent customer problem. A network I'm building uses GRE over ADSL links, at one site the customer reported an email problem. The user could see email headers but was unable to open up the emails when the traffic traversed the GRE link.
After some digging he then told me that users at another site can open up the email from the same server. The router configuration is the same, using the command IP TCP ADJUST-MSS 1420 on the GRE tunnel interface.
Checking IOS versions, 12-2-11.T11 the command appears to work ok, in 12-3-8.T4 it dosent. So I'm in the process of copying IOS from the working router.
I tested the command on IOS 12.2.15.T14 running on kit in my security practice lab, it works fine for TCP sessions traversing the router, without NAT applied.
So it looks like this may be an IOS issue after all, when the customer lets me reload it I can confirm or deny this thinking.
Whilst testing this in my lab I noticed that a telnet session to a loopback address always returns a TCP MSS of 536, I'm looking at this in more detail.