WatchGuard unterstützt die Mobile VPN-Protokolle IKEv2, SSLVPN, IPsec und L2TP, um sich sicher mit dem Firmennetzwerk zu verbinden. Hierbei kommt immer wieder die Frage auf, welches Protokoll für die Anforderungen am Besten geeignet ist.
Dieses Webinar zeigt Ihnen die Vor- und Nachteile der sicheren Verbindungen und kann Sie bei der Entscheidungsfindung unterstützen:
VPN-Verbindungen sind in den letzten Jahren zu einer immer wichtigeren Komponente der hybriden Arbeitswelt geworden. Es ist nicht nur essentieller geworden Mitarbeitern von extern einen Zugang auf die interne Infrastruktur und dahinterliegenden Ressourcen zu gewähren, sondern diese auch mit mehr als nur einem Benutzernamen und Passwort zu sichern. Des Weiteren ist die Wahl des Protokolls und Komplexität der Verwaltung ein weiterer Faktor, der den Einsatz der “richtigen” VPN-Lösung für den eigenen Use Case bestimmt.
In diesem Webinar stellen WatchGuard Security-Experten die Kombination der Multifaktor-Lösung WatchGuard AuthPoint mit den Mobile VPN Varianten von IKEv2 und SSL der WatchGuard Fireboxen (Cloud/Lokal) dar.
WatchGuard unterstützt die Mobile VPN-Protokolle IKEv2, SSLVPN, IPsec und L2TP um sich sicher mit dem Firmennetzwerk zu verbinden. Hierbei kommt immer wieder die Frage auf, welches Protokoll für die Anforderungen am besten geeignet ist?
Folgende Themen werden in diesem Webinar behandelt:
Der WatchGuard SSLVPN Client kann auch für eine “silent”-Installation ohne Benutzerinteraktion installiert werden. Folgende Kommandozeilenparameter werden unterstützt:
Ein Kunde hatte Probleme mit dem SSLVPN unter Windows 10: nach Aufbau des VPNs wurde die WLAN-Verbindung getrennt. Weiterlesen
WatchGuard hat mit Fireware 11.12.2 das Authentication Portal (üblicherweise auf Port 4100) noch weiter vom SSLVPN-Portal abgetrennt. Bei älteren Fireware Releases war es möglich, über https://[IP-der-Firebox]/sslvpn_logon.shtml die SSLVPN-Login-Seite aufzurufen und über https://[IP-der-Firebox]/logon.shtml die Login-Seite für die normale User Authentifizierung an der Firewall – unabhängig davon, welcher Port (4100/Authentification oder 443/SSLVPN bzw. anderer eingestellter Port) aufgerufen wurde. Die saubere Trennung der beiden Dienste führt nun einerseits zu einer erhöhten Sicherheit, ist aber möglicherweise für den einen oder anderen etwas hinderlich. Beispielsweise wenn jemand, der die Authentifizierung von External nutzen soll, an seinem aktuellen Internet-Zugang nicht über Port 4100 ins Internet hinaus darf. Hier war es extrem praktisch, die Authentifizierung eben auch auf dem üblicherweise in ausgehende Richtung offenen Port 443 ansprechen zu können.
Folgende Workarounds können nun eingerichtet werden:
Falls der externe Port 443 bereits für Microsoft Outlook Web Access (OWA) oder einen anderen Dienst (interner Webserver mit HTTPS) für die Weiterleitung nach innen benutzt wird, hilft hierbei künftig eventuell ein für Fireware 12.x angekündigtes neues Feature: Host Header Redirection. Mit diesem Feature soll es möglich werden, auf der WatchGuard Firewall ein Multidomain/SAN-Zertifikat zu installieren und dann abhängig vom jeweiligen Hostnamen auf unterschiedliche interne IPs weiterzuleiten. Leider wird hier nach meinem Kenntnisstand SSLVPN außen vor bleiben.
Die Watchguard XTM 330 wird ab Werk bereits mit dem XTM Pro Upgrade und den damit verbundenen Funktionserweiterungen wie Multi-WAN, Policy Based Routing, Dynamic Routing, QoS und der Maximalzahl der vorgesehenen 55 SSLVPN-User ausgeliefert. Bei den größeren Modellen ab XTM 5 aufwärts ist bei XTM Pro auch die Cluster-Fähigkeit (HA) in den Versionen Active/Active und Active/Passive enthalten.
Derzeit wird jedoch bei der XTM 330 kein HA (Cluster) unterstützt!
In einer der künftigen Softwareversionen soll jedoch die Clusterfähigkeit auch für die XTM 330 freigeschaltet werden!
Vor ein paar Wochen hatte ich den Fall, dass ein Kunde eine RSA SecurID Appliance (v3.0) zur Two-Factor Authentication seiner WatchGuard Mobile User VPN Verbindungen nutzen wollte. Trotz vermeintlich korrekter Konfiguration sowohl der WatchGuard XTM 510 als auch der RSA Appliance wollte es partout nicht klappen. Die eigentliche Ursache kam erst fast zufällig in einem Support Call mit RSA ans Tageslicht: weil NTP (Network Time Protocol), also der automatische Zeitabgleich mit Zeitservern im Internet auf der RSA Appliance fehlerhaft konfiguriert war, hatte die RSA Appliance eine um etwa 12 Stunden falsche Systemzeit, was eben zur Ablehnung der Usereinwahlen geführt hat… Mit korrekter Systemzeit auf der RSA Appliance war dann “alles gut”…
Puuuuh, nach mehr als einem halben Jahr komme ich endlich mal wieder dazu, hier einen Beitrag zu schreiben. Ich will nicht klagen, es waren einfach sehr viele und anspruchsvolle Projekte in den letzten Monaten. In den nächsten Wochen hoffe ich nun, hier wieder einige hilfreiche Postings schreiben zu können.
Ich fange mit einem “alten Schuh” an, allerdings in einer etwas anderen Ausprägung. Ich habe bereits ja empfohlen, sich in der WatchGuard XML Konfigurationsdatei, und insbesondere bei Passwörtern, Pre-Shared Keys etc. auf den Zeichensatz US-ASCII 7 zu beschränken, d.h. also insbesondere auf die Verwendung von äöüß und Sonderzeichen zu verzichten. Ich empfehle sogar, Kennwörter etc. gänzlich nur aus den klassischen Buchstaben A-Z, a-z und den Ziffern 0-9 zu bilden. Ganz ohne Sonderzeichen, lieber ein paar Stellen mehr…
Wenn nun User Authentication gegenüber Active Directory im Spiel ist, sollte diese Grundregel auch beherzigt werden, wenn die User ihre AD/Windows-Kennwörter festlegen. Ein Kunde berichtete von MUVPN-Einwahl-Problemen bei einem bestimmten User. Dieser hatte ein €-Zeichen in seinem Windows-Kennwort. Die Einwahl schlug fehl. Nach Änderung des AD/Windows-Kennworts (ohne €-Zeichen) war die Einwahl erfolgreich!
Der Kunde hat mir freundlicherweise eine Liste von Zeichen geschickt, die in einem AD/Windows-Kennwort vorkommen dürfen, damit eine MUVPN-Einwahl / User Authentication erfolgreich ist:
!#$%&()*+,-.0123456789:;<=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]_abcdefghijklmnopqrstuvwxyz{} und das “Leerzeichen”…
Diese Einschränkung dürfte dann auch gelten, wenn die Einwahl bzw. Authentication per PPTP-VPN (i.V. mit RADIUS), SSL-VPN (AD oder RADIUS) und auch in Verbindung mit Two-Factor Authentication Systemen wie VASCO oder RSA gegenüber AD erfolgt!
In einem Support Incident hatte ich in den letzten Wochen mit dem Problem zu kämpfen, dass Mobile User, die sich per MUVPN (NCP IPSec Client) oder WatchGuard SSL-VPN-Client einwählen, zwar eine augenscheinlich stabile VPN-Verbindung stehen haben – aber trotzdem nicht auf Resourcen im lokalen Netzwerk zugreifen können.
Die Besonderheit hierbei war jedoch, dass der Zugriff unmittelbar nach der Einwahl möglich war (z.B. Test per “ping -t”) – nach ein paar Sekunden jedoch plötzlich nicht mehr. Ein Vergleich der Routing Table des Einwahl-PCs (“route print”) sofort nach der Einwahl und später nach dem Auftreten des Problems zeigt, dass die Einwahl-Routen in das lokale Netzwerk plötzlich verschwinden, wodurch natürlich nicht mehr auf die internen Resourcen zugegriffen werden kann… Umfangreiche Fehlersuche zeigte auf, dass das beschriebene Problem nur in Kombination aus bestimmten Faktoren auftritt. Reproduzierbar war das Problem insbesondere, wenn auf dem betroffenen Client-PC:
Der Workaround, der das Problem bei dem betreffenden Kunden zunächst umschifft hat (ohne dabei jedoch das eigentliche Problem zu beheben) basiert darauf, unter Systemsteuerung > Netzwerkverbindungen in dem virtuellen Netzwerkadapter, der von dem MUVPN-IPSec-Client (NCP) erzeugt wird, auf dem Tab “Authentication” das Häkchen entfernen bei Enable IEEE 802.1X Authentication:
Das o.g. Häkchen scheint auch bei virtuellen Adaptern automatisch aktiviert zu sein (wie dem IPSec MUVPN-Client und dem WatchGuard SSLVPN-Client), wenn der darunter liegende physikalische Netzwerk-Adapter diese Funktion unterstützt. Nachdem die VPN-Software die Verbindung hergestellt hat, greift offenbar die 802.1X Authentication ein und unterbricht für kurze Zeit die Netzwerkverbindung. Anschließend kommt offenbar zwar die Netzwerkverbindung zurück, aber die Routen sind aus der Routingtabelle verschwunden…
