vpn android strongswan lancom mit zertifikaten

[tobiasr]

Unter VPN->IKEv2->Authentifizierung:
- lokale AUthentifizierung: Digital-Signature
- lokaler Identitätstyp: FQDN, Lokale Identität: mein.dyndns.de
- Entfernter Identitätstyp: FQDN, Entfernte Identität: mobil01.vpn
- Lokales Zertifikat: VPN1

Zertifikate - CA/Lancom:
CN=mein.dyndns.de/O=Mein Firmenname
Nachtrag: auch hier natürlich den SAN mit "DNS:mein.dyndns.de" entsprechend setzen.

Mobilgerät:
CN=mobil01.vpn/O=Mein Firmenname
SAN: "DNS:mobil01.vpn" (ohne die Anführungszeichen)
Schlüsselverwendung: digitalSignature, keyEncicpherment, critical
Erw. Schlüsselverwendung: clientAuth

[averlon]

interessant - ganz anders als in der Dokumentation.

Werde ich morgen mal ausprobieren und alles auf Anfang setzen.

Danke

[GrandDixence]

Bitte zuerst die Grundlagen zur Erstellung und Handhabung von X.509-Zertifikate erlernen, bevor man ziellos "herumbastelt"! Mögliche Einstiege:
https://www.baeldung.com/linux/crt-key-files

https://jamielinux.com/docs/openssl-cer ... -pair.html

https://www.bjoern.info/2020/12/ssl-tls ... uesselung/

https://www.heise.de/hintergrund/Chrome ... 17594.html

Ohne fundierte Kenntnisse der X.509-Zertifikate wird ein grosser Glücksfall benötigt, damit ein zertifikatsbasierter VPN-Tunnel einwandfrei funktioniert.

[averlon]

Zertifikate - CA/Lancom:
CN=mein.dyndns.de/O=Mein Firmenname
Nachtrag: auch hier natürlich den SAN mit "DNS:mein.dyndns.de" entsprechend setzen.

Ich habe die CA im Lancom entsprechend angepasst.

Jetzt muss ich ja über die Weboberfläche das "Aktuelles CA Zertifikat herunterladen" --> cacert.crt

Wenn ich mir diese Datei im Windows öffne kann ich mir die Details anschauen.

Leider steht als "Aussteller" immer noch der alte Wert drin - obwohl ich a) im lanconfig Zertifikate aus und wieder eingeschaltet habe und sogar einen reboot des Routers gemacht habe.

Ich denke, bevor ich dieses Problem nicht behoben habe brauche ich nicht weiter zu machen. Ansonsten wird die VPN-Verbindung nie zustande kommen.

[averlon]

ok - geschafft.

Ich musste zuerst über die Weboberfläche "neue CA-Zertifikate erstellen" und das mit dem Parameter "-f" = force.

Wenn ich jetzt das CA-Zertifikat herunterlade steht der neue "Aussteller" drin.

Jetzt kann es weiter gehen!

[averlon]

Die Verbindung steht! - Danke für die Hilfestellung.

Ich habe festgestellt, dass es egal ist, was im CN im Mobilgerät drin steht. Fakt ist "/" wird nicht akzeptiert!.

Mobilgerät:
CN=mobil01.vpn/O=Mein Firmenname

Und jetzt das Ganze noch für IPV6 - werde ich mal versuchen!

[averlon]

so ganz funktioniert das routing noch nicht.

Ich kann vom Android einen ping auf den lancom machen. Alle anderen pings auf andere Geräte im Netz werden nicht beantwortet.

Die FW sollte eigentlich richtig konfiguriert sein - muss ich aber noch einmal prüfen.

Update: Ich hatte noch eine Änderung gemacht, die doch Auswirkungen auf die FW hatte. FW korrigiert - alles läuft!

[averlon]

So - jetzt noch mal alles zusammen:

Unter VPN->IKEv2->Authentifizierung:
- lokale AUthentifizierung: Digital-Signature
- lokaler Identitätstyp: FQDN, Lokale Identität: mein.dyndns.de
- Entfernter Identitätstyp: FQDN, Entfernte Identität: mobil01.vpn
- Lokales Zertifikat: VPN1

In der ursprünglichen Dokumentation stand:
- lokaler Identitätstyp = ASN.1 Distinguished-Name = "CN=<dyndns-name>"
und
- Entfernter Identitätstyp: ASN.1 Distinguished-Name = "CN=<client>.invalid"

Das mit dem ASN.1 Distinguished-Name scheint es nicht zu funktionieren. Hingegen mit FQDN (wie oben beschrieben) sehr wohl !!!

Zertifikate - CA/Lancom:
CN=mein.dyndns.de/O=Mein Firmenname
Nachtrag: auch hier natürlich den SAN mit "DNS:mein.dyndns.de" entsprechend setzen.

Nach meinen Tests:

Code: Alles auswählen

CN=mein.dyndns.de/O=Mein Firmenname

muss nicht "CN=mein.dyndns.de" sein. Da kann irgendwas stehen!

Wichtig ist natürlich der SAN-Eintrag!

Mobilgerät:
CN=mobil01.vpn/O=Mein Firmenname
SAN: "DNS:mobil01.vpn" (ohne die Anführungszeichen)
Schlüsselverwendung: digitalSignature, keyEncicpherment, critical
Erw. Schlüsselverwendung: clientAuth

Nach meinen Tests:
- "CN=mobil01.vpn/O=Mein Firmenname" geht insofern nicht, weil "/" nicht akzeptiert werden bzw. dann in "|" umgewandelt werden, was wenig hilfreich ist.
- im CN-Eintrag kann irgendwas stehen. Sollte - soweit ich das vestehe - das Gerät/Client/Benutzer indentifizieren.
- Erw. Schlüsselverwendung: clientAuth - dafür muss im Lancom ein neues profil angelegt werden, denn das als STANDARD vorhandene Profil "VPN" hat die Schlüsselverwendung "clientAuth" nicht drin - soweit ich das feststellen konnte. Ob man das wirklich braucht, habe ich nicht getestet, gehe aber davon aus. Zumindest hat es nicht geschadet. Ich habe das neue Profil angelegt und dann bei der Erstellung des Zertifikates für das Gerät/Client/Benutzer ausgewählt.

[averlon]

@tobiasr: Danke für die Unterstützung!

[tobiasr]

Der / in CN kommt durch das Zusammenführen der Felder Gerätename, Firmenname, Ort, PLZ, etc. automatisch. Der trennt die einzelnen Felder.

[Hagen2000]

Bei meinen VPN-Verbindungen (allerdings mit iPhones und deren integriertem IPSec-Modul) habe ich den ASN.1-Distinguished-Name verwendet und hier steht in der Router-Konfiguration als lokale Identität sinngemäß /CN=host.domain.tld/O=Firma drin - beachte den führenden '/' am Anfang des Eintrags.
Soweit ich mich erinnere, mussten alle Felder angegeben werden, die im Zertifikat definiert sind (also außer CN= und O= beispielsweise auch OU=, emailAddress=).
Die Verwendung der SAN-Liste ist seit langem verpflichtend und die Verwendung des Common Names (CN) abgekündigt. Daher kannst Du da auch was Beliebiges eintragen. Für eine möglichst hohe Kompatibilität zu alten Programmen sollte man aber im CN den wichtigsten Eintrag der SAN-Liste wiederholen.