Site-to-Site VPN - Overlapping ACL's

takethesewords · ‎02-02-2007

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 10.1.1.0 /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 10.1.1.0 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 !

Jon Marshall · ‎02-02-2007

Hi

it doesn't matter if the host addresses are actually different, if they both have to use the 10.1.1.0/24 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.

HTH

Jon