Category Archives: Technischer Blog

Reboot / Einschaltproblem bei XTM 5

Ein Kunde hat berichtet, dass seine XTM 505 nach einem über den Firebox System Manager ausgelösten Reboot nicht wieder sauber hochgefahren ist. Auch ein Neustart über den Ein-/Aus-Taster am Gerät (wie bei einem PC, den man hart neu starten will: 6 Sekunden gedrückt halten) brachte keinen Erfolg: im LCD-Display waren nur ein paar unleserliche Zeichen zu sehen.
Nachdem jedoch das Stromkabel gezogen und nach ca. 1 Minute wieder eingesteckt wurde, ist die XTM 505 nach dem Einschalten wieder ganz normal hochgefahren – und hatte auch noch die zuletzt aktive Konfiguration!
WatchGuard hat hierzu auch einen offenen BUG. Offenbar zicken die Netzteile, die in einem gewissen Seriennummern-Bereich verbaut worden sind, bisweilen etwas herum… Also: bei seltsamen Verhalten der Hardware einfach mal komplett den Stromstecker ziehen… 😉

Neue XTM 33 wird nicht mehr warm

Neu in der WatchGuard-Preisliste Januar 2012 sind die Modelle XTM 33 und XTM 33-W. Optisch gleichen die Geräte der XTM 2. Im Inneren arbeitet jedoch eine DEUTLICH leistungsfähigere Hardware mit einer schnelleren CPU und doppelt so viel Hauptspeicher (512 MB) wie bei einer XTM 2. Angeboten wird eine normale “wired version” XTM 33 – und eine Wireless Version XTM 33-W mit integriertem WLAN Accesspoint.
Auf der WatchGuard Conference 2012 in Neuss wurde eine XTM 33 für den WLAN-Zugang der Teilnehmer verwendet. Auch bei gleichzeitiger Nutzung durch ca. 30-40 User war kein Leistungseinbruch bei der Performance – und auch keine nennenswerte Erwärmung feststellbar! (Die XTM 2 Modelle werden im laufenden Betrieb teilweise recht warm. WatchGuard begründete dies bislang mit Hardware-Design-Gründen: die Metallunterseite der XTM 2 wird als passiver Kühlkörper mit verwendet).
Auch bei einer XTM 33 ist das XTM Pro Upgrade bereits im Lieferumfang enthalten. Jedoch wird es – anders als bei der XTM 330 – künftig keine Freischaltung der HA (Cluster) Funktionalität für die XTM 33 geben!
Die XTM 33 liegt preislich 10% unter der XTM 330.

XTM 330 soll HA (Cluster) fähig werden

Die Watchguard XTM 330 wird ab Werk bereits mit dem XTM Pro Upgrade und den damit verbundenen Funktionserweiterungen wie Multi-WAN, Policy Based Routing, Dynamic Routing, QoS und der Maximalzahl der vorgesehenen 55 SSLVPN-User ausgeliefert. Bei den größeren Modellen ab XTM 5 aufwärts ist bei XTM Pro auch die Cluster-Fähigkeit (HA) in den Versionen Active/Active und Active/Passive enthalten.
Derzeit wird jedoch bei der XTM 330 kein HA (Cluster) unterstützt!
In einer der künftigen Softwareversionen soll jedoch die Clusterfähigkeit auch für die XTM 330 freigeschaltet werden!

Lauter Lüfter bei XTM 330 soll leiser werden

Das im Dezember 2011 erstmals ausgelieferte neue 19″ 1HE Modell WatchGuard XTM 330 überzeugt durch eine ausgewogene Kombination aus Dual-Core CPU und 1 GB Hauptspeicher.
Damit ist das Gerät künftig sicher die erste Wahl für kleine Unternehmen bis etwa 100 Mitarbeiter, die eine professionelle 19″ Hardware Firewall/VPN Appliance suchen, die auch in der Lage ist, alle verfügbaren WatchGuard Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Service, Reputation Enabled Defense und Application Control) performant abbilden zu können. Preislich liegt die XTM 330 genau 20% unter der XTM 505, wenn man berücksichtigt, dass das XTM Pro Upgrade bei der 330 bereits enthalten ist, aber bei der 505 separat dazu bestellt werden muss.
Während die XTM5 bereits temperaturgesteuerte Lüfter hat, die ein solches Gerät angenehm leise machen, laufen die Lüfter bei der XTM 330 derzeit ständig auf 100% und erzeugen einen hohen Geräuschpegel, der eigentlich nur in einem Serverraum erträglich ist… 🙂
Es soll jedoch demnächst ein Software-Update/Patch geben (BIOS-Update für die XTM 330), so dass auch bei diesem Modell die Temperatursteuerung funktioniert und die XTM 330 im Normalbetrieb deutlich leiser werden soll.

(Wert-)schöpferische Phase beendet…

Das schlechte Gewissen reist ständig mit. Seit Oktober 2011 habe ich jetzt hier auf dem Blog nichts mehr geschrieben. Begründen und entschuldigen kann ich das nur mit dem Hinweis auf die Vielzahl von WatchGuard-Projekten, die wir (BOC Computersysteme GmbH) im 4.Quartal 2011 umgesetzt haben. Knapp 200 neue WatchGuard-Boxen wurden alleine in diesen drei Monaten verkauft und großteils auch von uns installiert. Auf der WatchGuard Conference am 19.01.2012 in Neuss durfte ich dafür auch die Auszeichnung Best Performing Partner 2011 Central EMEA (Europe, Middle East and Africa) entgegen nehmen. Dazu kommen noch die Lizenzverkäufe (LiveSecurity Renewals und UTM Software Suite bzw. Security Services Verlängerungen) und die “ganz normalen” Wartungs-Dienstleistungen und Software-Migrationen, teilweise auch schon auf die neue Fireware XTM 11.5.1. Über die Erfahrungen hierbei werde ich nun in kürzerer Folge hier berichten… 🙂

X Core und X Peak e-series nicht direkt von v10.x auf v11.3.3 oder v11.3.4 updaten!

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!

WSMMGR Lizenznummer derzeit nur per Support Incident

Auch mehr als zwei Monate nach dem Umbau der WatchGuard-Webseite gibt es noch keine Möglichkeit, die Lizenznummer für den “WatchGuard System Manager” (bzw. besser gesagt: die “Management Server” Komponente, vgl. auch https://www.boc.de/watchguard-info-portal/watchguard-system-manager-vs-watchguard-management-server-2/) selbständig aus seinem LiveSecurity Account auzulesen wie das bis Anfang Juli möglich war.
Wer aktuell seine VPNMGR, WSMMGR und/oder WSMUPGRADE Lizenznummer(n) braucht und nicht bereits irgendwo dokumentiert hat, muss leider bei WatchGuard einen Support Incident aufmachen (per Web oder telefonisch) – und sich die entsprechenden Lizenznummer(n) von den WatchGuard-Kollegen händisch auslesen und übermitteln lassen…

Secondary IP nicht auf VLANs

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…

Maximal vier physikalische External Interfaces

Aus früheren Zeiten hat auch die aktuelleste Fireware XTM 11.4.2 noch die Beschränkung, dass maximal vier physikalische Interfaces konfiguriert werden können. Wenn aber doch einmal MEHR als vier externe Interfaces konfiguriert werden sollen, bleibt noch der Weg über VLANs. Hierbei wird z.B. ein physikalisches Interface der WatchGuard als VLAN-Interface eingerichtet – und die ganzen externen Anschlüsse dann eben als Tagged VLAN mit unterschiedlichen VLAN-IDs. Zwischen der WatchGuard und den externen Leitungen sitzt dann ein VLAN-fähiger Switch, auf dem die gleichen VLAN-IDs konfiguriert sind. Die verschiedenen ISP-Router sind dann jeweils an einem Untagged Port angeschlossen, der dem passenden VLAN zugeordnet ist. Der Switch-Port, an dem die WatchGuard angeschlossen wird, muss als Trunk Port eingerichtet werden (Tagged).

Auf diese Weise kann man natürlich auch physikalische Ports auf der WatchGuard einsparen, wenn es in komplexen Umgebungen einmal eng wird. Statt z.B. mehrere Trusted oder Optional Networks direkt als physikalische Interfaces auf der WatchGuard einzurichten, können diese auch als VLANs auf einem VLAN-Switch abgebildet werden, der nur über ein einzelnes Kabel an der WatchGuard angeschlossen ist…