strongSwan IKEv2 + Windows 7 Agiles VPN: Was verursacht Fehler 13801?


8

Ich habe eine AWS-Instanz, die ich als VPN-Server verwenden möchte. Es verbindet Windows 7-Clients mit einem privaten Netzwerk in der Amazon Cloud.

  • Ich habe Ubuntu 12.04 und das strongswan-ikev2Paket installiert .
  • ipsec version Berichte Linux strongSwan U4.5.2/K3.2.0-52-virtual
  • Beachten Sie, dass sich sowohl der Client als auch der Server hinter NAT befinden (der Client, weil er sich in einem lokalen Büronetzwerk befindet, und der Server, weil er sich in der Amazon-Cloud befindet). Ich habe die UDP-Ports 500 und 4500 sowohl im Amazon-Dashboard als auch in der Firewall des Clients entsperrt.
  • Dies ist /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
    
  • Dies ist /etc/ipsec.secrets:

    : RSA openssl-key.rsa
    TESTDOMAIN\testuser : EAP "testpassword"
    
  • Ich habe das CA-Zertifikat, das das Hostzertifikat des Servers signiert hat, zum Zertifikatspeicher des lokalen Computers (nicht des Benutzers) hinzugefügt, damit Windows den Server authentifizieren kann.

Ich versuche dann mit dem Server zu verbinden , um den Client Windows 7 verwenden , wie vorgeschrieben hier , mit einer Ausnahme - ich den DNS - Namen bin mit , anstatt die IP - Adresse. Ich gebe den Benutzernamen, die Domäne und das Kennwort in meine Datei ipsec.secrets ein und es wird versucht, eine Verbindung herzustellen.

Wenn dies der Fall ist, erhalte ich strongSwan-Protokolle, die so aussehen. Ich habe diese ein wenig aus Gründen der Zensur und Klarheit gemungert; CLIENTPUB / CLIENTPRIV sind die öffentlichen und privaten IP-Adressen des Clients und AMAZONPRIV ist die private IP-Adresse des Servers (an die die öffentliche IP des Servers - Amazon nennt dies eine "elastische IP" - weitergeleitet wird).

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]

Zu diesem Zeitpunkt zeigt Windows sofort eine Fehlermeldung an:

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

Nach einigen Sekunden versucht charon es erneut und schließt dann die Verbindung.

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

Und das ist es.

Soweit ich das beurteilen kann, folge ich allen Anweisungen im strongSwan-Wiki.

Was mache ich hier falsch?

Bearbeiten: Dies ist definitiv ein Problem mit Zertifikaten. Ich habe die erweiterten Validierungsprüfungen deaktiviert, indem ich die Registrierung bearbeitet und neu gestartet habe, wie in MSKB926182 beschrieben (lol, wenn Sie einen Link dazu wollten), und kann jetzt ohne Fehler eine Verbindung zu meinem VPN-Server herstellen. Ich werde herausfinden, wie Zertifikate erstellt werden, die den Anforderungen entsprechen, und eine Antwort hinzufügen. Vielen Dank an @ecdsa für den Zeiger auf die Zertifizierungsseite im strongSwan-Wiki, die mich in die richtige Richtung gelenkt hat.


Wie sieht die Registerkarte Sicherheit der VPN-Eigenschaften auf dem Windows 7-Client aus? Auch wenn mein Setup nicht identisch ist, arbeitet IKEv2 mit den Zertifikaten im Zertifikatspeicher des aktuellen Benutzers.
0xFE

Entspricht Ihr Serverzertifikat allen Anforderungen ?
Ecdsa

Wenn Sie Ihr eigenes Problem gelöst haben, können Sie unten eine Antwort veröffentlichen und diese als gelöst markieren.
Michael Hampton

Antworten:


5

Ich habe das herausgefunden. @ecdsa hat mich in die richtige Richtung gelenkt, und ich konnte das Problem endlich lösen, indem ich dieser Anleitung folgte .

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

Über den Fehler

Die Fehlermeldung lautete "Fehler 13801: Anmeldeinformationen für die IKE-Authentifizierung sind nicht akzeptabel". Dies klang, als ob meine Benutzeranmeldeinformationen nicht funktionierten. Dies ist jedoch eine Meldung zur Authentifizierung des Servers , die (gemäß meiner Konfiguration) vom SSL-Zertifikat des Servers ausgeführt wird. Microsoft hat eine Dokumentation zur Fehlerbehebung bei IKEv2-VPN-Verbindungen veröffentlicht , in der mögliche Ursachen für diesen Fehler aufgeführt sind:

  • Das Zertifikat ist abgelaufen.
  • Das vertrauenswürdige Stammverzeichnis für das Zertifikat ist auf dem Client nicht vorhanden.
  • Der Betreff des Zertifikats stimmt nicht mit dem Remotecomputer überein.
  • Dem Zertifikat sind nicht die erforderlichen EKU-Werte (Enhanced Key Usage) zugewiesen.

In meinem Fall hatte mein Problem mit den EKU-Werten zu tun. Nach der Anleitung, die ich oben verlinkt habe, konnte ich ein Zertifikat mit den richtigen EKU-Werten erstellen, und es hat hervorragend funktioniert.

Um dies zu beheben, können Sie die EKU-Prüfung auf Ihrem Windows-Client deaktivieren (dies sollte natürlich nur zu Testzwecken erfolgen):

  • Starten regedit
  • Navigieren Sie zu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters
  • Fügen Sie ein aufgerufenes DWORD hinzu DisableIKENameEkuCheckund setzen Sie seinen Wert auf1
  • In der Microsoft-Dokumentation werden Sie angewiesen, danach einen Neustart durchzuführen. Dies war jedoch nicht erforderlich, damit dies wirksam wird.

Eine weitere mögliche Ursache: IP wird in cert verwendet, aber der Hostname wird auf dem Client verwendet.
Larsen

oder der Hostname befindet sich im Zertifikat, aber der Client stellt eine Verbindung zu seiner IP-Adresse her. Lösung:ipsec pki --isue ... --san @ipaddress
Bouke

Nachdem ich diese Schritte ausgeführt hatte, bestand mein Problem schließlich darin, dass das vertrauenswürdige Stammverzeichnis an der falschen Stelle installiert wurde. Es sollte sich unter "Computer \ Vertrauenswürdige Stammzertifizierungsstellen" und nicht unter "Aktueller Benutzer \ TRCA" befinden.
Bouke

2

Ich hatte ein identisches Problem und löste es, indem ich sicherstellte, dass die Zertifikatkette in der Zertifikatdatei enthalten war (Endentitätszertifikat, Zwischenzertifizierungsstelle, Stammzertifizierungsstelle - in dieser Reihenfolge). TLS macht Spaß.

Nach dem Neustart von strongSwan funktionierte dies nicht mehr, funktionierte jedoch wieder, als ich die Zwischen- und Stammzertifizierungsstelle ablegte /etc/ipsec.d/cacerts.


0

Nach einer langen Suche hat dieser Thread meine Windows Phone 10 (WP10) -Konfiguration mit IKEv2 zum Laufen gebracht! Eine Sache zu erwähnen könnte sein, dass Sie Ihren Strongswan mit --enable-eap-identity --enable-eap-mschapv2 --enable-openssl (und wahrscheinlich --enable-dhcp) konfigurieren müssen, um die erforderlichen Plugins zu haben. Und ja, Sie müssen die Zertifikate richtig stellen (auf der Serverseite - der Client muss nur die Stammzertifizierungsstelle des Servers kennen).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.