core: IPsec site to site with dynamic DNS results in "unable to resolve %any, initiate aborted" on initialization

Important notices

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

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• 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

Describe the bug

I’ll start by stating that I’m not sure if this is indeed a bug or me just misunderstanding things. But, to me it looks like a likely bug.

I’m currently running OPNsense 23.1.1_2-amd64. I recently did an upgrade, but I’m not sure from which version that was. I don’t think this used to be an issue, but I can’t be sure of that either because the tunnel works if initiated by the remote party.

The problem is that if I enable Allow any remote gateway to connect under phase 1 IPsec settings, it won’t connect to the remote party. It will log unable to resolve %any, initiate aborted, and nothing further seems to happen. Both parties (OPNsense in this end, an older pfSense in the other) have dynamically assigned IP addresses and thus use dynamic DNS for resolving the remote addresses. If I initiate the connection from the pfSense installation, the tunnel goes up and everything works just fine. But, initiation from the OPNsense end seems impossible.

If I disable Allow any remote gateway to connect, OPNsense will also connect straight away. Why not just leave it disabled then? This is where I’m unsure if I misunderstand something. The “help text” for Allow any remote gateway to connect states:

Recommended for dynamic IP addresses that can be resolved by DynDNS at IPsec startup or update time.

This sounds like something I should have enabled from the description. My understanding is that it won’t reject the remote party during initialization if the remote IP doesn’t match the remote DNS entry. That might happen just after a change, due to DNS caching before expiry. So, it seems like a good idea not to reject the other party if this situation occurs.

It should however not, as I understand it, affect the “outgoing address” when trying to initiate a connection. The error seems to indicate that it’s trying to establish a connection with an undefined remote address. That’s not the case, it should still use that specified under Remote Gateway when initializing a connection.

To Reproduce

I’m not sure what circumstances that’s required for this to happen, except that Allow any remote gateway to connect must be enabled. This happens even if I put a static IP in the Remote Gateway field, as long as Allow any remote gateway to connect is enabled. That might be all it takes to reproduce, but to narrow it down a but, I can mention that I’m using IKEv2, IPv4, Start immediate, Mutual PSK, and User distinguished name for both identifiers. It’s hard to imagine that the encryption, hashing or phase 2 settings matter as it never comes to any of that.

Expected behavior

I expect that it’s possible to initiate a IPsec connection even if Allow any remote gateway to connect is enabled.

Environment

OPNsense 23.1.1_2 (amd64, OpenSSL 1.1.1t) Intel® Atom™ CPU C3558 @ 2.20GHz (4 cores, 4 threads)