PfSense 2.2.3 and 2.2.4 to StrongSwan with user distinguished name

MrMoo

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 ...

Logged errors:

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

cmb

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 something@remote.example / something@local.example and it'll work.

MrMoo

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
	leftid=@sun.strongswan.org
	leftfirewall=yes
	right=192.168.0.1
	rightsubnet=10.1.0.0/16
	rightid=@moon.strongswan.org
	auto=add

https://www.strongswan.org/uml/testresults/ikev2/net2net-psk/moon.ipsec.conf

# /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"

https://www.strongswan.org/uml/testresults/ikev2/net2net-psk/moon.ipsec.secrets

cmb

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.

MrMoo

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.

cmb

Take out the leading @, just local.example.

MrMoo

thank you very much, my misunderstanding of the different id types and how the non-decorated name works.