PfSense 2.2.3 and 2.2.4 to StrongSwan with user distinguished name
Same as https://redmine.pfsense.com/issues/4785 affects "My Identifier" set to "User distinguished name". The local identifier in ipsec.secrets is written as %any instead of the configured value.
$ cat /var/etc/ipsec/ipsec.secrets %any @remote.example : PSK ...
Jul 28 15:01:58 charon: 16[IKE] <con1|39>no shared key found for '@local.example' - '@remote.example'
Jul 28 15:01:58 charon: 16[IKE] <con1|39>no shared key found for '@local.example' - '@remote.example'</con1|39></con1|39>
Site-to-site IKEv2 VPN using IPv4 and PSKs, other side is strongswan-5.2.0-7.el7.x86_64
That's not the problem. Do you really have UDNs defined as just "@hostname"? That's permitted by the GUI, but when you write out something as just "@hostname" to ipsec.secrets, strongswan treats it as a FQDN type identifier. We specify userfqdn: in front of the leftid and rightid in ipsec.conf, which won't match the FQDN type in ipsec.secrets. Change that to email@example.com / firstname.lastname@example.org and it'll work.
I'm following the StrongSwan examples, and hoping they are a reasonable authority on such issues. This format did work for 2.2.2 and earlier: ikev2/net2net-psk. So is this limitation because the interface does not permit fqdn?
# /etc/ipsec.conf - strongSwan IPsec configuration file config setup conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret keyexchange=ikev2 mobike=no conn net-net left=192.168.0.2 leftsubnet=10.2.0.0/16 email@example.com leftfirewall=yes right=192.168.0.1 rightsubnet=10.1.0.0/16 firstname.lastname@example.org auto=add
# /etc/ipsec.secrets - strongSwan IPsec secrets file @moon.strongswan.org @sun.strongswan.org : PSK 0sv+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL @moon.strongswan.org %any : PSK 0x45a30759df97dc26a15b88ff @sun.strongswan.org : PSK "This is a strong password" : PSK 'My "home" is my "castle"!' 192.168.0.1 : PSK "Andi's home"
The examples you're showing are Distinguished Name (FQDN) not User Distinguished Name. Set the ID type to DN and it'll work and match what you're doing on the opposite side.
In 2.2.2 and earlier, the hostnames were dropped into ipsec.secrets without the necessary leading @, which makes strongswan resolve the FQDN to an IP and use the IP. The config also didn't specify the leftid/rightid type which was newly added to strongswan, so it was just dropping them in there as entered and letting strongswan pick which type it looked like they were. Now things are handled more correctly, and it doesn't work because the config wasn't right to begin with, it just happened to work because of strongswan's assumptions.
If I set Distinguished Name the interface yields the following errors keeping the @ prefix, so I should specify just the host name as the prefix is forcing FQDN interpretation? Apologies for my lack of knowledge, I'll have to check this remote site tomorrow.
The following input errors were detected:
A valid domain name for 'My identifier' must be specified.
A valid FQDN for 'My identifier' must be specified.
A valid domain name for 'Peer identifier' must be specified.
A valid FQDN for 'Peer identifier' must be specified.
Take out the leading @, just local.example.
thank you very much, my misunderstanding of the different id types and how the non-decorated name works.