OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: Jürgen Garbe on February 19, 2020, 10:43:54 am
-
Hi there,
I have to do outbound NAT for an IPSec connection (not 1:1 NAT and not 1:n, but m:n ...).
In the outbound NAT rules (using hybrid), the ipsec interface can be chosen, but the traffic is not translated and leaves the standard gateway (untranslated).
Any ideas?
Actually I do simply work around this by using a seperate opnsense instance which is doing the needed NATing.
Regards
Jürgen
-
Did you add the spd to Phase2?
-
Hm, I think so:
The source net is 10.6.0.0/8 which should be NATed to 172.18.132.48/29 (random, sticky).
The destination net is 10.16.100.0/24.
In the Phase2 definitions the local net is 172.18.132.48/29 and the remote net is 10.16.100.0/24.
Again: actually I work around this behaviour using a seperate opnsense instance which only does the NAT and it works.
Or do you eventually mean I have to use the original source net (10.6.0.0/8) instead as local Phase2 net?
-
You have to insert the original net as SPD in Phase2, thats all (including Nat)
-
Not sure what you mean.
Do you mean to add the original network as manual SPD entry?
If not:
I can't change the requirement that the customer is forcing us to use a "transport net" 172.18.132.48/29 on our side as endpoint of the IPSec tunnel.
So I can't simply change the given Phase2 local net entry to our local network 10.6.0.0/8.
That's why I need the outbound NAT.
-
Can you post a screenshot of Phase2 please?
-
Yes (please ignore unsafe settings like AES 128):
-
You need to add the real source network in "Manual SPD entry"
-
I added the original (before outbound NAT) network 10.6.0.0/8 to the manual SPD entry.
Please check my outbound NAT settings too.
Results:
1. Outbound NAT into the IPSec tunnel is working now. Thank you very much (any explanation or link to this method? Is it simply a kind of hack or work around?). :)
2. Start on traffic does not work in this configuration. :(
I have to change to "start immediate" instead of simply pinging it to get the tunnel opened... Any hint to this behaviour?
-
Search for IPsec Binat, it's clearly documented regarding the SPD.
No idea regarding the start immediate .. sorry
-
Ok, I did not recognize this chapter as relevant, because of my outbound (and not binat) situation.
Now it sounds trivial: additional networks to be forwarded into the tunnel have to be defined here.
Meanwhile I found a good hint on a german site describing this very well:
https://techcorner.max-it.de/wiki/OPNsense_-_NAT_before_IPSEC
In fact I was irritaded, because my thinking was that first the outbound NAT is happening and because of defining the destination net of the outbound NAT as local net in my Phase2 definition everything should work fine...
Learning never ends ;)
Topic solved!
-
I wrote this article, it's my employer ;)
-
I have to come back to this topic :(
The customer not only wants that we connect to one remote net (10.16.100.0/24) through the transport NET but also one web server on address 10.220.252.1.
I think the right way to achieve this is to set up another Phase2 which addresses this host.
But:
Now the "trick" adding manual SPDs isn't working any longer (of course...).
Even packets for the remote net are forwarded through the isolated tunnel of the last Phase2 definition.
Again: help would be fine ;)
-
Screenshot of IPsec overview please
-
First of all, please not to be confused, that you see here slightly modified addresses, I use in a private virtual test environment (172.18.133/29 instead of 172,18.132 of the real world, 10.17.100.80 instead of 10.16.100.80).
In the screenshot, you can see the corresponding IPSec status overview, which is showing, that ping packets to 10.17.100.80 are forwarded to the tunnel defined for 10.230.252.1.
The target IPSec endpoint answers on the correct tunnel.
If I change the order of the Phase2 definitions, everything is ok pinging 10.17.100.80 but the ping packets to 10.230.252.1 are forwarded to the wrong tunnel.
So each packet coming from our source net 10.6.0.0/8 which is outbound NATed and added as manual SPD entry in both Phase2 definitions is always and only using the (isolated) tunnel of the last Phase2 definition :(
Edit 1:
In my work-around setup (doing the outbound NAT on an own opnsense instance -> no need for manual SPD entries) everything is working as expected.
Edit 2:
Also the fact, that automatically (re-)starting the tunnel on incoming traffic is not working in the "integratated outbound NAT" scenario discussed here is a real big game stopper, I think.
Other thougts are very welcome!
-
Pop up ;)
Any ideas?
-
Actually I'm a bit confused with all tests and test networks, etc.
Just to be sure, when you have only ONE Phase2 SA, everything works as expected?
-
Sorry for confusion...
Actually I am very sure that the actual version has 2 different problems:
1. If an "Outbound NAT before IPSec" configuration is used,
- where one local net has to be NATed to one transport net
- which therefor comes with the need of adding "Manual SPD entries" in Phase2 definition of this tunnel
-> then the "traffic detection", which normally is able to start the tunnel, is not working. In consequence you have to manually start the tunnel.
2. If an "Outbound NAT before IPSec" configuration is used,
- where one local net has to be NATed to one transport net
- which is the local net of 2 different IPSec Phase2 definitions I need to be able to reach 2 different remote nets (which also comes with the need of adding "Manual SPD entries", this time into both Phase2 definitions of this tunnel (one for each remote net)
-> then every outgoing traffic is forwarded only through the last defined Phase2 definition tunnel (see my last screenshot) and not to the correct one one, which corresponds to the Phase2 remote network.
Puh, sorry, but I was not able to describe it less complicated...
-
There is currently a limitations that nat on IPsec only works when using one Phase2
-
Yes,
but additionally, in case of just one Phase2, the traffic detection for the automatic tunnel start isn't working too...