Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
The Cisco VPN Client is able to connect to the PIX Firewall but not able to pass traffic
One likely explanation is that the same Access Control List (ACL) is being used for NAT bypass (NAT 0) as well as for crypto map.
If the same ACL is bound with NAT 0 as well as the LAN-LAN crypto map entry, then this behavior is expected because the NAT 0 ACL also has the VPN client pool configured as the destination. When the crypto map is checked for this traffic, it finds a match with the LAN-to-LAN tunnel and is never sent out through the dynamic crypto map. The static crypto map takes the precedence over the dynamic crypto map. The PIX attempts to encrypt the traffic using the static crypto map and sends out to the relevant peer, as shown:
access-list myvpn permit ip 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0 nat (inside) 0 access-list myvpn crypto map mymap 10 ipsec-isakmp crypto map mymap 10 match address myvpn crypto map mymap 10 set peer 188.8.131.52 crypto map mymap 10 set transform-set myset
To add clients, issue these commands:
ip local pool mypool 192.168.100.1-192.168.100.254 access-list myvpn permit ip 10.1.1.0 255.255.255.0 192.168.100.0 255.255.255.0
Now, the myvpn ACL is configured for the remote LAN-to-LAN network, as well as the VPN client pool. Whenever there is some traffic from the 10.1.1.0 network for the 192.168.100.0 network, it goes to the 184.108.40.206 peer rather than the VPN Client.
To resolve this issue, create another ACL for NAT 0. Do not use the same ACL for NAT 0 and the crypto map.