My heading may not make any sense and depending on the perspective it could either be a source or destination NAT. Whatever it maybe here is my scenario.
My environment has just about 100 IPSec L2L tunnels to our customers. The customers have a server that we need access to, hence the VPN tunnel. As our business grows and we add more customers overlapping IP address of customer servers will become a common issue. That way I get around it now is I ask the customer to Policy NAT their source IP address of their server to a public address which is then encrypted and sent over the VPN tunnel. I have been getting some resistance from customer on this mainly because they don’t want to use a public IP address or don’t know how to policy nat or it’s just not possible in there scenario. So I’m tossing around the idea of controlling the NAT of the customers server on my end. The big question here is, can the ASA NAT the source address of a particular host coming across a VPN tunnel (Outside Interface) going to my (Inside interface). If so it will allow me to control the customers host IP address such that it will never overlap I hope I made sense here, if I need to draw a diagram and can do one quickly.
Sure you can..
For example let' say you have this:
Your inside LAN = 10.0.0.0/8
Remote Site1 internal LAN = 10.1.1.0/24
Remote Site2 internal LAN = 10.2.2.0/24
To avoid the overlapping problem in this scenario normally the Policy NAT is done on the remote end.
However, if not wanted to do it on the remote end, you can do it on your side (asuming you want to NAT the remote 10.1.1.0/24 to 192.168.1.0/24 and 10.2.2.0/24 to 192.168.2.0/24)
static (out,in) 10.1.1.0 192.168.1.0 netmask 255.255.255.0
static (out,in) 10.2.2.0 192.168.2.0 netmask 255.255.255.0
In this case your internal 10.0.0.0/8 will see both remote LANs as 192.168.x.0
This absolutely makes sense and is becoming more and more of an issue in enterprise networks. You can NAT the customer addresses after the packets are decrypted.
Your internal network: 10.1.1.0/24
Customer encrypted network: 10.2.2.0/24
You discover 10.2.2.0/24 in your enterprise routing table and determine there is an overlapping IP address problem.
Build the IPSEC rules (Interesting traffic selection) to account for the addresses the customer will send through the tunnel. Then install the following static in based on 172.16.1.0/24 not being currently used in your network.
static (outside,inside) 172.16.1.0 10.2.2.0 255.255.255.0
# If a route is needed install this static – may need to redistribute
# into the IGP.
route outside 172.16.1.0 255.255.255.0