ASA 5500 VPN Slowness Issue

Unanswered Question
Dec 11th, 2007

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
ccbootcamp Tue, 12/11/2007 - 20:56

What types of pipes do you have for access on your 5500s? What version of code on the asas?What type of pipes are your clients using to connect? How many VPN sessions? I would try to have them download a large file not using the VPN, just straight from something behind the 5500s (like a webserver or ftp server).

Also, an after thought, have you tried the Cisco VPN client?

-brad

http://www.ccbootcamp.com

(please rate the post if this helps!)

castillom Wed, 12/12/2007 - 08:13

What types of pipes do you have for access on your 5500s? DS3 Pipe

What version of code on the asas?

ASA 8.0(2)

ASDM 6.0(2)

What type of pipes are your clients using to connect?

clients can be coming from cable modem speeds to dialup to air cards. My test was using the air card at about 500-800 Kbps upload and 600-1400 Kbps download speeds. It should have taken about 15 minutes (worst case) to upload the 55MB file to the server.

How many VPN sessions?

Total Cumulative =

5510 - 474

5540 - 399

5540 - 1475

I would try to have them download a large file not using the VPN, just straight from something behind the 5500s (like a webserver or ftp server).

Downloading from within the network works fine. No issues there. The problem is with my VPN users. I did try the client with no luck.

-Maria

ccbootcamp Wed, 12/12/2007 - 09:23

Yes, try to have them download the file w/out the VPN/IPSEC tunnel into the ASA. You also need to take a VERY strong look at your ASA CPU utilization and your bandwidth utilization - especially with that many users. What types of utilization are you seeing?

-brad

www.ccbootcamp.com

(please rate the post if this helps!)

castillom Wed, 12/12/2007 - 09:37

I'm not sure what you mean without the VPN tunnel. BTW:No IPSEC in use. Go through the VPN directly? It's not setup to allow that. Now from behind the vpn, isn't that inside the network? Unclear what you mean.

Total cumulative is not representative of what the actual numbers are. We have about 20 users at most at the same time. CPU and bandwidth is not an issue. CPU >20% Input/Output kbps 114/88

-Maria

ccbootcamp Wed, 12/12/2007 - 10:02

What you are telling me isnt making sense. 20 concurrent users only doing 114/88 kbps?!?! When you initiate the large transfer, what is the CPU and bandwidth?

Do you have a webserver or FTP server behind one of the ASAs? If so, stick a large file on there, and try the same test w/out using a VPN.

-brad

www.ccbootcamp.com

(please rate the post if this helps!)

acomiskey Wed, 12/12/2007 - 09:23

Could be an mss problem. Are you receiving something like this following log when downloading large files.

Dropping TCP packet from xxxx to xxxx, reason: MSS exceeded, MSS 1380, data 1432

castillom Wed, 12/12/2007 - 10:05

Actually getting a file too deep error. User also stated that he was getting dropped pings while trying to download his 91MB file. The error was also file too deep.

castillom Wed, 12/12/2007 - 10:23

Based on your comments, it appears that you are talking about adjusting the MTU on the vpn. The link below references some ping tests to determine if the traffic requires framentation. I will go off and do some testing. Any comments on MTU on a vpn would be helpful? I've done it on crypto tunnels router-to-router, but not on a vpn.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008081e621.shtml

Thanks,

Maria

kellerja1 Fri, 12/14/2007 - 12:16

I am getting the same problem on a pair of 8.0(3) boxes we are getting ready to deploy as a replacement for a single Checkpoint Connectra box.

I enabled DTLS at the start of the test phase and users where reporting it was taking 2 to 3 times as long to transfer files when connected to the test cluster then over the existing SSL vpn.

For example, a 4.88mb PDF took at most 278 seconds to transfer from a sprint tethered blackberry connection on the existing Checkpoint 3DES TLS connection.

With 3DES DTLS enabled the same download would average to around 11 minutes (660s).

With just 3DES TLS the transfer through the AnyConnect connection took an average of 225 seconds.

With debugging on for everything, I'm not seeing MSS errors for the DTLS connection.

I'm wondering just how much the compression for the TLS connection helps for file transfers on the Connectra and ASA vs the DTLS session with less latency, but no compression.

Getting ready to put in a TAC ticket on it after I finish doing some time tests.

castillom Fri, 12/14/2007 - 15:32

That is very interesting information. I too have opened a TAC case on this issue. I will share my results and I am curious what you find as well. It seems that Datagram Transport Layer Security (DTLS) may be causing problems rather than preventing latency and bandwidth issues.

kellerja1 Fri, 02/22/2008 - 02:46

We still have a TAC ticket open, because I don't have a test ASA right now. TAC wants to set up a test with an ASA on our network so they can log in and run tests themselves.

castillom Fri, 02/22/2008 - 07:55

I also still have my TAC case open. I am getting ready to upgrade to high priority so that it gets more attention.

castillom Fri, 03/07/2008 - 08:14

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@k... Fri, 03/07/2008 - 08:20

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 Fri, 03/07/2008 - 08:31

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.

Actions

Login or Register to take actions

This Discussion

Posted December 11, 2007 at 1:01 PM
Stats:
Replies:17 Avg. Rating:
Views:590 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard