I have a 100mbps ethernet internet connection connected to a ASA5510. My Cisco VPN Clients complain about very poor performance. I get great speed test speeds. MTU on the ASA is set to 1500. I have the "crypto ipsec df-bit clear-df outside" command enabled also. I cannot get more than 3mbps up when copying files to my house. Tried from multiple internet connections and have the same problem. Any ideas?
Coincidentally, If anything that command (clear DF) is going to lower your performance and allow fragmented packets through VPN.
It think it's time to do some sniffer traces and see where the problem is coming from (fragmentation, latancy, packet loss, serialization etc etc), it would be also great to establish a baseline (i.e. expectations, or ideal scenario) of performance.
Actually that command and lowering the tcpmss to 1300 has helped significatly. I just copied a file from HQ to my Home PC and I was getting 20mbps where before I would only get 2 or 3 mbps.
Where do you want the traces from? A machine with the VPN Client, copying data?
Lowering MSS helped. Clearing DF-bit just makes it possible to fragment data, which is a perofmance killer, lowering MSS made sure that fragmentaion is not occuring for TCP. :-)
You should try a capture on client and at least inside of the ASA. Compare the two, make sure you have times synced on ASA and the client.
Hello William and Marcin,
I totally agree with Marcing, disabling Path MTU is a killer QoS mechanism so make sure you have configure the NO cleareance of the DF bit on the IP header.
Now to add something to the discussion On the capture shown (I guess it was capture on the VPN client, you did not say which IP is the source) but there is definetly sub-optimal performance on the network.
Check the amount of TCP Retransmit packets shown on the capture (606 retransmissions to be exact).
Are retransmissions one way only or both ways?
Rate all of the helpful posts!!!
Follow me on http://laguiadelnetworking.com
To add more, we're talking about SMB traffic here, probably the worst idea for measuring performance.
That's where baseline comes in .... get iperf, single flow TCP, and single flow UDP (1300 bytes) test, test both inbound and boutbound, let's have establish some baseline.
In case of any performance problems we need to see what are the numbers we should be comparing the problematic numbers to.
As Julio pointed out there were quite a few retransmits in the case of packet capture you provided, it impacted the window size among other things.
Which seems to be indicating packet loss ... somewhere ... :-)
At least at this stage we know it does not look like a fragmentation problem.
What we need in any case is a comparison for single from TCP (because that's what you've been indicating as problem, at least so far) on both ends of test for both test and baseline.
I would also add single from UDP as a good test.
My suggestion was to use iperf to establish some baseline since it does not have any control plane overhead (unlike SMB).
Once you have those it's time to get your wireshark out and strat narrowing down where the problem is and what's exactly causing it.
A small tip, try using a service/server in same L2 domain as inside interface of ASA to narrow down the problem.
I would also suggest connecting your test client outside of ASA (as few L3 hops away as possible, posisbly in same L3 as your outside interface) to establish the best-possible scenario/baseline.
What I would do I to have TAC provide you with some guidance and analysis, especially if/when it might come to understastanding/decoding TLS/DTLS.
Is your ISP Cogent? We have narrowed our problems down to our ISP Cogent admitting they have very high congestion at some of their peering points around the net. I have a data center about 10 miles away running on Above.NET for Internet and I can copy files at 95mbps over the VPN, but from my home Comcast connection (which Cogent admitted to having peering issues with) I get HORRIBLE sub 1mpbs speeds.