search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.39k stars 759 forks source link

Issue with IPsec tunnel 23.1_6 and FQDN #6313

Closed at0msense closed 1 year ago

at0msense commented 1 year ago

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

I'm currently testing the migration of IPsec tunnels from ipsec.conf to swanctl.conf. For this I've upgraded one side of the tunnel to 23.1_6. The migrated tunnel can be started from both sides without any problems. Then I created an analog configuration with "Connections [new]" and deleted the old configuration. Unfortunately, I find that now the tunnel can only be started from one side (23.1_6). From the other side this leads to the error NO_PROPOSAL_CHOSEN. The problem seems to be that the site has no IP address at rightid but a FQDN. If I change "Local addresses" at this site from FQDN to the current IP address, it is possible to initiate the tunnel from both sites again afterwards.

tunnel can only be initiated from side2 with this config side1 ipsec.conf (22.7.11) left = 99.99.99.99 right = host.example.org

side2 swanctl.conf (23.1.6) local_addrs = host.example.org remote_addrs = 99.99.99.99

tunnel can be initiated from both sides with this config side1 ipsec.conf (22.7.11) left = 99.99.99.99 right = host.example.org

side2 swanctl.conf (23.1.6) local_addrs = 88.88.88.88 remote_addrs = 99.99.99.99

AdSchellevis commented 1 year ago

If I understand you correctly you are trying to use a fqdn on new (connections) versus old(tunnels), in which case it would make sense it doesn't work as the old pf** code tries to resolve the address instead of using the fqdn.

https://github.com/opnsense/core/blob/7609985e6986eca6acc64caec43254710be94216/src/etc/inc/plugins.inc.d/ipsec.inc#L666-L669

Quite some of this weirdness is the reason to add a separate module to replace the tunnels in the long run, too many assumptions and side-effects in the code, not really using the standards offered by strongswan.

at0msense commented 1 year ago

The tunnel between 22.7.11 and 22.7.11 works this way and the tunnel beween 23.1_6 ( legacy mode) and 22.7.11 works also fine. Means that it is not possible with swanctl to connect a tunnel between hosts with dyn IP addresses ?

AdSchellevis commented 1 year ago

if both use the same configuration (23.1.x), I would expect that it does work, you just can't mix addresses and fqdn's

at0msense commented 1 year ago

I'll try to upgrade my HA sense the next few days and the try it out. Is it possible to downgrade a node to 22.7 again with 'opnsense-revert -r 22.7.11' ? ( In case of errors that can't be resolved quickly )

AdSchellevis commented 1 year ago

no, you can only revert minor versions.

at0msense commented 1 year ago

I've now successfully upgraded my HA sense to 23.1_6. Worked without any problems. Many thanks for that. Then I started to change my tunnels from legacy to swanctl. The first tunnel worked without problems. The second tunnel I fail because I can't maintain another pre-shared key for the same Local identifier. But in my case all tunnels have different keys. This tunnel is the one with the FQDN on the other side. edit_pre-shared_key

AdSchellevis commented 1 year ago

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

fichtner commented 1 year ago

Just to note swanctl.conf is also used for old tunnels on 23.1, but its data model wasn’t changed and perhaps never will be.

at0msense commented 1 year ago

With the patch I could now also switch the second tunnel. The new tunnel now uses swanctl on both sides. The tunnel can still only be established from the side that uses the FQDN.

at0msense commented 1 year ago

Maybe it would fix the problem if I could maintain the fields "remote addresses"/"local addresses" and change the entry to "fqdn:host.example.org" , as it works for the automatically migrated tunnels. Unfortunately entering other data is not possible. I got an error message: Entry "fqdn:host.example.org" is not a valid hostname, IP address or range. According to https://docs.strongswan.org/docs/5.9/config/identityParsing.html strongswan is fqdn a valid option.

OPNsense-bot commented 1 year ago

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.