NAT before IPsec is not functional

[fraenki]

UPDATE

A limitation of the PF implementation on FreeBSD makes it impossible to apply NAT rules before sending packets through an IPsec tunnel. (I think OpenBSD fixed this limitation in their PF implementation a while ago. Unfortunately, the PF implementation on FreeBSD no longer follows OpenBSD's developments, so it's unlikely that we see this being ported over to FreeBSD.)

There are two steps required to fix this issue:

1. Patch strongSwan
2. Revive some old code

@ermal provided a nice explanation how these two things solve this issue. (Note that Ermal did mention "other ways of doing it", so there's likely a different/better solution possible.)

The drawbacks of this fix are obvious: The strongSwan patch will never be included in any upstream release, thus it may break with any new (major) release of strongSwan. And while this solution works very well, it's just a workaround for a limitation in PF/FreeBSD.

But, to be honest, the inability to use "NAT before IPsec" is a showstopper for me. That's why I'm currently using a custom build of strongSwan alongside a small patch to vpn.inc.

ORIGINAL REPORT

(for reference only)

If you configure IPsec NAT, the IPsec phase 2 tunnels may become unstable. In my case all phase 2 tunnels remain disconnected:

Oct 19 12:09:28 opnsense charon: 15[IKE] <con1-000|1> IKE_SA con1-000[1] established between X[X]...Y[Y]
Oct 19 12:09:28 opnsense charon: 15[IKE] IKE_SA con1-000[1] established between X[X]...Y[Y]
Oct 19 12:09:28 opnsense charon: 15[IKE] <con1-000|1> scheduling reauthentication in 28101s
Oct 19 12:09:28 opnsense charon: 15[IKE] <con1-000|1> maximum IKE_SA lifetime 28641s
Oct 19 12:09:32 opnsense charon: 13[IKE] <con1-000|1> sending retransmit 1 of request message ID 951205933, seq 4
Oct 19 12:09:39 opnsense charon: 12[IKE] <con1-000|1> sending retransmit 2 of request message ID 951205933, seq 4
Oct 19 12:09:52 opnsense charon: 06[IKE] <con1-000|1> sending retransmit 3 of request message ID 951205933, seq 4
Oct 19 12:10:16 opnsense charon: 08[IKE] <con1-000|1> sending retransmit 4 of request message ID 951205933, seq 4

The only solution in this case is to disable all IPsec NAT entries, stop ipsec and restart it. Afterwards all phase 2 tunnels will come up immediately. Once all phase 2 tunnels are established, it is possible to enable the IPsec NAT entries again (but this is dangerous because a reconnect of the tunnel is very unlikely to succeed).

We do not have this issue with IPsec NAT disabled.

While debugging #369 with @AdSchellevis we've been wondering why entries to ipsec.conf are added for IPsec NAT. Is this actually required for IPsec NAT to work? It seems that this confuses the ipsec daemon.

To be more precise: I do not use the IPsec NAT for masquerading my local networks, but instead to do actual NAT (allow my other local networks to access a remote IPsec network, even if the remote side does know nothing about these local networks). It's exactly what is described here (see "Remote End Notes").

[AdSchellevis]

@fraenki just checking, but if I'm not mistaken it functions normal if the nat entry is an actual tunnel, but if you want to nat some parts of your network, you can create entries over here which will never be active and may confuse strongswan sometimes, but will do the nat part, because it has nothing to do with ipsec.

The problem over here seems to be, that we can't configure these "do not NAT all my traffic tunnels" in the nat section of the firewall.

Am I right?

[fraenki]

@AdSchellevis I'm not sure what you mean with "...if the nat entry is an actual tunnel...".

On the other hand, yes, the problem seems to be that we're not able to create similar NAT rules elsewhere. Currently it's only possible on the IPsec phase 2 configuration page.
I've already tried to replace this "IPsec phase 2 NAT" entry with a regular "outbound NAT rule", but this didn't work. I'm not sure what magic was missing to make it work. Maybe it's related to #438?

[fraenki]

Just "confirmed" this issue with a second tunnel, FWIW. Disabling the IPsec phase 2 NAT entries immediately solved the connection issue.

[AdSchellevis]

That's good, and yes it's related to the other issue. You can only create NAT rules for tunnels you actually have at the moment, and there doesn't seem to be a logic reason for it.
When the rules are disabled, your situation should work (because it seems to keep the rules, #439), but eventually you need to be able to create outbound nat rules for this.

[fraenki]

OK, let me summarize what I've tried so far.

I have the following IPsec phase 2 tunnel configured:

• Local network: 192.168.1.0/24
• Remote network: 10.22.13.0/24

But I want to be able to reach the remote network from my second local network, 172.16.2.0/24, too. That's why I've added the following IPsec phase 2 NAT configuration (documentation/description):

• Local Network: 172.16.2.0/24
• NAT/BINAT Network: 192.168.1.0/24
• Remote Network: 10.22.13.0/24

This should allow us to access the remote network 10.22.13.0/24 from our second local network 172.16.2.0/24, because it gets NAT to 192.168.1.0/24. You see that a pf NAT rule is added:

binat on enc0 inet from 172.16.2.0/24 to 10.22.13.0/24 -> 192.168.1.0/24

And it works. But the ipsec daemons gets confused, as described earlier.

That's why I've tried the following:

• disabled the IPsec phase 2 NAT configuration
• the pf BINAT rule was still there
• added a regular outbound NAT rule (Firewall->NAT->Outbound)

Now the pf NAT table looks like this:

nat on enc0 inet from 172.16.2.0/24 to 10.22.13.0/24 -> 192.168.1.0/24 port 1024:65535
binat on enc0 inet from 172.16.2.0/24 to 10.22.13.0/24 -> 192.168.1.0/24

Unfortunately, the connection from 172.16.2.0/24 to 10.22.13.0/24 stopped working immediately after disabling the IPsec phase 2 NAT configuration. I guess the regular outbound NAT rule and the BINAT rule aren't enough to get it working. (FWIW, actually BINAT isn't really what I want, but it is OK for demonstration purposes.)

Is there any way to configure this IPsec NAT without interferring with the ipsec daemon?

[fraenki]

@AdSchellevis I've seen some (rather old) posts stating that PF can't do NAT for IPsec (at least not on FreeBSD). Is this statement still true? On the other hand some people advise to set net.inet.ipsec.filtertunnel=1 in this regard... do you have any comments on this to share? :)

[fraenki]

Setting the sysctl net.inet.ipsec.filtertunnel to 1 did not help to solve the NAT issue, but it would allow us to filter the traffic inside the tunnel (as the name suggests).

[fichtner]

@fraenki what's the status here?

[fraenki]

@fichtner Currently it cannot be solved so easily. I think I should open a new RFE issue with only details on the technical limitations/issues.

[fichtner]

We can update the first post if needed, just let me know how to transform the ticket (title+description). would be sad to lose the extra info in the comments.

[fraenki]

@fichtner I've updated my original submission with the description of the underlying problem.

[fichtner]

@fraenki thank you :)