0

I'm a bit stuck with configuring strongswan to connect to my office network as it refuses to verifiy the right side in any way, i was wondering if anyone knows of a way to just tell strongswan to ignore the server certificate and finish connecting? or if there is a way to download the right side certificate so i could at least use rightcert to force it to recognize the right side.

I don't unfortuantly have access to the configuration of the server that i'm connecting to (/ can't change it without it being a pita) but this is what i can tell about it without being given access to the configuration, also the network admin only supports windows so i'm pretty much on my own when asking questions about this.

  • The VPN server software is running on a firewall box which is using an ancient copy of smoothwall
  • VPN server is Openswan 2.6.38
  • It doesn't have a default local certificate setup so seems to just select the 1st client certificate that was generated instead which is then spit out in the logs below on the "received end entity cert" line
  • All the certificates have been generated with the same CA

Here is the relevant errors from the strongswan logs

16[ENC] received unknown vendor ID: 49:4b:45:76:32
16[IKE] received end entity cert "<some cert with no fqn or ip in the cn>" #for example C=AB, ST=CD, L=CD, O=Example Org, OU=IT, CN=made_up_thing, [email protected]
16[IKE] no trusted RSA public key found for '<server ip>'

Here's the contents of my ipsec.conf with ip's and cert values removed

config setup
        charondebug="ike 2, cfg 2, enc 2"

conn %default
        ikelifetime=480m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        ike=3des-sha1-modp1024,3des-sha1-modp2048,aes128-sha1-modp1024,aes256-sha1-modp1024,aes128-sha1-modp2048,aes256-sha1-modp2048
        #ike=3des-md5;modp1024,aes-sha1;modp1536,aes-sha1;modp1024

conn office
        left=%any
        leftcert=/etc/vpn.crt
        leftid="CN=client blah, O=org, ST=uk, ..." #actual value match dn from /etc/vpn.crt
        leftauth=pubkey
        leftfirewall=yes
        right=<server ip>
        rightsubnet=192.168.3.0/24
        rightca="CN=ca blah, O=org, ST=uk, ..." #actual value match dn from /etc/ipsec.d/cacerts/ca.pem
        auto=add

From what i understand after reading https://wiki.strongswan.org/issues/940 strongswan is suppose to check the right side certificate is signed by the same CA and move along but i suspect as the rightid doesn't match the cert in anyway it's just throwing it hands up and refusing, although it could also be openswan is not sending along the CA cert as i don't see "sending issuer cert " in the logs although as i have a copy of the CA cert i don't think this should cause any issues.

Update 1:

As suggested trying rightid=%any i see the same result in the logs as not having it no trusted RSA public key found for '<server ip>'

if i change the value to be the cn value from the logs so in my example above it was "made_up_thing" it still fails but the logs show 11[IKE] IDir '<server ip>' does not match to 'made_up_thing'

Improve this question

1 Answer 1

Reset to default
1

Your problem is that you didn't specify rightid, in which case it defaults to the remote's IP address. Since that usually is not contained as subjectAltName in the certificate the authentication will fail with the error you saw.

To fix this set rightid to either the full subject DN of the remote's certificate or to one of its subjectAltNames (if it contains any). If you are desperate, you may set rightid=%any so any peer with an accepted certificate can authenticate.

Improve this answer
3
  • i get exactly the same error when using rightid=%any and when using the cn value from the logs i get IDir '<server ip>' does not match to '<cn value>'
    – Snipzwolf
    Commented Aug 13, 2019 at 17:19
  • 1
    Ah, I see. So the other peer actually authenticates with its IP address even though it is not contained in the certificate? That won't work with strongSwan unless you modify the source code. The identity the peer actually uses has to be contained in the certificate (either as subjectAltName or it must be the full subject DN). So if you can't change the peer's config, so it e.g. uses the subject DN as identity, this won't work.
    – ecdsa
    Commented Aug 14, 2019 at 9:35
  • That seems to be the case, i might try using the same version of openswan to see if i can get that to connect to it as presumably if it supports this kind of config maybe it will be able to connect to it too. What i find odd is windows clients don't seem to care at all about all this weirdness but strongswan does.
    – Snipzwolf
    Commented Aug 15, 2019 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .