0

I have a StrongSwan VPN server set up on an Ubuntu 18.04 server, and it is working well. I am able to connect to this VPN from Windows 10 and macOS, and everything works wonderfully. The problem is that I can't get Linux to connect to this same VPN server using the StrongSwan client.

The Linux client is simply a road-warrior scenario where I am using charon-cmd to make an on-demand VPN connection, as follows:

root@ubuntu:~# charon-cmd --cert DigiCertCA.crt --host vpn.example.com --identity <myuser>

00[LIB] created TUN device: ipsec0
00[LIB] dropped capabilities, running as uid 0, gid 0
00[DMN] Starting charon-cmd IKE client (strongSwan 5.3.5, Linux 4.4.0-142-generic, x86_64)
00[LIB] loaded plugins: charon-cmd aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 sshkey pem openssl fips-prf gmp agent xcbc hmac ccm gcm kernel-libipsec kernel-netlink resolve socket-default eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic
00[JOB] spawning 16 worker threads
15[IKE] initiating IKE_SA cmd[1] to XX.YYY.199.103
15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
15[NET] sending packet: from 192.168.1.29[60971] to XX.YYY.199.103[4500] (1256 bytes)
16[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[60971] (38 bytes)
16[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
16[IKE] peer didn't accept DH group MODP_2048, it requested MODP_3072
16[IKE] initiating IKE_SA cmd[1] to XX.YYY.199.103
16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
16[NET] sending packet: from 192.168.1.29[60971] to XX.YYY.199.103[4500] (1384 bytes)
05[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[60971] (584 bytes)
05[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH) ]
05[IKE] local host is behind NAT, sending keep alives
05[IKE] remote host is behind NAT
05[IKE] establishing CHILD_SA cmd
05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
05[NET] sending packet: from 192.168.1.29[50969] to XX.YYY.199.103[4500] (304 bytes)
04[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[50969] (3408 bytes)
04[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID N(AUTH_FOLLOWS) ]
04[IKE] received end entity cert "C=US, ST=Massachusetts, L=Needham Heights, O=Example Corporation, CN=*.example.com"
04[IKE] received issuer cert "C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1"
04[IKE] no trusted RSA public key found for '10.1.1.4'
04[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
04[NET] sending packet: from 192.168.1.29[50969] to XX.YYY.199.103[4500] (80 bytes)

Note that the error near the end of the above log is "no trusted RSA public key found for 10.1.1.4". That IP address is the NAT-ed "internal" IP address of the StrongSwan server machine. The public-facing IP address of this same machine is XX.YY.199.103.

On the charon-cmd command-line, I specify --cert DigiCertCA.crt because this is the intermediate certificate from the CA that issued our primary certificate for this server.

I've googled the error "no trusted RSA public key found for (IP-addr)" and found some discussion, but none of the suggestions have helped me so far. Can someone please help to troubleshoot this problem? I have re-issued the certificate with a SAN name that exactly matches the name that the client is using to connect, because I understand that StrongSwan generally doesn't like wildcard certificates. But adding the SAN name didn't help.

Here is the server-side configuration for StrongSwan. Keep in mind that all of this server configuration works correctly when connecting from Windows 10 and macOS.

Server-side File: /etc/ipsec.conf

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn ikev2-vpn
    auto=add
    ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@*.example.com
    leftcert=example_com.crt
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.1.0/16
    rightdns=8.8.8.8,8.8.4.4
    rightsendcert=never
    eap_identity=%identity

Server Certificate (real domain-name changed to example.com for this discussion, but everything else is exact). Note that this is a wildcard certificate where the "CN" name has an asterisk. However, also note that there is a SAN (subject alternative name) with the exact name that I am using from the client to reach the server, in this case it is vpn.example.com.

root@base:/etc/ipsec.d/certs# openssl x509 -in example_com.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            09:11:4c:4d:84:9b:3a:c4:16:31:d8:4b:12:52:1b:0f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
        Validity
            Not Before: Apr 22 00:00:00 2021 GMT
            Not After : May 23 23:59:59 2022 GMT
        Subject: C = US, ST = Massachusetts, L = Needham Heights, O = Example Corporation, CN = *.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:af:76:1f:f6:9a:e4:a5:2f:12:f1:e3:80:de:46:
                    4e:61:39:17:87:9d:d0:d5:13:9a:2e:8d:aa:cb:2a:
                    1c:28:8e:27:27:54:df:bb:c9:2a:fb:74:a1:b0:96:
                    1c:21:3d:26:8f:63:03:1b:45:36:6b:a3:46:07:dd:
                    44:6e:a6:db:e5:db:e5:4d:5f:e2:5a:21:5e:d4:a2:
                    d6:02:11:71:4b:89:8e:93:dd:d2:ef:13:b2:55:74:
                    d4:eb:e1:ad:ec:70:76:b3:8b:a8:f0:ae:60:39:f2:
                    1e:5b:f6:a7:a6:e3:ad:b5:8c:6b:a5:25:fa:fc:ac:
                    05:03:16:ab:77:37:d4:14:8c:28:46:9e:37:f7:d9:
                    3c:63:4e:a5:ea:e7:14:0c:46:e9:43:4b:45:f9:f6:
                    8f:6c:db:6d:da:9b:1d:98:d5:e3:dd:be:a2:8f:2a:
                    d2:66:e6:92:38:49:aa:e4:4b:52:8b:c2:28:79:f6:
                    32:94:99:56:78:5a:b3:c3:98:cd:f8:fd:2b:37:e8:
                    25:ae:5b:31:43:82:42:d2:35:95:c3:53:d0:31:09:
                    da:61:23:4c:08:42:68:08:50:d2:ef:26:60:5d:01:
                    9f:6f:ed:25:40:02:98:29:e9:19:bf:7f:98:b5:45:
                    4c:c8:5d:1d:8f:31:da:bc:de:42:45:ed:51:2e:da:
                    7f:5d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4
            X509v3 Subject Key Identifier:
                E2:30:0F:0F:D7:96:0B:BE:4A:19:55:54:2B:D4:1A:2F:E9:11:40:A3
            X509v3 Subject Alternative Name:
                DNS:*.example.com, DNS:example.com, DNS:vpn.example.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1.crl
                Full Name:
                  URI:http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1.crl
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.2
                  CPS: http://www.digicert.com/CPS
            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1.crt
            X509v3 Basic Constraints: critical
                CA:FALSE
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D:                                11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47
                    Timestamp : Apr 22 20:58:13.047 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:55:BC:68:21:95:C6:A7:AF:82:B9:BC:C3:
                                2B:82:49:E5:F9:88:EA:90:96:8B:27:17:4A:5D:E1:B3:
                                F2:D3:03:92:02:20:0D:24:0B:20:5D:17:F6:5A:F9:67:
                                5B:A4:67:A2:64:8F:F4:9C:F7:95:A2:30:BE:AC:69:57:
                                EB:3F:2D:EC:70:7E
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 22:45:45:07:59:55:24:56:96:3F:A1:2F:F1:F7:6D:86:                                E0:23:26:63:AD:C0:4B:7F:5D:C6:83:5C:6E:E2:0F:02
                    Timestamp : Apr 22 20:58:12.955 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:AC:04:98:CB:33:16:0A:5E:A6:83:AA:
                                20:BB:B2:15:00:73:6B:BA:B6:DD:AB:8C:BF:4E:09:42:
                                43:AF:BF:CA:7F:02:20:23:29:7D:F7:3E:6F:C5:70:CE:
                                8F:E1:40:B7:F9:84:39:29:D0:06:12:7B:58:4A:11:D9:
                                8A:14:60:D1:CF:51:3A
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 41:C8:CA:B1:DF:22:46:4A:10:C6:A1:3A:09:42:87:5E:                                4E:31:8B:1B:03:EB:EB:4B:C7:68:F0:90:62:96:06:F6
                    Timestamp : Apr 22 20:58:12.964 2021 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:15:E7:1D:C7:A4:61:33:A8:41:91:42:FD:
                                53:31:98:AB:ED:20:07:12:2A:FA:D7:AA:86:67:44:88:
                                29:41:7A:6B:02:21:00:EE:1A:9C:7E:80:30:1E:26:D3:
                                6E:2A:BF:32:C9:46:AB:C3:F1:9D:85:F8:71:B9:75:D9:
                                1F:DE:86:58:84:C1:32
    Signature Algorithm: sha256WithRSAEncryption
         46:80:80:28:cf:e2:95:e4:1e:ef:40:12:fb:c8:d9:5b:57:1e:
         cd:b1:8c:94:11:87:ec:09:b7:43:57:27:79:f6:61:38:86:ba:
         3b:f7:b9:16:79:b4:c9:86:d5:cf:d8:49:9e:ec:a1:a1:d5:1d:
         e0:6c:9d:38:71:6c:f6:f2:90:3a:88:18:cc:6d:d1:c0:90:2d:
         bb:e4:96:be:e6:b3:cb:04:af:09:6c:e5:b9:17:e7:6d:45:1e:
         42:c5:eb:ef:e2:3f:91:55:76:39:1b:2c:75:12:d9:a1:bd:2e:
         bc:18:f8:e8:ed:f4:be:75:5b:c6:0d:6a:ec:6a:3d:15:d9:7c:
         35:5d:98:46:bf:10:d7:56:7b:a2:55:23:29:21:3c:2e:3e:6f:
         39:0f:0d:a0:a6:3e:3d:9c:70:b9:0c:ce:92:2b:7b:ca:bb:67:
         97:1e:1a:a8:08:c7:54:b4:96:79:00:32:9b:50:b5:1f:09:d9:
         ab:be:aa:42:1d:68:a1:87:a1:26:36:a4:f4:c7:56:27:20:72:
         c6:f5:f6:47:ee:ac:9e:b3:03:9e:95:0e:f0:61:cb:a6:75:71:
         11:c6:ee:fb:44:08:e1:25:3c:77:9a:99:97:2a:62:56:54:99:
         8e:3d:a7:4b:cc:20:38:23:d5:c5:b5:9f:67:0f:c8:6c:5f:f2:
         f2:6d:e4:32

CA certificate from DigiCert. I have a copy of this certificate on the client-side and am specifying this file in the --cert argument of "charon-cmd".

root@base:/etc/ipsec.d/cacerts# openssl x509 -in DigiCertCA.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:35:08:d5:5c:29:2b:01:7d:f8:ad:65:c0:0f:f7:e4
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Validity
            Not Before: Sep 24 00:00:00 2020 GMT
            Not After : Sep 23 23:59:59 2030 GMT
        Subject: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c1:4b:b3:65:47:70:bc:dd:4f:58:db:ec:9c:ed:
                    c3:66:e5:1f:31:13:54:ad:4a:66:46:1f:2c:0a:ec:
                    64:07:e5:2e:dc:dc:b9:0a:20:ed:df:e3:c4:d0:9e:
                    9a:a9:7a:1d:82:88:e5:11:56:db:1e:9f:58:c2:51:
                    e7:2c:34:0d:2e:d2:92:e1:56:cb:f1:79:5f:b3:bb:
                    87:ca:25:03:7b:9a:52:41:66:10:60:4f:57:13:49:
                    f0:e8:37:67:83:df:e7:d3:4b:67:4c:22:51:a6:df:
                    0e:99:10:ed:57:51:74:26:e2:7d:c7:ca:62:2e:13:
                    1b:7f:23:88:25:53:6f:c1:34:58:00:8b:84:ff:f8:
                    be:a7:58:49:22:7b:96:ad:a2:88:9b:15:bc:a0:7c:
                    df:e9:51:a8:d5:b0:ed:37:e2:36:b4:82:4b:62:b5:
                    49:9a:ec:c7:67:d6:e3:3e:f5:e3:d6:12:5e:44:f1:
                    bf:71:42:7d:58:84:03:80:b1:81:01:fa:f9:ca:32:
                    bb:b4:8e:27:87:27:c5:2b:74:d4:a8:d6:97:de:c3:
                    64:f9:ca:ce:53:a2:56:bc:78:17:8e:49:03:29:ae:
                    fb:49:4f:a4:15:b9:ce:f2:5c:19:57:6d:6b:79:a7:
                    2b:a2:27:20:13:b5:d0:3d:40:d3:21:30:07:93:ea:
                    99:f5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4
            X509v3 Authority Key Identifier:
                keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalRootCA.crt
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl
                Full Name:
                  URI:http://crl4.digicert.com/DigiCertGlobalRootCA.crl
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.1
                Policy: 2.23.140.1.2.1
                Policy: 2.23.140.1.2.2
                Policy: 2.23.140.1.2.3
    Signature Algorithm: sha256WithRSAEncryption
         77:ab:b7:7a:27:3d:ae:bb:f6:7f:e0:5a:56:c9:84:aa:ca:5b:
         71:17:dd:22:47:fc:4e:9f:ee:d0:c1:a4:04:e1:a3:eb:c5:49:
         c1:fd:d1:c9:df:8c:af:94:45:2c:46:2a:a3:63:39:20:f9:9e:
         4a:24:94:41:c8:a9:d9:e2:9c:54:05:06:cb:5c:1c:be:00:1b:
         0f:a8:5a:ff:19:bb:65:c7:16:af:21:56:dd:61:05:c9:e9:8f:
         98:76:df:6b:1b:d0:72:0c:50:b9:30:29:7a:bf:60:59:10:66:
         13:3a:2d:ac:15:11:6c:2d:23:0c:02:3e:05:3b:fe:e5:a1:9c:
         e2:8a:db:87:d7:4a:e8:5e:e7:48:06:eb:ab:12:9a:f2:af:84:
         c3:5b:83:4a:99:81:83:ab:00:a1:ca:0a:3c:4c:a2:25:89:2a:
         22:a7:a4:f3:33:4c:5b:8c:2e:1a:02:97:0f:9d:8f:6d:2d:95:
         08:fb:4f:da:f1:91:38:25:e1:9c:6e:61:18:87:6a:ce:b1:bb:
         00:30:6a:9b:b7:af:da:f1:c5:97:fe:8a:78:24:aa:ea:93:80:
         ba:33:65:7a:bc:a1:77:e9:7f:69:14:0b:00:3f:77:92:b1:4d:
         5b:73:87:0a:13:d0:9c:c8:f2:4b:39:4f:52:84:49:a6:4c:90:
         4e:1f:f7:b4
0

Well for anyone that stumbles upon this in the future, the solution was to modify the /etc/ipsec.conf file as follows:

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn ikev2-vpn
    auto=add
    ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=vpn.example.com
    leftcert=example_com.crt
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.1.0/16
    rightdns=8.8.8.8,8.8.4.4
    rightsendcert=never
    eap_identity=%identity

I guess StrongSwan is super-picky about the "leftid" parameter-- it must exactly match what's in the certificate's SAN name, and it must exactly match what's in the --host parameter of charon-cmd.

Would be nice if the StrongSwan had a log message telling you WHY there is "no trusted RSA public key found for 10.1.1.4". Instead, it's hours and hours of trial and error and groping around in the dark trying this and that at random.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.