Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Site-to-Site VPN - Overlapping ACL's

we have a Cisco 3745 as our VPN end point. customer end points vary between cisco, linksys, sonicwall, watchguards, etc.

we have a customer who can not define interesting traffic in a host specific form, thus they have to open the whole subnet up. in this case, the subnet is /24 (customer A). this is not a problem, except for the fact that a new customer (customer B) recently added also has this limitation - AND also uses the same address range. (they do, however, use different IP addresses for their particular hosts but must open the entire range)

when the tunnel is brought up, it goes into a QM_IDLE state (Phase 1 works), but when I do a "sh crypto ipsec sa peer" on the customer A peer IP, the first entry shows the "current peer" field is the customer B peer, but the "remote crypto endpoint" shows the customer A IP.

in the config, the crypto map config for customer A is a lower number than customer B, so it appears first. we tried placing host specific deny statements into the customer A ACL, but that did not work.

when we move customer B over to another peer on our network that we use for debugging, it comes up fine. presumably because the customer A config is not present on this second peer.

what can be done to stop this conflict between VPN peers ? i don't believe changing address schemes is a viable option for either customer.

if it will help i can post output from "show crypto ipsec sa peer" command.

any help/suggestions at all will be very appreciated !

Hall of Fame Super Blue

Re: Site-to-Site VPN - Overlapping ACL's


it doesn't matter if the host addresses are actually different, if they both have to use the range then it will not work on your VPN end point.

The solution is for one of them to NAT their source IP addresses to either a pool of different addresses or just one single address at their end before they send the packets to you. Note that you can use any address range as long as it doesn't conflict with anything else so they don't have to be publically routable, although what a lot of companies do is to NAT their source IP addresses to the public IP address of the external interface of their firewall.

Can't speak for the other firewalls but on pix if you do NAT your addresses to something else in your crypto access-list you must use the Natted addresses and not the original source ip addresses.