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

    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



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



  • 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



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