10-01-2013 12:44 PM
We have two clients that want to set up l2l IPsec VPN tunnels on an ASA 5525 (8.6) with the same /24 private IP range. Each customer requires access to the same remote /24 private range. Readdressing isn't a likely solution for either customer. Is there a way we can do this without the firewall getting confused as to how to send the return traffic back to these customers?
Thanks!!
Solved! Go to Solution.
10-01-2013 12:57 PM
Hi,
I would suggest doing Static Policy NAT on both sites. Do a Static Policy NAT that will NAT each sites /24 network to some equal size NAT network. This will keep the NAT setup simple and make it easy to determine what is the actual IP address of the host at the other site.
If you do Static Policy NAT like mentioned above it will essentially mean if your original network was 10.10.10.0/24 and the NAT network was 192.168.10.0/24 then you could determine that hosts 10.10.10.10 NAT IP address was 192.168.10.10 and so on.
When configuring the L2L VPN between the sites you would specify the NAT network in the ACL that defines the networks which traffic will be tunneled.
Using the above mentioned real and mapped network and using the 8.6 software NAT configuration format (lets also presume that the remote sites NAT network is 192.168.20.0/24) then the Static Policy NAT could be configured like this
object network LAN
subnet 10.10.10.0 255.255.255.0
object network LAN-MAPPED
subnet 192.168.10.0 255.255.255.0
object network REMOTE-LAN
subnet 192.168.20.0 255.255.255.0
nat (inside,outside) source static LAN LAN-MAPPED destination static REMOTE-LAN REMOTE-LAN
The above configuration would naturally handle the site with the ASA5525-X running 8.6 software
Hope this helps
- Jouni
10-01-2013 12:57 PM
Hi,
I would suggest doing Static Policy NAT on both sites. Do a Static Policy NAT that will NAT each sites /24 network to some equal size NAT network. This will keep the NAT setup simple and make it easy to determine what is the actual IP address of the host at the other site.
If you do Static Policy NAT like mentioned above it will essentially mean if your original network was 10.10.10.0/24 and the NAT network was 192.168.10.0/24 then you could determine that hosts 10.10.10.10 NAT IP address was 192.168.10.10 and so on.
When configuring the L2L VPN between the sites you would specify the NAT network in the ACL that defines the networks which traffic will be tunneled.
Using the above mentioned real and mapped network and using the 8.6 software NAT configuration format (lets also presume that the remote sites NAT network is 192.168.20.0/24) then the Static Policy NAT could be configured like this
object network LAN
subnet 10.10.10.0 255.255.255.0
object network LAN-MAPPED
subnet 192.168.10.0 255.255.255.0
object network REMOTE-LAN
subnet 192.168.20.0 255.255.255.0
nat (inside,outside) source static LAN LAN-MAPPED destination static REMOTE-LAN REMOTE-LAN
The above configuration would naturally handle the site with the ASA5525-X running 8.6 software
Hope this helps
- Jouni
10-01-2013 01:08 PM
Thanks!
10-01-2013 02:00 PM
Quick follow-up question. If the two customers needed access to different servers, could I use access lists per each VPN policy to forgo having to NAT both sides with different ranges?
Thanks!
10-01-2013 02:07 PM
Hi,
If you mean that the overlapping networks would want to connect to remote server IP that is not used in the local network then it wouldnt really make a difference.
You will need NAT for both sites networks as otherwise traffic wont flow correctly.
If you didnt NAT either site the traffic wouldnt even reach the local networks VPN device as the source host would think the remote device is in the same local network and when the destination IP address is in the same network as the actual host forming the connection, then the host wont even send the traffic to its default gateway but will rather send ARP request to try to determine the MAC address of the remote host. This will naturally fail.
If you were to only NAT one sites address/subnet then the initial connection forming would possibly/perhaps reach the remote site but as the other sites address/subnet wouldnt be translated the connection would still not form because of the above mentioned reasons.
If you were to perform NAT on both of the sites, neither site would notice the overlap in the local IP address as both site would only see the remotes sites NAT IP address and because of that traffic would flow just fine.
- Jouni
10-01-2013 02:43 PM
So, just to be clear, I will still have to NAT both sides if peer A's private range is 192.168.1.0/24 and only needs to talk to 10.50.50.0/25 and peer B's private range of 192.168.1.0/24 only needs to talk to 10.50.50.128/25? The idea being that the ACL responsible for processing the request would route the traffic back through its associate crypto map peer statement and get back to its point of origin based on the IP address of the peer. However, it sounds like it's not going to work that way.. [peerA 192.168.1.0/24] ---> VPN <----[ASA 5525-X: 10.50.50.0/25 10.50.50.128/25] ----> VPN <---- [PeerB 192.168.1.0/24]
10-01-2013 03:01 PM
Hi,
So both sites have the network 192.168.1.0/24 and Site A has 10.50.50.128/25 and Site B has 10.50.50.0/25?
I am not 100% sure but it might be so that if the 192.168.1.0/24 network was the only one initiating connections to the network 10.50.50.x/25 and the 10.50.50.x/25 network didnt have any need to open/initiate connections to the 192.168.1.0/24 then perhaps the ASA would know to forward the traffic back to the L2L VPN when it has seen the initial packet coming from there.
If the 10.50.50.x/25 network were to initiate a connection I would imagine that the connection would never reach the L2L VPN connection as the ASA would check the routing table where to forward the traffic and I guess in this situation it would see the network 192.168.1.0/24 directly connected or routed behind some local interface. Naturally this might be overriden with NAT configurations in the new software but I am not really sure its worth it when there is an easier/clearer solution.
Though I am not sure. When any kind of network overlap is in question I wouldnt even consider trying out an overlapping setup between the site as NATing both sites is a simple way to completely get around this anyway and keep the network setup clear.
- Jouni
10-01-2013 03:23 PM
Excellent! Thank you for your valuable feedback! One last question: With the above scenario:
Using the above mentioned real and mapped network and using the 8.6 software NAT configuration format (lets also presume that the remote sites NAT network is 192.168.20.0/24) then the Static Policy NAT could be configured like this
object network LAN
subnet 10.10.10.0 255.255.255.0
object network LAN-MAPPED
subnet 192.168.10.0 255.255.255.0
object network REMOTE-LAN
subnet 192.168.20.0 255.255.255.0
nat (inside,outside) source static LAN LAN-MAPPED destination static REMOTE-LAN REMOTE-LAN
The access-list would be using the NAT'd ranges for the crypto map, correct?
Thanks!
10-01-2013 03:32 PM
Hi,
Yes, the ACL used in the "crypto map
Now that I look at your above posts it seems to me that you have perhaps added some information. I mean the small topology of the network.
It seems that your site perhaps has both the 10.50.50.0/25 and 10.50.50.128/25? In other words the 10.50.50.0/24 and there are actually 2 remote sites both with 192.168.1.0/24 networks that connect to your site? If that is the case then I have missunderstood the situation partly. I thought you were talking about a single L2L VPN connection between 2 sites.
Nevertheless I would still suggest the similiar solution. I would have either of the remote sites NAT their network so there is no overlap from your perspective. As I said, in this setup only one of the 2 remote sites would have to NAT their network before the L2L VPN connection.
If for some reason there should be a connection between the 2 192.168.1.0/24 networks then both of those sites would require NAT.
I guess the above posts contain some useless information and speculation since the setup seems to be different from what I originally suspected.
- Jouni
10-01-2013 02:55 PM
I would suggest a different solution:
Add IPv6-addressing for the systems that need to talk and the VPN. Also if you don't have public IPv6-addresses, you can start with ULA for this scenario.
--
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide