[gelöst] Keine Verbindung zwischen Lancom und Android Strongswan

[knut32]

Hallo,

wir wollen eine VPN-Verbindung zwischen einem Android Smartphone und dem Lancom Router LC-1790EF herstellen. Dazu haben wir die VPN Option 25 dazu gebucht.

Die Verbindung soll über ikev2 per Zertifikat erfolgen. Wir haben ein Routerzertifikat und ein Clientzertifikat erstellt. Zur Zertifikatserstellung sind wir nach dieser Anleitung vorgegangen:

https://support.lancom-systems.com/know ... d=32984244

Die VPN-Verbindung haben wir nach dieser Anleitung konfiguriert:

https://support.lancom-systems.com/know ... d=32983599

Über den VPN Advanced Client funktioniert die Verbindung. Jedoch nicht mit der App StrongSwan auf dem Handy. Das Clientzertifikat haben wir in der App importiert.

Wir erhalten die Fehlermeldung: constrained check failed: identity ‘DynDns-Adresse’ requiered. selected peer config ‘android’ unacceptable: constraint checking failed.

Einen Screenshot haben wir angehängt.
Wie können wir erfolgreich eine Verbindung aufbauen?

Danke

[GrandDixence]

Der VPN-Client (hier StrongSwan App unter Android) hat das 3. IKE-Telegramm für den VPN-Tunnelaufbau gesendet (IKE_AUTH request). Darauf hat der VPN-Server (hier LANCOM-Router) mit dem 4. IKE-Telegramm geantwortet (IKE_AUTH response). In diesem 4. IKE-Telegramm teilt der VPN-Server mit, dass im 3. IKE-Telegramm das falsche X.509-Zertifikat gesendet wurde. Der VPN-Server erwartet ein Zertifikat mit "identity" (geschwärzt, tja...).

Bitte hier weiterlesen:
viewtopic.php?t=19346

Siehe auch:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

https://www.heise.de/hintergrund/Einfac ... 70056.html

[knut32]

Wir haben im Lancom 2 Zertifikate erstellt. Das 1. mit dem Namen "VPN-Zert" und dem Nachnamen "Router". Das 2. bekam den Namen "VPN-Zert und den Nachnamen "Client".

Danach haben wir das 1. in den Lancom hochgeladen. Das 2. wiederrum haben wir auf Handy kopiert.

Im Strongswan eine neue Verbindung angelegt.

Server: dyndns-Adresse
VPN-Typ: IKEv2 Zertifikat

Dort auf Benutzer-Zertifikat installieren geklickt und das aufs Handy kopierte 2. Zertifikat gewählt.

CA-Zertifikat: automatisch wählen

Haben wir eventuell irgendetwas vergessen? Oder hätten wir beim 1. Zertifikat was anderes angeben müssen? (z.B. die dyndns-Adresse)

Ich bin leider nicht im Büro. Ich lade dann noch mal einen ungeschwärzten Screenshot hoch

[knut32]

Hier noch der Screenshot

[Dr.Einstein]

Könnte das gleiche Problem wie hier sein:

fragen-zum-thema-vpn-f14/vpn-ike-v2-mit ... ml#p110118

Fehlender X509v3 Subject Alternative Name in den zertifikatseigenschaften. Hier kommt die Public IP / DynDNS Name rein.

[knut32]

Hallo.

Also die Verbindung funktioniert jetzt auch mit dem Handy und StronSwan.
Der Tip mit dem Subject Alternative Name war Gold wert
Dieser SAN hat bei unserem Routerzertifikat gefehlt. Warum? Weil es diesen Eintrag bei der Zertifikatserstellung einfach nicht gab.

Man muss diesen Punkt erst aktivieren. Und zwar im Lancom unter:

Konfigurieren -> Zertifikate -> Zertifikatsbehandlung -> Vorlagen

Dort den Eintrag Default auswählen, auf Bearbeiten klicken und Subject alt. Name (SAN) auf Ja stellen. Speichern und hochladen.

Jetzt gibt es in der WebConfig unter der Zertifikatsverwaltung bei Neues Zertifikat erstellen den Punkt SAN.
Dort trägt man die DynDns-Adresse ein. Wichtig ist das man DNS: davor schreibt. Also in der Art:

DNS:DynDns-Adresse

Wenn man eine IP hat, dann in der Form IP:IP-Adresse

Das muss man auch nur im Router-Zertifikat eintragen. Im Client-Zertifikat ist das nicht nötig.

[UKernchen]

Oder besser: Zertifikate nicht im Router erzeugen.
Mit XCA geht das wirklich komfortabel.
https://uwe-kernchen.de/phpmyfaq/index. ... on_id=1393

Ggf. macht der SAN-Eintrag auch im Client-Zertifikat Sinn.
(siehe Variante 2)
https://uwe-kernchen.de/phpmyfaq/index. ... on_id=1398

[mh1]

(...)Der Tip mit dem Subject Alternative Name war Gold wert
(...)Das muss man auch nur im Router-Zertifikat eintragen. Im Client-Zertifikat ist das nicht nötig.

Stimmt nicht ganz.
Je nachdem, mit welchen Programmen man arbeitet bzw. was man machen will.
Windows z.B. stellt sehr strikte Anforderungen an ein Zertifikat und die Fehlersuche wird sehr schwer, wenn man diese Anforderungen ignoriert

....auch bei HTTPS ist schon seit >20 Jahren der Abgleich des Servernamens mit dem CN auf depreceated