Project

General

Profile

Issue #1018

StrongSwan 5.1.3-4.11.1: Problems with conn matching - altName doesn't get matched

Added by Olaf Martens about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.1.3
Resolution:
No change required

Description

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=81.169.175.87
        leftfirewall=yes
        leftcert=central-servercert.der
        leftid="C=DE, O=robidu.de, CN=vpn@robidu.de" 
        reauth=yes
        compress=yes
        auto=route

conn backup-server
# This one works, and the link comes up without any problems.
        keyingtries=1
        right=85.214.197.171
        rightid="C=DE, O=robidu.de, CN=backup@robidu.de" 
        rightsendcert=yes
        mobike=no

conn rw-tls
# This one hiccups when attempting to establish a connection...
        forceencaps=yes
        leftsubnet=0.0.0.0/0
        rightid=*@rw.robidu.de
        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 95.91.229.136[1429] to 81.169.175.87[500] (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] 95.91.229.136 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 81.169.175.87[500] to 95.91.229.136[1429] (485 bytes)
Jul  4 11:00:46 16[NET] received packet: from 95.91.229.136[1424] to 81.169.175.87[4500] (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 81.169.175.87[C=DE, O=robidu.de,CN=<user>@rw.robidu.de]...95.91.229.136[<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 81.169.175.87[4500] to 95.91.229.136[1424] (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.

History

#1 Updated by Tobias Brunner about 5 years ago

  • Description updated (diff)
  • Status changed from New to Feedback

Jul 4 11:00:46 16[CFG] looking for peer configs matching 81.169.175.87[C=DE, O=robidu.de,CN=<user>@rw.robidu.de]...95.91.229.136[<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 5 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.

#3 Updated by Tobias Brunner about 5 years ago

now only the RADIUS server hiccups with the credentials.

What are you referring to?

#4 Updated by Olaf Martens about 5 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.

#5 Updated by Tobias Brunner about 5 years ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

OK, great. Thanks for the clarification.

Also available in: Atom PDF