Cisco VPN Client to Pix 506 problem

In article , LLFF wrote: :On the outside interface of the pix I configure a public address :delivered by my ISP.

:As usual, I've used the wizzard in PDM to configure a VPN Access, but :it does not work. :If i show logs on the pix when trying to access by VPN client, I can :see that the state stay in "AG_NO_STATE". On the Cisco knowledge base, :I saw that : "The ISAKMP SA has been created, but nothing else has :happened yet.

Please post the ipsec related portion of your 506 config (with the passwords and public IP suitably obscured.)

But first -- have you tried isakmp nat-traversal 20 ?

Hi Walter,

see after the ipsec and others related portions :

... access-list 100 permit udp any any eq isakmp ... access-list inside_outbound_nat0_acl permit ip any 10.0.*.*

255.255.255.* access-list outside_cryptomap_dyn_20 permit ip any 10.0.*.* 255.255.255.* access-list outside_cryptomap_dyn_40 permit ip any 10.0.*.* 255.255.255.* ... ip address outside 84.*.*.* 255.255.255.* ip address inside 10.0.*.* 255.255.255.* ... global (outside) 10 interface nat (inside) 0 access-list inside_outbound_nat0_acl nat (inside) 10 0.0.0.0 0.0.0.0 0 0 static (inside,outside) 84.*.*.* server1 netmask 255.255.255.255 0 0 static (inside,outside) 84.*.*.* server2 netmask 255.255.255.255 0 0 ... access-group 100 in interface outside route outside 0.0.0.0 0.0.0.0 84.*.*.* 1 ... sysopt connection permit-ipsec no sysopt route dnat crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20 crypto dynamic-map outside_dyn_map 20 set transform-set ESP-DES-SHA crypto dynamic-map outside_dyn_map 40 match address outside_cryptomap_dyn_40 crypto dynamic-map outside_dyn_map 40 set transform-set ESP-DES-MD5 crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map crypto map outside_map interface outside isakmp enable outside isakmp policy 20 authentication pre-share isakmp policy 20 encryption des isakmp policy 20 hash sha isakmp policy 20 group 2 isakmp policy 20 lifetime 86400 isakmp policy 40 authentication pre-share isakmp policy 40 encryption des isakmp policy 40 hash md5 isakmp policy 40 group 2 isakmp policy 40 lifetime 86400 vpngroup XXX address-pool NAME vpngroup XXX dns-server *.*.*.* vpngroup XXX idle-time 1800 vpngroup XXX password ******** vpngroup YYY address-pool NAME2 vpngroup YYY dns-server *.*.*.* vpngroup YYY idle-time 1800 vpngroup YYY password ********

I will try isakmp nat-traversal 20 ...

Thanks a lot,

Jov.

In article , LLFF wrote: :access-list inside_outbound_nat0_acl permit ip any 10.0.*.* 255.255.255.*

:ip address inside 10.0.*.* 255.255.255.*

:nat (inside) 0 access-list inside_outbound_nat0_acl

For outgoing traffic, the ACL for a nat 0 access-list is read with the left address being the source (inside) IP and the right address being the destination (outside) IP. For incoming traffic, the ACL is read in reverse, with the right address used for the source and the left for the destination.

Thus, your nat 0 access-list statement indicates that traffic

*to* 10.0.*.* is exempt from NAT.

But your "ip address inside" statement indicates that the

10.0.*.* addresses are *inside*, not on the far side of the link.

If this is not a side effect of over-obfuscation for posting purposes, then you will need to correct this.

It is, by the way, always better for nat 0 access-list to be as restrictive as feasible. Don't use 'any' as the source, use the inside IP range. Similarily, it is always better for the plain nat, nat (inside) 10 in your case, to be specific instead of using

0.0.0.0 0.0.0.0 .

Consider, for example, what happens when one of your hosts randomly DHCPs into the private range 169.254.x.x and then tries sending traffic out. The traffic will be permitted unless you specifically block such things, because the nat statement allows 0/0 to be translated to the global IP. If the traffic is to the outside, replies to it will get as far as the PIX on the return and be de-nat'd, but then will be dropped because the PIX will see that the route to 169.254 is via the outside interface which is where the reply packet just came from. If the traffic was destined across the VPN, then the other end will still be able to reply and the other end will forward the 169.254 packet along the default route which will punt it back to the PIX... where again it will be dropped. But in the meantime, in either case the remote end will have acted on the packet.

Now consider what happens if you get a virus loose inside and it starts forging all kinds of packets with random source IP addresses...