ASA 5500 VPN Slowness Issue

[castillom]

We have two 5540 and one 5510 in production. Clients are complaining that they can not copy large files from the local workstation to a server through the vpn. We're using the SSL VPN Client and I have Datagram Transport Layer Security (DTLS)enabled. I also downloaded the Anyconnect client (anyconnect-win-2.1.0148-pre-deploy-k9.msi) and tried that with no luck. Downloading a 54MB file failed after about 40 minutes. Are there any other optimization features I should be looking at?

Thanks,

Maria Castillo

[castillom]

Recent activity has included upgrading to 8.0(3). I also have some of my more heavier clients using the Anyconnect client. My next step will be to change the Sysopt connection tcpmss setting from 1380 to 1300. The upgrade + anyconnect was to address a disconnect issue. The tcpmss is specifically for the large file transfer issue.

[chris.russell]

Thanks castillom.

Our issue is similar but not the same.

We're running 8.0(3) and latest AnyConnect build. We're basically seeing horrendous latency (anywhere up to 4 seconds on ping) on the client VPN sessions which are a direct result of the upgrade to v8/anyconnect. The customer was using v7/SSLClient without issue for over a year however required Vista support for the SSL clients.

I've tried disabling dtls on the outside interface so I`ll pass back any findings.

Thanks for your reply.

[kellerja1]

After isolating everything to a server directly off the ASA's I've been unable to replicate the issue for DLS/Cable modem connected testing. DTLS is showing about a 10% improvement for KB/s transfer tests over TLS.

The original testing was done on a sprint blackberry tethered connection, which may end up being an MTU related issue. Going to try and do some more testing from the blackberry connection to test for max MTU size across sprint.

We also have cisco WAAS/WAEs on the network, so we may have been getting tcp optimization of the TLS sessions from the test systems to the datacenter ASAs. We ran into an issue shortly after my initial problem reports where the WAEs at the testing site where overloading as well and may have caused issues, where the UDP traffic was likely not being optimized based on our configs.