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 !
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...