Probleme bei IPSec-VPN zw. LANCOM-Router und Ubuntu mit Zertifikaten

[g-man]

Hallo,

seit mehreren Tagen versuche ich vergeblich einen zertifikatsbasierten VPN-Zugang (IKEv2) zwischen meinem LANCOM Router 1781VA (LCOS Version 10.20) und einem (K/)Ubuntu 18.04 herzustellen. Hierbei habe ich mich an folgenden Anleitungen / Beiträgen orientiert:
- fragen-zum-thema-vpn-f14/ipsec-vpn-zwis ... 16254.html
- aktuelle-lancom-router-serie-f41/1781va ... tml#p90462

Ich gehe davon aus, dass die Einstellungen auf dem Router sowie die Zertifikate korrekt sind, da ich erfolgreich eine VPN-Verbindung zwischen dem Router und Windows 10 (nativer VPN-Client) herstellen konnte, auch wenn dies nicht ganz unproblematisch war.

Der LANCOM Router fungiert als CA, demnach habe hier auch die entsprechenden Zertifikate (Stamm-, Client-, Server-) erstellt. Zudem habe ich Folgendes auf dem Router konfiguriert:
> VPN > IKEv2/IPSec > Authentifizierung
> Name: VPN_JANE
> Lokale Authentifizierung: Digital Signature
> Lokales Dig. Signature-Prof.: WINDOWS
> Lokaler Identitätstyp: ASN.1-Distinguished
> Lokale Identität: C=DE/O=LANCOM SYSTEMS/CN=LANCOM CA
> Entfernte Authentifizierung: Digital Signature
> Entf Dig. Signature-Profil: WINDOWS
> Entfernte Identitätstyp: ASN.1-Distinguished
> Entfernte Identität: CN=vpn_jane@intern.example.com
> Lokales Zertifikat: VPN6 (hier ist das Gateway-/Server-Zertifikat eingebunden)

Unter Ubuntu nutze ich den strongSwan Client (network-manager-strongswan). Im Abschnitt "Gateway" habe ich das Server-Zertifikat eingebunden, welches ich vorher mit folgendem Befehl extrahiert hatte:

Code: Alles auswählen

user@linux-client:~$ openssl pkcs12 -nokeys -clcerts -in intern.example.com.p12 -out intern.example.com.crt

Unter "Authentifizierung" findet sich ein ähnliches Bild: hier habe ich das Client-Zertifikat und den dazugehörigen privaten Schlüssel eingespielt. Letzteren musste ich zudem in pkcs1 umwandeln, weil mir strongswan / charon-nm sonst eine Fehlermeldung ausgibt, die sich darauf bezieht, dass er keinen privaten Schlüssel findet:

Code: Alles auswählen

user@linux-client:~$ openssl pkcs12 -nokeys -clcerts -in vpn_jane@intern.example.com.p12 -out vpn_jane@intern.example.com.crt_clcerts
user@linux-client:~$ openssl pkcs12 -nocerts -in vpn_jane@intern.example.com.p12 -out vpn_jane@intern.example.com.key
user@linux-client:~$ openssl rsa -in vpn_jane@intern.example.com.key -out vpn_jane@intern.example.com.key_pkcs1

Das Root-/Stammzertifikat habe ich unter ipsec eingebunden:

Code: Alles auswählen

root@linux-client:~$ openssl pkcs12 -nokeys -cacerts -in vpn_jane@intern.example.com.p12 -out /etc/ipsec.d/cacerts/intern.example.com.crt
root@linux-client:~$ ipsec restart

Bei einem Verbindungsversuch steht im syslog für charon-nm folgende Fehlermeldung aus:

Code: Alles auswählen

Jun 11 16:02:57 linux-client charon-nm: 05[CFG] received initiate for NetworkManager connection strongswan
Jun 11 16:02:57 linux-client charon-nm: 05[CFG] using gateway certificate, identity 'CN=vpn_jane@intern.example.com'
Jun 11 16:02:57 linux-client charon-nm: 05[IKE] initiating IKE_SA strongswan[7] to 81.81.81.81
Jun 11 16:02:57 linux-client 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) ]
Jun 11 16:02:57 linux-client charon-nm: 05[NET] sending packet: from 192.168.0.112[53449] to 81.81.81.81[500] (894 bytes)
Jun 11 16:02:57 linux-client charon-nm: 07[NET] received packet: from 81.81.81.81[500] to 192.168.0.112[53449] (38 bytes)
Jun 11 16:02:57 linux-client charon-nm: 07[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Jun 11 16:02:57 linux-client charon-nm: 07[IKE] peer didn't accept DH group ECP_256, it requested MODP_2048
Jun 11 16:02:57 linux-client charon-nm: 07[IKE] initiating IKE_SA strongswan[7] to 81.81.81.81
Jun 11 16:02:57 linux-client charon-nm: 07[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) ]
Jun 11 16:02:57 linux-client charon-nm: 07[NET] sending packet: from 192.168.0.112[53449] to 81.81.81.81[500] (1086 bytes)
Jun 11 16:02:57 linux-client charon-nm: 06[NET] received packet: from 81.81.81.81[500] to 192.168.0.112[53449] (481 bytes)
Jun 11 16:02:57 linux-client charon-nm: 06[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ V ]
Jun 11 16:02:57 linux-client charon-nm: 06[ENC] received unknown vendor ID: 81:75:2e:b5:91:4d:73:5c:df:cd:c8:58:c3:a8:ed:7c:1c:66:d1:42
Jun 11 16:02:57 linux-client charon-nm: 06[IKE] local host is behind NAT, sending keep alives
Jun 11 16:02:57 linux-client charon-nm: 06[IKE] received 1 cert requests for an unknown ca
Jun 11 16:02:57 linux-client charon-nm: 06[IKE] authentication of 'CN=vpn_jane@intern.example.com' (myself) with RSA signature successful
Jun 11 16:02:57 linux-client charon-nm: 06[IKE] sending end entity cert "CN=vpn_jane@intern.example.com"
Jun 11 16:02:57 linux-client charon-nm: 06[IKE] establishing CHILD_SA strongswan{6}
Jun 11 16:02:57 linux-client charon-nm: 06[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH CPRQ(ADDR DNS NBNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Jun 11 16:02:57 linux-client charon-nm: 06[NET] sending packet: from 192.168.0.112[49559] to 81.81.81.81[4500] (1568 bytes)
Jun 11 16:02:58 linux-client charon-nm: 16[NET] received packet: from 81.81.81.81[4500] to 192.168.0.112[49559] (1456 bytes)
Jun 11 16:02:58 linux-client charon-nm: 16[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH CPRP(DNS DNS ADDR) TSi TSr N(INIT_CONTACT) SA ]
Jun 11 16:02:58 linux-client charon-nm: 16[IKE] received end entity cert "CN=intern.example.com"
Jun 11 16:02:58 linux-client charon-nm: 16[IKE] no trusted RSA public key found for 'CN=LANCOM CA, O=LANCOM SYSTEMS, C=DE'
Jun 11 16:02:58 linux-client charon-nm: 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Jun 11 16:02:58 linux-client charon-nm: 16[NET] sending packet: from 192.168.0.112[49559] to 81.81.81.81[4500] (80 bytes)

Abgesehen von der Meldung "received 1 cert requests for an unknown ca" scheint wohl die Nachricht "no trusted RSA public key found for [...]" ausschlaggebend für das Scheitern der Verbindung zu sein. Das strongSwan FAQ erläutert hierzu folgende Lösungsversuche:

- The client transmits its certificate to the remote peer (Configure logging as shown on the HelpRequests page and search for "cert" without ")

Siehe oben, meines Erachtens zeigt der Client sein Zertifikat vor.

- The remote peer trusts the root CA that issued the client's certificate or the client's certificate is locally available and loaded (check with ipsec listcerts or swanctl --list-certs)

Wie bereits oben erwähnt, habe ich das Rootzertifikat unter /etc/ipsec.d/cacerts abgelegt.

Code: Alles auswählen

root@linux-client:~# ipsec listcacerts

List of X.509 CA Certificates

  subject:  "C=DE, O=LANCOM SYSTEMS, CN=LANCOM CA"
  issuer:   "C=DE, O=LANCOM SYSTEMS, CN=LANCOM CA"
  validity:  not before Jun 14 15:02:32 2018, ok
             not after  Jun 14 15:02:32 2019, ok (expires in 3 days)
  serial:    95:12:09
  flags:     CA CRLSign self-signed 
  pathlen:   1
  authkeyId: 48:08:a3:c1:5c:a8:c5:98:ae:98:a1:b0:6c:82:c4:6b:10:d8:60:db
  subjkeyId: 48:08:a3:c1:5c:a8:c5:98:ae:98:a1:b0:6c:82:c4:6b:10:d8:60:db
  pubkey:    RSA 2048 bits
  keyid:     1c:fe:d1:54:23:f2:e2:f2:c5:2d:c9:58:43:69:b3:5f:8e:23:5e:61
  subjkey:   48:08:a3:c1:5c:a8:c5:98:ae:98:a1:b0:6c:82:c4:6b:10:d8:60:db

- The remote peer's certificate is valid

Das Zertifikat ist weder abgelaufen, noch steht es auf der Zertifikatsperrliste / revocation list.

- The remote peer's transmitted ID is either in one of it's certificate's SAN fields with the correct type (type IP if it's an IP, type FQDN if it's a FQDN) or it is its certificate's whole DN (distinguished name)

Als ich die Zertifikate erstellte, habe ich sowohl beim Client- wie auch beim Server-Zertifikat das SAN-Feld mit "DNS:INTERN.EXAMPLE.COM" ausgefüllt. Eine Prüfung auf dem Client ergibt folgendes:

Code: Alles auswählen

user@linux-client:~$ openssl pkcs12 -nokeys -clcerts -in vpn_jane@intern.example.com.p12 | openssl x509 -noout -text -in - | grep 'DNS'
		DNS:INTERN.EXAMPLE.COM

Ähnlich beim Server-Zertifikat:

Code: Alles auswählen

user@linux-client:~$ openssl pkcs12 -nokeys -clcerts -in intern.example.com.p12 | openssl x509 -noout -text -in - | grep 'DNS'
		DNS:INTERN.EXAMPLE.COM

Wie bereits erwähnt, unter Windows 10 war der Verbindungsaufbau erfolgreich. Angesichts der Anleitungen / Beiträge gehe ich davon aus, dass es auch unter Linux funktionieren sollte. Habe ich irgendwo einen offensichtlichen Fehler gemacht oder dergleichen übersehen? Gibt es eine Einstellung, die ich auf dem LANCOM Router anders konfigurieren muss, z. B. das "Entf Dig. Signature-Profil"? Oder muss ich den strongSwan Client anders einrichten?

Für jede Hilfe wäre ich sehr dankbar.

[GrandDixence]

Der StrongSwan VPN Client erhält im IKE_AUTH-Telegramm ein Maschinenzertifikat für "CN=intern.example.com". Gemäss der LANCOM-Konfiguration "Lokale Identität" ist dieses Maschinenzertifikat auf "C=DE/O=LANCOM SYSTEMS/CN=LANCOM CA" per Stammzertifikat/CA verbürgt, was offenbar nicht der Fall ist. Wahrscheinlich genügt es die LANCOM-Konfiguration "Lokale Identität" auf "CN=intern.example.com" umzustellen.

Das Feld "Certificate" unter VPN->Gateway im StrongSwan-Network-Plugin sollte leer gelassen werden oder das Stammzertifikat enthalten?!
Der öffentliche Schlüssel des Maschinenzertifikat/Serverzertifikat kommt vom LANCOM-Gerät per IKE_AUTH-Telegramm beim VPN-Tunnelaufbau zum StrongSwan Client. Wieso sollte man hier ein Serverzertifikat eintragen?

Ich empfehle die ersten Gehversuche beim Aufbau einer PKI mit dem Maschinenzertifikat und Stammzertifikat für das Webinterface/Webconfig des LANCOM-Geräts (https://) zu machen. Dazu brav Konfigurationsbackups erstellen! Stammzertifikat im Zertifikatsspeicher des Webbrowser (Firefox) oder im Zertifikatsspeicher des Betriebssystem installieren (MS Internet Explorer/MS Edge).

Erst wenn man ein wenig sattelfest im Thema PKI/X.509 ist, sollte man sich an die VPN-Zertifikate wagen.

[g-man]

Hallo GrandDixence,

vielen Dank für die Hilfe, jetzt funktioniert es

Ich habe auf dem LANCOM-Router die "Lokale Identität", wie von dir beschrieben, auf "CN=intern.example.com" gesetzt. Du hast natürlich recht, dass es wenig sinnvoll ist, das Server-Zertifikat im Client einzubinden. Da ist mir definitiv ein grober Schnitzer unterlaufen Weshalb ich das gemacht habe, kann ich mir im Nachhinein auch nicht mehr erklären. Insofern ist es sinnvoll, wenn man an dieser Stelle das Root-Zertifikat einbindet. Letztlich habe ich das Root-Zertifikat dem System / ca-certificate stores hinzugefügt (vgl. https://askubuntu.com/a/94861):

Code: Alles auswählen

user@linux-client:~$ sudo mkdir /usr/share/ca-certificates/example
user@linux-client:~$ sudo openssl pkcs12 -nokeys -cacerts -in vpn_jane@intern.example.com.p12 -out /usr/share/ca-certificates/example/intern.example.com.crt
user@linux-client:~$ sudo dpkg-reconfigure ca-certificates

Bei letzterem Befehl muss das Zertifikat noch ausgewählt werden.