StrongSwan 5.1.3-4.11.1: Problems with conn matching - altName doesn't get matched
I'm using StrongSwan both for connecting servers to each other by means of an IPsec tunnel and for establishing a remote tunnel from remote boxes to one of the servers. The host-to-host tunnel works since I'm using complete DN matching for determining the connection. However, the remote machines use EAP-RADIUS to connect and as such send the CN associated with the remote machine's cert as a login name, but somehow the host still expects the full DN. Furthermore the remote side doesn't start up StrongSwan as a system service, but instead it gets invoked via NetworkManager (it correctly points to the strongswan-nm daemon so that kind of problem is already avoided).
Here's the config that I use on the host that acts as a central hub (/etc/ipsec.conf):
config setup strictcrlpolicy=no uniqueids=no ca robidu.de cacert=cacert.der auto=add ca intermediate cacert=intermediate-cert.der auto=add conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=3 dpdaction=restart dpddelay=2m keyexchange=ikev2 left=22.214.171.124 leftfirewall=yes leftcert=central-servercert.der leftid="C=DE, O=robidu.de, CNfirstname.lastname@example.org" reauth=yes compress=yes auto=route conn backup-server # This one works, and the link comes up without any problems. keyingtries=1 right=126.96.36.199 rightid="C=DE, O=robidu.de, CNemail@example.com" rightsendcert=yes mobike=no conn rw-tls # This one hiccups when attempting to establish a connection... forceencaps=yes leftsubnet=0.0.0.0/0 firstname.lastname@example.org leftauth=pubkey rightauth=eap-radius rightsendcert=yes right=%any rightsourceip=172.16.1.0/24 auto=add
Although currently StrongSwan expects the right hand side to send its cert for inspection, disabling this won't help, either. I have tried that option, but the result is about the same.
The output of the cert is as follows (with obfuscated user names) - please note that the altName is matching the CN:
cert: X509 subject: "C=DE, O=robidu.de, CN=<user>@rw.robidu.de" issuer: "C=DE, O=robidu.de CN=robidu.de Intermediate certificate" validity: not before Feb 18 11:45:30 2015, ok not after Feb 07 11:45:30 2017, ok (expires in 584 days) serial: 40:7d:c8:ee:8b:f6:e3:0c altNames: <user>@rw.robidu.de flags: authkeyId: ea:86:e2:7a:bd:db:1f:f4:97:c3:a1:29:35:84:85:73:e9:e6:4b:7e subjkeyId: d0:28:f0:8f:2a:eb:be:1f:59:a7:f1:90:78:7b:9e:e0:07:f0:6a:5d pubkey: RSA 2048 bits keyid: 38:26:e3:20:f7:4c:38:8a:52:ba:87:f7:a6:ed:f7:97:d5:18:67:77 subjkey: d0:28:f0:8f:2a:eb:be:1f:59:a7:f1:90:78:7b:9e:e0:07:f0:6a:5d
Here's the relevant log snippet from the host:
Jul 4 11:00:46 07[NET] received packet: from 188.8.131.52 to 184.108.40.206 (1128 bytes) Jul 4 11:00:46 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] Jul 4 11:00:46 07[IKE] 220.127.116.11 is initiating an IKE_SA Jul 4 11:00:46 07[IKE] remote host is behind NAT Jul 4 11:00:46 07[IKE] sending cert request for "C=DE, O=robidu.de CN=robidu.de Intermediate certificate" Jul 4 11:00:46 07[IKE] sending cert request for "C=DE, O=robidu.de, CN=robidu.de Root CA" Jul 4 11:00:46 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ] Jul 4 11:00:46 07[NET] sending packet: from 18.104.22.168 to 22.214.171.124 (485 bytes) Jul 4 11:00:46 16[NET] received packet: from 126.96.36.199 to 188.8.131.52 (396 bytes) Jul 4 11:00:46 16[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR DNS NBNS) N(IPCOMP_SUP) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) ] Jul 4 11:00:46 16[CFG] looking for peer configs matching 184.108.40.206[C=DE, O=robidu.de,CN=<user>@rw.robidu.de]...220.127.116.11[<user>@rw.robidu.de] Jul 4 11:00:46 16[CFG] no matching peer config found Jul 4 11:00:46 16[IKE] peer supports MOBIKE Jul 4 11:00:46 16[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] Jul 4 11:00:46 16[NET] sending packet: from 18.104.22.168 to 22.214.171.124 (76 bytes)
Now, how do I get this thing going? Right now I absolutely don't have any idea on what could possibly be going wrong here.
#1 Updated by Tobias Brunner over 7 years ago
- Description updated (diff)
- Status changed from New to Feedback
Jul 4 11:00:46 16[CFG] looking for peer configs matching 126.96.36.199[C=DE, O=robidu.de,CN=<user>@rw.robidu.de]...188.8.131.52[<user>@rw.robidu.de]
There is something wrong with the rightid on the client. Did you configure the user certificate as server certificate in the GUI? You need to either configure the CA certificate or the server certificate.
#2 Updated by Olaf Martens about 7 years ago
O.k., then I have been mistaken from a previous setup that had some cert problems that caused StrongSwan to default to the leftid and rightid set in the configs.
Setting the server cert in the GUI actually resolved the problem - now only the RADIUS server hiccups with the credentials.
#4 Updated by Olaf Martens about 7 years ago
RADIUS misbehaved after an update to a new major release, because it didn't know the users that I had set any more, and even though StrongSwan could find the proper selector for the connection, it nevertheless got rejected (I'm using EAP to authenticate against a RADIUS server).
It took me some time to figure out the cause, because the location of the credentials had changed with the update.
Anyway, the issue is completely resolved now. Thanks.