Issue with IPsec tunnel 23.1_6 and FQDN

[at0msense]

Important notices

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

• [x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

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]

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.

core/src/etc/inc/plugins.inc.d/ipsec.inc

Lines 666 to 669 in 7609985

	} elseif ($id_type == "dyn_dns") {
	$thisid_data = ipsec_resolve($id_data);
	} elseif ($id_type == "peeraddress") {
	$thisid_data = ipsec_resolve($ph1ent['remote-gateway']);

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]

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]

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]

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]

no, you can only revert minor versions.

[at0msense]

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.

[AdSchellevis]

#6316

[fichtner]

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]

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]

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]

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.