Tag Archives: MUVPN

Policy Based Routing

2 Comments

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interface auszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende HTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.

RSA SecurID Appliance verweigert User Authentication wegen falscher Systemzeit

Comment

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”…

Begrenzter Zeichensatz bei Active Directory Authentication

Comment

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!

XTM: Mobile User verlieren Routing in das lokale Netzwerk

1 Comment

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:

  • Windows XP läuft als Betriebssystem
  • eine Broadcom-Netzwerkkarte eingebaut ist, die IEEE 802.1X Authentication unterstützt (oder ein anderer Hersteller)
  • eventuell begünstigt auch das Vorhandensein des “Novell-Client” auf dem gleichen PC das Problem.

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…

Vodafone und WatchGuard MUVPN IPSec Client

1 Comment

Die Vodafone-Software, die den UMTS-Verbindungsaufbau steuert, enthält in einigen Versionen einen Fehler. Wenn bei bestehender UMTS-Verbindung der WatchGuard MUVPN IPSec-Client gestartet wird, wird die UMTS-Verbindung getrennt! Erklärung: im Hintergrund wird eine “Zero-Click-Connect” Verbindung, welche augenscheinlich deaktiviert ist, dennoch ausgeführt. Diese wechselt die Verbindung und es kommt zu dem Abbruch. Die fehlerhaften Versionen der Vodafone-Software versuchen, die Verbindung über den Tunnel aufzubauen, was eben ja nicht möglich ist. Die aktuelle Version 9.49 der Vodafone-Software enthält diesen Fehler nicht mehr.

LDAP Authentication für IPSec Mobile User VPN

Comment

In einem Migrationsprojekt von WatchGuard Fireware 10.x nach Fireware XTM 11 fand ich neulich bestätigt, dass bei Fireware XTM 11 das Coding geändert wurde, mit dem die Firebox eine LDAP Authentication (hier: Novell e-Directory) durchführt. Problem war, dass externe Client-PCs mit installiertem IPSec-Client (NCP) nach der Umstellung auf Fireware XTM v11.2.3 zwar die VPN-Einwahl vornehmen konnten, anschließend aber kein Traffic durch den Tunnel geflossen ist. Im Traffic Monitor war der Traffic als Unhandled External Packet zu sehen – allerdings mit korrekt angezeigtem User (z.B. testaccount@LDAP). Insofern war klar: die Firebox hat aufgrund der Rückmeldung vom LDAP erkannt, dass Benutzername und Kennwort korrekt waren. Sie konnte an dieser Stelle ebenfalls die Gruppenzugehörigkeit erkennen und hat aus dem korrekten IP-Adresspool eine Einwahl-IP vergeben. Soweit so gut.

Trotzdem hat irgendetwas verhindert, dass die FIREWALLREGEL, die zu der entsprechenden Mobile User VPN Gruppe gehört, ausgeführt wird – also wurde die Gruppenzugehörigkeit für den Firewall-Part nicht korrekt hinterlegt. Bei der Ursachenforschung wurden mehrere Besonderheiten des Kunden-LDAP beleuchtet, z.B. verwendet der Kunde Leerzeichen im Benutzernamen. Im Endeffekt konnte das Problem jedoch darauf eingekreist werden, dass der LDAP Gruppenname, der eben auch als Name für die MUVPN Gruppe auf der WatchGuard Firebox verwendet wird, aus einer Kombination aus Groß- und Kleinbuchstaben bestand! Wurde also der Gruppenname im LDAP so geändert, dass er entweder NUR aus Großbuchstaben oder NUR aus Kleinbuchstaben bestand und die MUVPN Gruppe gelöscht und mit der neuen Syntax neu erzeugt wurde, FUNKTIONIERTE sowohl VPN-Einwahl als auch Traffic korrekt.
Da der Kunde mit 70 Standorten jedoch international aufgestellt ist und die LDAP Gruppennamen auch noch für andere Softwareprodukte in der bisherigen Schreibweise benötigt wurden, musste das Problem anderweitig umgangen werden. Es zeigte sich, dass die allerneueste Version des NCP-Clients, den WatchGuard als Version 11.2.3 im Software Download Portal bereit stellt, mit der Mischung aus Groß- und Kleinbuchstaben im LDAP Gruppennamen korrekt umgehen kann. Es wurde also entschieden, diesen Anlass zu nutzen und alle mobilen Clients auf den neuesten IPSec-Client upzudaten.

Achtung bei Migration auf Fireware XTM: Routing Table – Abarbeitung ändert sich

1 Comment

Momentan habe ich wenig Zeit für meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) – und erleiden bisweilen Schiffbruch. In den allermeisten Fällen lassen sich die Probleme darauf zurückführen, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.

Generell gilt bei XTM: VPN hat Vorrang!

Welche Probleme können daraus entstehen und welche Lösungsansätze gibt es:

  • 1. Mobile User VPN. Während noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool für die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grundsätzlich ein Problem und führt zu gravierendem Fehlverhalten.

    Verwenden Sie grundsätzlich für die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich persönlich verwende gerne für PPTP den Bereich 172.31.254.1 bis 50, für IPSec 172.31.255.1 bis x (je nach Lizenz) und für SSL-VPN 172.31.253.0/24. Diese Bereiche werden in aller Regel noch nicht für andere Zwecke verwendet – und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.

  • 2. Network > Routes. Das Problem hier lässt sich anhand von folgendem Support Fall verdeutlichen: als eth1 (=Trusted) war bei einem Kunden definiert: 192.168.0.1/30, d.h. außer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Domänencontroller des Unternehmens befinden, über die u.a. auch die Einwahl der mobilen User gegenüber Active Directory authentifiziert wurde (Eintrag unter Setup > Authentication > Authentication Servers > Active Directory). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Außenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0/24 bedient hat. Während unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verhält sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus – sondern packt ihn in den Tunnel in die Außenstelle x ein, wo er im Nirwana landet… Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des/zum Standleitungs-Router so abändern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird…

  • 3. Problematik: vermaschte IP-Netze. Unter einem “vermaschten IP-Netz” verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP/IP-Basis miteinander kommunizieren können, wobei das Routing jedoch nicht direkt von Außenstelle zu Außenstelle geführt wird, sondern über einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Außenstelle z.B. ein IP-Netz à la 10.0.23.0/24 verwendet haben – und einen BOVPN-Tunnel zu 10.0.0.0/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat – und auch tatsächlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Außenstellen eingepackt hat. Damit ließen sich auch schon in der Vergangenheit zentralisierte VoIP-Lösungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Außenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine Lösung gemeinsam zu erarbeiten.

  • 4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte/Überschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und überschaubar über die Runden gehen.

SSL-VPN bei Multi-WAN auf einer X Edge

1 Comment

Bei Vorhandensein der Edge Pro (Standard bei X55e, Nachrüst-Option bei X10e und X20e) können beide WAN-Anschlüsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL für Multi-WAN oder einmal DSL und einmal UMTS als Fallback).

Obwohl die GUI auch andere Einstellungen zulässt, terminieren VPN-Verbindungen immer auf WAN1, solange WAN1 aktiv ist. Insofern handelt es sich bezüglich VPN bei WAN2 um ein reines Failover-Interface. Hat man die Konstellation, dass z.B. zunächst auf WAN1 ein normaler ADSL-Anschluss liegt (z.B. T-DSL 6000 mit 512 kBit Upload) – und nach einiger Zeit kommt ein SDSL-Anschluss hinzu (2 Mbit symmetrisch), der gerade wegen des höheren Upload für VPN-Verbindungen genutzt werden soll – sollte man die External Interface neu zuordnen, so dass der SDSL auf WAN1 und der ADSL auf WAN2 zu liegen kommt.

Im Falle von Mobile User SSL-VPN kann man eine Primary IP und eine Secondary IP angeben. Hierbei sollte Primary immer die WAN1-IP sein (bzw. der DYNDNS-Hostname) und Secondary immer die WAN2-IP. Der Client ist zwar in der Lage, die Secondary IP zu connecten und bekommt von dort auch die VPN-Konfig zugewiesen, die eigentliche VPN-Verbindung wird dann aber zu der Primary IP (sprich WAN1) aufgebaut, solange dieses Interface aktiv ist. Sind die IPs vertauscht oder wird z.B. nur die WAN2-IP in die Konfiguration eingetragen, kommt keine Verbindung zustande. Der Client zeigt im Log die Fehlermeldung “Connection refused (WSAECONNREFUSED)” und steht im Logon-Fenster in einer Endlosschleife “Paused, waiting 5 seconds”.

Support kennt hierzu auch ähnliche Berichte aus der Praxis:
BUG30110: Cannot construct SSL VPN and MOVPN on WAN2 while WAN1 is up und BUG23704: Cannot construct a tunnel on WAN2 while WAN1 is up. Diese wurden aber abgeschlossen mit dem Hinweis, dass dieses Verhalten “normal” und “by design” ist.

Jetzt 25 MUVPN-Lizenzen bei der X550e dabei

Comment

Bislang kam die Firebox X550e immer mit fünf (5) MUVPN-Lizenzen (IPSec Mobile User VPN-Client – derzeit wird der NCP-Client mit ausgeliefert!). Neuerdings beinhaltet der Feature Key jedoch 25 MUVPN-Lizenzen. Sie können kostenfrei die zusätzlichen Lizenzen nachrüsten, wenn Sie sich mit Ihren Zugangsdaten an der WatchGuard Website anmelden und für Ihre X550e einen neuen Feature Key herunterladen und anschließend über den WSM > Policy Manager mit Setup > Feature Keys… auf Ihre X550e hochladen.