If you want to connect subnets from two sites over an IPSec Site-to-Site VPN and both subnets on each site are identical, you have to use 1:1 NAT aka BINAT (Bidirectional NAT) to overcome this pitfall.

Imagine the following situation. You want to connect Site A over an IPSec Site-to-Site VPN Tunnel with Site B. The pitfall is that both sites using the same subnet

If in the figure below the client from Site A with its own IP wants to send a packet to the client in Site B with the IP, the packet from the client in Site A will never send to and hit the gateway in Site A as the destination IP resides in the same subnet and therefore the client tries to submit the packet directly to the destination in the same subnet. So the packet never reached the destination and remote network.

Therefore you can use NAT/BINAT translation on both sites to mask the real networks behind a different network which doesn’t exists on the other site.

In case both sites wants access each destination on the other site, we have to translate the complete network/subnet on each site.

For example Site A will mask/translate his local network behind the network and Site B will also mask/translate his local network behind the network

In pfSense this would look like this from Site A in phase 2 for the IPSec tunnel configuration:

Above you can see that Site A mask/translate his local network with toward Site B. For the remote network in Site B we have to enter the new masked/translated network from Site B. In order that this work, Site B on his part also have to mask/translate its own local network behind the network toward Site A.

On Site B this would look like this in pfSense:

If now the client from Site A sends a packet to the client in Site B, pfSense in Site A will translate the source IP from the client in Site A into toward Site B.

Incoming packets from Site B to the client in Site A will then also have the masked/translated destination IP, therefore pfSense in Site A have to change the destination IP into the real IP in Site A with in order to be able to submit the packets to the Client in Site A.

The same happens in Site B for the other way.

Because of that clients in each site have to know the masked/translated IP from the destination in the other site as it is not possible to address them with their real IP as mentioned.

So if my client in Site A wants to send a packet to the client in Site B, it cannot send the packet to its real IP, instead it have to use the masked/translated new IP

You can accomplish this with a new DNS Forward Lookup Zone or Conditional Forwarders in each site which contains the masked IPs or quick an dirty in smaller deployments with local hosts files.

In the example above we assumed that both sites want to access each other.

In cases only one site want’s to access the other site, you can mask/translate the site who wants to access the remote site just behind one IP address instead a complete network/subnet.

Also known as Port Address Translation

Port Address Translation (PAT), is an extension to network address translation (NAT) that permits multiple devices on a local area network (LAN) to be mapped to a single public IP address. The goal of PAT is to conserve IP addresses.

In this case it is mapped to a single local network address.

For example only clients from Site A wants to access clients in Site B. In this case the configuration in pfSense from Site A looks like this:

The network from Site A will be masked/translated with one IP address toward Site B.

In Site B the configuration should look like this. The local network is masked/translated with as used but for the remote network in Site A we only have to use one IP address

Therefore we do not have to waste a complete /24 subnet in Site B as we only have to spend one IP address for the remote network.


Network address translation (NAT)

Port and Address Translation (PAT)

NAT with IPsec Phase 2 Networks