In diesem Artikel geht es um die Migration eines alten WatchGuard FireClusters auf ein neues WatchGuard FireCluster (bspw. nach einem Trade-Up). Weitere Informationen zu der WatchGuard Trade-Up Promotion mit den je nach Modell empfohlenen Trade-Ups finden Sie unter >> WatchGuard Trade-Up Promotion.
Die Migration einer einzelnen Firebox haben wir in dem Artikel >> HOWTO: WatchGuard Firebox Migration nach Trade-Up beschrieben. Weiterlesen
In diesem Artikel geht es um die Migration einer alten WatchGuard Firebox auf eine neue WatchGuard Firebox (bspw. nach einem Trade-Up).Weitere Informationen zu der WatchGuard Trade-Up Promotion mit den je nach Modell empfohlenen Trade-Ups finden Sie unter >> WatchGuard Trade-Up Promotion.
Die Migration eines alten FireClusters auf ein neues FireCluster haben wir in dem Artikel >> HOWTO: WatchGuard Firebox Migration bei FireCluster beschrieben.
Weiterlesen
Die Segmentierung von Netzwerken ist ein wichtiger Bestandteil um sowohl die Stabilität als auch die Performance für Clients, Server, etc. auf einem stetig gutem Niveau zu halten. Wer den Datenverkehr zwischen diesen Netzwerken mit Sicherheitsmechanismen überwachen möchte, ist dazu angehalten die Rolle des Gateways vom Switch zur Firewall zu migrieren.
In diesem Webinar stellen Ihnen WatchGuard-Experten vor, wie Sie mit den aktuellsten Sicherheitsmechanismen Ihre Netzwerke in Form von Konfiguration und Verwaltung untereinander schützen können.
WatchGuard bietet ein neues Feature: Firebox Configuration and Management in WatchGuard Cloud. Das Feature ist seit Freitag in der Open Beta.
Anmeldemöglichkeit hier: https://watchguard.centercode.com/key/FireboxManagementWGCloud
Die Idee dabei ist, ein vereinfachtes Management über eine sehr übersichtliche Web-UI in der Cloud, inklusive Templates, alternativ/zusätzlich zum bisherigen Management über Web-UI bzw. WSM.
Diese Artikel-Serie beschreibt die neue Management-Oberfläche.
Mit der Firebox T20, T40 und T80 ist kürzlich eine neue Generation der leistungsfähigen Tabletop Appliances erschienen. Gerade wenn “alte” Systeme ausgetauscht werden stellt sich oft die Frage wie z.B. das bestehende Regelwerk übernommen werden kann.
Neben der Vorstellung der neuen Appliances ist das Ziel dieses Webinars die Darstellung verschiedener Möglichkeiten zur einfachen Konfiguration und Übernahme von bereits bestehenden Regelwerken. Darüberhinaus wird gezeigt, wie Sie neue Appliances in zentrale Verwaltungsoberflächen integrieren können.
Zur Konfiguration Ihrer WatchGuard Firebox empfehlen wir den Policy Manager.
Voraussetzungen: PC mit installiertem System Manager, abgeschlossener Web Setup Wizard.
Dieser Artikel beschreibt, wie Sie eine Watchguard Firebox mit dem Policy Manager administrieren können.
Im Normalbetrieb kann man ja für jedes Firewall-Interface die Ethernet Geschwindigkeit (10/100/1000 Mbit) und Full Duplex bzw. Half Duplex über Network > Configuration manuell einstellen, wobei aber in der Regel die Einstellung “Auto Negotiate” beibehalten werden sollte, solange keine Ethernet Errors und Collisions offensichtlich sind. Im HA Cluster-Betrieb können die NIC Einstellungen auf dem/den “Cluster-Interface(s)“, mit denen die Boxen direkt miteinander verbunden sind, jedoch NICHT manuell beeinflusst werden! Im Regelfall befinden sich beide Cluster Member direkt beieinander und sind mit einem normalen Patchkabel (1:1 oder Cross-Over) verbunden. In manchen Installationen befinden sich die beiden Cluster-Boxen aber in verschiedenen Räumen/Rechenzentren und sind teilweise mehrere Hundert Meter weit voneinander entfernt. Bei diesen Entfernungen kommen dann Querverbindungen zum Einsatz, die auf LWL/Glasfaser-Technik basieren. Je nachdem wie die Netzwerk-Infrastruktur an beiden Lokationen aussieht und wie viele freie LWL-Fasern zur Verfügung stehen, werden die Interfaces der beiden Fireboxen dann entweder direkt miteinander verbunden (über LWL-Medienkonverter) – oder über VLANs, die auf entsprechenden Switchen an beiden Lokationen konfiguriert sind. In beiden Fällen hatte ich nun in der Praxis bereits Fälle, dass speziell die HA-Verbindung (Cluster Interface) zwischen den beiden Boxen Probleme bereitet hat und Ethernet Errors und Collisions auftraten. Teilweise konnten die beteiligten externen Netzwerk-Komponenten (=Medien-Konverter) nicht auf einen festen Wert eingestellt werden oder es gab nach wie vor Probleme, egal auf welche Werte das Interface auf dem beteiligten VLAN-Switch (z.B. HP) eingestellt war. Hier kann dann nur über die WatchGuard versucht werden, das Problem abzustellen. Aber wie gesagt, für das Cluster Interface lassen sich keine festen Werte über die GUI einstellen. Also muss hier mal wieder ein Texteditor und ein manueller Eingriff in die XML-Konfigurationsdatei ran… 😉
Je nachdem, wie bzw. wie oft das betreffende Interface vorher schon mal konfiguriert war, findet sich in der Konfig-Datei dann folgende Stelle:
[Schnipp] (für die Ansicht hier “<" und ">” durch “{” und “}” ersetzt) {interface}
{name}Optional-5{/name}
{description /}
{property}0{/property}
{if-item-list}
{item}
{item-type}1{/item-type}
{physical-if}
{if-num}6{/if-num}
{enabled}1{/enabled}
{if-property}4{/if-property}
{ip}0.0.0.0{/ip}
{netmask}255.255.255.255{/netmask}
{mtu}1500{/mtu}
{auto-negotiation}1{/auto-negotiation}
{link-speed}100{/link-speed}
{mac-address-enable}0{/mac-address-enable}
{mac-address /}
{full-duplex}1{/full-duplex}
Die fett markierten Stellen sprechen für sich und müssen eben entsprechend händisch angepasst werden, also Auto Negotiation ausschalten (=0) und die entsprechenden Werte für Link Speed und Full Duplex an (=1) bzw. aus (=0) einstellen. Anschließend kann die XML-Datei gespeichert und auf die Firebox hochgeladen werden. Im Policy Manager unter Network > Configuration wird dann auch die Änderung des “NIC Speed” angezeigt (also z.B. 100 Mbit Full Duplex)…
Ein Kunde berichtete über BOVPN Tunnel, die instabil laufen und häufig abbrechen. Hier folgender wichtige Hinweis: Als Gateway-Adresse darf in der BOVPN-Konfiguration nur die Primary IP eines External Interface verwendet werden – auf keinen Fall eine Secondary IP!Dieser Hinweis ist natürlich nur in einer Umgebung relevant, bei der auf dem/den External Interface(s) als Konfigurationsmethode “Static IP” gewählt ist, also die Kombination aus einer vom Internet Service Provider zugewiesenen IP-Adresse, Subnetzmaske und Default Gateway (typischerweise eine “Standleitung” mit vorgelagertem ISP-Router, z.B. Telekom Company Connect). In einem solchen Fall weist der Provider üblicherweise ein 8-er IP-Netz (/29) oder 16-er IP-Netz (/28) zu. Aus einem solchen IP-Subnetz können theoretisch alle verwendbaren IP-Adressen (5 respektive 13) dem Interface der WatchGuard zugewiesen werden. Hiervon ist nur eine unter Network > Configuration > Interfaces direkt eingetragen (das ist die Primary IP!), die anderen werden über die Registerkarte “Secondary” eingetragen. Jedoch darf eben nur genau die “Primary IP” als Gateway-IP in der/den BOVPN-Konfiguration(en) verwendet werden!!
Mit diesem Blog-Beitrag hatte ich bereits auf das Problem eines möglichen Verlusts der Konfiguration beim direkten Umstieg von Fireware v10.x auf Fireware XTM v11.3.3 und v11.3.4 hingewiesen. Der Hinweistext “Note: If you are upgrading from Fireware XTM OS v10.x, you must upgrade to Fireware XTM OS v11.3.2 before you upgrade to v11.3.4” im Software-Portal bestätigt nun also dieses Problem. Wenn Sie also auf einer X Core e-series (X550e, X750e, X1250e) oder einer X Peak e-series (X5500e, X6500e, X8500e, X8500e-F) die Migration von v10 auf v11 vorhaben, sollten Sie tunlichst den Zwischenschritt auf v11.3.2 mit in Ihren Upgrade-Pfad einbauen!
Ich musste aktuell in einem Projekt feststellen, dass Secondary IPs nur auf physikalischen Interfaces konfiguriert werden können, nicht aber auf VLANs. Ich konfiguriere Secondary IPs z.B. sehr gerne auf External Interfaces, um damit mehrere (oder alle) vom Provider zugewiesenen externen IP-Adressen auf einem externem Interface verfügbar zu machen, so dass diese für eingehenden Datenverkehr als Basis für einen SNAT-Eintrag (Statisches NAT oder Server Load Balancing) verwendet werden können.
In dem angesprochenen Projekt musste das neu hinzu kommende externe Interface aber auf einem VLAN-Interface konfiguriert werden. Hier konnte ich die weiteren IPs nur auf dem Weg über 1-to-1-NAT Einträge nachträglich verfügbar machen, was aber natürlich deutlich weniger flexibel ist wie die typischen SNAT-Einträge, die z.B. nur einen bestimmten Port einer IP-Adresse zu einem bestimmten internen Server weiterleiten…
