Connecting OpenVPN Sites with Conflicting IP Subnets

One common use of NAT with OpenVPN is to mask conflicting LAN subnets between two locations. If two networks are using the exact same subnet, or overlapping subnets, as their LAN or other internal network they cannot communicate across a site-to-site VPN without NAT.

Danger

Shared key mode has been deprecated by OpenVPN as it is no longer considered sufficiently secure for modern requirements.

Shared key mode will be removed from future versions of OpenVPN. Users should not create any new shared key tunnels and should immediately convert any existing shared key tunnels to SSL/TLS mode.

When an SSL/TLS instance is configured with a /30 tunnel network it behaves in a similar manner to shared key mode. The primary difference is the need to create and distribute the certificate structure to peers. See OpenVPN Site-to-Site Configuration Example with SSL/TLS for information on configuring OpenVPN in SSL/TLS mode.

Site-to Site Example

In this example 10.3.0.0/24 is the LAN on both sides of a VPN. Hosts on the 10.3.0.0/24 subnet will never reach the other end of the VPN to communicate with the remote 10.3.0.0/24 subnet. Clients will always treat that network as local, attempting to reach the other systems via ARP. With NAT, however, the remote side can be made to function as if it were using a different subnet.

Note

Utilizing NAT will work for many protocols but some that are commonly desirable across VPN connections, primarily SMB/CIFS file sharing between Windows hosts, may not function in combination with NAT. If hosts use a protocol which is not capable of functioning with NAT, this is not a viable solution.

Figure Site to Site with Conflicting Subnets shows an example where both ends are using the same subnet. After assigning the OpenVPN interface to an OPT interface on both sides, as described in Assigning OpenVPN Interfaces, 1:1 NAT can be applied.

../_images/diagrams-openvpn-sitetosite-nat.png

Site to Site with Conflicting Subnets

The firewall at Site A translates its LAN to 172.16.1.0/24 and the firewall at Site B translates to 172.17.1.0/24. A 1:1 NAT entry on each firewall translates its entire /24 range.

To reach Site A from Site B, clients at Site B use 172.16.1.x IP addresses. The 1:1 NAT rule translates the last octet in the 10.3.0.x IP address to the last octet in 172.16.1.x. A client at Site B attempting to reach 10.3.0.10 at Site A would use 172.16.1.10. To reach 10.3.0.50 at Site B from Site A, a client would use 172.17.1.50.

Figure Site B 1:1 NAT Configuration show the 1:1 NAT configuration for each side, where the tun interface is assigned as OPT1.

../_images/openvpn-1to1nat-sitea.png

Site A 1:1 NAT Configuration

../_images/openvpn-1to1nat-siteb.png

Site B 1:1 NAT Configuration

In the OpenVPN configuration on both sides, the Remote network must be the translated IP subnet, not 10.3.0.0/24. In this example, the Remote Network at Site A is 172.17.1.0/24, and Site B is 172.16.1.0/24.

After applying the NAT configuration changes and configuring the remote networks accordingly on both sides, the networks will be able to communicate using the translated subnets.

Site-to-Multi-Site Example

This section describes how to map multiple subnets that have the same IP address range using OpenVPN so that they can be accessed from a central site. For example 192.168.0/24 is a very common addressing scheme and the main site may need to access all the systems on those networks.

This is the desired outcome, Site 0 is the hub:

Site 0 - 10.1.1/24
Site 1 - 192.168.0/24 -> 10.10.1/24
Site 2 - 192.168.0/24 -> 10.10.2/24
Site 3 - 192.168.0/24 -> 10.10.3/24

For example, with this type of setup in place, site 0 can access 192.168.0.33 at site 2 as 10.10.2.33.

Note

This configuration requires 1:1 NAT which means that some things may not work, see notes in the remaining sections for details.

There are multiple alternate ways to reach this goal. This example has the remote sites (Sites 1-3) run the “server” and Site 0 runs the “clients”. Either direction works.

Preliminary

Pick two ranges for this scheme. The first range is for mapping subnets and the second range is for OpenVPN client to server connections. This example uses 10.10.0.0/16 for the mappings and 10.254.100/24 for the VPN endpoints. The first choice supports up to 253 mappings and the second choice gives 64 /30 subnets to link it all up.

Examples before NAT:

Site 0 to Site 1:

           <--------             (OpenVPN)            ---------->

10.1.1/24 --- 10.254.100.2/30 --- INTERNET --- 10.254.100.1/30 --- 192.168.0/24

Site 0 to Site 2:

           <--------             (OpenVPN)            ---------->

10.1.1/24 --- 10.254.100.6/30 --- INTERNET --- 10.254.100.5/30 --- 192.168.0/24

Note

Notice how the addresses on the right are not unique - they are always 192.168.0.0/24.

NAT can make each remote site unique:

10.1.1/24 --- (OpenVPN) --- INTERNET --- OpenVPN_Interface - NAT - 10.10.1/24 <=> 192.168.0/24
10.1.1/24 --- (OpenVPN) --- INTERNET --- OpenVPN_Interface - NAT - 10.10.2/24 <=> 192.168.0/24
10.1.1/24 --- (OpenVPN) --- INTERNET --- OpenVPN_Interface - NAT - 10.10.3/24 <=> 192.168.0/24

Site 0 sends packets to a destination in the mapped subnet down the tunnel which corresponds to the desired Site 1, 2, or 3 and the NAT at the other end translates to and from that mapping and sends the result back to Site 0.

Recipe

In the following examples, only necessary changes from default are given. Pick suitable transports (UDP by default) and ports (1194 by default) Put in a suitable firewall rule on the server WAN interfaces to allow the inbound connection VPN. This should be restricted to the WAN IP address of Site 0. Both ends must have a suitable firewall rule on the OpenVPN interface for traffic to pass.

At Site 1-3

OpenVPN server

At each remote site, create a new OpenVPN server:

Server Mode:

Peer to Peer

Description:

Link to Site 0

TLS authentication:

Check “Automatically generate a shared TLS authentication key.”

IPv4 Tunnel Network:

Link subnet, e.g. 10.254.100.0/30

IPv4 Remote networks:

IP address range(s) at Site 0, e.g. 10.1.1.0/24

If Site 0 has multiple IP ranges then specify them all in IPv4 Remote networks, comma separated. After saving, edit the VPN instance and copy the shared key to the other end (see below)

1:1 NAT

Add one of these for each network range at Site 0:

Interface:

OpenVPN

External subnet IP:

Mapping subnet, first IP address, e.g. 10.10.1.0

Internal IP:

LAN net

Destination:

Network, IP range at Site 0, e.g. 10.1.1.0/24

Not the default gateway

If this firewall is not the default gateway for the site then use an outbound NAT rule on LAN to ensure that replies from the clients return via the OpenVPN tunnel. Without this, the systems at Sites 1-3 will reply via their default gateway because they will be unaware of the Site 0 network. Another option is to put a suitable route on the site gateway via the LAN address of the OpenVPN system but this will introduce an asymmetric route and which will potentially break things even more than the double NAT.

At Site 0

OpenVPN client

Create a separate OpenVPN client for each remote subnet (Where examples are given they are for Site 1 ):

Server mode:

Peer to Peer (Shared key)

Server host or address:

IP address of the remote site

Description:

Text to describe the connection, such as the site name, mapping subnet, and link subnet. For example, Site 1 10.254.100.0/30 10.10.1.0/24

Shared Key:

Copy from the server for the site link

IPv4 Tunnel Network:

Link subnet, e.g. 10.254.100.0/30

IPv4 Remote networks:

Mapping network, e.g. 10.10.1.0/24

Notes

  • SIP and RTP can be tricky with NAT involved

  • DNS may not work well under this scheme

  • Anything relying on DNS may have issues, such as web links that do not use the passed host name but use the built in name

  • Do not forget to put suitable firewall access rules on the various OpenVPN interfaces