Tag Archives: Failover

HOWTO: Redundantes AuthPoint Radius (Microsoft Netzwerkrichtlinienserver) Setup mit der WatchGuard Firebox

Problemstellung

Da Microsoft für IKEv2 oder L2TP MS-CHAPv2 voraussetzt, müssen die Radius Anfragen von dem AuthPoint Gateway an einen Microsoft NPS weitergeleitet werden. Leider Kann in AuthPoint kein NPS Failover konfiguriert werden. Für SSLVPN oder IPSEC wird kein NPS benötigt!

Lösungsvorschlag

Die Firebox bietet die Möglichkeit mit einem Loopback Interface und einer SNAT Load Balancing Action, die Radius Anfragen auf mehrere Server zu verteilen.
Um die Erreichbarkeit der Server zu prüfen, sendet die Firebox alle 10 Sekunden ein ICMP Paket an die Server. Wenn einer der Radius Server nicht mehr auf die ICMP Pakete antwortet werden die Anfragen an den verbliebenen Server gesendet, bis der Server wieder auf die ICMP Pakete antwortet.
Dieses Setup bietet leider keine Redundanz, wenn der Radius Dienst nicht mehr ordnungsgemäß funktioniert.

Weiterlesen »

LTE-Failover für jede WatchGuard inkl. Cluster und LTE-Passthrough

Mobilfunk eignet sich spätestens seit LTE nicht nur als „Notlösung“ in schwach ausgebauten Regionen, sondern auch als performanter Failover ohne auf Kabelinfrastruktur angewiesen zu sein (Kupfer/Glas/Koax nutzt häufig die gleiche Gebäudeeinführung und dient daher nur bedingt als Ausfallsicherheit).

LTE bietet zudem die Möglichkeit einen Standort temporär anzubinden, welcher sich noch im Aufbau befindet (Schalttermin des Providers steht aus, Baumaßnahmen notwendig, etc.)

Labor-Umgebung:
WatchGuard T35-W (v12.5.7)
MikroTik LtAP mini (6.47.10)
Telekom SIM-Karte mit Datentarif

Ziel:
Anbindung der WatchGuard an das LTE-Netz und Terminierung der ext. IP direkt auf der WatchGuard.

Konfiguration MikroTik:
Den MikroTik via LAN an ein Notebook anschließen und mittels WinBox die Konfigurationsoberfläche öffnen:

Weiterlesen »

Best Practices – SDWAN mit WatchGuard – Nutzung von WAN-Leitungen für Web-, Cloud- und Standort-Verbindungen

Inhalt:

In vielen Bereichen werden heute aus Redundanz- und Failover-Gründen mehrere WAN Verbindungen eingesetzt. In diesem Webinar wird aufgezeigt, wie man mit SD-WAN von WatchGuard diese WAN Verbindungen verwenden kann, um Failover oder andere Anforderungen umzusetzen. Nicht nur der Zugriff auf Online-Ressourcen, sondern auch die Standortvernetzung kann durch die Nutzung von SD-WAN optimal gestaltet werden.

Jetzt zum Webinar anmelden!

Best Practices – Sicher vernetzt mit SD-WAN

Inhalt:

In vielen Bereichen werden heute aus Redundanz- und Failover-Gründen mehrere WAN Verbindungen eingesetzt. In diesem Webinar wird aufgezeigt, wie man mit SD-WAN von WatchGuard sinnvoll diese WAN Verbindungen verwenden kann, um Failover oder andere Anforderungen umzusetzen. Nicht nur der Zugriff auf Online-Ressourcen, sondern auch die Standortvernetzung kann durch die Nutzung von SD-WAN optimal gestaltet werden.

Jetzt zum Webinar anmelden!

Best Practices – Standortvernetzung mit SD-WAN

Inhalt:

In vielen Bereichen werden heute aus Redundanz und Failover Gründen mehrere WAN Verbindungen eingesetzt. In diesem Webinar wird ihnen aufgezeigt, wie man mit SD-WAN von WatchGuard sinnvoll diese WAN Verbindungen verwenden kann, um Failover oder andere Anforderungen umzusetzen.

Ziel dieser technischen Webinar-Reihe ist es, Ihnen umfassende Hintergrundinformationen zu vermitteln.
Anhand von Konfigurationsbeispielen wird dargestellt, wie Sie die Security Appliances von WatchGuard optimal und noch effektiver einsetzen können.

Jetzt zum Webinar anmelden!

Best Practices – Standortvernetzung mit SD-WAN

Inhalt:

In vielen Bereichen werden heute aus Redundanz- und Failover-Gründen mehrere WAN Verbindungen eingesetzt. In diesem Webinar wird aufgezeigt, wie man mit SD-WAN von WatchGuard sinnvoll diese WAN Verbindungen verwenden kann, um Failover oder andere Anforderungen umzusetzen.

Ziel dieser technischen Webinar-Reihe ist es, Ihnen umfassende Hintergrundinformationen zu vermitteln.
Anhand von Konfigurationsbeispielen wird dargestellt, wie Sie die Security-Lösungen von WatchGuard optimal und effektiv einsetzen können.

 

Webinaraufzeichnung jetzt ansehen!

WatchGuard Cluster in Verbindung mit Dynamic Arp Inspection (DAI)

WatchGuard verwendet im Cluster-Betrieb virtuelle Mac-Adressen. Bei einem Cluster-Failover wird dann ein Gratious Arp Paket gesendet, damit alle beteiligten Switches ihre ARP-Table bzw. ihre Mac-Adress-Port-Table anpassen können. Dies kann bei leistungsfähigen Switches mit aktueller Firmware möglicherweise zu Problemen führen, wenn man die Konfiguration nicht entsprechend anpasst.

Weiterlesen »

Korruptes Zertifikat entfernen

Vor ein paar Tagen hatte ich mit einer X750e (Softwareversion Fireware XTM 11.3.4) zu tun, die im Basic Managed Mode als Außenstelle an einem WatchGuard Management Server lief (Softwareversion WSM 11.5.3). Die BOVPN-Tunnel waren als Managed VPN Tunnels über den Management Server eingerichtet. Die BOVPN-Tunnel kamen nicht mehr hoch und die X750e ließ über WSM / Policy Manager auch keine Änderungen an der Konfiguration zu – auch dann nicht, wenn man mit einem lokalen WSM direkt mit der Box verbunden war. Fehlermeldung beim Schreiben einer Konfiguration: “An error occured while retrieving all certificates from the Firebox [IP]). Unable to send request to module”. Ein Neustart der Box brachte keine Änderung.

Die Fehlersuche zeigte Probleme mit den Zertifikaten auf der X750e. “View… Certificates” aus dem Firebox System Manager konnte die Zertifikate nicht anzeigen (leeres Feld und darüber eine leere Fehlermeldung).

Auch im CLI Modus brachte der Befehl “show certificates” nur eine Fehlermeldung. Der certd daemon lief auch nicht. Ich hatte einen ähnlichen Fall bereits vor ein paar Monaten. Damals waren auch Zertifikate kaputt, die Box ließ sich jedoch noch über WSM / Policy Manager administrieren. Damals konnte ich das Problem durch ein Software-Update auf eine neuere Fireware XTM Version beheben. Vermutlich hätte auch das Aufspielen der gleichen Version geholfen. Da jetzt aber WSM / Policy Manager nicht mehr funktionierten, habe ich dieses Mal über das Web-Interface gearbeitet (System > Upgrade OS) und auf diesem Weg die 11.3.4er sysa-dl Datei erneut hochgeladen. Nach dem Reboot war certd wieder da und die Zertifikate waren wieder sichtbar. Anschließend konnte die Box auch wieder an den zentralen Management Server angebunden werden, jedoch kamen die Managed VPN Tunnel immer noch nicht hoch. Als nächstes habe ich den zentralen WSM / Management Server näher untersucht. Beim Versuch, die Managed VPN Tunnel neu anzulegen, stürzte der WSM jedes Mal mit einer Fehlermeldung der AppMngr.exe ab. Ein Neustart des Dienstes half nicht, auch nicht der Reboot der kompletten Windows Server 2008 Maschine.

Als temporären Workaround wollte ich nun den BOVPN Tunnel zwischen der Außenstelle und dem zentralen System (ein XTM 810 Active/Passive Cluster mit Fireware XTM 11.5.3) manuell anlegen, damit die User zumindest erst einmal wieder arbeiten konnten. In der XML Konfigurationsdatei des zentralen XTM810 Clusters ist mir dann aufgefallen, dass dort noch die DVCP-basierte Gateway- und Tunnel-Definition der alten “Managed VPN” Verbindung angezeigt wurde, obwohl diese eigentlich gar nicht mehr vorhanden sein sollte. Durch ein Cluster Failover verschwanden diese Fragmente dann aus der zentralen Firewall-Konfiguration, woraufhin auch der WSM / Management Server nicht mehr abschmierte und schlussendlich der BOVPN Tunnel doch wieder regulär als “Managed VPN” Tunnel erfolgreich eingerichtet werden konnte…