Category Archives: Technischer Blog

Lock / Unlock bei SMTP E-Mails

Comment

Der SMTP-proxy verfügt im Bereich Attachments sowohl bei Content Types als auch bei Filenames über die Optionen Allow, Lock, AV Scan, Strip, Drop undBlock im Pull-Down-Menü Actions to take. Wurde zur Steuerung von unerwünschten E-Mail-Anhängen vom Default Strip (Herausschneiden und Löschen) abgewichen und die Option Lock gewählt, werden Dateianhänge, auf die ausgewählten Kriterien passen, von der WatchGuard Firewall “ge-locked”.

Im Detail passiert folgendes: die Datei wird binärtechnisch leicht verändert, es werden ein paar Byte vor und hinter die Datei gehängt. Außerdem wird der Dateiname um die Endung .clk ergänzt (cloaked). Die Datei hängt aber nach wie vor an der eigentlichen E-Mail dran und erreicht auch das Postfach des Empfängers. Versucht nun der Empfänger, die Datei mit Doppelklick zu öffnen, schlägt dies fehl. Dies ist auch so beabsichtigt! An die E-Mail wird eine zusätzliche Textdatei angehängt, die die bei Deny Message definierte Fehlermeldung beinhaltet. Der Standardtext lautet: “The WatchGuard Firebox that protects your network has detected a message that may not be safe. […] Your network administrator can unlock this attachment.”Außerdem finden sich nähere Angaben über die Datei und den Grund.

Die Option Lock gibt es schon seit über zehn Jahren bei WatchGuard-Produkten. Die theoretische Denke dahinter ist auch genau so alt: der Empfänger speichere die ge-lockte Datei z.B. auf ein transportables Speichermedium (Diskette, USB-Stick) und gehe damit zu seinem Systemadministrator. Dieser starte in einer MSDOS-Eingabeaufforderung auf einem – separat vom lokalen Netzwerk stehenden und mit einer aktuellen lokalen Antivirus-Software ausgestatteten – PC das kleine Hilsprogrammunlock.exe, das sich im Verzeichnis C:\Programme\WatchGuard\wsm10.2\binbefindet und entpackt dadurch die .clk-Datei in den Urzustand, woraufhin sie mit der Antivirus-Software untersucht und bei Unbedenklichkeit an den eigentlichen Empfänger ausgehändigt werden kann. Abwandlungen in der einen oder anderen Form gestattet… 🙂

Auch das Gateway Antivirus-Subsystem kann die Option Lock nutzen, entweder wenn bereits tatsächlich ein Virus in der Datei gefunden wurde – oder wenn ein Scan Error aufgetreten ist, also die AV Engine die Datei nicht scannen konnte. Das ist übrigens auch dann der Fall, wenn die Datei verschlüsselt ist – und sei es nur eine ZIP-Datei, die mit einem Kennwort versehen wurde. Klar – eine verschlüsselte Datei kann erst dann auf Viren gescannt werden, wenn sie korrekt entschlüsselt wurde. In einem solchen Fall kann man natürlich der lokalen Antivirus-Software auf dem PC des Empfängers vertrauen und anstelle von Lock die Option Allow wählen – oder man nutzt die Option Lock und überläßt zumindest das Entpacken dem Administrator…

Wie Auto Negotiation auf HA Port abschalten?

Comment

In einem Hochverfügbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang “klassisch” per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL/Glasfasern verbundene Serverräume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuführung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische “Static IP” Konfiguration.

Für alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT über Switche, sondern DIREKT miteinander verbunden – mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und häufig zufällige Failovers ausgelöst wurden.

Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert für den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch “Auto-Sensing” eingestellt – auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde…

Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei für das entsprechende Interface der Wert für < auto-sensing > von 1 auf 0 geändert und die gewünschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschließend auch noch für diezweite Firebox manuell in deren Konfigurationsdatei geändert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.

Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell “nicht supported” und erfolgen auf “eigene Gefahr”.

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services(WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.

Command Line Interface (CLI) auf Port 4118 tcp

Comment

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung imKommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört.

Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).

Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen.

cli

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unterhttp://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

1 Comment

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird - also Firewall-Regeln verwendet werden, dieauf User-Basis greifen und nicht auf Maschinen-Basis - kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. 

Der beste Ansatz, dieses Verhalten zu umgehen, ist der Einsatz eines offiziellen Webserver SSL-Zertifikats, das aber kostenpflichtig ist und im Regelfall pro Jahr ebenfalls kostenpflichtig erneuert werden muss.

Alternativ dazu kann bei Vorhandensein einer (Windows) Active Directory Umgebung dort auch eine eigene (Windows-)Zertifizierungsstelle aufgesetzt und darüber ein eigenes Webserver-Zertifikat generiert werden. Computer, die Mitglied der Domäne sind, lernen dieses Zertifikat dann automatisch.

Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:

Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:

WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über "Import Certificate / CRL" auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: "Error: Error occurred while performing 'import certificate': certificate add error msg="Failed to import a certificate!! 6_982: certificate validation fail" add certificate". Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier:http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option"IPSec, Web Server, Other". Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate... > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglichGroß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Trade-Up / Migration auf neue WatchGuard Hardware

Comment

Viele Kunden steigen derzeit von einer WatchGuard X Core e-series X550e, X750e, X1250e auf ein entsprechendes Nachfolge-Modell XTM 505, XTM 510, XTM 520 und XTM 530 um (respektive von X Peak e-series auf XTM8). Fast immer taucht die Frage auf, ob die bestehende Konfiguration des “alten” Geräts auf das “neue” Gerät übertragen werden kann. Ja, sie kann. Es gilt aber ein paar kleine Hürden zu überwinden.

Zunächst muss natürlich die neue Box über die WatchGuard Website registriert und der neue Feature Key (Lizenzdatei) heruntergeladen werden. Auf dem Konfigurations-PC/Notebook haben Sie den aktuellen WSM 11.4.2 und die entsprechende Fireware XTM 11.4.2 für Ihre Geräte-Familie installiert, und auch das Adobe Flash Plugin für Ihren Browser ist vorhanden. Überhttps://10.0.1.1:8080 melden Sie sich mit dem User “admin” und dem Factory Default Kennwort “readwrite” an. Sie klicken den Setup Wizard mit den Default-Werten durch, importieren dabei auch den Feature Key und vergeben am Schluss Ihre eigenen Firewall-Kennwörter. Nach der erneuten Anmeldung mit Ihrem eigenen “admin”-Kennwort installieren Sie über System > Upgrade OS die neueste Fireware XTM 11.4.2 auf der Box, die daraufhin einmal durchbooten wird. Auf Ihrem Konfigurations-PC/Notebook starten Sie dann den WSM 11.4.2 und machen ein “Connect to Device” zu Ihrer neuen XTM-Box. Anschließend öffnen Sie den Policy Manager, der Ihnen die praktisch “leere” XML-Konfigurationsdatei der neuen XTM-Box anzeigt.

So weit, so gut. Erst jetzt wird es interessant:

Im Policy Manager laden Sie über File > Open > Configuration File die letzte XML-Konfigurationsdatei Ihrer “alten” WatchGuard. Auf die Frage “Do you want to save this new configuration to a file?” antworten Sie mit NEIN.

Sie sehen daraufhin die Konfigurationsdatei Ihrer “alten” WatchGuard. Falls Sie bisher eine X750e/X1250e im Einsatz hatten, bei der das Interface ganz rechts außen (eth7) im Einsatz war, sollten Sie sich die Network > ConfigurationEinstellungen für dieses Interface auf Papier notieren und prüfen, ob das Interface irgendwo namentlich in Firewall-Regel(n) auftaucht und auch diese entsprechend dokumentieren! Über Setup > System > Model wählen Sie Ihr neues Hardware-Modell aus. Es folgt eine Warnmeldung, die auf die veränderte Anzahl der Ethernet-Schnittstellen hinweist (eine XTM5 hat jetzt 7 Interfaces, eine alte X550e hatte 4, eine X750e/X1250e 8 Interfaces). Anschließend müssen Sie noch bei Setup > Feature Keys den Feature Key der alten Box removen und den Feature Key der neuen Box importieren. Beachten Sie bitte, dass im Policy Manager ganz unten rechts noch der Hinweis steht, dass es sich um eine Konfigurationsdatei des Typs “Fireware XTM v11.0-v11.3.x” handelt:

Auch bis hierhin alles planmäßig.

Anschließend starten Sie ein “Save to Firebox”. Die eventuelle Warnmeldung “The specified IP address does not match any of the interfaces specified in this config file. Are you sure you want to save to this Firebox?” (…ist klar, weil Ihre alte Konfigurationsdatei höchstwahrscheinlich eben nicht die 10.0.1.1 für eth1 enthält…) bestätigen Sie mit JA.

und erhalten dann eine zweite Warnmeldung: “The configuration file must be upgraded before it can be saved to the v11.4.2 device. Would you like to upgrade the configuration now?”. Auch die bestätigen Sie mit JA.

Anschließend folgt überraschend: “Error communicating with Firebox [IP]. INTERNAL_ERROR: The configuration is invalid, missing application action object”, die Sie nur mit OK bestätigen können.

=> Brechen Sie den Vorgang dann mit CANCEL ab und schließen Sie den Policy Manager.

Öffnen Sie den Policy Manager erneut, und öffnen Sie über File > Open > Configuration File die NEUESTE Version der Konfigurationsdatei, die im Zuge des vorigen “Save to Firebox” gespeichert wurde (ist nur wenige Minuten alt…). Bestätigen/ignorieren Sie die weiter oben bereits beschriebenen Warnmeldungen und starten Sie dann erneut den Vorgang “Save to Firebox”. Beachten Sie in diesem Zusammenhang, dass nun im Policy Manager ganz unten rechts für die Konfigurationsdatei der Typ “Fireware XTM v11.4.2” angezeigt wird:

=> Jetzt – beim zweiten Mal – sollte das Hochladen der Konfigurationsdatei funktionieren:


Danach sollten Sie die neue Box dann auch über die “alten” TCP/IP-Einstellungen auf den entsprechenden Interfaces ansprechen können! [Hinweis: die Firewall-Kennwörter sind nicht Bestandteil der Konfigurationsdatei, sondern hardwarespezifisch! D.h. die neue Firebox hat nicht automatisch die Kennwörter der alten Firebox, sondern die, die Sie ihr über den Setup Wizard verpasst haben!]

Multi-WAN und Policy Based Routing

Comment

Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, können bis zu vier Interfaces als External Interface konfiguriert werden. Hier können jeweils unterschiedliche Internet-Anschlüsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen überlastet ist, weil “zu viel” HTTP/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig Bandbreite für VPN-Anbindungen, E-Mail und andere unternehmenskritische Anwendungen übrig bleibt…
Statt einfach die Bandbreite der Standleitung für teuer Geld beim Provider hochsetzen zu lassen, kann auch darüber nachgedacht werden, einen – deutlich billigeren – ADSL, VDSL oder Kabel-TV-Anschluss als zweiten Internet-Anschluss an die gleiche WatchGuard anzubinden und über das Firewall-Regelwerk festzulegen, dass der typische HTTP und HTTPS Traffic über eben diese billigere DSL-Leitung geführt wird (Policy Based Routing, PBR). Damit wird die (teure) Standleitung von eben diesem TrafficENTLASTET.

Die unternehmenskritischen Services können so evtl. auch auf längere Sicht auf dem bisherigen Stand zu deutlich geringeren laufenden Kosten versorgt werden.

Wenn nun mindestens ein zweites Interface der WatchGuard als “External” konfiguriert wird, sind zusätzliche Einstellungen erforderlich, ohne die das gewünschte Verhalten eventuell nicht zum Tragen kommt! Insbesondere muss im Policy Manager unter Network > Configuration die Registerkarte Multi-WAN beachtet werden, die bei Verwendung nur eines einzelnen externen Interfaces “ausgegraut” war.
Hier wähle ich in der Regel als Default-Verhalten im Multi-WAN-Betrieb anstelle des voreingestellten Verfahrens “Routing Table” das Verfahren “Failover” aus und aktiviere hinter dem Button “Configure” die am typischen Multi-WAN-Betrieb beteiligten externen Interfaces (die Zahlen in Klammern entsprechen der Interface-Nummer auf der WatchGuard: z.B. 0=eth0, 6=eth6):

Die angezeigte Reihenfolge der Interfaces entspricht auch dem tatsächlichen Verhalten der WatchGuard Firebox für ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gemäß dieser Liste von oben nach unten bedient. Will heißen: Wenn das ganz oben aufgeführte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das nächste Interface in der Liste verwendet…

Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird über die Registerkarte Multi-WAN gesteuert:

Für jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verfügbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgeführten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardmäßig das Default Gateway des jeweiligen Interfaces). Wenn die angepingte IP-Adresse (3+1) = 4 x 15 => 60 Sekunden) nicht antwortet, wird das Interface auf “INACTIVE” gesetzt. Kommen wieder drei aufeinanderfolgende Antworten im Abstand von 15 Sekunden, wird das Interface wieder auf “ACTIVE” gesetzt und nimmt am Multi-WAN-Verfahren teil.

Daraus ergeben sich zwei Problematiken:

    • Problem 1 (Szenario Standleitung) => “Wo befindet sich das Default Gateway einer Standleitung?” Antwort: “Das ist der Übergaberouter des ISP, der sich in der Regel beim Kunden vor Ort befindet und per Kabel direkt an der WatchGuard angeschlossen ist”. Wenn nun eben dieser Router auf “ping” antwortet: Ist das eine zuverlässige Aussage darüber, ob nun die eigentliche Internet-Anbindung durch diesen Router hindurch funktioniert? Antwort: “Nein”. Typischerweise sollte also hier eine EXPLIZITE IP-ADRESSEkonfiguriert werden, die irgendwo tatsächlich im Internet liegt.

 

  • Problem 2 (Szenario PPPoE oder DHCP-Einwahl) => Das Default Gateway des Interfaces wird dem Interface vom Provider erst bei der Einwahl zugewiesen. In vielen Fällen (providerabhängig!)antwortet aber genau diese als Default Gateway zugewiesene IP-Adresse nicht auf ping. Was ist also das Resultat im Default-Zustand? Das Interface arbeitet zunächst (3+1) x 15 => 60 Sekunden ordnungsgemäß, wird dann jedoch von der WatchGuard als “INACTIVE” eingestuft und aus dem Multi-WAN-Verfahren herausgenommen… Insbesondere in diesem Fall sollte also UNBEDINGT eine tatsächliche IP-Adresse im Internet als ping-Ziel definiert werden…

Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verfügbarkeit von externen Systemen abhängig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverfügbar ausgelegt sind: 8.8.8.8, 4.2.2.3, 141.1.1.1 oder die typischen DNS-Server der Telekom 194.25.0.60, 194.25.0.68, 194.25.0.52, 194.25.2.129 etc. Providerunabhängig lautet meine Empfehlung generell:Verwenden Sie hier nach Rücksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverfügbar ausgelegt ist – und die sich nicht in absehbarer Zeit ändern wird!

(Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgeführt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gemäß o.g. ausmalen kann… War zum Glück an einem Wochenende…)

Nachdem nun die Voraussetzungen für das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tatsächlichen PBR (Policy Based Routing) Firewall-Regeln herangehen.

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 Interfaceauszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehendeHTTP/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.

Diagnostic Tasks / Extended Ping / TCP Dump

Comment

Eine relativ unbekannte Funktion des Firebox System Managers sind dieDiagnostic Tasks, die im Traffic Monitor per Rechtsklick mit der Maus erreicht werden können:

Eine Funktion ist Extended Ping, mit dem z.B. pings von der Firewall selbst aus gestartet werden können – und zwar auch unter Angabe des tatsächlich zu verwendenden Interfaces! Das kann gerade im Multi-WAN Umfeld interessant sein, wenn geprüft werden muss, ob ein bestimmter Ziel-Host auch genau über das angegebene Interface erreichbar ist (Problematik vgl.http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html). Ein weiterer Anwendungsfall kommt aus dem Umfeld Dynamic Routing, wenn geprüft werden muss, ob das Routing eben auch auf den alternativen Wegen/Interfaces möglich ist. Die Advanced Options werden erst angezeigt, wenn das entsprechende Häkchen gesetzt ist. Im u.g. Screenshot wird die Ziel-IP 10.10.10.200 direkt von der Quell-IP 192.168.1.1 (Firebox Interface) angepingt:

Mittels TCP Dump lässt sich z.B. rudimentär mit verfolgen, welche Datenpakete auf welchem Interface transportiert werden – auch ohne dass sie zwingend im Traffic Monitor angezeigt werden:

Multi-WAN Konflikt mit zwei redundanten Cisco HSRP Router-Paaren

Comment

Das Debugging einer problembehafteten HA Umgebung aus zwei X750e mit Fireware XTM 11.3.2 (ich betrachte diese Version derzeit für Cluster aus X Core / Peak e-series am stabilsten) hat heute einen netten Sonderfall aufgezeigt, der für die Störungen sicher mitverantwortlich war:
Der Kunde betreibt schon seit vielen Jahren ein WatchGuard VPN mit ca. 40 Außenstellen. Wie so oft hat in der Vergangenheit dafür eine einzelneCompany Connect Anbindung der Telekom mit 2 Mbit/s gereicht. Diese Leitung war mit redundanten Cisco-Routern und zudem einerZweiwegeführung ausgestattet. Der Kunde hatte nun bei der Telekom eine weitere Company Connect Anbindung beauftragt, mit 34 Mbit/s und ebenfalls redundanten Cisco-Routern und Zweiwegeführung. Auf der WatchGuard waren diese beiden Anbindungen als Multi-WAN konfiguriert – im Failover-Modus.
Bei einem Routine-Check des “Status Report” im Firebox System Manager ist mir in der ARP Table der WatchGuard aufgefallen, dass dort beide vorgelagerten Router-Paare (2 Mbit an eth0 und 34 Mbit an eth1) mit der gleichen Hardware MAC Adresse 00:00:0C:07:AC:01 aufgeführt waren.

Recherche hat ergeben, dass dies eine virtuelle MAC-Adresse ist, die vonredundanten Cisco-Routern im HSRP Modus verwendet wird – und zwar dann, wenn auf den Routern die HSRP Group ID = 1 eingestellt ist. Offenbar hat der ISP also beide Router-Paare (da verschiedene Einzelaufträge) per Default mit der gleichen HSRP Group versehen… Das wird auch erst dann zum Problem, wenn beide Leitungen wie im vorliegenden Fall an das gleiche System angeschlossen werden. Die Auswirkungen kann man sich ausmalen.
Ein Support Call bei der Telekom hat dazu geführt, dass ein Router-Paar auf dieHSRP Group ID = 2 eingestellt wurde, wodurch sich die virtuelle MAC-Adresse auf 00:00:0C:07:AC:02 geändert hat und nunmehr aus Sicht der WatchGuard die Interfaces sauber konfiguriert sind: