IPSEC legacy migration: Local identifier - My IP Address?

[Gromhelm]

I heavily rely on my IPSEC site-to-site policy VPN and waited until now to do the legacy migration.

I got until the pre-shared Key step, where in my legacy setup I used "My IP address" for phase 1 (Auth) in the field "My identifier".

In the new IPSEC setup, there is no drop-down for selecting "My identifier". I have a dynamic IP-address on one side, so I cannot enter a static ip address here.
It says:
> This can be either an IP address, fully qualified domain name or an email address.

What do you suggest selecting here, going forward with the migration?

[Monviech (Cedrik)]

Hello, read the migration from tunnels to connections section in here:

https://docs.opnsense.org/manual/vpnet.html

[Gromhelm]

Thank you. I am reading this section over and over and I can't seem to find the information you're trying to point me to.

There are two paragraphs regarding PSK:

When migrating Pre-Shared Key type tunnels to connections, make sure to add an entry in the "Pre-Shared Keys" module as well. If both ends should use their own identifier, fill in both local and remote values. The legacy module requested this information in the phase 1 page and wrote the same information to the secrets.

This tells me to "fill in both local and remote values", but not how.

Further down it says:

Since OPNsense uses the new Strongswan format also for legacy tunnels, it is rather easy to convert a tunnel manually when downloading the swanctf.conf file from the machine.

But when I download my Legacy swanctf.conf, I can only see my current WAN IP Address - I can't set this IP address as "My identifier", as it will regularly Change. I need some automation to replace the former (legacy) "My IP Address" Feature, which is not available in the new PSK-dialogue.

[Monviech (Cedrik)]

The identifier can be anything it does not have to be an IP address.

e.g., fqdn or dn

https://docs.strongswan.org/docs/latest/config/identityParsing.html

[Gromhelm]

Ok, I would have preferred keeping my current WAN IP as the identifier, but I can use the FQDN from the dyndns-url I am using to tell the other side my identity. It will be somewhat off between the time my provider sends me a new WAN address and the time my script was able to update the FQDN dyn dns. I will try. Thanks!

[Patrick M. Hausen]

The FQDN does not even have to be registered in DNS nor does the email address need to exist. These are just random identifiers which the remote site needs to accept. That's all.

[Gromhelm]

Interesting. Thanks for the classification! I just started the new connections and it went up flawlessly immediately!

[Edit] After testing, this was probably a leftover observation from a previous (legacy) connection.

[Gromhelm]

Doh, I just found out that the new IPSEC Implementation seems not to support FQDN anymore (like I am trying to do)

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

> you mentioned your setup worked before this change, dynamic addresses weren't supported before 21.1.4 for the new connections.

After extensive testing today, it seems I am confirming it does not work having a dynamic IP attached to a FQDN/CNAME entry, the connections are failing with "no matching peer config found".

See also this comment: https://linuxnews.de/verschlimmbessertes-vpn-ein-wort-der-warnung-zu-opnsense-deciso/

The problem seems to be that using an dynDNS FQDN CNAME entry as `Local addresses` (e.g.  jashdejvmiuqlachhsqaxs.siteb.example.com), is not acceptable, as the other side sends an actual IP (41.41.41.41), for which the comparison fails.

If I compare the swanctl.conf form legacy to the new, I can see that in the legacy conf, the actual IP was written:

Code Select Expand

        local_addrs = 41.41.41.41
        remote_addrs = 31.31.31.31

whereas if I download the new swanctl.conf, I see the FQDN entry:

Code Select Expand

        local_addrs = jashdejvmiuqlachhsqaxs.siteb.example.com
        remote_addrs = 31.31.31.31

What I am observing here is that if a packet comes in addressed to 41.41.41.41, and the config is jashdejvmi..., even though that resolves to the same IP, the match seems to still fail because strongSwan has not resolved it to 41.41.41.41 and stored that value.

This behavior is mentioned in the GitHub issue #6781. Resolving and using FQDNs in "Local addresses" can cause peer mismatches unless the resolved IP aligns perfectly and is interpreted correctly by the daemon at that moment.

Any suggestions?

[Edit2]

One step further... I changed the FQDN to User distuinguished FQDN (simply put a user in front of my FQDN for PSK identity): user@jashdejvmiuqlachhsqaxs.siteb.example.com).

This came up immediately. I will observe this further and see if it helped..

[newsense]

The problem seems to be that using an dynDNS FQDN CNAME entry as `Local addresses` (e.g.  jashdejvmiuqlachhsqaxs.siteb.example.com), is not acceptable, as the other side sends an actual IP (41.41.41.41), for which the comparison fails.

I'm using FQDNs updated dynamically both for local and remote without issues.

[Gromhelm]

Yes, my issue was rather that the use of FQDN did not work as PSK Identity. I had to put a user in front of it. Not sure if this is related to the other side, where I use pfSense and maybe the FQDN for PSK ID is first resolved to an IP and then send over, where the match fails. Anyway, with User Distinguished FQDN, this works now.

All seems to work now. Updated my blog post here:
https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/