VPN mit Mac OS oder iOS mit Cisco IPSec und Zertifikaten

[Hagen2000]

Hallo zusammen,

ich versuche bestehende VPN-Verbindungen mit den systemeigenen Clients von Mac OS bzw. iOS zum LANCOM-Router (alles jeweils aktuelle SW-Versionen) von PSK auf Zertifikate umzustellen, damit u.A. VPN-on-demand funktioniert.

Für die Zertifikatserstellung verwenden wir eine eigene CA (erstellt mit openssl bzw. xca).

Leider finde ich in der KB von LANCOM nur wenig Hilfreiches. Gibt es Forumsmitglieder, die so etwas schon mal zum Laufen gebracht haben und ein paar Tipps dazu geben können?

Auch Links auf weiterführende Dokumente sind willkommen!

[Hagen2000]

Ich komme hier alleine nicht weiter.
Folgende Kombinationen funktionieren:

• Cisco IPSec Client (Mac OS 10.11.3) mit PSK / aggressive mode
• LANCOM Advanced Client mit Zertifikat, ohne XAUTH
• LANCOM Advanced Client mit Zertifikat, mit XAUTH

Versuche ich hingegen mit dem Cisco IPSec Client mit Zertifikaten eine Verbindung aufzubauen, so scheint es Probleme in der XAUTH-Phase zu geben. Folgend die Trace-Daten auf dem LANCOM-Router:

Code: Alles auswählen

[VPN-IKE] 2016/03/17 09:06:28,946  Devicetime: 2016/03/17 09:06:26,968
Sending packet before encryption:
IKE 1.0 Header:
Source/Port         : xxx.xxx.xxx.xxx:4500
Destination/Port    : yyy.yyy.yyy.yyy:4500
| Initiator cookie  : FC 61 6E 3B 97 6E C7 57
| Responder cookie  : 5A AE 1F E1 E8 EA C3 C7
| Next Payload      : HASH
| Version           : 1.0
| Exchange type     : TRANSACTION
| Flags             : 0x00   
| Msg-ID            : 3859603308
| Length            : 76 Bytes
HASH Payload
| Next Payload      : ATTRIBUTE
| Reserved          : 0x00
| Length            : 24 Bytes
| Signature Data    : AA CB 73 FD 19 A4 27 46 E6 27 74 6E 54 67 34 F0
|                     1C 8D 5B F2
ATTRIBUTE Payload
| Next Payload      : NONE
| Reserved          : 0x00
| Length            : 20 Bytes
| Type              : REQUEST
| Reserved2         : 0x00
| Identifier        : 18578
| Attribute 0
| | Type            : Basic, XAUTH_TYPE
| | Value           : 0
| Attribute 1
| | Type            : Variable, XAUTH_USER_NAME
| | Length          : 0
| | Value           : 
| Attribute 2
| | Type            : Variable, XAUTH_PASSWORD
| | Length          : 0
| | Value           : 
Rest                : 00 00 00 00

[VPN-IKE] 2016/03/17 09:06:28,946  Devicetime: 2016/03/17 09:06:26,969
Sending packet after encryption:
IKE 1.0 Header:
Source/Port         : xxx.xxx.xxx.xxx:4500
Destination/Port    : yyy.yyy.yyy.yyy:4500
| Initiator cookie  : FC 61 6E 3B 97 6E C7 57
| Responder cookie  : 5A AE 1F E1 E8 EA C3 C7
| Next Payload      : HASH
| Version           : 1.0
| Exchange type     : TRANSACTION
| Flags             : 0x01 Encrypted  
| Msg-ID            : 3859603308
| Length            : 76 Bytes
Encrypted Data      : 33 B0 7E 99 AB 8E 19 6F 77 26 98 54 75 B0 5A 2B
                      EF 5B F8 18 08 BB 2C C0 73 2A 3A 21 DC 06 E4 BE
                      A1 45 DC F7 06 0B 1B DE D8 5F C7 FC 97 5B 93 C3

[VPN-IKE] 2016/03/17 09:06:29,024  Devicetime: 2016/03/17 09:06:27,048
Received packet:
IKE 1.0 Header:
Source/Port         : xxx.xxx.xxx.xxx:4500
Destination/Port    : yyy.yyy.yyy.yyy:4500
| Initiator cookie  : FC 61 6E 3B 97 6E C7 57
| Responder cookie  : 5A AE 1F E1 E8 EA C3 C7
| Next Payload      : HASH
| Version           : 1.0
| Exchange type     : INFO
| Flags             : 0x01 Encrypted  
| Msg-ID            : 3087407191
| Length            : 76 Bytes
Encrypted Data      : 82 A3 E2 59 D5 00 01 D6 A4 6B 10 B3 06 D5 8B 63
                      78 E5 A5 16 94 19 2C 75 D7 50 4E 49 9C 79 86 60
                      37 BA FB 24 1D 91 9A D6 95 49 0F D4 C0 01 2D 71

[VPN-IKE] 2016/03/17 09:06:29,024  Devicetime: 2016/03/17 09:06:27,049
Received packet after decryption:
IKE 1.0 Header:
Source/Port         : xxx.xxx.xxx.xxx:4500
Destination/Port    : yyy.yyy.yyy.yyy:4500
| Initiator cookie  : FC 61 6E 3B 97 6E C7 57
| Responder cookie  : 5A AE 1F E1 E8 EA C3 C7
| Next Payload      : HASH
| Version           : 1.0
| Exchange type     : INFO
| Flags             : 0x00   
| Msg-ID            : 3087407191
| Length            : 76 Bytes
check_general_parse_errors: payload HASH at offset 28 of length 17887 exceeds the packet's limit at offset 76
Rest                : D7 94 45 DF FF F4 8E 71 47 D7 9B 2D A4 E1 FD DE
                      C3 5A F6 7E 4E EB 10 5A 00 00 00 0C 00 00 00 01
                      01 00 00 16 00 00 00 00 00 00 00 00 00 00 00 0C

[VPN-Status] 2016/03/17 09:06:29,024  Devicetime: 2016/03/17 09:06:27,049
IKE log: 090627.049481 Default message_parse_payloads: reserved field non-zero: 94

[VPN-Status] 2016/03/17 09:06:29,024  Devicetime: 2016/03/17 09:06:27,049
IKE log: 090627.049627 Default dropped message from 87.168.126.189 port 4500 due to notification type PAYLOAD_MALFORMED

[VPN-Status] 2016/03/17 09:06:29,024  Devicetime: 2016/03/17 09:06:27,049
IKE info: Informational messages are unidirectional and therefore are not answered! (cookies FC 61 6E 3B 97 6E C7 57 5A AE 1F E1 E8 EA C3 C7)


[VPN-IKE] 2016/03/17 09:06:36,013  Devicetime: 2016/03/17 09:06:33,820
Resending encrypted packet:
IKE 1.0 Header:
Source/Port         : xxx.xxx.xxx.xxx:4500
Destination/Port    : yyy.yyy.yyy.yyy:4500
| Initiator cookie  : FC 61 6E 3B 97 6E C7 57
| Responder cookie  : 5A AE 1F E1 E8 EA C3 C7
| Next Payload      : HASH
| Version           : 1.0
| Exchange type     : TRANSACTION
| Flags             : 0x01 Encrypted  
| Msg-ID            : 3859603308
| Length            : 76 Bytes
Encrypted Data      : 33 B0 7E 99 AB 8E 19 6F 77 26 98 54 75 B0 5A 2B
                      EF 5B F8 18 08 BB 2C C0 73 2A 3A 21 DC 06 E4 BE
                      A1 45 DC F7 06 0B 1B DE D8 5F C7 FC 97 5B 93 C3

[TraceStopped] 2016/03/17 09:06:36,699
Used config:
# Trace config
trace + VPN-IKE
trace + VPN-Status

# Show commands
show bootlog 
[Legend] 2009/07/09 00:00:00,000
VPN-Status, TraceStarted, TraceStopped, Sysinfo, ShowCmd, VPN-IKE
[Index] 2009/07/09 00:00:00,000
1,141,8;4,7909,356;3,1355,43;5,702,17;0,200,4;0,267,5;5,1036,30;5,771,18;0,197,3;0,150,3;0,131,3;0,131,3;5,11365,367;0,532,7;0,1364,14;5,2697,86;5,1735,43;
5,2551,58;5,7642,115;5,8322,143;0,167,3;5,8432,142;5,7871,118;0,652,7;0,182,3;0,173,3;5,1241,39;5,713,17;5,690,17;5,809,18;0,161,3;0,198,3;0,221,4;5,708,17;
2,141,8;

Beim Paket mit Devicetime: 2016/03/17 09:06:27,049 geht irgendetwas mit der Payload schief.
Die ersten Bytes D7 94 45 DF werden offensichtlich als Länge (0x45DF = 17887) und Typ (0x94) interpretiert.

Wo liegt der Fehler bzw. wo muss ich weiter suchen?

[steveurkel]

Hallo Hagen2000!

Ich stand vor einem ähnlichen Problem. (alte Router ohne myVPN) und ich wollte endlich vom unsicheren AgressiveMode wegkommen
Mit Shrew hat es mit Zertifikaten wunderbar funktioniert. Nur das Iphone wollte nicht. Das zeigt dann nämlich an "Serverzertifikat konnte nicht überprüft werden".
Ich habe mich an folgender Anleitung orientiert http://www.mhslabs.de/index.php (mit unten beschriebener Ergänzung)

Das hat folgenden Hintergrund: Zuerst schaut das Iphone ob dem eigenen Clientzertifikat UND dem vom Lancom übermittelten Serverzertifikat vertraut wird. Dazu muss das Root-Zertifikat in das Iphone importiert werden. (Als Zertifizierungsstelle). Du hast dann also zwei Zertifikate auf dem Iphone. (Im XCA Root-Ca markieren, Export im Format DER und dann aufs Iphone importieren) Beide sind dann grün mit "vertrauenswürdig markiert und alle von dieser CA ausgestellten Zertifikate sind jetzt "vertrauenswürdig"

Und nun prüft das Iphone ob im Zertifikat das der Lancom bei der Einwahl liefert auch das "subject alternative name" enthalten ist. (Das findest du auf der Seite "Erweiterungen" im XCA)

Steht da nix drin wird die Aushandlung mit obiger Fehlermeldung abgebrochen.

Wenn es einen "subject alternative name" vom Typ DNS: findet wird versucht den DNS-Namen aufzulösen und vergleicht dann das Ergebnis mit der IP-Adresse (aufgelöster DNS-Name) unter der der Lancom erreichbar ist. Wer sowieso mit festen IPs arbeitet kann auch den Typ IP statt DNS probieren.

Wenn alles i.o. ist wird der Tunnel erfolgreich aufgebaut, ansonsten kommt wieder die obige Fehlermeldung.


Gruss

Steffen

[Hagen2000]

Hallo Steffen,

vielen Dank für die Hinweise. Ich hatte kurz vor Ostern noch eine VPN-Verbindung erfolgreich aufbauen können und auch die von Dir erwähnten Punkte (mehr oder weniger zufällig) berücksichtigt. Einige Details sind jedoch noch offen, insbesondere der Test mit einem iPhone.

Ich habe mich zunächst auf die Verbindung von einem Mac (mit aktueller Version 10.11) aus konzentriert, da hier bessere Diagnosemöglichkeiten zur Verfügung stehen als auf einem iPhone oder iPad.

Den gesamten Import der VPN-Einstellungen habe ich übrigens über ein Profil, erstellt mit dem Apple Configurator 2, gelöst. Das funktioniert recht komfortabel. Das Stammzertifikat hatte ich ohnehin schon mit aufgenommen, da es auch für https-Zugriffe auf hausinterne Server benötigt wird. Aber Danke für den Hinweis, dass damit das Serverzertifikat überprüft wird. Bei meinen ersten Tests ohne Stammzertifikat erschien beim VPN-Tunnelaufbau eine Fehlermeldung, dass das Serverzertifikat nicht überprüft werden konnte. Jetzt ist klar, wieso.

Mac OS arbeitet offenbar mit dem racoon VPN-Client. Hier bekommt man über die Console-App zumindest ein paar Log-Meldungen angezeigt und ist nicht so blind wie beim iPhone.

Was ich allerdings noch nicht zum Laufen bekommen habe, ist die PFS (Perfect Forward Secrecy). In der /etc/racoon/racoon.conf finden sich zwar Einträge der Form „pfs_group 1;“ - allerdings alle in Kommentaren. Für die aktive VPN-Verbindung wird dynamisch eine Konfigurationsdatei im Verzeichnis /var/run/racoon erzeugt und hier ist nicht die Rede von PFS. Auf der LANCOM-Seite muss daher die PFS-Gruppe auf "kein PFS" gestellt werden. Dies widerspricht irgendwie der Apple-Dokumentation https://help.apple.com/deployment/ios/#/ior03a622a9f, in der steht, dass für PFS dieselbe Gruppe wie für Phase 1 (IKE) eingetragen werden muss und es dann funktionieren soll.

Zum Subject Alternative Name:
Ich habe hier http://docplayer.org/2478181-Vpn-ipsec- ... emand.html gelesen, dass der CN im Zertifikat dem FQDN des Servers entsprechen muss, da der VPN-Client diesen nochmals überprüft. Daher habe ich den CN des VPN-Zertifikats für den LANCOM-Router entsprechend aufgesetzt. Diese Einstellung scheint offenbar vom racoon-Client zwingend vorausgesetzt zu werden.

Anm.: Der "subject alternative name" (SAN)- Eintrag ist nicht zwingend erforderlich. Falls er jedoch existiert, wird der CN des Zertifikats ignoriert. Das ist interessant zu wissen für den Fall, dass man in einem Zertifikat mehrere DNS-Einträge benötigt. Die SAN-Liste ist also keine Ergänzung zum CN sondern wird alternativ zu diesem benutzt.

Wie schon oben erwähnt, benutze ich den Apple Configurator 2. Damit habe ich auch bereits VPN on demand zum Laufen bekommen! Es fehlt allerdings noch die Konfiguration der WLANs, in denen der VPN-Tunnel nicht benötigt wird (z.B. wenn man sich ohnehin im Firmen-WLAN befindet). Dies kann man offenbar nur durch manuelles Editieren des Profils (ist eine XML-Datei) erreichen.

Ganz interessant ist auch dieser Artikel: http://dertest.org/2014/08/iphone-ipad- ... pn-router/

Es bleiben also folgende zwei Fragen:

- Wie kann PFS aktiviert werden?
- Wie kann die Liste der auszunehmenden WLANs (OnDemandRules) konfiguriert werden?

[Hagen2000]

So, es läuft nun mit Mac OS 10.11.4 und iOS 9.3.1. Hier noch in der Kürze ein paar Details, die es zu beachten gilt:

• Mit dem Apple Configurator 2.2 kann das VPN-Profil samt Client-Zertifikat + privatem Schlüssel (sollten zusammen in einer .p12-Datei vorliegen) komfortabel vorbereitet werden.
• Das Stammzertifikat muss ebenfalls auf das Gerät gebracht werden, da dieses zum Verifizieren des VPN-Serverzertifikats benötigt wird. Dabei darf bei Mac OS kein Konfigurationsprofil verwendet werden, da das Stammzertifikat dabei regelmäßig falsch installiert wird. Am besten importiert man zuerst das Stammzertifikat als PEM-Datei (.cer oder .crt usw.) von Hand in den Schlüsselbund system und spricht ihm dann das Vertrauen für alle Benutzer aus. Bei iOS hingegen gab es keine Probleme mit der Installation des Stammzertifikats über ein Konfigurationsprofil.
• Die OnDemandRules müssen mit einem Texteditor nachträglich von Hand erstellt werden, da der Apple Configurator 2.2 hier nur die eigentlich seit iOS 7 abgekündigten, alten Einträge vornehmen kann, die viele Einstellungen nicht ermöglichen. Siehe https://developer.apple.com/library/mac ... ction.html für eine vollständige Referenz.
• Das von Hand editierte Konfigurationsprofil konnte ich problemlos mit dem Apple Configurator 2.2 per USB auf ein angeschlossenes iPhone übertragen und sogar vorher bearbeiten ohne dass die händisch erstellen Einträge verloren gingen. Dieses Verhalten ist aber nirgends offiziell spezifiziert!
• PFS wird offenbar erst ab IKEv2 unterstützt.
• Wie schon zuvor erwähnt, muss im VPN-Serverzertifikat der CN dem FQDN im WAN des LANCOM-Routers entsprechen (also z.B. der DynDNS-Name). Er sollte zusätzlich auch in der SAN-Liste des Zertifikats enthalten sein. Dies ist angeblich bei IKEv2 zwingend erforderlich, das habe ich jedoch nicht verifiziert. Bei IKEv1 funktioniert es definitiv auch ohne diesen Eintrag.
• In der zugehörigen IPSec-Proposal-Liste muss das Proposal TN-AES-SHA-96 enthalten sein.

Viel Erfolg bei eigenen Konfigurationen!