Ich hatte an dieser Stelle vor einiger Zeit beschrieben, wie man das IPSEC-VPN der OVGU konfiguriert um einigermaßen schmerzfrei arbeiten zu können.

Mit einem Update vor kurzem funktioniert die dort beschrieben Konfiguration nicht mehr, die Verbindung wird zwar zunächst aufgebaut, aber sofort terminiert. Wie ich nach einigem Debuggen (IKEv1 ist ein absurdes Protokoll, aber hier trotzdem ein kleines Parserchen) und einem Ticket mit erwartungsgemäß vollständig nutzloser Support-Antwort (dort meint man nur AnyConnect supporten zu müssen, obwohl IPSEC offiziell auf der Webseite beschrieben wird) festgestellt habe, liegt das an einer einzelnen Einstellung. Irgendwo in der PFS-Aushandlung nach dem initialen Handshake wird nochmal eine RSA-Gruppe eingestellt, und die „default“-Einstellung von SSVPN (und auch den meisten OS-nativen Clients) ist eine 768-bit MODP group. Diese MUSS laut RFC von jeder Serversoftware unterstützt werden. Wird sie aber mit der jetzt ausgerollten Version „Cisco Systems, Inc ASA5540 Version 9.1(devil) built by builders on Fri 27-Feb-15 13:50“ nicht mehr, die damit gegen RFC 2409 verstößt. Die korrekte Verhaltensweise im Falle unsupporteter Gruppen-Anforderungen ist übrigens eine „ATTRIBUTES-NOT-SUPPORTED(13)“-Message. Stattdessen kommt eine „NO-PROPOSAL-CHOSEN(14)“, man verstößt also gleich nochmal gegen die RFC, und das in einer Art und Weise, die das Debuggen gleich nochmal schwerer macht.

Der Fix ist jetzt also: in SSVPN in den Phase2-Einstellung die Group 2 erzwingen.

Hier findet ihr eine Konfigurationsdatei zum direkten Importieren: UniMDVPN.vpn

Für den Zugang zu internen Maschinen braucht man an der Univerität Magdeburg wie bei viele anderen eine VPN-Einwahl. Man setzt dabei aus unerfindlichen Gründen auf Cisco AnyConnect, und damit fangen die Probleme an.

Dort gibt es eine Policy-Einstellung, die dafür sorgt, dass der AC-Client eine Route für 0.0.0.0/255.255.255.255 setzt – sich also alle Verbindungen krallt, nicht nur die, die an Server der Uni gehen. Das macht sogar teilweise Sinn, so funktioniert zum Beispiel die Netblock-Authentifizierung für den Zugang zu den Archiven mancher Journals. Meistens allerdings bringt das nur Ärger – nämlich dann, wenn man durch diese Verbindung aus dem eigenen LAN gekegelt wird und z.B. an seine Dateien nicht mehr rankommt.

Zum Glück ist aber auch IPsec verfügbar, und mit etwas Tricksen funktioniert das dann auch.

Als IPSec-Client verwende ich den Shrew Soft VPN Client. Windows enthält zwar selbst einen, der ist aber so gut wie nicht konfigurierbar.

Die Grundeinstellungen sind relativ einfach und mit dem bebilderten Teil hier und den vom URZ genannten Daten recht einfach eingerichtet. Ist man etwas fauler (also Student), existierten früher auch mal PCF-Files, die die komplette Konfiguration enthalten. Mittlerweile werden nicht mehr angeboten, aber mit etwas Googelei findet man da durchaus noch etwas. Nach Laden der Datei UniMDVPN.pcf sind nur noch zwei Einstellungen notwendig: Auf der Seite „Phase 1“ muss der Hash Algorithm von Default auf SHA1 umgestellt werden. Default ist nämlich MD5 (auch bei Windows, da kann man das aber nicht einfach umstellen), verwendet man das allerdings im Handshake wird die Verbindung direkt in der Luft hängen gelassen.
Außerdem umzustellen ist auf der letzten Seite („Policy“) die Routen-Generierung. Hier sind wir bei der erwähnten Einstellung von AnyConnect, alle Verbindungen zu kapern. Das passiert auch hier standardmäßig, wenn „Obtain toplogy automatically or tunnel all“ gesetzt ist. Dort also den Haken entfernen und Routen von Hand eintragen. Da ich das nur für Uniserver brauche, habe ich hier Include:141.44.0.0/255.255.0.0 gesetzt, so dass alle anderen Verbindungen unbeeinflusst bleiben.

Die Verbindung sollte sich jetzt herstellen lassen und z.B. SSH auf die richtige Maschine funktionieren. Wenn nicht – überprüfen, ob der Router auch so eingestellt ist, dass L2TP und IPSec durchgelassen werden 😉