17
Lancom IKEv2 - Mac OS VPN
Hallo Leute,
gibt es hier zufällig einen Lancom Experten, der das besagte Szenario schon einmal erfolgreich durchgeführt hat ?
Aktuell verwende ich zertifikatbasiertes ikev1 mit der Lancom Smart CA.
Dies soll abgelöst werden durch IKEv2, natürlich auch zertifikatsbasiert mit der Lancom Smart CA.
Als Client soll der integrierte Mac OS X VPN Client genutzt werden, der IKEv2 auch unterstützt.
Falls es hier jemanden gibt der in diese Richtung schon Erfahrung hat, bzw. das Szenario schonmal erfolgreich durchgeführt hat, würde ich mich freuen, wenn sich jemand bei mir meldet.
Ich habe mich jetzt gut 1 Woche damit auseinandergesetzt, einiges durchprobiert, aber bekomme es einfach nicht zum laufen...
Im Grunde habe ich folgende Anleitung befolgt:
https://www2.lancom.de/kb.nsf/b8f10fe5665f950dc125726c00589d94/8a0fa8d3d ...
Nur bei der Authentifizierung habe ich, da ich zertifikatsbasiertes VPN haben möchte folgende Abweichungen vorgenommen:
Lokale Authentifizierung: "RSA Signature"
Lokaler Identitätstyp: "ASN.1-Distinguished-Name"
Lokale Identität: Den Zertifkatnamen vom lokalen Router Zertifikat "CN=...." angegeben
Lokales Passwort: Frei gelassen
Entfernte Authentifizierung: "RSA Signature"
Entfernte Identitätstyp: "ASN.1-Distinguished-Name"
Entfernte Identität: Den Zertifikatnamen für das Clientzertifikat "CN=....."
Entferntes Passwort: Frei gelassen
Ansonsten alles so wie ich der Anleitung... !
Im MAC OS X habe ich dann das Clientzertifikat in den Schlüsselbund importiert.
Dann habe ich im MAC OS X VPN Client eine IKEv2 VPN Verbindung mit den folgenden Werten erstellt:
Serveradresse: externe IP des LC Routers
Entfernte ID: Den Zertifikatnamen "CN=..." des Routers, wie im Router angegeben bei "Lokale Identität".
Lokale ID: Den Zertifikatnamen "CN=...." des Clients, wie im Router bei "Entfernte Identität" angegeben.
Unter Authentifizierungseinstellungen:
Ohne
und das Client-Zertifikat ausgewählt....
Leider kommt keine VPN Verbindung zu stande.
VPN-Statustrace sagt:
gibt es hier zufällig einen Lancom Experten, der das besagte Szenario schon einmal erfolgreich durchgeführt hat ?
Aktuell verwende ich zertifikatbasiertes ikev1 mit der Lancom Smart CA.
Dies soll abgelöst werden durch IKEv2, natürlich auch zertifikatsbasiert mit der Lancom Smart CA.
Als Client soll der integrierte Mac OS X VPN Client genutzt werden, der IKEv2 auch unterstützt.
Falls es hier jemanden gibt der in diese Richtung schon Erfahrung hat, bzw. das Szenario schonmal erfolgreich durchgeführt hat, würde ich mich freuen, wenn sich jemand bei mir meldet.
Ich habe mich jetzt gut 1 Woche damit auseinandergesetzt, einiges durchprobiert, aber bekomme es einfach nicht zum laufen...
Im Grunde habe ich folgende Anleitung befolgt:
https://www2.lancom.de/kb.nsf/b8f10fe5665f950dc125726c00589d94/8a0fa8d3d ...
Nur bei der Authentifizierung habe ich, da ich zertifikatsbasiertes VPN haben möchte folgende Abweichungen vorgenommen:
Lokale Authentifizierung: "RSA Signature"
Lokaler Identitätstyp: "ASN.1-Distinguished-Name"
Lokale Identität: Den Zertifkatnamen vom lokalen Router Zertifikat "CN=...." angegeben
Lokales Passwort: Frei gelassen
Entfernte Authentifizierung: "RSA Signature"
Entfernte Identitätstyp: "ASN.1-Distinguished-Name"
Entfernte Identität: Den Zertifikatnamen für das Clientzertifikat "CN=....."
Entferntes Passwort: Frei gelassen
Ansonsten alles so wie ich der Anleitung... !
Im MAC OS X habe ich dann das Clientzertifikat in den Schlüsselbund importiert.
Dann habe ich im MAC OS X VPN Client eine IKEv2 VPN Verbindung mit den folgenden Werten erstellt:
Serveradresse: externe IP des LC Routers
Entfernte ID: Den Zertifikatnamen "CN=..." des Routers, wie im Router angegeben bei "Lokale Identität".
Lokale ID: Den Zertifikatnamen "CN=...." des Clients, wie im Router bei "Entfernte Identität" angegeben.
Unter Authentifizierungseinstellungen:
Ohne
und das Client-Zertifikat ausgewählt....
Leider kommt keine VPN Verbindung zu stande.
VPN-Statustrace sagt:
[VPN-Status] 2016/10/27 18:46:53,802 Devicetime: 2016/10/27 18:47:20,255
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 604 bytes
Gateways: xxxxxxxxxx:500<—xxxxxxxxxx:62809
SPIs: xxxxxxxxxxx0000000000000000, Message-ID 0
Peer identified: DEFAULT
Received 4 notifications:
+REDIRECT_SUPPORTED
+STATUS_NAT_DETECTION_SOURCE_IP
+STATUS_NAT_DETECTION_DESTINATION_IP
+IKEV2_FRAGMENTATION_SUPPORTED
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are behind a NAT => sending periodic keep alives every 20 seconds
+IKE_SA:
Proposal 1 Protocol IPSEC_IKE
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)
——————
[VPN-Status] 2016/10/27 18:46:53,922 Devicetime: 2016/10/27 18:47:20,474
Peer DEFAULT: Constructing an IKE_SA_INIT-REPLY for send
IKE_SA:
Proposal 1 Protocol IPSEC_IKE:
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+KE-DH-Group 14 (2048 bits)
Sending an IKE_SA_INIT-RESPONSE of 457 bytes
Gateways: xxxxxxxxx:500-->xxxxxxxxxx:62809
SPIs: xxxxxxxxxxxxxxx, Message-ID 0
———————
[VPN-Status] 2016/10/27 18:46:53,922 Devicetime: 2016/10/27 18:47:20,543
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: xxxxxxxxxx5, responder cookie: xxxxxxxxxxxE8
SA ISAKMP for peer DEFAULT encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/28/2016 21:47:20 (in 97200 sec) / 0 kb
life time hard 10/29/2016 00:47:20 (in 108000 sec) / 0 kb
———————
[VPN-Status] 2016/10/27 18:46:53,974 Devicetime: 2016/10/27 18:47:20,587
IKE log: 184720.587661 Default x509_DN_XN: d2i_X509_NAME() failed
———————
[VPN-Status] 2016/10/27 18:46:53,974 Devicetime: 2016/10/27 18:47:20,587
IKE log: 184720.587708 Default x509_DN_conf_cmp: x509_DN_XN() failed
—————————
[VPN-Status] 2016/10/27 18:46:53,974 Devicetime: 2016/10/27 18:47:20,590
IKE log: 184720.590222 Default rsa_sig_decode_hash: no CERT subject match the ID
—————————
[VPN-Status] 2016/10/27 18:46:53,974 Devicetime: 2016/10/27 18:47:20,593
Peer DEFAULT: Received an IKE_AUTH-REQUEST of 1920 bytes (encrypted)
Gateways: xxxxx:4500<—xxxxx:62810
SPIs: xxxxxxxxxE8, Message-ID 1
+Received-ID:AUTH CN=xxxxxxxxxx :USER_FQDN:RSA_SIG matches Expected-ID:AUTH ID_NONE:ID_NONE:RSA_SIG
+Road-warrior identified and accepted (Peer xxxxxxx-VPN302C using RSA_SIG)
+Peer uses AUTH(RSA:SHA1)
+Authentication successful
Received 4 notifications:
+STATUS_INITIAL_CONTACT
+STATUS_MOBIKE_SUPPORTED
+STATUS_ESP_TFC_PADDING_NOT_SUPPORTED
+STATUS_NON_FIRST_FRAGMENTS_ALSO
+INTERNAL_IP4_ADDRESS()
+INTERNAL_IP4_DHCP()
+INTERNAL_IP4_DNS()
+INTERNAL_IP4_NETMASK()
+INTERNAL_IP6_ADDRESS()
+INTERNAL_IP6_DHCP()
+INTERNAL_IP6_DNS()
-Not configured as Server () or not cert as proposal -> abort
—————————
[VPN-Status] 2016/10/27 18:46:54,089 Devicetime: 2016/10/27 18:47:20,701
VPN: WAN state changed to WanSetup for (0.0.0.0), called by: 00eaf010
—————————
[VPN-Status] 2016/10/27 18:46:54,089 Devicetime: 2016/10/27 18:47:20,701
VPN: WAN state changed to WanCalled for xxxxxx-VPN302C (0.0.0.0), called by: 00eaed2c
—————————
[VPN-Status] 2016/10/27 18:46:54,089 Devicetime: 2016/10/27 18:47:20,701
vpn-maps[20], remote: xxxxxxx-VPN302C, nego, connected-by-name
—————————
[VPN-Status] 2016/10/27 18:46:54,089 Devicetime: 2016/10/27 18:47:20,701
Peer xxxxxx-VPN302C: Constructing an IKE_AUTH-REPLY for send
+Local-ID 198.51.100.23:IPV4_ADDR
+I use AUTH(RSA:SHA1)
+Signature of length 256 bytes (2048 bits) computed
IKE_SA_INIT [responder] for peer xxxxx-VPN302C initiator id CN=xxxxxxxxxxxx , responder id 198.xx.xx.xx
initiator cookie: xxxxxxxxxxx5, responder cookie: xxxxxxxxxxE8
NAT-T enabled. We are behind a nat, the remote side is not behind a nat
SA ISAKMP for peer xxxxxx-VPN302C encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/28/2016 21:47:20 (in 97200 sec) / 0 kb
life time hard 10/29/2016 00:47:20 (in 108000 sec) / 0 kb
NOTIFY(INTERNAL_ADDRESS_FAILURE)
Sending an IKE_AUTH-RESPONSE of 1360 bytes (encrypted)
Gateways: xxxxxxxx:4500-->xxxxxxxxx:62810
SPIs: xxxxxxxxxE8, Message-ID 1
——————————
[VPN-Status] 2016/10/27 18:46:54,089 Devicetime: 2016/10/27 18:47:20,702
IKE info: CHILD_SA removed: peer xxxxxx-VPN302C rule ISAKMP-PEER-DEFAULT removed
——————————
[VPN-Status] 2016/10/27 18:46:54,139 Devicetime: 2016/10/27 18:47:20,751
Peer xxxxxxx-VPN302C: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: xxxxxxx:4500<—xxxxxxx:62810
SPIs: xxxxxxxxxxE8, Message-ID 2
——————————
[VPN-Status] 2016/10/27 18:46:54,139 Devicetime: 2016/10/27 18:47:20,752
Peer xxxxxxxx-VPN302C: Constructing an INFORMATIONAL-REPLY for send
Sending an INFORMATIONAL-RESPONSE of 80 bytes (encrypted)
Gateways: xxxxxxxx:4500-->xxxxxxxx:62810
SPIs: xxxxxxxxxxE8, Message-ID 2
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 320555
Url: https://administrator.de/contentid/320555
Printed on: April 18, 2024 at 18:04 o'clock
17 Comments
Latest comment
Hallo,
das sieht so aus, als hättest du Zertifikate mit falschen Parametern erstellt. Stimmen Schlüssel-Verwendung bzw. erweiterte Schlüsselverwendung für Client- bzw. Serverauthentifizierung? Ich würde da selbst ein komfortables Tool wie XCA der Lanconfig vorziehen und das dann hochladen.
Grüße
Richard
das sieht so aus, als hättest du Zertifikate mit falschen Parametern erstellt. Stimmen Schlüssel-Verwendung bzw. erweiterte Schlüsselverwendung für Client- bzw. Serverauthentifizierung? Ich würde da selbst ein komfortables Tool wie XCA der Lanconfig vorziehen und das dann hochladen.
Grüße
Richard
Hallo und danke für die Antwort.
Also die Zertifikate beinhalten folgende "Optionen" / "Parameter" :
Router-Zertifikat:
CN=VPN
C=DE
L=Stadt
SN=Router
ST=NRW
E=email@provider.de
postalCode=12345
Client-Zertifikat:
Router-Zertifikat
CN=VPN
C=DE
L=Stadt
SN=Client01
ST=NRW
E=email@provider.de
postalCode=12345
Also die Zertifikate beinhalten folgende "Optionen" / "Parameter" :
Router-Zertifikat:
CN=VPN
C=DE
L=Stadt
SN=Router
ST=NRW
E=email@provider.de
postalCode=12345
Client-Zertifikat:
Router-Zertifikat
CN=VPN
C=DE
L=Stadt
SN=Client01
ST=NRW
E=email@provider.de
postalCode=12345
Wie gesagt muss auch die Schlüsselverwendung definiert werden: für den Server mindestens als Digitale Signatur, Schlüsselverschlüsselung, IP-Security und Server-Authentifizierung (wie bei jedem zertifikatbasierten VPN, schau dir nochmal entsprechende Leitfäden an).
Was ich gestern übersehen hatte: Deine ID wird ja auch abgelehnt. In der Regel wird der ASN1-DN-String auf einen Parameter verkürzt und der Subject Name erwartet, nicht CN. Ich würde hier vorerst eine andere ID nehmen, die weniger vom Parsing der jeweiligen Implementierung abhängt und den Fehler schon mal ausschließt. Und eben extern generell, unabhängig von der Implementierung funktionierende Zertifikate erzeugen, denn in der erweiterten Schlüsselverwendung des Lanconfig-Assistenten sehe ich auch keine Entsprechung für IP-Security (mag sein, dass das über "Verwedung für VPN 1..." festgelegt wird).
Was ich gestern übersehen hatte: Deine ID wird ja auch abgelehnt. In der Regel wird der ASN1-DN-String auf einen Parameter verkürzt und der Subject Name erwartet, nicht CN. Ich würde hier vorerst eine andere ID nehmen, die weniger vom Parsing der jeweiligen Implementierung abhängt und den Fehler schon mal ausschließt. Und eben extern generell, unabhängig von der Implementierung funktionierende Zertifikate erzeugen, denn in der erweiterten Schlüsselverwendung des Lanconfig-Assistenten sehe ich auch keine Entsprechung für IP-Security (mag sein, dass das über "Verwedung für VPN 1..." festgelegt wird).
Also es läuft bereits ein Zertifikatbasiertes VPN über IKEv1 (IPsec), mit der bestehenden Konfiguration.
Muss also bei IKEv2 irgendwas anders gemacht werden, an der Zertifikatbehandlung ?
Ich verstehe ehrlich gesagt nicht so ganz, was du mit "schlüsselverwendung" meinst...
Du meinst also ich soll den ASN1-String, den ich in der Konfiguration angegeben habe, ändern ?
In was ?
Und eine externe CA, möchte ich ungerne machen, dafür ham' wir ja die Lancom-Smart-CA extra...
Muss also bei IKEv2 irgendwas anders gemacht werden, an der Zertifikatbehandlung ?
Ich verstehe ehrlich gesagt nicht so ganz, was du mit "schlüsselverwendung" meinst...
Du meinst also ich soll den ASN1-String, den ich in der Konfiguration angegeben habe, ändern ?
In was ?
Und eine externe CA, möchte ich ungerne machen, dafür ham' wir ja die Lancom-Smart-CA extra...
Zitat von @geforce28:
Ich verstehe ehrlich gesagt nicht so ganz, was du mit "schlüsselverwendung" meinst...
Ich verstehe ehrlich gesagt nicht so ganz, was du mit "schlüsselverwendung" meinst...
Die üblichen Zertifikat-Erweiterungen "keyUsage" bzw. "extendedKeyUsage", um bei der Spezifikation zu bleiben. Ein Zertifikat wird ja abgelehnt, wenn der öffentliche Schlüssel nicht für die jeweilige Verwendung markiert ist. Wenn du das im aktuellen LANConfig machst, hast du (aus dem Gedächtnis) in demselben Dialog, in dem du deine Daten angibst zwei Schaltflächen "Schlüsselverwendung" bzw. "Erweiterte Schlüsselverwendung". Die öffnen je ein Fenster, wo du mit Haken das auswählen kannst. Unten ist noch ein Drop-Down "Verwendung für VPN 1..." , dessen Auswirkung auf das Zertifikat ich zugegebenermaßen nicht kenne. Aber wenn es im Log schon heißt
-Not configured as Server () or not cert as proposal -> abort
hast du jedenfalls kein ordentliches (Server-)Zertifikat.
Du meinst also ich soll den ASN1-String, den ich in der Konfiguration angegeben habe, ändern ?
Das ist ein anderes Problem:
IKE log: 184720.590222 Default rsa_sig_decode_hash: no CERT subject match the ID
In was ?
Den Subject Name-String "SN=Router". Konventionell würde eigentlich anhand eines (im Zweifel gleichlautenden) Subject Alternative Names identifiziert, den du in dieser beschränkten Zertifikats-Verwaltung meiner Erinnerung nach aber nicht zusätzlich festlegen kannst. Daher wird wohl der SN verwendet und akzeptiert. Wobei wie gesagt auf Fehlersuche überhaupt keine ASN1-ID anzuraten ist, die jeder Hersteller nach Lust und Laune interpretiert, sondern was Einfaches: E-Mail, FQDN etc.
Guten Morgen,
danke für deine Ansätze.
Es ist tatsächlich kein Server Zertifikat bei mir ausgewählt worden...
Beim Zertifikat erstellen auf der Smart-CA kann man aber einen SAN angeben, werde ich mal probieren...!
Zu deinem Ansatz die ASN1-ID nicht zu verwenden habe ich die Frage:
Sowohl auf Lancom-Seite, als auch auf Client Seite ?
Ich dachte die ASN1 wird immer benötigt, da sonst zertifikatbasiertes VPN garnicht läuft.. ?
Oder meinst du, dass ich auf Client Seite dann nur den als Entfernte ID den SAN angeben sollte, und bei lokale ID ?
Kannst du mal ein Beispiel machen, wie du das meinst, was jeweils auf Lancom und auf Client Seite bei den ID's eingetragen werden soll ?
Vielen Dank für deine Mühe !
danke für deine Ansätze.
Es ist tatsächlich kein Server Zertifikat bei mir ausgewählt worden...
Beim Zertifikat erstellen auf der Smart-CA kann man aber einen SAN angeben, werde ich mal probieren...!
Zu deinem Ansatz die ASN1-ID nicht zu verwenden habe ich die Frage:
Sowohl auf Lancom-Seite, als auch auf Client Seite ?
Ich dachte die ASN1 wird immer benötigt, da sonst zertifikatbasiertes VPN garnicht läuft.. ?
Oder meinst du, dass ich auf Client Seite dann nur den als Entfernte ID den SAN angeben sollte, und bei lokale ID ?
Kannst du mal ein Beispiel machen, wie du das meinst, was jeweils auf Lancom und auf Client Seite bei den ID's eingetragen werden soll ?
Vielen Dank für deine Mühe !
Ein zertifikatbasiertes VPN ist auch ohne ASN1-ID möglich. Erforderlich sind wechselseitig korrespondierende IKE(v2)-IDs, wie du es ja an sich versucht hast. Den ASN1-String zu verwenden, setzt aber das sichere Wissen voraus, wie er im konkreten Fall aus der Konfiguration geparst und mit dem Zertifikat abgeglichen wird. Oder eben Herumprobieren. Wenn du für den Client die E-Mail-Adresse als ID nimmst (also lokal auf dem Client/remote auf dem Server) und für den entsprechend Server die IP oder den FQDN, über den du ihn (immer) erreichst, sollte diese Fehlerquelle vorerst ausgeschlossen sein.
Wenn du dich geduldest, ich werde das bis Ende November mal praktisch ausprobieren, wenn auch nicht mit MacOS. Dann ist das nicht mehr so aus dem Gedächtnis geschrieben. Ein Thema, das du später bei bei MacOS ggf. noch abklären musst: Ob der Client Lancom-kompatible Cipher-Suites unterstützt/zulässt. CBC ist verbreitet, aber eben nicht mehr erste Wahl. Wenn das ein aktuelles MacOS (aus September?) mag es das vielleicht nicht mehr. Das aber nur am Rande, davon ist in der Log nichts zu sehen.
Wenn du dich geduldest, ich werde das bis Ende November mal praktisch ausprobieren, wenn auch nicht mit MacOS. Dann ist das nicht mehr so aus dem Gedächtnis geschrieben. Ein Thema, das du später bei bei MacOS ggf. noch abklären musst: Ob der Client Lancom-kompatible Cipher-Suites unterstützt/zulässt. CBC ist verbreitet, aber eben nicht mehr erste Wahl. Wenn das ein aktuelles MacOS (aus September?) mag es das vielleicht nicht mehr. Das aber nur am Rande, davon ist in der Log nichts zu sehen.
Habe das Problem nun quasi gefunden:
"ASN.1 Distinguished Names can't be used as identities because the client currently sends them as identities of type FQDN."
(https://forums.developer.apple.com/thread/61122)
Ist wohl ein Apple Problem, dass sowohl der Local Identifier, als auch der Remote Identifier, egal was man macht grundsätzlich als FQDN, anstatt als ASN.1 gesendet werden.
Ist dann wohl einfach nicht möglich mit dem integrierten Mac VPN Client, oder ?
Das blöde ist nur, dass der Lancom VPN Client für MAC auch keine IKEv2 Unterstützung hat....
Mit dem Windows Lancom VPN Client funktioniert Zertifikatbasiertes VPN...
"ASN.1 Distinguished Names can't be used as identities because the client currently sends them as identities of type FQDN."
(https://forums.developer.apple.com/thread/61122)
Ist wohl ein Apple Problem, dass sowohl der Local Identifier, als auch der Remote Identifier, egal was man macht grundsätzlich als FQDN, anstatt als ASN.1 gesendet werden.
Ist dann wohl einfach nicht möglich mit dem integrierten Mac VPN Client, oder ?
Das blöde ist nur, dass der Lancom VPN Client für MAC auch keine IKEv2 Unterstützung hat....
Mit dem Windows Lancom VPN Client funktioniert Zertifikatbasiertes VPN...
Zitat von @geforce28:
Ist dann wohl einfach nicht möglich mit dem integrierten Mac VPN Client, oder ?
Ist dann wohl einfach nicht möglich mit dem integrierten Mac VPN Client, oder ?
Mit einem anderen Identitätstyp für den Client schon, das strongSwan-Wiki listet das ja nur als Beschränkung: https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile
Wobei ich auch zweifel habe, ob sich OS X in der Beziehung wie iOS verhält.
Das Dokument habe ich auch schon gelesen, aber wohl nicht ganz verstanden... 
Was meinst du mit einem anderen Identitätstyp.
Geht ja dann nur FQDN als Identitätstyp und das sowohl für enternte ID, und lokale ID.
Muss dann beides FQDN sein...
Aber dann kann ich doch kein Zertifikat verwenden oder wo ist der Fehler ?
Was meinst du mit einem anderen Identitätstyp.
Geht ja dann nur FQDN als Identitätstyp und das sowohl für enternte ID, und lokale ID.
Muss dann beides FQDN sein...
Aber dann kann ich doch kein Zertifikat verwenden oder wo ist der Fehler ?
Wenn es da heißt
schließe ich daraus, dass man andere Identitäten anstelle von ASN.1 problemlos verwenden kann. Wie es der Zufall will, habe ich oben schon vorgeschlagen, keinen ASN.1-String zu verwenden, um (andere) Probleme zu vermeiden. Nimm doch einfach die E-Mail-Adresse.
ASN.1 Distinguished Names can't be used as identities because the client currently sends them as identities of type FQDN.
schließe ich daraus, dass man andere Identitäten anstelle von ASN.1 problemlos verwenden kann. Wie es der Zufall will, habe ich oben schon vorgeschlagen, keinen ASN.1-String zu verwenden, um (andere) Probleme zu vermeiden. Nimm doch einfach die E-Mail-Adresse.
Ja aber, wenn ich kein ASN1 angebe, kann der Lancom dann trotzdem fehlerfrei eine Verbindung per Zertifikaten aufbauen?
Habe es eben mal ausgetestet....
Im Lancom den local und remote Identifier auf FQDN gestellt und entsprechend am Client auch umgestellt.
Das macht der Lancom nicht mit...
Anbei mal eine Zeile auf seinem VPN-Packet trace:
Das sagt für mich aus, dass der Lancom immer den ASN1_DN haben will.
EDIT:
Also ein IKEv2 PSK VPN funktioniert natürlich...
Aber mir geht es hier ja um ein zertfikatbasiertes VPN, nicht dass wir uns Missverstehen
Habe es eben mal ausgetestet....
Im Lancom den local und remote Identifier auf FQDN gestellt und entsprechend am Client auch umgestellt.
Das macht der Lancom nicht mit...
Anbei mal eine Zeile auf seinem VPN-Packet trace:
Compare: -Received-ID local.local:FQDN != Expected-ID CN=xxx-VPN/C=DE/L=xxxx/SN=Client01/ST=xxx/E=xxx@xxx.de/postalCode=12345:DER_ASN1_DNDas sagt für mich aus, dass der Lancom immer den ASN1_DN haben will.
EDIT:
Also ein IKEv2 PSK VPN funktioniert natürlich...
Aber mir geht es hier ja um ein zertfikatbasiertes VPN, nicht dass wir uns Missverstehen
Jetzt habe ich mir das mit live angesehen, mit mäßigem Erfolg. Ich werde das selbst nicht mehr verwenden, sodass mein Ehrgeiz etwas gedämpft ist.
1. Ich habe StrongSwan für Android (ohne root) benutzt, der standardmäßig die ASN1-ID übermittelt. Von daher kann ich das mit anderen Identitäten nicht reproduzieren. Technisch erforderlich ist eine ASN1-Identität nicht, weil das Zertifikat ja gegen die CA geprüft wird, nicht gegen die IKE-ID. Wenn das mit OS X nicht funktioniert, kannst du StrongSwan auch dort installieren.
2. Da ich auf dem Gerät keine VPN-Option habe, habe ich die Zertifikate in xca erstellt:
CA:
Client:
Server:
VPN-Setup:
Das funktioniert im Ergebnis noch nicht. Mein Hauptproblem ist, dass das (mangels VPN-Option?) scheinbar auf Site-to-Site-Betrieb ausgelegt ist. Das Feld "Entfernter Gateway" gibt es in der Dokumentation nicht. Dort wird ein Hostname/eine IP der Gegenstelle erwartet, die unabhängig von den Identitäten und der IKE-Serverkonfiguration validiert werden. Natürlich Quatsch für ein Client-Setup. Habe ich da was übersehen, oder wie bist du darüber weg gekommen?
Wenn ich die IP dort eintrage, läuft das soweit, dass eine falsche Client-ID abgelehnt wird. Der ASN1-String als "richtige" ID für die obigen Zertifikate ist:
Richtig heißt in dem Fall, dass dann nicht mehr die ID abgelehnt wird, sondern das ganze an "ike general failure 0x22ff" scheitert (müsste ERR_IKE_REASSEMBLY_INCOMPLETE sein). Soweit vorerst, bis ich das mit einem statisch angebundenen Client nochmal angehe.
1. Ich habe StrongSwan für Android (ohne root) benutzt, der standardmäßig die ASN1-ID übermittelt. Von daher kann ich das mit anderen Identitäten nicht reproduzieren. Technisch erforderlich ist eine ASN1-Identität nicht, weil das Zertifikat ja gegen die CA geprüft wird, nicht gegen die IKE-ID. Wenn das mit OS X nicht funktioniert, kannst du StrongSwan auch dort installieren.
2. Da ich auf dem Gerät keine VPN-Option habe, habe ich die Zertifikate in xca erstellt:
CA:
Client:
Server:
VPN-Setup:
Das funktioniert im Ergebnis noch nicht. Mein Hauptproblem ist, dass das (mangels VPN-Option?) scheinbar auf Site-to-Site-Betrieb ausgelegt ist. Das Feld "Entfernter Gateway" gibt es in der Dokumentation nicht. Dort wird ein Hostname/eine IP der Gegenstelle erwartet, die unabhängig von den Identitäten und der IKE-Serverkonfiguration validiert werden. Natürlich Quatsch für ein Client-Setup. Habe ich da was übersehen, oder wie bist du darüber weg gekommen?
Wenn ich die IP dort eintrage, läuft das soweit, dass eine falsche Client-ID abgelehnt wird. Der ASN1-String als "richtige" ID für die obigen Zertifikate ist:
E=client@test.local,CN=Client,OU=Test,O=C.R.S.,L=Berlin,ST=Berlin,C=DERichtig heißt in dem Fall, dass dann nicht mehr die ID abgelehnt wird, sondern das ganze an "ike general failure 0x22ff" scheitert (müsste ERR_IKE_REASSEMBLY_INCOMPLETE sein). Soweit vorerst, bis ich das mit einem statisch angebundenen Client nochmal angehe.
Moin und danke erstmal vielmals für deine Mühe !!
Das Feld "Entferntes Gateway" ist bei mir auch und fehlt nur in der "Dokumentation", da es erst später dazugepatcht wurde...
Kann man einfach frei lassen, wenn man keins angeben möchte.
Bei "Lokales Zertifikat" in deinem vorletzten Screenshot hast du nichts ausgewählt, dort muss doch der VPN-Slot ausgewählt werden, wohin du das Server Zertifikat importiert hast, so sagte mir das der Lancom-Support.
Ich habe das ganze übrigens mittlerweile mal mit dem Windows Lancom Advanced VPN Client getestet, und dort läuft alles soweit fehlerfrei.
Problem ist bei mir noch immer, dass der MAC Client, egal was man macht IMMER sowohl lokale ID, als auch entfernte ID als FQDN sendet.... !
Das kann doch nicht wahr sein...
Das Feld "Entferntes Gateway" ist bei mir auch und fehlt nur in der "Dokumentation", da es erst später dazugepatcht wurde...
Kann man einfach frei lassen, wenn man keins angeben möchte.
Bei "Lokales Zertifikat" in deinem vorletzten Screenshot hast du nichts ausgewählt, dort muss doch der VPN-Slot ausgewählt werden, wohin du das Server Zertifikat importiert hast, so sagte mir das der Lancom-Support.
Ich habe das ganze übrigens mittlerweile mal mit dem Windows Lancom Advanced VPN Client getestet, und dort läuft alles soweit fehlerfrei.
Problem ist bei mir noch immer, dass der MAC Client, egal was man macht IMMER sowohl lokale ID, als auch entfernte ID als FQDN sendet.... !
Das kann doch nicht wahr sein...
Zitat von @geforce28:
Das Feld "Entferntes Gateway" ist bei mir auch und fehlt nur in der "Dokumentation", da es erst später dazugepatcht wurde...
Kann man einfach frei lassen, wenn man keins angeben möchte.
Das Feld "Entferntes Gateway" ist bei mir auch und fehlt nur in der "Dokumentation", da es erst später dazugepatcht wurde...
Kann man einfach frei lassen, wenn man keins angeben möchte.
Ich bekomme da eine Fehlermeldung, was mich auch überrascht hat. Jetzt habe oben leider nicht geschrieben, was für eine.
Bei "Lokales Zertifikat" in deinem vorletzten Screenshot hast du nichts ausgewählt, dort muss doch der VPN-Slot ausgewählt werden, wohin du das Server Zertifikat importiert hast, so sagte mir das der Lancom-Support.
Danke, wie peinlich. Am Wochenende probiere ich das nochmal.
Ich bin gespannt
So, mit der Korrektur läuft das jetzt (fast) mit dem eingebauten Android-Client sowie mit StrongSwan auf Android.
Was ich auf die Schnelle nicht weg bekomme, ist das Entfernte-Gateway-Problem. Wenn ich das freilasse, kommt:
Gegenüber oben habe ich den VPN1-Zertifikat-Container angegeben und die Server-ID auf ASN1 umgestellt. Entsprechend meinen Zertifikaten:
Das funktioniert sofort mit dem Android-Client (wo keine Server-ID zu konfigurieren ist). Trägt man das so als Server-Identität in StrongSwan ein, scheitert es allerdings zunächst (Server kann nicht authentifiziert werden):
Wie am Vergleich der Zeile 35 mit den übrigen ID-Strings ersichtlich ist, ist also die in StrongSwan einzutragende ID umgekehrt zu der im Lancom verwendeten. Mit clientseitig
als Server-ID funktioniert es. Das sollte so auch mit StrongSwan für Mac funktionieren.
Was ich auf die Schnelle nicht weg bekomme, ist das Entfernte-Gateway-Problem. Wenn ich das freilasse, kommt:
[VPN-Status] 2016/12/03 18:46:59,354 Devicetime: 2016/12/03 18:47:12,531
IKE info: ikev2: dropped message from {CLIENT-IP} port 37005 due to notification type INVALID_SYNTAX
[VPN-Status] 2016/12/03 18:46:59,370 Devicetime: 2016/12/03 18:47:12,531
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 628 bytes
Gateways: {SERVER-IP}:500<--{CLIENT-IP}:37005
SPIs: 0xCDAA617E88F5B1FD0000000000000000, Message-ID 0
-[ISAKMP-PEER-DEFAULT].VPN-ID is empty
-Message could not be validated => droppingGegenüber oben habe ich den VPN1-Zertifikat-Container angegeben und die Server-ID auf ASN1 umgestellt. Entsprechend meinen Zertifikaten:
E=server@test.local,CN=Server,OU=Test,O=C.R.S.,L=Berlin,ST=Berlin,C=DEDas funktioniert sofort mit dem Android-Client (wo keine Server-ID zu konfigurieren ist). Trägt man das so als Server-Identität in StrongSwan ein, scheitert es allerdings zunächst (Server kann nicht authentifiziert werden):
Dec 3 19:03:54 00[DMN] Starting IKE charon daemon (strongSwan 5.4.0, Linux 3.4.0-4540543, armv7l)
Dec 3 19:03:54 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
Dec 3 19:03:54 00[JOB] spawning 16 worker threads
Dec 3 19:03:54 07[CFG] loaded user certificate 'C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Client, E=client@test.local' and private key
Dec 3 19:03:54 07[CFG] loaded CA certificate 'C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=CA, E=test@test.local'
Dec 3 19:03:54 07[IKE] initiating IKE_SA android[137] to {SERVER-IP}
Dec 3 19:03:54 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) ]
Dec 3 19:03:54 07[NET] sending packet: from {CLIENT-IP}[57432] to {SERVER-IP}[500] (732 bytes)
Dec 3 19:03:56 10[IKE] retransmit 1 of request with message ID 0
Dec 3 19:03:56 10[NET] sending packet: from {CLIENT-IP}[57432] to {SERVER-IP}[500] (732 bytes)
Dec 3 19:03:56 11[NET] received packet: from {SERVER-IP}[500] to {CLIENT-IP}[57432] (38 bytes)
Dec 3 19:03:56 11[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Dec 3 19:03:56 11[IKE] peer didn't accept DH group ECP_256, it requested MODP_4096
Dec 3 19:03:56 12[MGR] ignoring request with ID 0, already processing
Dec 3 19:03:57 11[IKE] initiating IKE_SA android[137] to {SERVER-IP}
Dec 3 19:03:57 11[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) ]
Dec 3 19:03:57 11[NET] sending packet: from {CLIENT-IP}[57432] to {SERVER-IP}[500] (1180 bytes)
Dec 3 19:03:58 13[NET] received packet: from {SERVER-IP}[500] to {CLIENT-IP}[57432] (713 bytes)
Dec 3 19:03:58 13[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
Dec 3 19:03:58 13[IKE] local host is behind NAT, sending keep alives
Dec 3 19:03:58 13[IKE] received 1 cert requests for an unknown ca
Dec 3 19:03:58 13[IKE] sending cert request for "C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=CA, E=test@test.local"
Dec 3 19:03:59 13[IKE] authentication of 'C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Client, E=client@test.local' (myself) with RSA signature successful
Dec 3 19:03:59 13[IKE] sending end entity cert "C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Client, E=client@test.local"
Dec 3 19:03:59 13[IKE] establishing CHILD_SA android
Dec 3 19:03:59 13[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) ]
Dec 3 19:03:59 13[NET] sending packet: from {CLIENT-IP}[60404] to {SERVER-IP}[4500] (2064 bytes)
Dec 3 19:03:59 16[NET] received packet: from {SERVER-IP}[4500] to {CLIENT-IP}[60404] (1616 bytes)
Dec 3 19:03:59 16[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH CPRP(DNS DNS ADDR) TSi TSr N(INIT_CONTACT) SA ]
Dec 3 19:03:59 16[IKE] received end entity cert "C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Server, E=server@test.local"
Dec 3 19:03:59 16[CFG] using certificate "C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Server, E=server@test.local"
Dec 3 19:03:59 16[CFG] using trusted ca certificate "C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=CA, E=test@test.local"
Dec 3 19:03:59 16[CFG] reached self-signed root ca with a path length of 0
Dec 3 19:03:59 16[IKE] authentication of 'C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Server, E=server@test.local' with RSA signature successful
Dec 3 19:03:59 16[CFG] constraint check failed: identity 'E=server@test.local, CN=Server, OU=Test, O=C.R.S., L=Berlin, ST=Berlin, C=DE' required
Dec 3 19:03:59 16[CFG] selected peer config 'android' inacceptable: constraint checking failed
Dec 3 19:03:59 16[CFG] no alternative config found
Dec 3 19:03:59 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Dec 3 19:03:59 16[NET] sending packet: from {CLIENT-IP}[60404] to {SERVER-IP}[4500] (80 bytes)Wie am Vergleich der Zeile 35 mit den übrigen ID-Strings ersichtlich ist, ist also die in StrongSwan einzutragende ID umgekehrt zu der im Lancom verwendeten. Mit clientseitig
C=DE, ST=Berlin, L=Berlin, O=C.R.S., OU=Test, CN=Server, E=server@test.localals Server-ID funktioniert es. Das sollte so auch mit StrongSwan für Mac funktionieren.
