NAT before IPsec: limitations and workarounds #1773
Comments
|
I plan to work on this (later this year), please assign the issue to me. |
|
(can always move milestone up if you want) |
|
We are affected by both this issue and #2173 We manually added the correct spdadd entries via setkey which works. How can I add spdadd entries so they survive a reboot/upgrade? |
|
@ruffy91 I still plan to work on this, but I had to postpone it to July/August (it will not be ready for OPNsense 18.7). |
|
Hi, I had similar requirement for some BINAT requirements. I run into the problem that autogenerated spd entries are not correctly generated when the Remote ID in phase 1 is not the external remote IP. For reasons the other side is not able to change their used ID to the external IP and so I am stuck to a workaround. Manual set SPD entries fixed it for me temporarily but I would like to manage this entries persistent over api or gui that this configurations are backed up and documented. Regards, |
|
@fraenki was there a change with OpnSense 18.7.10 ? regards, |
…can't add a tunnel. switch to remote-gateway if that is a valid ip address. It's not a complete fix, for #1773 but improves error logging and adds functionality when peer identifier is currently broken.
|
@bluesource 8f45e0d should fix your issue. |
|
just for info: its working again after a call with deciso (business support). The Issue was: Remote FW is only accepting a Cert as peer identifier and therefore we set "KeyID" with value "%any, although remote FW has a fix IP. Then the Manual SPD entries are not set. Fix from deciso: and btw: great support from Deciso! |
|
Hi, is this still open to fix in 19.1.x? I had to change my WAN configuration in several remote sites from PPPoE to a static IP behind a NAT router. The normal IPsec tunnels are all working normal, but the additional networks of the remote sides, which must be NATed before IPsec are not entering the tunnel any more. Regards, |
|
we don't have other fixed queued than 8f45e0d at the moment. |
|
OK. Can you help me to find out where or why the packets are not finding the way into the tunnel? I really need this feature back working! When I remove the manual SPD for the additional network in phase 2, the packets were send out over the standard gateway via WAN. So IPsec configuration is recognizing the additional network. But I can't see any SNAT transformation in the firewall log of the packets. The configuration for this is unchanged and made in the 1to1 NAT of the firewall section. |
|
To make it short: I've found my mistake, NAT before IPsec is working when OPNsense is behind a NAT router. Before I had to change the WAN configuration, I used 'my IP address' and 'peer IP address' in the phase 1 as identifiers at both ends. After I moved one router behind a NAT router, I had to use 'IP address' on one side for one identifier. I chose 'my identifier' in the OPNsense behind the NAT router and put the public WAN IP address of the NAT router in. Everything worked fine, except the additional networks behind this OPNsense. Maybe it is possible to put this hint into the IPsec BINAT wiki. |
fichtner
added
help wanted
|
Hi, we ran into this issue with the router behind a NAT. The phase 1 identifier is set to 'IP address' (with public IP in value field). The manual SPD entry was incorrectly using this IP address as the local tunnel endpoint instead of the opnsense IP from which the tunnel is initiated. My fix was to modify /usr/local/etc/inc/plugins.inc.d/ipsec.inc with the following: // add manual added spd entries
if (!empty($config['ipsec']['phase1']) && !empty($config['ipsec']['phase2'])) {
foreach ($config['ipsec']['phase1'] as $ph1ent) {
foreach ($config['ipsec']['phase2'] as $ph2ent) {
if (!isset($ph2ent['disabled']) && $ph1ent['ikeid'] == $ph2ent['ikeid'] && !empty($ph2ent['spd'])) {
- $myid_data = ipsec_find_id($ph1ent, "local");
+ $myid_data = ipsec_get_phase1_src($ph1ent);
$peerid_spec = ipsec_find_id($ph1ent, "peer");
if (!is_ipaddr($peerid_spec)) {
if (is_ipaddr($ph1ent['remote-gateway'])) {
$peerid_spec = $ph1ent['remote-gateway'];
} else {
log_error(sprintf(
"spdadd: unable to match remote network on %s or %s [skipped]",
$peerid_spec,
$ph1ent['remote-gateway']
));
continue;
}
}
foreach (explode(',', $ph2ent['spd']) as $local_net) {This is probably incorrect for a general solution, but it fixed my issue. |
|
@olivierIllogika good to hear this solved your issue, I'm always struggling a bit with the At a first glance it looks like we missed the correct policy source definition here, which resulted in a working setup when using the external address. Looking at the code, it looks like it will only work at the moment if I've prepared a fix 30a5536, which incorporates your change. now we need to find some people to validate this on their functional setups. @fraenki @mimugmail do you have the time and spirit to test this patch? Thanks in advance! |
|
@AdSchellevis fair warning: I'm not at all familiar with the code or setkey. The setkey documentation could indeed be a little more specific, but as I understand it, the "tunnel/%s-%s/require" string needs to match the tunnel's endpoint:
I'm not sure about the 'SA' part, but this (linux) documentation mentions the tunnel explicitly: https://www.mad-hacking.net/documentation/linux/networking/ipsec/spd-setkey.xml If this assumption is correct, it might make sense to (1) remove the $peerid_spec is_ipaddr() check and just get the phase 1 destination from the start; and (2) rename the variables from $myid_data/$peerid_spec to $tunnel_src/$tunnel_dst |
|
@olivierIllogika I think you are right, we could do a bit more here to clarify things. let me refactor this a bit further and add some logging in case the end result varies from what it does on current stable. |
|
@olivierIllogika this should be it 1e8ebbf , it needs 30a5536 first as a starting point. My setup still works with the patch applied, hopefully this removes the limitations, it will simplify the code as well (after removal of the extra temporary logging). |
|
Hi, |
|
@Jesper-fr works like a charm on my end, we don't need patches to Strongswan. Just don't forget to add manual spd entries (some documentation can be found here https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html) |
|
My problem is that I only have access to one end of the tunnel. The opposite end is at a customer site. |
|
IPsec can be tricky to debug, certainly if you can't access both sides. |
|
I can't see that the NAT address is being sent through the tunnel. Encode counters are not increasing when I do a ping from a server in my end of the tunnel towards the customer server. |
|
Screenshots and logs please, best via Forum threas |
|
I litle more explanation firewall interfaces: My local server is comming via VLAN 10 and is being translated to interface addr. on VLAN 32. I will provide screenshots tomorrow. |
|
please find attached a packet capture . Ping done from a server 10.220.2.13 and it's being translated to 10.222.8.4, but the packet towards 10.1.204.108 is not being tunneled. I have tried to do 2 configs. Both configs are outbound nat
PACKET CAPTURE WAN PACKET CAPTURE IPSEC in below image, test is 10.220.2.13 - Salling group is 10.1.204.108 - VLAN32_NAT_INTERFACE is 10.222.8.4
|
|
@Jesper-fr can you please use our forum for discussions (as Michael requested)? . |
|
Sorry....i'm new to GitHub. Were do I find forum ? |
|
no problem, things happen, our forum can be found here : https://forum.opnsense.org/ |
|
Sorry, but I have tried to post my issue on that forum, but I didn’t get
any response what so ever
|
|
please just add enough detail there as @mimugmail requested. (free) community support is provided by people helping out in their own time. If you have an actual reproducible bug or a feature request, you can always open a new ticket of your own. Spamming threads in existing issues won't help solving the original ticket. (this case should probably already be closed, since the specific work-arounds where fixed a month ago. @fraenki close now?) |
|
This issue has been automatically timed-out (after 180 days of inactivity). For more information about the policies for this repository, If someone wants to step up and work on this issue, |
As described in #440 there are two limitations in our new implementation:
The first one is related to "My identifier":
This means that it's required to use an IP address for "My identifier". Anything else, for example "Distinguished name", will not work. (Well, maybe it might work to get the IP address from the selected interface for those cases... but I'm not sure.)
Besides that I've found another case where "NAT before IPsec" is not yet working: when OPNsense is behind NAT. In this case there's a mismatch (as can be seen in the
setkeyoutput):Apparently, the Router IP that is used for this tunnel is not configured on the OPNsense firewall. But instead there's a port forward on the Router.
As opposed to my original submission, I think it might be possible to workaround both limitations. The reason why it's not working is the same in both cases: the local entry is erroneous in the
setkeyoutput. We should add a new option to the GUI to allow the user to overwrite this value. I think in both cases the user should be able to enter the right value, it's hard to "guess" it because there are many corner cases. Additionally a bit of background information as to when this is required should be added to the help text.The text was updated successfully, but these errors were encountered: