08-09-2011 02:30 PM
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
Solved! Go to Solution.
08-10-2011 09:54 AM
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.
08-09-2011 03:00 PM
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.
08-09-2011 03:02 PM
Also, what's on ACL 102 and what is your IP Pool and NAT 0 ACL?
08-09-2011 03:25 PM
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
08-09-2011 03:32 PM
Ride on
Lets hope it stays stable then .
I can remember what the default is for NAT-T.
08-09-2011 03:41 PM
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)........
08-09-2011 03:50 PM
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 .
08-09-2011 04:19 PM
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.....
08-09-2011 08:38 PM
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.
08-10-2011 12:47 AM
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
08-10-2011 07:22 AM
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!
08-10-2011 09:49 AM
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
08-10-2011 09:54 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide