Troubleshooting vpn slowness and packet retransmits could be a puzzling task, especially when it’s over an IPsec tunnel.
Last week I had the opportunity to troubleshoot a problem with slow website loading times on a webserver across the link. It was difficult to troubleshoot as the site would appear intermittently and was slow to load. A ping or a telnet to the server on the side returned packets swiftly without any issues. I verified that the tunnel was up and was transmitting without any problems. Where could the problem be?
With a simple wireshark capture I found out that retransmissions were occuring very frequently. This was when I found out the packets were fragmented quite a bit and realized that the VPN concentrator had been set with a very small MTU. This was nasty, as it had almost been intentionally tampered with to create an effect of slowness. Such transmission slowness is extremely difficult to troubleshoot as there was no issue with the connectivity itself.
The rule for setting MTU is that the largest value that does not result in the error “Packet needs to be fragmented, but DF set,” is your ISP’s MTU less 28 bytes. This excludes the IP (20 bytes) and ICMP (8 bytes) headers.
Here’s a link with a detailed explanation on how MTU affects performance.
Update: August 14 2015 – Another look at VPN slowness and Maximum Segment Size (MSS)
I ran into this issue once more and wanted to document the problem and steps to resolution.
Problem & Symptoms: A web portal behind a VPN tunnel was loading very slowly. The browser takes an abnormally long time to render anything. Often times the page was unresponsive (ERR_CONNECTION_RESET) and taking upwards of 120+ seconds to load. HTTP latency and responses were extremely slow (20-30+) seconds.
Approaching the Solution: ICMP packet analysis using pings of various fixed sizes pin pointed the maximum packet size that can be sent without fragmentation
ping -f -l [packetsize] [www.cisco.com]
The optimal packet size was found to be 1300 bytes. This can be further confirmed by modifying the MTU of the network adapter on the client OS. In windows this was the command that was run.
netsh interface ipv4 set subinterface “Local Area Connection” mtu=1300 store=persistent
Long term solution: Since modifying the adapter only fixes the problem for one machine. A better long term fix is to utilize a feature called “MSS Clamping” which is performed on the the VPN termination device.
On the Cisco ASA this is under Configuration/Firewall/Advanced/TCP Options/Edit Interface.
After the changes were done, the browser load times were significantly faster. This change will be immediately noticeable.
Here’s another post on Cisco describing the problem that occurs.