Openvpn – Connecting to vpn through double nat

Here's what may be an issue. Imagine you have following network:

address pool: 10.1.1.0/255.255.255.0
router: 10.1.1.1
internal interface on internal vpn server: 10.1.1.2
some external machine that VPNs to network: 10.2.2.2
some internal client machine: 10.1.1.90

When you trying to access SIC from external VPN box, then traffic route goes like this:

• 10.2.2.2
• vpn (internet)
• 10.1.1.2
• 10.1.1.90
• OK

Seems fine, HOWEVER, in order for traffic to flow, the 10.1.1.90 machine should be able to respond and that means that packets from it must be routable to 10.2.2.2 too. Internal client has obviously ip: 10.1.1.90, mask: 255.255.255.0 and router: 10.1.1.90. Therefore, packets would be routed like this:

• 10.1.1.90
• 10.1.1.1 (sine it is router, and 10.2.2.2 is not directly addressable)
• internet
• NOT FOUND

Basically, reply packets will not even reach VPN. What can you do? Obviously, what will work is to add route to internal client to route all packets to 10.2.2.2 not to VPN box instead of router, such as (Windows box):

route add 10.2.2.0 mask 255.255.255.0 10.1.1.2

this will resolve the problem on single-machine level. Reply packets will go:

• 10.1.1.90
• 10.1.1.2 (explicit route)
• vpn (internet)
• 10.2.2.2

To resolve issue on the network level, you must modify router in a same matter to redirect all traffic going to 10.2.2.0 to 10.1.1.2. This way reply packet will go:

• 10.1.1.90
• 10.1.1.1
• 10.1.1.2
• vpn (internet)
• 10.2.2.2

Another solution is: make your VPN box to NAT on 10.1.1.2 interface. This way for internal machines it will look as if all the traffic originates from 10.1.1.2, and replies will go to 10.1.1.2. I would advise to go through routing though, since NAT will require additional resources on VPN box for connection tracker

It is possible to solve this using NAT; it's just not very elegant.

So under the assumption you couldn't solve this by having internal nets which have so uncommon network numbers as to never actually come into conflict, here's the principle:

As both the local and remote subnet have identical network numbers, traffic from your client will never realize it has to go through the tunnel gateway to reach its destination. And even if we imagine it could, the situation would be the same for the remote host as it is about to send an answer.

So stay with me and pretend that as of yet, there are no side issues as I write that for full connectivity, you would need to NAT both ends inside the tunnel so as to differentiate the hosts and allow for routing.

Making some nets up here:

• Your office network uses 192.0.2.0/24
• Your remote office uses 192.0.2.0/24
• Your office network VPN gateway hides 192.0.2.0/24 hosts behind the NATed network number 198.51.100.0/24
• Your remote office network VPN gateway hides 192.0.2.0/24 hosts behind the NATed network number 203.0.113.0/24

So inside the VPN tunnel, the office hosts are now 198.51.100.x and remote office hosts are 203.0.113.x. Let's furthermore pretend all hosts are mapped 1:1 in the NAT of their respective VPN gateways. An example:

• Your office network host 192.0.2.5/24 is statically mapped as 198.51.100.5/24 in the office vpn gateway NAT
• Your remote office network host 192.0.2.5/24 is statically mapped as 203.0.113.5/24 in the remote office vpn gateway NAT

So when host 192.0.2.5/24 in the remote office wants to connect to the host with the same ip in the office network, it needs to do so using the address 198.51.100.5/24 as destination. The following happens:

• At the remote office, host 198.51.100.5 is a remote destination reached through the VPN and routed there.
• At the remote office, host 192.0.2.5 is masqueraded as 203.0.113.5 as the packet passes the NAT function.
• At the office, host 198.51.100.5 is translated to 192.0.2.5 as the packet passes the NAT function.
• At the office, return traffic to host 203.0.113.5 goes through the same process in the reverse direction.

So whilst there is a solution, there are a number of issues which must be addressed for this to work in practice:

• The masqueraded IP must be used for remote connectivity; DNS gets complex. This is because endpoints must have a unique IP address, as viewed from the connecting host.
• A NAT function must be implemented both ends as part of the VPN solution.
• Statically mapping hosts is a must for reachability from the other end.
• If traffic is unidirectional, only the receiving end needs static mapping of all involved hosts; the client can get away with being dynamically NATed if desirable.
• If traffic is bidirectional, both ends need static mapping of all involved hosts.
• Internet connectivity must not be impaired regardless of split- or non-split VPN.
• If you can't map 1-to-1 it gets messy; careful bookkeeping is a necessity.
• Naturally one runs the risk of using NAT addresses which also turn out to be duplicates :-)

So solving this needs careful design. If your remote office really consists of road warriors you add a layer of problems in that:

• they never know beforehand when they end up on overlapping net ids.
• the remote office gateway NAT would need to be implemented on their laptops.
• the office gateway would need two VPNs, one NAT-free and one NATed, to cover both scenarios. Otherwise, in the event someone were to pick one of the subnets you chose for the NAT method, things wouldn't work.

Depending on your VPN client you might be able to automatically select one VPN or the other depending on the network address of the local segment.

Observe that all mentioning of NAT in this context denotes a NAT function which so to speak takes place within the tunnel perspective. Processwise, the static NAT mapping must be done before the packet "enters" the tunnel, i.e. before it is encapsulated in the transport packet which is to take it across the internet to the other VPN gateway.

This means that one must not confuse the public ip addresses of the VPN gateways (and which in practice may also be NAT:ed, but then wholly outside the perspective of transport to the remote site through VPN) with the unique private addresses used as masquerades for the duplicate private addresses. If this abstraction is difficult to picture, an illustration of how NAT may be physically separated from the VPN gateway for this purpose is made here:
Using NAT in Overlapping Networks.

Condensing the same picture to a logical separation inside one machine, capable of performing both the NAT and VPN gateway functionality, is simply taking the same example one step further, but does place greater emphasis on the capabilities of the software at hand. Hacking it together with for example OpenVPN and iptables and posting the solution here would be a worthy challenge.

Softwarewise it certainly is possible:
PIX/ASA 7.x and Later: LAN-to-LAN IPsec VPN with Overlapping Networks Configuration Example
and:
Configuring an IPSec Tunnel Between Routers with Duplicate LAN Subnets

The actual implementation therefore depends on a lot of factors, the operating systems involved, associated software and its possibilities not the least. But it certainly is doable. You would need to think and experiment a bit.

I learned this from Cisco as seen by the links.