1. Home
  2. Cisco Systems
  3. Cisco VPN Client config on 515

Cisco VPN Client config on 515

I am trying to get clients runnign Cisco VPN software to connect to my internal network. currently the clients can connect and authenticate ok but can't see anything on the inside network. I can not ping the client from the 515. Here are the relevent config bits. I can not enable "sysopt connection ipsec-enable" because of other VPN connections I need to control traffic on. Any ideas?

Thanks,

--AJ

PIX Version 6.3(4) nameif ethernet0 outside security0 nameif ethernet1 inside security100 access-list acl_out_test permit icmp any any echo-reply access-list acl_out_test permit icmp any any time-exceeded access-list acl_out_test permit icmp any any unreachable access-list acl_out_test permit icmp any any access-list acl_out_test permit ip 10.0.18.0 255.255.255.0 host

10.0.0.212 access-list acl_out_test permit ip host 10.0.0.212 10.0.18.0 255.255.255.0 access-list VPNs permit ip 10.18.0.0 255.255.255.0 10.0.0.0 255.255.0.0 access-list VPNs permit ip 10.0.0.0 255.255.0.0 10.18.0.0 255.255.255.0 access-list VPNs permit ip 10.0.101.0 255.255.255.240 host 10.200.2.91 access-list VPNs permit ip 10.0.98.0 255.255.255.240 host 10.200.2.91 ip address outside xx.xx.xx.253 255.255.255.224 ip address inside 10.0.255.240 255.255.0.0 ip local pool VPNPOOL 10.18.0.1-10.18.0.20 mask 255.255.255.0 global (outside) 1 xx.xx.xx.227 nat (inside) 0 access-list VPNs nat (inside) 1 0.0.0.0 0.0.0.0 0 0 static (inside,outside) xx.xx.xx.225 10.0.0.208 netmask 255.255.255.255 0 0 static (inside,outside) xx.xx.xx.226 10.0.0.210 netmask 255.255.255.255 0 0 access-group acl_out_test in interface outside route outside 0.0.0.0 0.0.0.0 xx.xx.xx.254 1 route inside 10.1.1.0 255.255.255.0 10.0.255.240 1 route inside 10.32.1.0 255.255.255.0 10.0.255.240 1 crypto ipsec transform-set VPNset esp-3des esp-md5-hmac crypto dynamic-map cVPNdymap 10 set transform-set VPNset crypto map VPNcrypto 10 ipsec-isakmp crypto map VPNcrypto 10 match address VPNs crypto map VPNcrypto 10 set peer xxx.xxx.xxx.251 crypto map VPNcrypto 10 set transform-set VPNset crypto map VPNcrypto 65530 ipsec-isakmp dynamic cVPNdymap crypto map VPNcrypto client authentication partnerauth crypto map VPNcrypto interface outside isakmp enable outside isakmp key **************** address xxx.xxx.xxx.251 netmask 255.255.255.255 isakmp identity address isakmp nat-traversal 20 isakmp policy 600 authentication pre-share isakmp policy 600 encryption 3des isakmp policy 600 hash md5 isakmp policy 600 group 2 isakmp policy 600 lifetime 86400 vpngroup TESTVPN address-pool VPNPOOL vpngroup TESTVPN dns-server 10.0.0.202 10.0.0.212 vpngroup TESTVPN wins-server 10.0.0.202 10.0.0.212 vpngroup TESTVPN default-domain testdom.com vpngroup TESTVPN idle-time 1800 vpngroup TESTVPN password *********************
Reply to
AJ
Loading thread data ...

That's the same access-list as you are using for your nat 0 access-list . Don't try to reuse access-lists that way: there are some cases where it is certain not to work properly, and there are other places where there are bugs that cause it to work incorrectly. Safest is to only any one ACL in one context.

Your VPN clients are going to be allocated an IP from VPNPOOL, which is part of 10.18.0/24 . These IPs will be "outside" as far as the PIX is concerned. Traffic from inside towards those IPs will therefore have a *destination* IP in 10.18.0/24 . That destination does not match your nat 0 access-list, so the traffic will be NAT'd as it goes outwards. If we hypothesize that the return traffic will use the allocated private IP as its source, then that private IP is not going to match the traffic expected by the Adaptive Security Algorithm (which would be expecting the NAT'd IP) and so the traffic would be dropped. If we hypothesize that the return traffic will have the NAT'd IP as its source, then that NAT'd IP will not match the acl_out_test access-list so the traffic would be denied.

If you try to fix the nat 0 access-list by just reversing the source and destination fields, such as access-list VPNs permit ip 10.0.0.0 255.255.0.0 10.18.0.0 255.255.255.0 then the outbound traffic would not be NAT'd. However, the non-NAT'd outbound traffic would then match the occurance of the same line in "crypto map VPNcrypto 10 match address VPNs" and so the outbound traffic would be grabbed by your regular VPN tunnel [which has a higher priority because it has a lower policy number] and sent there instead of proceeding to the VPN client dynamic-map policy entry that would allow the traffic to get back to the VPN client.

Probably what you want to do is eliminate the above line from the access-list you match against in your crypto policy, but still include it in the access-list you match against for nat 0 access-list . Which is another good reason for not attempting to re-use ACLs in different contexts -- you get unintended consequences.

The first of those two indicates that the crypto client is to be authenticated against the service you named "partnerauth"; this enables the Xauth mechanism. The isakmp key statement does NOT have no-xauth, so xauth will apply to the remote host xxx.xxx.xxx.251 that is using your VPNcrypto 10 policy entry. Was that your intention, or did you mean the "partnerauth" authentication to apply only to the dynamic clients ?

Reply to
Walter Roberson

OK so separating the ACLs from the NAT and the Crypto commands seams to have done the trick. Thanks for all the help!

So it works but I am wondering just how secure it is...

Essentially I will end up with an ACL on my outside interface allowing

10.18.0.0/24 into my internal network (I know I can control ports and destination IPs etc) but this is my protected network. Is this a good idea? Granted the IP on my outside interface has a public IP but isn't it possible to get packets to arrive at the outside interface which appear to originate from 10.18.0.0/24 without that traffic going over my VPN tunnel?

Is there better way?

--AJ

Reply to
AJ

Yes, if the sending network does not follow RFC1918 rules and permits

10.18.0/24 to be pass out of their network, then it is possible that nothing inbetween will filter the packets, and that they would arrive at your PIX interface if they are addressed to any of your public IPs.

If you are using private IPs internally, part of the solution to that is to permit the private IPs of the VPN to go only to the private IPs of the LAN: then the packets would not be able to get to your PIX unless the next-hop for some reason routes that IP range to your PIX.

Even if you do not do that, the PIX should notice that the source IP was not received over the VPN as expected and should drop the packet. The message is roughly "Received packet is not an IPSec packet". The PIX actively checks for IPs that should be tunneled but which are arriving directly.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.