NAT before IPSec question

[ivoruetsche]

Hi Forum Members

I try to setup a "NAT before IPSec" connection between two new OPNsense boxes (just install OPNsense, setup the basics, nothing else) in our test environment. I found some comments about, but not an exact statement about does it work or not in the latest version, or a documentation about.

Anyway, I spend some hours to bring it to run, but without luck, here is our test setup:

Site A.80 VLAN: 80 on the em1 interface (“SiteA.80”)
Site A.80 IP: 198.18.7.2/25
Site A.80 Test host: 198.18.7.99
Site A outside IP: 2.3.4.5

Site B.110 VLAN: 110 on the em1 interface (“SiteB.110”)
Site B.110 IP: 198.18.8.2/25
Site B.110 Test host: 198.18.8.11
Site B outside IP: 3.4.5.6

Site B.110 should be reachable with 198.18.48.0/25 and vise versa, so if I do a ping 198.18.48.11 on the host with the IP 198.18.7.99, the host 198.18.8.11 should be answered.

As I have no luck with the setup, I take other two new boxes and I install pfSense, with the same parameters on phase2 and FW rules on OPNsense and it works. What I doing wrong on the OPNsense site?


VPN/IPSec/Tunnel Settings/Phase1 and Phase 2 proposal is like described at https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
Site A:
VPN/IPSec/Tunnel Settings/Phase2:

• General information/Mode: Tunnel IPv4
• Local Network/Type: Network
• Local Network/Address: 198.18.7.0/25
• NAT/BINAT/NAT Type: Auto
• NAT/BINAT/Type: Network
• NAT/BINAT/Address: 198.18.48.0/25
• Remote Network/Type: Network
• Remote Network/Address: 198.18.48.0/25

Firewall/Rules:

• Allow all traffic on the interface “SiteB.110” from source 198.18.8.0/25 to destination 198.18.48.0/25
• Allow all traffic on the interface “IPSec” from source 198.18.48.0/25 to destination 198.18.7.0/25

Site B:
VPN/IPSec/Tunnel Settings/Phase2:

• General information/Mode: Tunnel IPv4
• Local Network/Type: Network
• Local Network/Address: 198.18.8.0/25
• NAT/BINAT/NAT Type: Auto
• NAT/BINAT/Type: Network
• NAT/BINAT/Address: 198.18.48.0/25
• Remote Network/Type: Network
• Remote Network/Address: 198.18.48.0/25

Firewall/Rules:

• Allow all traffic on the interface “SiteB.110” from source 198.18.8.0/25 to destination 198.18.48.0/25
• Allow all traffic on the interface “IPSec” from source 198.18.48.0/25 to destination 198.18.8.0/25

Would be nice, to get a hint

gruss ivo

[franco]

Sali Ivo,

NAT before IPsec as described below requires a patch to strongSwan we're not willing to incorporate until they pick it up by default. Details are here:

https://github.com/opnsense/core/issues/440

I am not sure what the state is in BSD in general WRT pf(4), there was a tutorial for OpenBSD way back:

http://undeadly.org/cgi?action=article&sid=20090127205841

And I don't know this solution if it can be incorporated into OPNsense. At this point, there is no out-of-the-box solution in the GUI.


Cheers,
Franco

[ivoruetsche]

Salü Franco

Thanks a lot for your answer. I found both of this article as well, but I hopping in the mean time there is a solution or a better workaround in place.

So, now, i'm a bit lost ... because one question is, why is the option NAT/BINAT Address available in the phase 2 configuration page?
And another question is, what we can do on our side, because we have some overlapping subnets. Patching or doing something behind the GUI is not really an option for us; pfSense hmmm... maybe... my stomach say no...

In the next weeks and months, it's not a problem to route all the overlapping subnets to the ASA who can handle this scenario, but anytime next year, we want to replace the boxes... And it would be nice to have a solution without boxes behind boxen

gruss ivo

[fraenki]

So, now, i'm a bit lost ... because one question is, why is the option NAT/BINAT Address available in the phase 2 configuration page?

This was added due to my request. And I'm glad this option exists, because it reduces the diff-size for me. There is still hope, that OPNsense will be able to support "NAT before IPsec" in the future.

And another question is, what we can do on our side, because we have some overlapping subnets. Patching or doing something behind the GUI is not really an option for us

Well, currently there is no other solution available. You could use the strongswan package provided by pfSense on OPNsense and lock it, so that it will not be overriden by the OPNsense package again. Something like this:

Code: [Select]

# WARNING! UNTESTED! USE AT YOUR OWN RISK!
fetch http://pkg.pfsense.org/pfSense_v2_3_2_amd64-pfSense_v2_3_2/All/strongswan-5.5.0.txz
pkg delete -f strongswan
pkg add strongswan-5.5.0.txz
pkg lock strongswan
Now you need to apply the following patch...

Code: [Select]

--- ipsec.inc.orig 2016-06-29 11:41:59.000000000 +0200
+++ ipsec.inc 2016-07-18 19:22:11.860639000 +0200
@@ -1029,6 +1029,18 @@
                                     continue;
                                 }
                                 if (!empty($ph2ent['natlocalid'])) {
+
+                                $natleftsubnet_data = ipsec_idinfo_to_cidr($ph2ent['natlocalid'], false, $ph2ent['mode']);
+                                if ($ph2ent['natlocalid']['type'] != "address") {
+                                    if (is_subnet($natleftsubnet_data)) {
+                                        $leftsubnet_data = "{$natleftsubnet_data}|{$leftsubnet_data}";
+                                    }
+                                } else {
+                                    if (is_ipaddr($natleftsubnet_data)) {
+                                        $leftsubnet_data = "{$natleftsubnet_data}|{$leftsubnet_data}";
+                                    }
+                                }
+
                                     $natfilterrules = true;
                                 }
                             }

...to your ipsec.inc; do something like this:

Code: [Select]

# WARNING! UNTESTED! USE AT YOUR OWN RISK!
scp patch.txt root@opnsense:
ssh root@opnsense
cd /usr/local/etc/inc
patch </root/patch.txt

This step is required to support the proprietary strongswan syntax which was added by the pfSense project.

In the next weeks and months, it's not a problem to route all the overlapping subnets to the ASA who can handle this scenario, but anytime next year, we want to replace the boxes... And it would be nice to have a solution without boxes behind boxen

Currently there is no better solution than using this proprietary patch for strongswan, because FreeBSD's pf simply does not support this functionality. Maybe we should add a help text to the IPsec page to inform users about this limitation.

Regards
- Frank

[franco]

The status quo is it doesn't work in FreeBSD, but I canot see that's entirely true.

I've inspected the code and at least NAT itself is not the problem in this case as it works. I will have to enhance my test environment to see how it can be set up in a real world case.

Jos has already offered to write the documentation How-To for this if we get it working. At the moment, I can't see why it shouldn't, but maybe I'm missing something (or there is a bit of code missing in the GUI to properly support it).

[ivoruetsche]

Salü Franco

If I can help in some cases, documentation, help or give access to a test environment, please tell me.

gruss ivo

[slemoal@tiscom.fr]

Hello, this feature to you advanced?

[mimugmail]

https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html

[slemoal@tiscom.fr]

Thanks