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, will not function in combination with NAT. If a protocol is used that is not capable of functioning with NAT, this is not a viable solution.

Figure 66: 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, 1:1 NAT can be applied.

Fig. 66: Site to Site with Conflicting Subnets

The traffic from Site A will be translated to 172.16.1.0/24, and Site B will be translated to 172.17.1.0/24. A 1:1 NAT entry is added on each end to translate the entire /24 range. To reach Site A from Site B, 172.16.1.x IP addresses will be used. The last octet in the 10.3.0.x IP will be translated to the last octet in the 172.16.1.x translated IP. To reach

10.3.0.10 at Site A from Site B, use 172.16.1.10 instead. To reach 10.3.0.50 at Site B from Site A, use 172.17.1.50. Figure 68: Site B 1:1 NAT Configuration show the 1:1 NAT configuration for each side, where the tun interface is assigned as OPT1.

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

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