Understanding the "new way" of BiNAT over IPSec

[anomaly0617]

Hi all,

In the past if I wanted to connect two buildings that had the overlapping internal subnet(s), I could use a 1:1 NAT mapping to deal with this problem. For instance:

Problem Scenario:

	Building A	Building B
Local Network	| 192.168.1.0/24	| 192.168.1.0/24 (Uh oh!)
Remote Network	| 1.2.3.4/30	| 4.3.2.1/30

In order to make this VPN tunnel work, I need to do something like this:

	Building A	Building A (Masq.)	Building B (Masq.)	Building B
Local Network	| 192.168.1.0/24	| 172.16.1.0/24	| 172.16.2.0/24	| 192.168.1.0/24
Remote Network	| 1.2.3.4/30			| 4.3.2.1/30

And now from Building A, if I ping 172.16.2.1, I get responses from the Building B firewall.

And from Building B, if I ping 172.16.1.1, I get responses from the Building A firewall.

The magic here was in the Phase 2 VPN tunnel, there was an "Manual SPD entries" field that let me specify the masquerade network. And then under Firewall >> NAT >> One-to-One, I'd create a custom mapping that converted, say, 172.16.2.26 into 192.168.1.26 in Building B, or 172.16.1.52 to 192.168.1.52 in Building A.

With me so far?

I'm migrating all of my VPN tunnels over to the new IPSec VPN Connections mechanism. And I've got 100+ new successful tunnels under my belt, so I'm fairly confident at this point that I'm doing it correctly. But this is the first time I've run into a conflict of networks.

So my question is, how do I achieve this under the new Connections mechanism of IPSec?

Is it under VPN >> IPSec >> Virtual Tunnel Interfaces, or
Is it under VPN >> IPSec >> Security Policy Database >> Manual >> Add Manual SPD?

Are there examples somewhere to reference?

Thanks, in advance!

[AdSchellevis]

Hi,

You're probably looking for this https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-binat.html , should be the same example as the legacy one, but for the new connections.

Just make sure to choose a unique reqid, certainly when legacy tunnels on the same machine exists (to prevent overlaps)

Best regards,

Ad

[Kotmanul]

Why need adding manually SPD records if we can make "install policy" in settings of phase 1?

[Patrick M. Hausen]

Why need adding manually SPD records if we can make "install policy" in settings of phase 1?

If you want to NAT what goes into the tunnel, in most cases the source network is not part of the policy - hence the reason for NAT. Remember the phase 2 entries must match on both sides and NAT is usually used when you don't have any control over the far side.

Unfortunately the routing/policy decision is made before NAT is applied, so your packets will go out the default (or another configured) gateway instead.

[Kotmanul]

Thanks. I'm fighting with binat already third day and binat still wins me.

I wrote everything what i found in officials docs but still no chance.

I already up first phase and it's okey but the second phase not working.


172.16.10.48/32 - > 10.10.1.1/32 - my WAN side -- WAN side B - 172.19.4.102/32

In a phase 2 i set my address 10.10.1.1
SPD set 172.19.4.102 only.

Req ID sets by system 5
1:1 NAT settings as in docs.
Rules-Ipsec allow all traffic

Logs says in this config that querying policy  not found. No connections.

But if i set install policy phase 2 making up, connections established on both sides but not reachable.

[Kotmanul]

Okay guys i found what the problem was. We  use service  in docker container and tunnel should be working with'em but in this server severa containers which have they own network inside.

And it turns out that the service in the container tried to ping another service in another container and not the end host on the other side of tunnel

And I configured Binat and Ipsec correctly the first time.
That's it