In part 1 we've applied NAT policies over IPsec tunnel mode s2s VPN traffic in a simple scenario.
In this part we will apply NAT policies over IPsec tunnel mode s2s VPN traffic in case of overlapped subnets(when the subnets behind the two VPN gateways overlap).
For example consider the case when the subnet behind the VPN gateways is the same, say 192.168.10.0/24.
This may happen when you do not own the remote VPN gateway, it may belong to a business partner, hence you do not have any control over the IP addressing scheme on their side, nor do they have any control on your side.
Or your company has acquired another company, and need to connect the offices together, but the acquired company may use the same private IP address subnet(s), so until you update the IP addressing scheme on their side to match your company's strategy, you may have to deal with this situation.
Unsaid in part 1, please note that NAT may break some applications, and the overlapped subnets case may add further pressure.
One way to deal with this(avoiding NAT), would be to have the VPN gateways act as ARP proxies, but this will work only if the remote server the local clients need to access has a distinct IP address, for example, if there is a local server 192.168.10.2, then it may not be possible to also have a remote server 192.168.10.2.
So, as we said, we have a subnet behind a Vyatta VC5 router, left Vyatta, 192.168.10.0/24, and an IPsec tunnel mode s2s VPN between this router and a remote router. For convenience, within the bellow lines the remote VPN gateway will be another Vyatta VC5(right Vyatta, the subnet behind it is the same 192.168.10.0/24), on which we will also apply NAT policies over the VPN IPsec s2s VPN traffic.
We want to mask the subnet behind Vyattas because it is the same at both ends, which creates a jam.
Clients behind left Vyatta need to access a few servers located on the remote site, and the clients located on the remote site need to access a few servers located behind left Vyatta.
Thus we will hide on left Vyatta the local subnet 192.168.10.0/24 as 192.168.210.0/24, local clients (192.168.10.100-192.168.10.200) being masked as 192.168.210.192/29 and local servers(192.168.10.10 and 192.168.10.11) as 192.168.210.10 and 192.168.210.11(we have assumed we have two servers behind left Vyatta that need to be accessed by the clients located on the remote site).
We used a pool of IP addresses to mask the local clients, but we could have just used a single IP address to do that.
Please note that none of left Vyatta's physical interfaces has an IP address from the 192.168.210.0/24 subnet as we don't really need that.
We will also do the same on the right Vyatta, and hide the local subnet 192.168.10.0/24 as 192.168.110.0/24, so that in the end, a VPN gateway and the clients behind it to be unaware of the real IP addresses behind the remote VPN gateway.
On right Vyatta, local clients (192.168.10.100-192.168.10.200) being masked as 192.168.110.128/29 and local servers(192.168.10.2 and 192.168.10.3) as 192.168.110.2 and 192.168.110.3(we have assumed we have two servers behind right Vyatta that need to be accessed by the clients located on the remote site).
We used a pool of IP addresses to mask the local clients, but we could have just used a single IP address to do that.
Please note that none of right Vyatta's physical interfaces has an IP address from the 192.168.110.0/24 subnet as we don't really need that.
Read more…