cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1079
Views
0
Helpful
0
Comments
TCC_2
Level 10
Level 10

Core issue

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 1.1.1.1
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 1.1.1.1 peer rather than the VPN Client.

Resolution

To resolve this issue, create another ACL for NAT 0. Do not use the same ACL for NAT 0 and the crypto map.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: