Site to Site VPN with similar subnets on each end

I have a project coming up to configure a new edge firewall to handle some 3rd party vendor services.

One part of this would be setting up a site to site connection with a vendor.

What would happen if both sides have the same subnets for interesting traffic? Site A advertises 10.10.10/24 and the same for site B? Would I have to NAT Site B’s incoming traffic as it hits my firewall?

Overlapping address space between both endpoints will cause a forwarding problem. If they’re the same network, the local routes will take precedence over the tunnel.

The solution is to translate the traffic before it’s forwarded on the tunnel.

  1. Site A uses Source NAT on interesting traffic to make it appear that it’s coming from an unused subnet.
  2. Site B defines this unused subnet as interesting traffic (no nat needed).

Site B doesn’t know that NAT is being used to prevent overlapping address space.

While there are solutions to overlapping address spaces, for third party vendors that you tie in to with VPNs they’ll almost certainly provide you with a NAT block for your network to reach their services. I see this most frequently deployed.

Customer A gets 10.10.10.1 to overload NAT to, Customer B gets 10.10.10.2, etc.

Basically this is easy to do in Cisco ASA and Firepower as you can perform both and source and destination NAT at one side (I think Palos also supports this, not much into Palos so I have limited knowledge), the other side doesn’t even have to know about your inside network as you will be including NAT’ed IP range in the encryption domain.
The only downside is that you need to access the other side using the Destination NAT’ed address, in your case instead of reaching the other side using 10.10.10.0/24 you may need to use a Destination NAT’ed subnet like 192.168.1.0/24.

If your firewall or vpn concentrator doesn’t support Source and Destination NAT then you may need to NAT the source traffic and include that on the encryption domain and the other side needs to do the same.

IPv6 if possible, otherwise we have a /25 of ARIN Public IP space set aside for SNAT for vendor VPN tunnels. Given it’s our space, we can guarantee it’s globally unique.

It works very well, if you’ve got the space for it.

Nat all vendors, keep good documentation people will forget.

yeh, more than likely you would have to nat it to something else.

As others have said, NAT is the key combined with route based (opposed to policy based) site to site VPN.

Very good answers in this thread, make sure you consider each one.

One thing I’d like to add - if you have any servers behind a NAT, or if you need point-to-point connectivity, then you would need to static-NAT those IP addresses. Easiest would be if you used a same-size range, example: if you NAT traffic going from A to B, traffic coming from site A 10.10.10/24 gets NATed to 192.168.1/24, then each address in the range 10.10.10/24 maps 1-to-1 to 192.168.1/24, then you’ll still have point-to-point connectivity. Think of this as simply replacing 10.10.10/24 with 192.168.1/24 for traffic going from A to B.

If the NAT subnet sizes do not match, such as NAT mapping 10.10.10/24 to 192.168.1/30, then you need to make sure that some ports are forwarded, or some IPs are kept static. There are a couple of ways you could do this. Think of this like a home router - there you receive 1 public IP, and if you need to expose a server of some sort, you need to port-forward to your server. In enterprise NAT environments, you can also set aside 1 (or more) IPs from the NAT range, and assign them to port-forwarding or similar tasks, and use the rest of the NAT range for other traffic forwarding.

We source NAT to public IP’s all 3rd party VPN connections and require them to do the same to us. So all of our encryption domains are between a few public IP’s on either end. Since we are usually providing or consuming a service, on one end it is just outbound source NAT and the other side (usually ours) is a list of PAT’s to internal services. The PAT’s can be a pain sometimes but it’s a manageable pain vs overlapping or conflicting IP space even possibly between the external third parties.

Thank you all for the responses! This helps me a lot.

As someone that does this on a daily basis, typically we ask our vendors to NAT the connection as most want to use a /16 block from AWS.

It could be done with Mikrotik, so I believe other vendors must have same functionality.

There is an “action” in NAT settings called “netmap” which can be used to static map whole subnet to some other range…

https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT

NAT is your only choice.

Also I’d drop the “interesting traffic” bit and just do route-based IPsec (VTI).

Yeah, you’ll have to NAT.

I see lots of replies here that don’t seem to take into account that the exact same addresses are in use on both sides of the tunnel and that traffic needs to flow in two directions. This means that one single routing device cannot complete the task, unless it is partitioned into logical systems or virtual routers. You cannot tell one router that the far end server 10.10.10.1 is reachable over the tunnel and assign 10.11.10.1 as the DNAT address for it if the local station 10.10.10.1 is supposed to reach it. There can only be one entry in the routing table matching 10.10.10.1. Also consider how the return traffic is handled, especially if you cannot manipulate the routing tables of the devices at the other end.

You need a dual routing stage:

Source: 10.10.10.0/24 wants to reach a server on the other side of the tunnel that has IP 10.10.10.1 (same as itself) but must reach it via fake IP 10.11.10.1

NAT router 1 does source NAT on the source IP to, say 10.255.10.1

NAT router 2 does destination NAT, translating destination IP to 10.10.10.1

Destination server 10.10.10.1 receives the traffic with 10.255.10.1 as source and can return the traffic

In a Juniper SRX and many other firewalls, this can be done using a separate routing instance for the second NAT router stage. If you have control over the two IPsec endpoints, you can use them for the respective role, but if you have several customers with potentially overlapping address space, you might want to setup a generic function for this so the resources at the respective customer are reachable via addresses like 10.11.a.b where a is the number indicating the customer and b is the resource/server you want to reach. This way you will be able to easily address 256 resources at 256 customers. Expanding beyond that is easy.

This is the answer- also yes Palo supports this. Very straightforward to deploy.

The explanation is perfect, but you can do this with even a sonicwall. Most business firewalls support this, it doesn’t need to be enterprise gear.

So it would be a 1:1 NAT between the tunnel subnet and destination subnet?

That’s correct, 1 to 1 mapping between real and mapped subnets.