cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2985
Views
0
Helpful
12
Replies

PIX515e VPN - Client Packet Loss

Mike Bailey
Level 1
Level 1

Hi,

Don't tend to use Cisco VPN but have setup one for a development environment.

This is on a PIX515E running 8.0(4), relevant sections of configuration below:

aaa-server vpn protocol radius

aaa-server vpn (inside-inf) host RADIUS

key *

!

crypto ipsectransform-set my-set esp-3des esp-sha-hmac

crypto ipsecsecurity-association lifetime seconds 28800

crypto ipsecsecurity-association lifetime kilobytes 4608000

crypto dynamic-map dynmap10 set transform-set my-set

crypto dynamic-map dynmap10 set security-association lifetime seconds 28800

crypto dynamic-map dynmap10 set security-association lifetime kilobytes 4608000

crypto map mymap 10 ipsec-isakmp dynamic dynmap

crypto map mymapinterface outside

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

crypto isakmp policy 65535

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

no crypto isakmp nat-traversal

ssl encryption des-sha1 rc4-md5

group-policy dev-vpn internal

group-policy dev-vpn attributes

dns-server value 192.168.1.1

vpn-filter value 102

default-domain value dev.net

tunnel-group DefaultRAGroupgeneral-attributes

authentication-server-group (outside) vpn

tunnel-group dev-vpn type remote-access

tunnel-group dev-vpn general-attributes

address-pool dev-vpn-pool

authentication-server-group vpn

default-group-policy dev-vpn

tunnel-group dev-vpn ipsec-attributes

pre-shared-key *

!

Clients are using a mixture of 4.8 and 5.0 clients and connect successfully but packet loss is seemingly high, pings are sporadic as per attached.

There are no speed/duplex issues on the infrastructure, all switch and firewall ports are error free.

Have been looking at other reports of issues and MTU seems to be discussed but not sure why users should need to be changing MTU to make a simple VPN work.


Any thoughts on the issue?

Thanks

1 Accepted Solution

Accepted Solutions

Hey Glad to hear that you got it working

And yeah those typos happen all the times, the worst part is that you struggle looking everywhere and everything else, reading docs and googling and when you realize what was wrong you just want to bang your head against the keyboard.

Have fun!!!

PS: Please remember to mark this question as answered.

View solution in original post

12 Replies 12

raga.fusionet
Level 4
Level 4

Mike, why do you have NAT-T disabled?

no crypto isakmp nat-traversal

What happens when you enable it? This helps the clients from behind NAT to pass traffic.

Thanks.

Also, what's on ACL 102 and what is your IP Pool and NAT 0 ACL?

Hmm interesting point on the "no crypto isakmp nat-traversal" thats not in my base config so must have been default in the PIX.

Have enabled and things look a little more stable from my test client, but then they have been more stable in the last hour or so anyhow!

ACL, IP Pool and NAT 0 detail below:

access-list 101 extended permit ip 192.168.1.0 255.255.255.0 dev-vpn-pool 255.255.255.0

access-list 102 extended permit udp dev-vpn-pool 255.255.255.0 192.168.1.0 255.255.255.0 eq domain

access-list 102 extended permit tcp dev-vpn-pool 255.255.255.0 192.168.1.0 255.255.255.0 eq ftp

access-list 102 extended permit tcp dev-vpn-pool 255.255.255.0 192.168.1.0 255.255.255.0 eq www

access-list 102 extended permit tcp dev-vpn-pool 255.255.255.0 192.168.1.0 255.255.255.0 eq 3389

access-list 102 extended permit icmp dev-vpn-pool 255.255.255.0 192.168.1.0 255.255.255.0

!

ip local pool dev-vpn-pool 192.168.10.1-192.168.10.62

!

global (outside) 1 interface

nat (inside-inf) 0 access-list 101

nat (inside-inf) 1 0.0.0.0 0.0.0.0

Ride on

Lets hope it stays stable then .

I can remember what the default is for NAT-T.

Nope back to being a pain again.

Just had an hour or so where pings were consistently less than 300ms with few drops.

Now its back to 2000+ms round trip time with packets being dropped all the time

Obviously this could be just network conditions (bandwidth/utilisation of the internet link the VPN is hanging off) but I can't imagine there will be much going on at the moment (nearly midnight in UK)........

Ok then, from a VPN client connected to the ASA start a continuos ping to host on the inside. From another host (hopefully from the same network as the first one, or same Internet connection) start a ping to the outside interface of the ASA.  (you could this from the same host but you would need to enable split tunneling for the VPN client).

If both pings get drops then and high response times then the problem is indeed the Internet Link. If you get fast response times from the ASA public's IP address but slow responses from the internal host then the ASA/VPN config needs to be looked at .

Ping is blocked to the PIX hosting the VPN by an inter-mediate firewall between it and the outside world (which is configured to pass the VPN traffic before anyone asks ).

I have therfore from the same LAN with two clients setup:

> Constant ping to internet router at the site (perfect, sub 40ms at all times)

> VPN connection + constant ping to internal host (useless, high latency and packet loss)

So looks like its either:

a) PIX configuration (which is above so if anyone can spot errors please shout)

b) Network/Firewall between internet router and VPN PIX (will speak to the admin of this in the morning)

Thanks for all the suggestions thus far.....

As the last tests I would try removing the filter, just to rule it out as posible problem and try again.

Also, you could try reducing the TCP MSS size however it's kind of weird that your pings are that slow (plus ICMP will not be affected by the TCP MSS, only your TCP apps)

sysopt connection tcp-mss 1200 

Your VPN config looks good, so I would check the rest of the path.

OK have found the source of the problem - QoS.....

We'd been told this development environment couldn't use more than 2Mbps of the shared internet link so I'd applied a QoS policy to the outside interface of the PIX (shape average etc).

Removing this and the pings immediately dropped to sub 40ms and consistent!!!

So now off to go and re-read the Cisco papers on PIX QoS

Hrm Interesting but yeah that definetely explains why.

I have very little experience with QoS, but I do have this doc that might help:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml

Sorry, I wish I could help more .

Good luck!

Luis,


Got it sorted now (thanks for all the suggestions along the way).

Had missed a 0 off the end of the QoS burst bandwidth - doh!

So instead of being 2048Kbps with 256Kbps burst it was 2048Kbps with 25.6Kbps burst.

As soon as I increased the burst figure everything was happy!

Thanks
Mike

Hey Glad to hear that you got it working

And yeah those typos happen all the times, the worst part is that you struggle looking everywhere and everything else, reading docs and googling and when you realize what was wrong you just want to bang your head against the keyboard.

Have fun!!!

PS: Please remember to mark this question as answered.