IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von geppi »

Wie ist das eigentlich gedacht, wenn ich die VPN Zugänge über IKEv2 mit Zertifikaten betreibe und sagen wir mal 2 VPN Zugänge an einem Lancom über 2 unterschiedliche Provider realisieren will?

Also bei Provider A hat der Lancom den FQDN a.example.com
und bei Provider B hat der Lancom den FQDN b.example.com

Muss mein VPN Zertifikat im Lancom dann als 'SubjectAltName' beide FQDNs haben damit der VPN Client es bei der Authentifizierung akzeptiert, oder kann ich irgendwie auch mit zwei verschiedenen Zertifikaten für a.example.com und b.example.com arbeiten, die dann z.B. als Gerätezertifikate VPN1 und VPN2 gespeichert werden?

Ich sehe bisher keine Möglichkeit letzteres zu realisieren oder kann ich irgendwie die lokale Identität, also das Zertifikat in VPN1 oder in VPN2, in Abhängigkeit von der Gegenstelle über die eine VPN Verbindung aufgebaut wird zuweisen?
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von GrandDixence »

Ich sehe unter:
fragen-zum-thema-vpn-f14/sitetosite-vpn ... tml#p91268
die entsprechenden Konfigurationsparameter für die Wahl der zu verwendenden Maschinenzertifikate.

Entsprechende VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
anwenden.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von geppi »

Hmm, irgendwie finde ich in den Links jetzt leider nicht wirklich eine Klärung meiner Frage.
Vielleicht hab' ich die Frage auch missverständlich gestellt.

Also ich hab einen funktionierenden VPN Zugang mittels IKEv2 basierend auf Zertifikaten über Provider A.
Da benutze ich auf dem Client ein Maschinenzertifikat für den 'ASN.1 Distinguished Name' CN=client.example.com und auf dem Lancom ein Gerätezertifikat für CN=A.example.com, welches dem FQDN entspricht, unter dem der Client den Lancom aus dem Internet erreicht.

Das funktioniert soweit.

Jetzt habe ich eine weitere WAN-Gegenstelle am Lancom zu Provider B und ich kann den Lancom aus dem Internet auch über den FQDN B.example.com erreichen. Dazu richte ich jetzt auf dem Client ein zweites VPN Profil ein, dass das gleiche Maschinenzertifikat CN=client.example.com verwendet, aber die Verbindung statt zu A.example.com zu B.example.com aufbaut.

Soweit ich es verstanden habe läuft das dann folgendermaßen ab.
Wenn die VPN-Verbindung aufgebaut wird, vergleicht der Lancom den vom Client übermittelten 'ASN.1 Distinguished Name' mit den Einträgen in der IKEv2-Verbindungsliste und ordnet der VPN-Verbindung dann den Eintrag aus der IKEv2-Verbindungsliste zu, der eine Übereinstimmung im 'Remote Identifier' seiner Authentication Parameter aufweist. Dann sendet der Lancom zur Authentifizierung den Wert des in diesem Eintrag konfigurierten 'Local Identifier' an den Client.

Mein Problem ist jetzt, dass immer der erste Eintrag aus der IKEv2-Verbindungsliste mit einer Übereinstimmung zugeordnet wird und dementsprechend auch immer der gleiche 'Local Identifier' als 'ASN.1 Distinguished Name' des Lancom an den Client gesendet wird.

Damit der Lancom einen anderen, nämlich z.B. CN=B.example.com schickt, muss der entsprechende Eintrag in der IKEv2-Authentication Liste auch einen anderen 'Remote Identifier' haben. Dann kann ich das VPN Profil auf dem Client aber nicht mit dem gleichen Maschinenzertifikat wie für den Zugang über Provider A einrichten.

Zur Zeit sehe ich also zwei Lösungsmöglichkeiten.

Entweder ich verpasse dem Client zwei unterschiedliche Maschinenzertifikate und nutze diese in den beiden unterschiedlichen VPN Profilen auf dem Client für Provider A bzw. B. Dazu brauche ich dann auch zwei unterschiedliche Einträge in der IKEv2-Verbindungsliste auf dem Lancom, welche auch jeweils ein anderes VPN-Gerätezertifikat benutzen. Eben passend zum FQDN der WAN-Gegenstelle für die diese Verbindung genutzt werden soll.

Die andere Möglichkeit wäre ein VPN-Gerätezertifikat auf dem Lancom, das als 'SubjectAltName' sowohl A.example.com als auch B.example.com hat. Damit könnte ein und der selbe Eintrag in der IKEv2-Verbindungsliste für den VPN-Zugang über beide Provider genutzt werden und es wäre auch weiterhin nur ein Maschinenzertifikat auf dem Client notwendig.
Letzteres erscheint mir die einfachste Lösung.

Ich hatte mich nur auf Grund der Tatsache, dass im Lancom mehrere VPN Zertifikate konfiguriert werden können gefragt ob das nicht doch anders gedacht ist? :G)
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von Dr.Einstein »

Du hast alles korrekt erkannt. Du müsstest zwei verschiedene Zertifikate hochladen, kannst aber einer VPN-Verbindung nur ein Zertifikat hinterlegen. D.h. du müsstest für jede WAN-Verbindung die Clientverbindung duplizieren.

Das mit dem "SubjectAltName" hab ich noch nie ausprobiert. Bei uns gibt es immer nur mehrere Zertifikate, wenn wir VPNs zu unterschiedlichen Firmen aufbauen. Dein Fall mit zwei WAN Verbindungen hatte ich noch nicht. Wenn das so funktioniert, solltest du die Variante wählen. Berichte dann bitte einmal.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von GrandDixence »

Anhand der Authentifizierungsinformationen im IKE_AUTH-REQUEST-Telegramms (3. IKE-Telegramm beim VPN-Tunnelaufbau) wählt der als VPN-Server arbeitende LANCOM-Router die VPN-Gegenstelle aus der VPN-Konfiguration:

/Setup/VPN/IKEv2/Gegenstellen/

Ein ordentlich konfigurierter LANCOM-Router verwendet die VPN-Gegenstelle "DEFAULT" nur für das erste und zweite IKE-Telegramm beim VPN-Tunnelaufbau (IKE_SA_INIT-REQUEST und IKE_SA_INIT-RESPONSE) (bei Einwahlverbindungen/RAS).

Die aktuell verwendete VPN-Gegenstelle ist schön im Trace "VPN-Debug" und "VPN-IKE" anhand der zweiten Zeile ersichtlich. Immer mit dem Auswerten des entschlüsselten IKE_AUTH-REQUEST-Telegramms wechselt der korrekt konfigurierte LANCOM-Router von der VPN-Gegenstelle "DEFAULT" zu einer verbindungsspezifischen VPN-Gegenstelle (bei Einwahlverbindungen/RAS)..

Code: Alles auswählen

[VPN-Debug] 2017/07/20 21:31:18,289
Peer DEFAULT: Received an IKE_AUTH-REQUEST of 2816 bytes (encrypted)
Gateways: 80.143.218.108:4500<--80.187.118.190:19875
SPIs: 0xBD4FC5920566ED426D6B223A4915192C, Message-ID 1
VLAN-ID 0, Routing tag 0, Com-channel 0 (invalid), hTxChan 0
Payloads: ENCR, IDI, CERT, NOTIFY(STATUS_INITIAL_CONTACT), CERTREQ, IDR, AUTH(RSA:SHA1), CP(REQUEST), NOTIFY(STATUS_ESP_TFC_PADDING_NOT_SUPPORTED), SA, TSI, TSR, NOTIFY(STATUS_MOBIKE_SUPPORTED), NOTIFY(STATUS_NO_ADDITIONAL_ADDRESSES), NOTIFY(STATUS_EAP_ONLY_AUTHENTICATION), NOTIFY(STATUS_IKEV2_MESSAGE_ID_SYNC_SUPPORTED)
PHONE: ADD MODE(7) OUTBOUD ESP 0.0.0.0/0 port(0) protocol(0)---80.143.218.108===80.187.118.190---192.168.22.220/32 port(0) protocol(0)
PHONE: ADD MODE(7) INBOUD ESP 192.168.22.220/32 port(0) protocol(0)---80.187.118.190===80.143.218.108---0.0.0.0/0 port(0) protocol(0)
Looking for payload IDI (35)...Found 1 payload.
  Compare: -Received-ID CN=Phone,C=DE,L=Mobile,SN=Client,ST=Mobile:DER_ASN1_DN != Expected-ID CN=Laptop/C=DE/L=Mobile/SN=Client/ST=Mobile:DER_ASN1_DN
  +Received-ID CN=Phone,C=DE,L=Mobile,SN=Client,ST=Mobile:DER_ASN1_DN matches the Expected-ID CN=Phone/C=DE/L=Mobile/SN=Client/ST=Mobile:DER_ASN1_DN
  +Config   ENCR  transform(s): AES-CBC-256
  +Received ENCR  transform(s): AES-CBC-256
  +Best intersection: AES-CBC-256
  +Config   PRF   transform(s): PRF-HMAC-SHA-512 PRF-HMAC-SHA-384 PRF-HMAC-SHA-256
  +Received PRF   transform(s): PRF-HMAC-SHA-512
  +Best intersection: PRF-HMAC-SHA-512
  +Config   INTEG transform(s): HMAC-SHA-512 HMAC-SHA-384 HMAC-SHA-256
  +Received INTEG transform(s): HMAC-SHA-512
  +Best intersection: HMAC-SHA-512
  +Config   DH    transform(s): 19
  +Received DH    transform(s): 16
  -No intersection

[VPN-Status] 2017/07/20 21:31:18,289
Peer DEFAULT: Received an IKE_AUTH-REQUEST of 2816 bytes (encrypted)
Gateways: 80.143.218.108:4500<--80.187.118.190:19875
SPIs: 0xBD4FC5920566ED426D6B223A4915192C, Message-ID 1
CHILD_SA (UNKNOWN, 'UNKNOWN' ) entered to SADB

+Received-ID CN=Phone,C=DE,L=Mobile,SN=Client,ST=Mobile:DER_ASN1_DN matches the Expected-ID CN=Phone/C=DE/L=Mobile/SN=Client/ST=Mobile:DER_ASN1_DN
-Proposal in IKE_SA_INIT exchange (peer DEFAULT) is not supported by peer PHONE (after identification)

[VPN-IKE] 2017/07/20 21:31:18,290
[PHONE] Sending packet before encryption:
Für die Unterscheidung von VPN-Gegenstelle ProviderA versus Provider B gilt:
- Entweder spricht der VPN-Client explizit a.example.com an oder b.example.com an => Unterscheidung in der Local-ID
- Oder er gibt sich als client@providera oder client@providerb aus. => Unterscheidung der Remote-ID

Die Unterscheidung per Local-ID erfolgt offenbar schon beim Erhalt des entschlüsselten IKE_SA_INIT-REQUEST-Telegramms (Erstes IKE-Telegramm beim VPN--Tunnelaufbau):

Code: Alles auswählen

[VPN-Status] 2017/07/20 21:31:16,497
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 746 bytes
Gateways: 80.143.218.108:500<--80.187.118.190:19829
SPIs: 0xBD4FC5920566ED420000000000000000, Message-ID 0
Peer identified: DEFAULT
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0xBD4FC5920566ED42B23807BDAE8C8EAA) entered to SADB
Der LANCOM-Router erlaubt für VPN-Tunneln keine Unterscheidung der Local-ID in X.509-Zertifikaten per SAN (SubjectAltName). Der LANCOM-Router erlaubt nur eine Unterscheidung per CN (Common Name) in X.509-Zertifikaten.

CN=<Common Name>

Siehe auch:
https://www.heise.de/hintergrund/Chrome ... 17594.html
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: IKEv2 VPN mit Zertifikaten und mehreren lokalen Identitäten

Beitrag von geppi »

GrandDixence hat geschrieben: 25 Mär 2023, 11:28 Der LANCOM-Router erlaubt für VPN-Tunneln keine Unterscheidung der Local-ID in X.509-Zertifikaten per SAN (SubjectAltName). Der LANCOM-Router erlaubt nur eine Unterscheidung per CN (Common Name) in X.509-Zertifikaten.
Das brauche ich zum Glück für meinen Lösungsansatz mittels des 'SubjectAltName' auch gar nicht, weil hier nicht der Lancom Router eine Unterscheidung erlauben muss, sondern der Client muss damit zufrieden sein, dass er den FQDN des Servers nicht im 'Common Name' sondern im 'SubjectAltName' des Server-Zertifikats findet. Und dafür ist dieser Eintrag ja auch eigentlich gedacht. :D

Ich kann also Berichten, dass die Lösung mit dem 'SubjectAltName' funktioniert.

Am Client Zertifikat braucht wie gesagt nix geändert zu werden. Es enthält einfach den 'Common Name', der zur Identifizierung der 'Remote Identity' im IKEv2-Verbindungslisten Eintrag für den Client verwendet wird. In meinem Beispiel CN=client.example.com.

Auch am IKEv2-Verbindungslisten Eintrag auf dem Lancom muss nix geändert werden, ebenso sind keine Änderungen am Eintrag in der Liste IKEv2-Authentifizierung notwendig.

Lediglich das verwendete VPN-Zertifikat auf dem Lancom muss erneuert werden und im 'SubjectAltName' müssen beide möglichen Werte für die 'Lokale Identität' stehen. Also in meinem Beispiel A.example.com und B.example.com. Der 'Common Name' im VPN-Gerätezertifikat kann einer von beiden sein. Also entweder A.example.com oder B.example.com, welcher spielt keine Rolle.

Auf dem Client erstellt man einfach ein zweites VPN-Verbindungsprofil mit identischen Werten zum bestehenden Verbindungsprofil des ersten Providers, ausser natürlich der VPN-Serveradresse, für die man jetzt eben den FQDN des Zugangs über den zweiten Provider eingibt.

Wenn der Lancom Router sich am Client authentifiziert, schickt er sein VPN-Gerätezertifikat und in dem steht ja jetzt auch der zum FQDN passende Eintrag im 'SubjectAltName'.

Ausprobiert hab' ich das mit einem StronSwan Linux VPN-Client und dem nativen Windows 10 VPN-Client.
Es könnte natürlich sein, dass sich andere VPN-Clients hier anders verhalten, sollten sie aber eigentlich nicht.
Antworten