Tag Archives: SSL VPN

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.

Neues Produkt: WatchGuard SSL 100

Comment

In Kürze wird eine neue SSL-VPN Appliance lieferbar sein: die WatchGuard SSL 100. Das Produkt basiert auf der Technologie der bekannten SSL 500 und SSL 1000, ist für den Betrieb von maximal 100 parallelen SSL-VPN Sessions ausgelegt und kommt standardmäßig mit einer Lizenz für 25 concurrent sessions. Diese Zahl kann schrittweise auf bis zu 100 erhöht werden. Preise sind leider noch nicht bekannt, werden aber sicher mit der nächsten Preisliste Anfang Juni kommuniziert. Das Produkt und die Optionen sind ab sofort bestellbar.

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.

Version 10.2.8 im Download-Bereich

2 Comments

Folgende Änderungen im Installationsverhalten ist mir aufgefallen: Beim Aufruf des Installers fireware10_2_8.exe kommt nicht mehr die verwirrende Meldung “Do you want to completely remove the selected application and all of its features?”, sondern zu der schon existierenden Version 10.2.x wird zusätzlich die Fireware 10.2.8 installiert. Zur Vermeidung von Fehlern empfehle ich nun, als ersten Schritt über Systemsteuerung > Software die bisherige Version Fireware 10.2.x zu deinstallieren – und anschließend den Installer fireware10_2_8.exe aufzurufen.

Weiterhin stehen im Download-Bereich neue Versionen für den IPSec Mobile User VPN-Client, den SSL-VPN-Client sowie für den Single Sign On (SSO) Client und Agent (Gateway).

WSM und Fireware 10.2.7 verfügbar

1 Comment

Die neuen Versionen WSM, Fireware und SSL-VPN-Client 10.2.7 stehen im Software Download Bereich der WatchGuard Website bereit. In den Release Notes sind als “Resolved Issues” die folgenden Bugs aufgeführt. Mit den meisten hatte ich auch schon persönlich Bekanntschaft geschlossen. Ich werde die neue Version in ein paar Minuten installieren und dann Anfang nächster Woche über meine Erfahrungen berichten.

  • This release resolves a kernel crash associated with branch office VPN and Mobile VPN with IPSec traffic through the Firebox X Core or Peak e-Series. [29491]

  • The Firebox no longer stops passing traffic when you save a configuration. [27821]

  • Policy Manager no longer prevents the entry of host ranges for 1-to-1 NAT on the BOVPN tunnel route settings page. [30010]

  • The Server Load Balancing feature in Fireware now correctly detects that a server is not responding and stops sending traffic to that server. [27276]

  • You can now apply QoS and a schedule when you create a VPN firewall policy template for managed BOVPN tunnels. [10270]

  • You should no longer see the error message “HTTP response code: 500 for URL https://x.x.x.x:4117/cmm/cmd” when you try to connect to WSM. [29336]

  • If there is an active Mobile VPN with PPTP tunnel connected to the Firebox during a configuration save, Firebox System Manager no longer shows the HA peer status as “in-transition.” [27557]

  • WSM and Firebox System Manager connections no longer fail after a configuration save to two Fireboxes configured in an HA configuration. [31990]

  • The Windows SSL VPN client no longer fails to install on Windows XP with a Runtime Error message. [31932]

  • The Windows SSL VPN client now operates correctly after a computer returns from sleep mode. [31523]

Sichere Fernwartung einer X Edge

Comment

Um eine entfernt stehende Firebox X Edge auch per HTTPS direkt über das Internet administrieren zu können, füge ich normalerweise bei Firewall > Incoming eine Custom Packet Filter Policy hinzu, die eingehenden HTTPS-Verkehr direkt auf das Webinterface der Firebox leitet (Static NAT). Damit nicht jeder beliebige Rechner aus dem Internet bis zur Anmeldeseite gelangt, lasse ich jedoch nur die bekannten festen IP-Adressen z.B. des Hauptstandorts des Kunden (und unsere eigenen) zu:

Hat die X Edge eine feste externe IP-Adresse, erfolgt der Zugriff über https://EXTERNE-IP. Bei einer dynamischen externen IP-Adresse nehme ich mir einen kostenfreien DYNDNS-Hostname zu Hilfe, der bei Network > Dynamic DNS eingetragen wird:

Befindet sich die X Edge in einer (VPN-)Außenstelle unseres Unternehmens, sorgt diese Einrichtung natürlich auch dafür, dass wir die X Edge über das Internet erreichen können, auch wenn der reguläre VPN-Tunnel dorthin gerade einmal nicht zur Verfügung steht 🙂 Wenn ich parallel dazu auch die SSL-VPN-Möglichkeit der X Edge nutzen möchte, um dort mobile User zu terminieren, lege ich den Port für Remote-HTTPS meist von 443 zum Beispiel auf 444 um: Administration > System Security:

Neue Software-Versionen 10.2.6

Comment

Mit heutigem Datum (12.12.2008) wurden die Software-Versionen WatchGuard System Manager (WSM), Fireware und Edge 10.2.6 im Download-Bereich der WatchGuard-Website bereit gestellt. Dort steht auch eine neue Version 10.2.6 des WatchGuard SSL VPN Client bereit. Nach der Installation von 10.2.6 in unserem Produktiv-System waren keine negativen Auswirkungen erkennbar. Alle vorkonfigurierten BOVPN-Tunnel kamen erfolgreich wieder hoch, auch die Mobile User VPN Einwahl verlief erfolgreich…