NetworkManager and IPsec on Ubuntu 18.04
Describe the bug
NetworkManager strongSwan plugin works on Ubuntu 18.04, but it needed some minor tweak on the server side: leftid=fqdn.tld should be replaced with leftid="CN=fqdn.tld" in /etc/ipsec.conf.
However, this "workaround" seems to break macOS clients configured with *.mobileconfig files.
To Reproduce
Steps to reproduce the behavior:
- I installed algo. Server is running behind ip44 NAT (Scaleway network), internal IPv4 is
10.19.70.131. It also has IPv6 connectivity. Domain name pointing to the server iswafl.darkk.net.ru, it has bothA(51.158.182.23) andAAAArecords. I installed algo on an existing server and used the following options:
Enter the IP address of your server: (or use localhost for local installation):
localhost
Enter the public IP address or domain name of your server: (IMPORTANT! This is used to verify the certificate)
wafl.darkk.net.ru
Algo version: 9f241b188693c80e4a9abc0d9683f670719ab18d, Server is Ubuntu 20.04.4 LTS, algo/configs/wafl.darkk.net.ru/.config.yml is the following:
server: localhost
server_user: root
ansible_ssh_port: "22"
algo_provider: local
algo_server_name: algo
algo_ondemand_cellular: False
algo_ondemand_wifi: False
algo_ondemand_wifi_exclude: X251bGw=
algo_dns_adblocking: False
algo_ssh_tunneling: False
algo_store_pki: True
IP_subject_alt_name: wafl.darkk.net.ru
ipsec_enabled: True
wireguard_enabled: True
- I configured Ubuntu 18.04.6 LTS client with
network-manager-strongswanusing instructions for Network Manager configuration andcacert.pemas Gateway Certificate. The client fails to connect,/var/log/syslogcomplains aboutunsupported critical X.509 extension: X509v3 Name Constraints, it's documented in strongSwan tracker and #1758.
NetworkManager[1202]: <info> [1649413388.0619] audit: op="connection-activate" uuid="afcc7962-fc99-4ce4-ba10-0e65791367cc" name="wafl, NL, IPsec" pid=19895 uid=1000 result="success"
NetworkManager[1202]: <info> [1649413388.0939] vpn-connection[0x5637fb0ae740,afcc7962-fc99-4ce4-ba10-0e65791367cc,"wafl, NL, IPsec",0]: Saw the service appear; activating connection
NetworkManager[1202]: <info> [1649413388.1199] vpn-connection[0x5637fb0ae740,afcc7962-fc99-4ce4-ba10-0e65791367cc,"wafl, NL, IPsec",0]: VPN connection: (ConnectInteractive) reply received
gnome-shell[2217]: JS ERROR: TypeError: item is undefined#012setActiveConnections/<@resource:///org/gnome/shell/ui/status/network.js:1520:17#012setActiveConnections@resource:///org/gnome/shell/ui/status/network.js:1517:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_syncVpnConnections@resource:///org/gnome/shell/ui/status/network.js:1855:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22
charon-nm: 05[CFG] received initiate for NetworkManager connection wafl, NL, IPsec
NetworkManager[1202]: <warn> [1649413388.1308] vpn-connection[0x5637fb0ae740,afcc7962-fc99-4ce4-ba10-0e65791367cc,"wafl, NL, IPsec",0]: VPN connection: failed to connect: 'Loading gateway certificate failed.'
charon-nm: 05[LIB] found unsupported critical X.509 extension: X509v3 Name Constraints
charon-nm: 05[LIB] OpenSSL X.509 parsing failed
charon-nm: 05[LIB] building CRED_CERTIFICATE - X509 failed, tried 4 builders
:lady_beetle: The certificate lists only IPv6 address for the domain name wafl.darkk.net.ru as a Permitted name in the constraints:
$ openssl x509 -text < cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
7b:3a:2f:d3:8b:11:7e:2a:30:f1:ac:ad:04:11:08:21:a4:00:e0:99
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = wafl.darkk.net.ru
Validity
Not Before: Mar 23 11:46:03 2022 GMT
Not After : Mar 20 11:46:03 2032 GMT
Subject: CN = wafl.darkk.net.ru
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:85:87:79:be:f7:e0:1d:6d:01:f0:a0:4c:c5:82:
14:6e:3a:48:e5:94:29:75:be:b6:04:90:47:a8:55:
ad:a2:59:c3:f8:0c:d8:4f:c9:22:63:e6:94:06:23:
cc:a8:e5:c4:47:f8:64:33:3f:89:87:43:ee:af:4e:
07:bb:cd:36:40:f0:92:ed:24:2a:1f:c8:b8:74:60:
e1:96:f1:f9:5e:b2:4c:3b:93:5b:ae:b5:04:30:9e:
4a:b2:5e:88:f4:99:cd
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Subject Key Identifier:
C8:B5:6F:42:E7:75:1A:C9:32:3B:93:DF:1A:2E:B1:AB:FB:C6:AC:BB
X509v3 Authority Key Identifier:
keyid:C8:B5:6F:42:E7:75:1A:C9:32:3B:93:DF:1A:2E:B1:AB:FB:C6:AC:BB
DirName:/CN=wafl.darkk.net.ru
serial:7B:3A:2F:D3:8B:11:7E:2A:30:F1:AC:AD:04:11:08:21:A4:00:E0:99
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Name Constraints: critical
Permitted:
DNS:wafl.darkk.net.ru
email:a1c89ee1-b26f-5131-b8db-81d1031d4dd7.algo
IP:2001:BC8:1830:341:0:0:0:1/FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Excluded:
IP:0.0.0.0/0.0.0.0
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256
30:65:02:31:00:e5:22:8c:63:62:4b:68:29:c6:0e:d2:98:ff:
7e:7f:2d:dd:47:8b:3a:99:4e:6f:04:31:b2:44:c7:a5:30:e4:
1a:db:a7:57:6a:10:a7:1a:a7:df:12:a1:1f:24:12:d2:c9:02:
30:3f:19:c0:78:70:a0:52:96:86:9f:d3:53:4a:07:50:8f:49:
be:76:fb:e8:58:7a:10:f2:77:d5:d2:05:8b:78:5d:d0:f5:2b:
62:6d:e4:c5:28:9e:0e:94:3a:90:f2:58:fc
-----BEGIN CERTIFICATE-----
MIICmzCCAiGgAwIBAgIUezov04sRfiow8aytBBEIIaQA4JkwCgYIKoZIzj0EAwIw
HDEaMBgGA1UEAwwRd2FmbC5kYXJray5uZXQucnUwHhcNMjIwMzIzMTE0NjAzWhcN
MzIwMzIwMTE0NjAzWjAcMRowGAYDVQQDDBF3YWZsLmRhcmtrLm5ldC5ydTB2MBAG
ByqGSM49AgEGBSuBBAAiA2IABIWHeb734B1tAfCgTMWCFG46SOWUKXW+tgSQR6hV
raJZw/gM2E/JImPmlAYjzKjlxEf4ZDM/iYdD7q9OB7vNNkDwku0kKh/IuHRg4Zbx
+V6yTDuTW661BDCeSrJeiPSZzaOCASIwggEeMB0GA1UdDgQWBBTItW9C53UayTI7
k98aLrGr+8asuzBXBgNVHSMEUDBOgBTItW9C53UayTI7k98aLrGr+8asu6EgpB4w
HDEaMBgGA1UEAwwRd2FmbC5kYXJray5uZXQucnWCFHs6L9OLEX4qMPGsrQQRCCGk
AOCZMBIGA1UdEwEB/wQIMAYBAf8CAQAwgYIGA1UdHgEB/wR4MHagZjATghF3YWZs
LmRhcmtrLm5ldC5ydTArgSlhMWM4OWVlMS1iMjZmLTUxMzEtYjhkYi04MWQxMDMx
ZDRkZDcuYWxnbzAihyAgAQvIGDADQQAAAAAAAAAB/////////////////////6EM
MAqHCAAAAAAAAAAAMAsGA1UdDwQEAwIBBjAKBggqhkjOPQQDAgNoADBlAjEA5SKM
Y2JLaCnGDtKY/35/Ld1HizqZTm8EMbJEx6Uw5Brbp1dqEKcap98SoR8kEtLJAjA/
GcB4cKBSloaf01NKB1CPSb52++hYehDyd9XSBYt4XdD1K2Jt5MUong6UOpDyWPw=
-----END CERTIFICATE-----
- I configured the same client with
network-manager-strongswanusingwafl.darkk.net.ru.pemas Gateway Certificate. strongSwan NetworkManager manual allows that. Now the client is able to read the certificate but it fails to connect due to server reporting authentication problem:
charon-nm: 05[CFG] received initiate for NetworkManager connection wafl-ipsec
charon-nm: 05[CFG] using gateway certificate, identity 'CN=wafl.darkk.net.ru'
charon-nm: 05[IKE] initiating IKE_SA wafl-ipsec[9] to 51.158.182.23
charon-nm: 05[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
charon-nm: 05[NET] sending packet: from 192.168.100.9[59393] to 51.158.182.23[500] (294 bytes)
NetworkManager[1202]: <info> [1649347418.4118] vpn-connection[0x5637fb0ae740,afcc7962-fc99-4ce4-ba10-0e65791367cc,"wafl-ipsec",0]: VPN plugin: state changed: starting (3)
charon-nm: 11[NET] received packet: from 51.158.182.23[500] to 192.168.100.9[59393] (329 bytes)
charon-nm: 11[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
charon-nm: 11[IKE] local host is behind NAT, sending keep alives
charon-nm: 11[IKE] remote host is behind NAT
charon-nm: 11[IKE] received 1 cert requests for an unknown ca
charon-nm: 11[IKE] authentication of 'CN=leev-thinkpad' (myself) with ECDSA_WITH_SHA384_DER successful
charon-nm: 11[IKE] sending end entity cert "CN=leev-thinkpad"
charon-nm: 11[IKE] establishing CHILD_SA wafl-ipsec{9}
charon-nm: 11[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH CPRQ(ADDR DNS NBNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
charon-nm: 11[NET] sending packet: from 192.168.100.9[40761] to 51.158.182.23[4500] (1039 bytes)
charon-nm: 13[NET] received packet: from 51.158.182.23[4500] to 192.168.100.9[40761] (65 bytes)
charon-nm: 13[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
charon-nm: 13[IKE] received AUTHENTICATION_FAILED notify error
Server-side complains that no matching peer config found after looking for peer configs matching 10.19.70.131[CN=wafl.darkk.net.ru]...178.66.71.173[CN=leev-thinkpad]:
charon: 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
charon: 06[CFG] looking for an IKEv2 config for 10.19.70.131...178.66.71.173
charon: 06[CFG] candidate: %any...%any, prio 28
charon: 06[CFG] found matching ike config: %any...%any with prio 28
charon: 06[IKE] 178.66.71.173 is initiating an IKE_SA
charon: 06[IKE] IKE_SA (unnamed)[30] state change: CREATED => CONNECTING
charon: 06[CFG] selecting proposal:
charon: 06[CFG] proposal matches
charon: 06[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_384
charon: 06[CFG] configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_384
charon: 06[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_384
charon: 06[CFG] received supported signature hash algorithms: sha256 sha384 sha512
charon: 03[NET] waiting for data on sockets
charon: 06[IKE] local host is behind NAT, sending keep alives
charon: 06[IKE] remote host is behind NAT
charon: 06[CFG] sending supported signature hash algorithms: sha256 sha384 sha512 identity
charon: 06[IKE] sending cert request for "CN=wafl.darkk.net.ru"
charon: 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
charon: 06[NET] sending packet: from 10.19.70.131[500] to 178.66.71.173[59393] (329 bytes)
charon: 04[NET] sending packet: from 10.19.70.131[500] to 178.66.71.173[59393]
charon: 06[MGR] checkin IKE_SA (unnamed)[30]
charon: 06[MGR] checkin of IKE_SA successful
charon: 03[NET] received packet: from 178.66.71.173[40761] to 10.19.70.131[4500]
charon: 03[NET] waiting for data on sockets
charon: 08[MGR] checkout IKEv2 SA by message with SPIs d69e575b4b4e7baf_i 3ada9cea4a23f918_r
charon: 08[MGR] IKE_SA (unnamed)[30] successfully checked out
charon: 08[NET] received packet: from 178.66.71.173[40761] to 10.19.70.131[4500] (1039 bytes)
charon: 08[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH CPRQ(ADDR DNS NBNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_>
charon: 08[IKE] received end entity cert "CN=leev-thinkpad"
charon: 08[CFG] looking for peer configs matching 10.19.70.131[CN=wafl.darkk.net.ru]...178.66.71.173[CN=leev-thinkpad]
charon: 08[CFG] no matching peer config found
charon: 08[IKE] processing INTERNAL_IP4_ADDRESS attribute
charon: 08[IKE] processing INTERNAL_IP4_DNS attribute
charon: 08[IKE] processing INTERNAL_IP4_NBNS attribute
charon: 08[IKE] peer supports MOBIKE
charon: 08[IKE] got additional MOBIKE peer address: 192.168.123.1
charon: 08[IKE] got additional MOBIKE peer address: 172.17.0.1
charon: 08[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
charon: 08[NET] sending packet: from 10.19.70.131[4500] to 178.66.71.173[40761] (65 bytes)
charon: 04[NET] sending packet: from 10.19.70.131[4500] to 178.66.71.173[40761]
charon: 08[MGR] checkin and destroy IKE_SA (unnamed)[30]
Gateway Certificate also has two strange quirks:
- :warning: CN for the Gateway is exactly the same as CN for CA, both are
CN=wafl.darkk.net.ru. It's unclear to me if it's intentional. - :lady_beetle:
X509v3 Subject Alternative Namelists IPv6 address, but does not list IPv4 address:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=wafl.darkk.net.ru
Validity
Not Before: Mar 23 11:46:04 2022 GMT
Not After : Mar 20 11:46:04 2032 GMT
Subject: CN=wafl.darkk.net.ru
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:1c:b8:86:3f:2c:e9:ba:64:d0:32:b3:9a:3d:76:
8b:e3:9e:b1:f6:99:86:74:c2:d8:89:56:f4:89:69:
d4:ef:6a:ff:60:46:73:83:ce:ec:40:08:e4:ba:b9:
31:2e:13:71:76:8f:10:9f:61:25:39:a7:65:05:27:
b1:c0:48:81:5f:73:c5:1e:65:1f:dd:46:13:9a:f6:
cf:f2:f7:ab:fd:cc:55:ec:d3:7a:c3:24:3b:82:b1:
c7:5b:5f:f1:bd:23:2f
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
C0:42:52:D9:7E:25:B4:0B:C1:5E:87:E7:98:6E:DE:4B:3A:C7:7E:DB
X509v3 Authority Key Identifier:
keyid:C8:B5:6F:42:E7:75:1A:C9:32:3B:93:DF:1A:2E:B1:AB:FB:C6:AC:BB
DirName:/CN=wafl.darkk.net.ru
serial:7B:3A:2F:D3:8B:11:7E:2A:30:F1:AC:AD:04:11:08:21:A4:00:E0:99
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, ipsec Internet Key Exchange
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:wafl.darkk.net.ru, IP Address:2001:BC8:1830:341:0:0:0:1
Signature Algorithm: ecdsa-with-SHA256
30:65:02:30:08:ac:25:7f:23:d0:f9:e0:58:dc:f0:24:e7:94:
fd:2a:c3:9e:75:ed:57:02:e6:3a:f4:b3:9b:0a:06:ed:b7:fc:
1b:a4:07:e7:e7:d0:0f:b7:8c:69:e7:4a:4f:f7:83:c8:02:31:
00:83:71:e3:03:ad:9c:3a:e4:fe:8d:34:37:9f:2f:d3:f8:82:
65:d9:8f:d5:b6:5d:05:2f:5b:fa:6c:73:72:fb:a2:78:be:dd:
75:8a:8d:dc:b8:bf:a4:5e:dd:b9:f9:c0:67
-----BEGIN CERTIFICATE-----
MIICUTCCAdegAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBF3YWZsLmRh
cmtrLm5ldC5ydTAeFw0yMjAzMjMxMTQ2MDRaFw0zMjAzMjAxMTQ2MDRaMBwxGjAY
BgNVBAMMEXdhZmwuZGFya2submV0LnJ1MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE
HLiGPyzpumTQMrOaPXaL456x9pmGdMLYiVb0iWnU72r/YEZzg87sQAjkurkxLhNx
do8Qn2ElOadlBSexwEiBX3PFHmUf3UYTmvbP8ver/cxV7NN6wyQ7grHHW1/xvSMv
o4HsMIHpMAkGA1UdEwQCMAAwHQYDVR0OBBYEFMBCUtl+JbQLwV6H55hu3ks6x37b
MFcGA1UdIwRQME6AFMi1b0LndRrJMjuT3xousav7xqy7oSCkHjAcMRowGAYDVQQD
DBF3YWZsLmRhcmtrLm5ldC5ydYIUezov04sRfiow8aytBBEIIaQA4JkwJwYDVR0l
BCAwHgYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDETALBgNVHQ8EBAMCBaAw
LgYDVR0RBCcwJYIRd2FmbC5kYXJray5uZXQucnWHECABC8gYMANBAAAAAAAAAAEw
CgYIKoZIzj0EAwIDaAAwZQIwCKwlfyPQ+eBY3PAk55T9KsOede1XAuY69LObCgbt
t/wbpAfn59APt4xp50pP94PIAjEAg3HjA62cOuT+jTQ3ny/T+IJl2Y/Vtl0FL1v6
bHNy+6J4vt11io3cuL+kXt25+cBn
-----END CERTIFICATE-----
- I've replaced
leftid=wafl.darkk.net.ruwithleftid="CN=wafl.darkk.net.ru"in/etc/ipsec.conf— and it made connection possible.
The connection was working for this specific client using Gateway Certificate wafl.darkk.net.ru.crt. However, it's unclear to me what was the root cause for strongSwan to fail in this set-up with leftid=wafl.darkk.net.ru: is it dual-stack hostname, nat44 or something else.
Successful connection produces following logs on the server:
charon: 16[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH CPRQ(ADDR DNS NBNS) N(IPCOMP_SUP) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
charon: 16[IKE] received end entity cert "CN=leev-thinkpad"
charon: 16[CFG] looking for peer configs matching 10.19.70.131[CN=wafl.darkk.net.ru]...178.66.71.173[CN=leev-thinkpad]
charon: 16[CFG] candidate "ikev2-pubkey", match: 20/1/28 (me/other/ike)
charon: 16[CFG] selected peer config 'ikev2-pubkey'
charon: 16[CFG] using certificate "CN=leev-thinkpad"
charon: 16[CFG] certificate "CN=leev-thinkpad" key: 384 bit ECDSA
charon: 16[CFG] using trusted ca certificate "CN=wafl.darkk.net.ru"
charon: 16[CFG] checking certificate status of "CN=leev-thinkpad"
charon: 16[CFG] ocsp check skipped, no ocsp found
charon: 16[CFG] certificate status is not available
charon: 16[CFG] certificate "CN=wafl.darkk.net.ru" key: 384 bit ECDSA
charon: 16[CFG] reached self-signed root ca with a path length of 0
charon: 16[IKE] authentication of 'CN=leev-thinkpad' with ECDSA_WITH_SHA384_DER successful
charon: 16[IKE] processing INTERNAL_IP4_ADDRESS attribute
charon: 16[IKE] processing INTERNAL_IP4_DNS attribute
charon: 16[IKE] processing INTERNAL_IP4_NBNS attribute
charon: 16[IKE] peer supports MOBIKE
charon: 16[IKE] got additional MOBIKE peer address: 192.168.123.1
charon: 16[IKE] got additional MOBIKE peer address: 172.17.0.1
charon: 16[IKE] authentication of 'CN=wafl.darkk.net.ru' (myself) with ECDSA_WITH_SHA384_DER successful
charon: 16[IKE] IKE_SA ikev2-pubkey[11] established between 10.19.70.131[CN=wafl.darkk.net.ru]...178.66.71.173[CN=leev-thinkpad]
charon: 16[IKE] IKE_SA ikev2-pubkey[11] state change: CONNECTING => ESTABLISHED
charon: 16[IKE] sending end entity cert "CN=wafl.darkk.net.ru"
charon: 16[IKE] peer requested virtual IP %any
charon: 16[CFG] reassigning offline lease to 'CN=leev-thinkpad'
charon: 16[IKE] assigning virtual IP 10.149.0.1 to peer 'CN=leev-thinkpad'
- This workaround breaks macOS clients configured with current *.mobileconfig files. Peer lookup fails with the same symptoms:
charon: 03[NET] received packet: from 176.98.x.x[62445] to 10.19.70.131[4500]
charon: 15[MGR] checkout IKEv2 SA by message with SPIs f6ea5b5470c069b3_i dd64dd49bd7ea387_r
charon: 15[MGR] IKE_SA (unnamed)[9] successfully checked out
charon: 15[NET] received packet: from 176.98.x.x[62445] to 10.19.70.131[4500] (540 bytes)
charon: 15[ENC] parsed IKE_AUTH request 1 [ EF(1/3) ]
charon: 15[ENC] received duplicate fragment #1
charon: 15[MGR] checkin IKE_SA (unnamed)[9]
charon: 15[MGR] checkin of IKE_SA successful
charon: 15[MGR] checkout IKEv2 SA by message with SPIs f6ea5b5470c069b3_i dd64dd49bd7ea387_r
charon: 15[MGR] IKE_SA (unnamed)[9] successfully checked out
charon: 15[NET] received packet: from 176.98.x.x[62445] to 10.19.70.131[4500] (540 bytes)
charon: 15[ENC] parsed IKE_AUTH request 1 [ EF(2/3) ]
charon: 15[ENC] received fragment #2 of 3, reassembled fragmented IKE message (1118 bytes)
charon: 15[ENC] unknown attribute type INTERNAL_DNS_DOMAIN
charon: 15[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
charon: 15[IKE] received cert request for "CN=wafl.darkk.net.ru"
charon: 03[NET] waiting for data on sockets
charon: 03[NET] received packet: from 176.98.x.x[62445] to 10.19.70.131[4500]
charon: 06[MGR] checkout IKEv2 SA by message with SPIs f6ea5b5470c069b3_i dd64dd49bd7ea387_r
charon: 03[NET] waiting for data on sockets
charon: 15[IKE] received end entity cert "CN=mago-dev01"
charon: 15[CFG] looking for peer configs matching 10.19.70.131[wafl.darkk.net.ru]...176.98.x.x[[email protected]]
charon: 15[CFG] no matching peer config found
charon: 15[IKE] processing INTERNAL_IP4_ADDRESS attribute
charon: 15[IKE] processing INTERNAL_IP4_NETMASK attribute
charon: 15[IKE] processing INTERNAL_IP4_DHCP attribute
charon: 15[IKE] processing INTERNAL_IP4_DNS attribute
charon: 15[IKE] processing INTERNAL_IP6_ADDRESS attribute
charon: 15[IKE] processing INTERNAL_IP6_DHCP attribute
charon: 15[IKE] processing INTERNAL_IP6_DNS attribute
charon: 15[IKE] processing INTERNAL_DNS_DOMAIN attribute
charon: 15[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 15[IKE] peer supports MOBIKE
charon: 15[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
charon: 15[NET] sending packet: from 10.19.70.131[4500] to 176.98.x.x[62445] (65 bytes)
charon: 04[NET] sending packet: from 10.19.70.131[4500] to 176.98.x.x[62445]
charon: 15[MGR] checkin and destroy IKE_SA (unnamed)[9]
charon: 06[MGR] IKE_SA checkout not successful
charon: 15[IKE] IKE_SA (unnamed)[9] state change: CONNECTING => DESTROYING
charon: 15[MGR] checkin and destroy of IKE_SA successful
Expected behavior
- I expect IPv4 addresses to be put in the certificates SANs as well as IPv6
- I expect Algo to complain in case if dual-stack hostname is unacceptable for IPsec and/or wg-quick
- I expect CA Certificate and Gateway Certificate to have different DNs (unless there is a good reason for them to match)
I also want to understand if leftid="CN=wafl.darkk.net.ru" is the correct fix for this use-case.
Additional context
I'm aware that Ubuntu 18.04 strongSwan NetworkManager plugin does not support IPv6 per #559 and is suboptimal. Unfortunately wireguard NM plugin is not available for that version at all, so I decided to give IPsec a try.