strongSwan IKEv2 + Windows 7 Agile VPN: cosa causa l'errore 13801

Ho un'istanza AWS che voglio essere un server VPN. Connetterà i client Windows 7 a una rete privata nel cloud Amazon.

• Ho installato Ubuntu 12.04 e il strongswan-ikev2pacchetto.
• ipsec version rapporti Linux strongSwan U4.5.2/K3.2.0-52-virtual
• Si noti che sia il client che il server sono protetti da NAT (il client perché si trova su una rete di ufficio locale e il server perché si trova nel cloud di Amazon). Ho sbloccato le porte UDP 500 e 4500 sia sulla dashboard di Amazon che sul firewall del client.

• Questo è /etc/ipsec.conf:

  config setup
      plutostart=no
  
  conn %default
      keyexchange=ikev2
      ike=aes256-sha1-modp1024!
      esp=aes256-sha1!
      dpdaction=clear
      dpddelay=300s
      rekey=no
  
  conn win7vpn
      left=%any
      leftsubnet=<amazon VPC CIDR block>
      leftauth=pubkey
      leftcert=openssl-cert.pem
      leftid=<vpn server public dns name>
      right=%any
      rightsourceip=<amazon private IP address, which elastic ip is forwarded to>
      rightauth=eap-mschapv2
      rightsendcert=never
      eap_identity=%any
      auto=add
  

• Questo è /etc/ipsec.secrets:

  : RSA openssl-key.rsa
  TESTDOMAIN\testuser : EAP "testpassword"
  

• Ho aggiunto il certificato CA che ha firmato il certificato host del server nell'archivio certificati del computer locale (non utente) in modo che Windows possa autenticare il server.

Quindi provo a connettermi al server utilizzando il client Windows 7 come prescritto qui , con un'eccezione: sto usando il nome DNS anziché l'indirizzo IP. Inserisco nome utente, dominio e password nel mio file ipsec.secrets e tenta di connettersi.

Quando lo fa, ottengo i log di strongSwan che assomigliano a questo. Li ho mescolati un po 'sia per la censura che per la chiarezza; CLIENTPUB / CLIENTPRIV sono gli indirizzi IP pubblici e privati ​​del cliente e AMAZONPRIV è l'indirizzo IP privato del server (che è ciò che l'IP pubblico del server - Amazon lo definisce un "IP elastico" - inoltra a).

Sep  4 00:16:17 localhost charon: 14[IKE] CLIENTPUB is initiating an IKE_SA
Sep  4 00:16:17 localhost charon: 14[NET] received packet: from CLIENTPUB[500] to AMAZONPRIV[500]
Sep  4 00:16:17 localhost charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Sep  4 00:16:17 localhost charon: 14[IKE] CLIENTPUB is initiating an IKE_SA
Sep  4 00:16:17 localhost charon: 14[IKE] local host is behind NAT, sending keep alives
Sep  4 00:16:17 localhost charon: 14[IKE] remote host is behind NAT
Sep  4 00:16:17 localhost charon: 14[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Sep  4 00:16:17 localhost charon: 14[NET] sending packet: from AMAZONPRIV[500] to CLIENTPUB[500]
Sep  4 00:16:17 localhost charon: 15[NET] received packet: from CLIENTPUB[4500] to AMAZONPRIV[4500]
Sep  4 00:16:17 localhost charon: 15[ENC] unknown attribute type INTERNAL_IP4_SERVER
Sep  4 00:16:17 localhost charon: 15[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CP(ADDR DNS NBNS SRV) SA TSi TSr ]
Sep  4 00:16:17 localhost charon: 15[IKE] received cert request for "C=US, ST=TX, O=Test CA, CN=Test CA"
Sep  4 00:16:17 localhost charon: 15[IKE] received 316 cert requests for an unknown ca
Sep  4 00:16:17 localhost charon: 15[CFG] looking for peer configs matching AMAZONPRIV[%any]...CLIENTPUB[CLIENTPRIV]
Sep  4 00:16:17 localhost charon: 15[CFG] selected peer config 'dlpvpn'
Sep  4 00:16:17 localhost charon: 15[IKE] initiating EAP-Identity request
Sep  4 00:16:17 localhost charon: 15[IKE] peer supports MOBIKE
Sep  4 00:16:17 localhost charon: 15[IKE] authentication of 'C=US, ST=TX, O=DLP Test CA, CN=vpn.example.com' (myself) with RSA signature successful
Sep  4 00:16:17 localhost charon: 15[IKE] sending end entity cert "C=US, ST=TX, O=DLP Test CA, CN=vpn.example.com"
Sep  4 00:16:17 localhost charon: 15[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Sep  4 00:16:17 localhost charon: 15[NET] sending packet: from AMAZONPRIV[4500] to CLIENTPUB[4500]

A questo punto, Windows visualizza immediatamente un messaggio di errore:

Verifying user name and password...
Error 13801: IKE authentication credentials are unacceptable

Dopo alcuni secondi, charon riprova e quindi chiude la connessione.

Sep  4 00:16:37 localhost charon: 16[IKE] sending keep alive
Sep  4 00:16:37 localhost charon: 16[NET] sending packet: from AMAZONPRIV[4500] to CLIENTPUB[4500]
Sep  4 00:16:47 localhost charon: 03[JOB] deleting half open IKE_SA after timeout

E questo è tutto.

Per quanto ne so, sto seguendo tutte le istruzioni sul wiki di strongSwan.

Cosa sto facendo di sbagliato qui?

Modifica: questo è sicuramente un problema con i certificati. Ho disabilitato i controlli di validazione estesi modificando il registro e riavviando come descritto in MSKB926182 (lol se volevi un collegamento a quello) e ora posso collegarmi al mio server VPN senza errori. Scoprirò come generare certificati che soddisfano i requisiti e aggiungere una risposta. Grazie a @ecdsa per il puntatore alla pagina cert sul wiki di strongSwan che mi ha indicato nella giusta direzione.

Capito questo. @ecdsa mi ha indicato la giusta direzione e finalmente sono riuscito a risolvere il problema seguendo questa guida .

ipsec pki --gen --type rsa --size 4096 --outform pem > vpnca.key.pem
ipsec pki --self --flag serverAuth --in vpnca.key.pem --type rsa --digest sha1 \
    --dn "C=US, O=Example Company, CN=Example VPN CA" --ca > vpnca.crt.der
ipsec pki --gen --type rsa --size 4096 --outform pem > vpn.example.com.key.pem
ipsec pki --pub --in vpn.example.com.key.pem --type rsa > vpn.example.com.csr
ipsec pki --issue --cacert vpnca.crt.der --cakey vpnca.key.pem --digest sha1 \
    --dn "C=US, O=Example Company, CN=vpn.example.com" \
    --san "vpn.example.com" --flag serverAuth --outform pem \
    < vpn.example.com.csr > vpn.example.com.crt.pem 
openssl rsa -in vpn.example.com.key.pem -out vpn.example.com.key.der -outform DER

cp vpnca.crt.der /etc/ipsec.d/cacerts
cp vpn.example.com.crt.pem /etc/ipsec.d/certs
cp vpn.example.com.key.der /etc/ipsec.d/private

Sull'errore

Il messaggio di errore era "Errore 13801: le credenziali di autenticazione IKE sono inaccettabili", il che sembrava che le mie credenziali utente non funzionassero. Tuttavia, questo è un messaggio sull'autenticazione del server , che viene eseguito (secondo la mia configurazione) dal certificato SSL del server. Microsoft ha pubblicato la documentazione sulla risoluzione dei problemi relativi alle connessioni VPN IKEv2 che elenca le possibili cause di questo errore:

• Il certificato è scaduto
• La radice attendibile per il certificato non è presente sul client.
• Il nome soggetto del certificato non corrisponde al computer remoto.
• Al certificato non sono stati assegnati i valori EKU (Enhanced Key Usage) richiesti.

Nel mio caso, il mio problema riguardava i valori EKU. Seguendo la guida che ho collegato in alto, sono stato in grado di generare un certificato con i valori EKU corretti e ha funzionato alla grande.

Per risolvere questo problema, puoi disabilitare il controllo EKU sul tuo client Windows (ovviamente, questo dovrebbe essere fatto solo per il test):

• Lanciare regedit
• Navigare verso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters
• Aggiungi un DWORD chiamato DisableIKENameEkuChecke imposta il suo valore su1
• La documentazione di Microsoft ti dice di riavviare dopo aver fatto questo, ma non ho avuto bisogno per farlo avere effetto.

Ho avuto un problema identico e risolto assicurandomi di avere la catena di certificati nel file di certificato (certificato di entità finale, CA intermedia, CA principale - in quell'ordine). TLS è divertente.

Dopo aver riavviato strongSwan, questo ha smesso di funzionare, ma ha ripreso a funzionare quando ho lasciato cadere la CA intermedia e root /etc/ipsec.d/cacerts.

Dopo una lunga ricerca, questo thread ha fatto funzionare la mia configurazione di Windows Phone 10 (WP10) con IKEv2! Una cosa da menzionare potrebbe essere che devi ./configurare il tuo Strongswan con --enable-eap-identity --enable-eap-mschapv2 --enable-openssl (e probabilmente --enable-dhcp) per avere i plugin necessari. E sì, è necessario eseguire correttamente i certificati (sul lato server: il client deve solo conoscere la CA principale del server).