Score:0

Failed to start the IKEv2 VPN connection to surfshark via NetworkManager

us flag

I try to connect to surfshark VPN provider through IKEv2 manually. Here are the logs

 charon-nm[5070]: 05[CFG] received initiate for NetworkManager connection Surfshark IKE2
 charon-nm[5070]: 05[CFG] using gateway identity 'ru-mos.prod.surfshark.com'
 charon-nm[5070]: 05[IKE] initiating IKE_SA Surfshark IKE2[1] to 92.38.138.139
 charon-nm[5070]: 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[5070]: 05[NET] sending packet: from 192.168.2.35[35071] to 92.38.138.139[500] (1096 bytes)
 NetworkManager[4583]: <info>  [1636055533.4566] vpn-connection[0x56150178a510,6c89b390-d6ee-47d8-a547-346f75797487,"Surfshark IKE2",0]: VPN plugin: state changed: starting (3)
 charon-nm[5070]: 15[NET] received packet: from 92.38.138.139[500] to 192.168.2.35[35071] (38 bytes)
 charon-nm[5070]: 15[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
 charon-nm[5070]: 15[IKE] peer didn't accept DH group ECP_256, it requested ECP_521
 charon-nm[5070]: 15[IKE] initiating IKE_SA Surfshark IKE2[1] to 92.38.138.139
 charon-nm[5070]: 15[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[5070]: 15[NET] sending packet: from 192.168.2.35[35071] to 92.38.138.139[500] (1164 bytes)
 charon-nm[5070]: 01[NET] received packet: from 92.38.138.139[500] to 192.168.2.35[35071] (332 bytes)
 charon-nm[5070]: 01[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
 charon-nm[5070]: 01[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
 charon-nm[5070]: 01[IKE] local host is behind NAT, sending keep alives
 charon-nm[5070]: 01[IKE] sending cert request for "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 01[IKE] establishing CHILD_SA Surfshark IKE2{1}
 charon-nm[5070]: 01[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
 charon-nm[5070]: 01[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (438 bytes)
 charon-nm[5070]: 07[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (1248 bytes)
 charon-nm[5070]: 07[ENC] parsed IKE_AUTH response 1 [ EF(1/3) ]
 charon-nm[5070]: 07[ENC] received fragment #1 of 3, waiting for complete IKE message
 charon-nm[5070]: 08[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (1248 bytes)
 charon-nm[5070]: 08[ENC] parsed IKE_AUTH response 1 [ EF(2/3) ]
 charon-nm[5070]: 08[ENC] received fragment #2 of 3, waiting for complete IKE message
 charon-nm[5070]: 09[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (579 bytes)
 charon-nm[5070]: 09[ENC] parsed IKE_AUTH response 1 [ EF(3/3) ]
 charon-nm[5070]: 09[ENC] received fragment #3 of 3, reassembled fragmented IKE message (2949 bytes)
 charon-nm[5070]: 09[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
 charon-nm[5070]: 09[IKE] received end entity cert "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[IKE] received issuer cert "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG]   using certificate "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG]   using untrusted intermediate certificate "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG] checking certificate status of "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] certificate status is not available
 charon-nm[5070]: 09[CFG]   using trusted ca certificate "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 09[CFG] checking certificate status of "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG] certificate status is not available
 charon-nm[5070]: 09[CFG]   reached self-signed root ca with a path length of 1
 charon-nm[5070]: 09[IKE] authentication of 'ru-mos.prod.surfshark.com' with RSA_EMSA_PKCS1_SHA2_256 successful
 charon-nm[5070]: 09[IKE] server requested EAP_IDENTITY (id 0x00), sending 'mYidENtitY'
 charon-nm[5070]: 09[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
 charon-nm[5070]: 09[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (90 bytes)
 charon-nm[5070]: 10[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (67 bytes)
 charon-nm[5070]: 10[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 10[IKE] server requested EAP_PEAP authentication (id 0x01)
 charon-nm[5070]: 10[TLS] EAP_PEAP version is v0
 charon-nm[5070]: 10[ENC] generating IKE_AUTH request 3 [ EAP/RES/PEAP ]
 charon-nm[5070]: 10[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (275 bytes)
 charon-nm[5070]: 11[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (1065 bytes)
 charon-nm[5070]: 11[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 11[TLS] negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 charon-nm[5070]: 11[ENC] generating IKE_AUTH request 4 [ EAP/RES/PEAP ]
 charon-nm[5070]: 11[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (67 bytes)
 charon-nm[5070]: 12[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (1061 bytes)
 charon-nm[5070]: 12[ENC] parsed IKE_AUTH response 4 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 12[ENC] generating IKE_AUTH request 5 [ EAP/RES/PEAP ]
 charon-nm[5070]: 12[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (67 bytes)
 charon-nm[5070]: 13[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (747 bytes)
 charon-nm[5070]: 13[ENC] parsed IKE_AUTH response 5 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 13[TLS] received TLS server certificate 'C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]'
 charon-nm[5070]: 13[TLS] received TLS intermediate certificate 'C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority'
 charon-nm[5070]: 13[CFG]   using certificate "C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]"
 charon-nm[5070]: 13[CFG]   using untrusted intermediate certificate "C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority"
 charon-nm[5070]: 13[CFG] subject certificate invalid (valid from Apr 12 17:41:01 2021 to Jun 11 17:41:01 2021)
 charon-nm[5070]: 13[TLS] no TLS public key found for server '%any'
 charon-nm[5070]: 13[TLS] sending fatal TLS alert 'certificate unknown'
 charon-nm[5070]: 13[ENC] generating IKE_AUTH request 6 [ EAP/RES/PEAP ]
 charon-nm[5070]: 13[NET] sending packet: from 192.168.2.35[58480] to 92.38.138.139[4500] (74 bytes)
 charon-nm[5070]: 14[NET] received packet: from 92.38.138.139[4500] to 192.168.2.35[58480] (65 bytes)
 charon-nm[5070]: 14[ENC] parsed IKE_AUTH response 6 [ EAP/FAIL ]
 charon-nm[5070]: 14[IKE] received EAP_FAILURE, EAP authentication failed

Everything looks fine until at response 5 I get some weird certificate. I don't know how exactly the PEAP protocol goes, and what is supposed to happen on that step, but the connection works on windows, so I assume there is a problem on my end.

Score:1
cn flag
charon-nm[5070]: 13[CFG] subject certificate invalid (valid from Apr 12 17:41:01 2021 to Jun 11 17:41:01 2021)

Apparently, the certificate of the RADIUS server that requested EAP-PEAP has expired, but the subject with all that "example" stuff looks weird anyway (unless you modified that). Why Windows would accept that, if it actually uses EAP-PEAP, I don't know.

You could try to disable the eap-peap plugin and hope the server supports other EAP methods (e.g. EAP-MD5 or EAP-MSCHAPv2). To do so add the following to strongswan.conf:

charon-nm {
  plugins {
    eap-peap {
      load = no
    }
  }
}
us flag
Yep, disabling eap-peap worked. Basically, every other protocol worked. Could there be a reason why specifically eap-peap configuration is broken? I don't think they did it on purpose. Also, is there a way to disable the plugin for just one connection? It feels wrong to disable it system-wide for just one server. It doesn't matter for me, since I don't plan to make other IKEv2 connections, but still.
cn flag
That "example" stuff looks like a test certificate. So maybe they are not even aware that it's still enabled or misconfigured (possible that it just works with other clients, either because they ignore the cert, or they don't support EAP-PEAP). It's the first method the server requests, though, it's not that it requests a different one and the client demands a switch to it. Other EAP methods (e.g. those I listed above) don't use certificates on the RADIUS server, so... And no, EAP methods can't be disabled per connection. It's possible to select a method in connection configs, but not via NM.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.