Author: Bernd Och

Hardware-Problem bei einigen M200 und M300

Einige WatchGuard Firebox M200 und M300 haben Performance Probleme, wenn die Interfaces 3 bis 7 (eth3 bis eth7) verwendet werden. Hierfür ist eine Charge fehlerhafter Netzwerk-Chips verantwortlich, die in einigen M200 und M300 Appliances verbaut worden sind.
Das Problem äußert sich in signifikantem Paketverlust oder Durchsatzproblemen von und zu Netzen, die über eth3 bis eth7 verbunden sind. Dies beeinträchtigt auch die korrekte Cluster-Funktionalität, wenn für das/die HA-Interface(s) die Schnittstellen eth3 bis eth7 verwendet werden, was in den allermeisten Fällen der Fall sein dürfte!

Ob Ihre M200 oder M300 von dem Problem betroffen ist, können Sie recht einfach selbst feststellen:

Firebox System Manager > Status Report

Scrollen Sie dort zu der Interface-Statistik der Interface eth3 bis eth7 und suchen Sie dort insbesondere nach dem Wert in_bad_octets. (Sie können im Status Report übrigens auf Strg+F drücken und am unteren Bildschirmrand geht ein Volltextsuchfeld auf, in dem Sie nach diesem Begriff suchen können…):

Eth6 NIC statistics
tx_packets: 10861583
tx_bytes: 2283336906
rx_packets: 8992113
rx_bytes: 905807745
in_good_octets: 473664403
in_bad_octets: 0
in_unicast: 4765801
in_broadcasts: 462

Wenn der Wert für „in_bad_octets“ dort Null beträgt oder sich über einen Zeitraum von mehreren Minuten nicht ändert, ist dieses Interface / Ihr Gerät von der Problematik NICHT betroffen. Bitte überprüfen Sie aber alle infrage kommenden Schnittstellen von eth3 bis eth7.
Wenn der Wert für „in_bad_octets“ hochzählt, machen Sie davon mehrere Screenshots oder erzeugen Sie durch Klick auf die Schaltfläche „Support“ unten rechts im Status Report die „support.tgz“ Datei. Öffnen Sie einen Support Incident in Ihrem Account auf der WatchGuard Website und berichten dort Ihre Feststellungen unter Hinweis auf den Knowledge Base Artikel 000011245. Laden Sie dort dann auch Ihre Screenshots bzw. die „support.tgz“ Datei hoch. Sie werden dann höchstwahrscheinlich per RMA ein Austauschgerät von WatchGuard erhalten.

Nochmal der Hinweis: Andere Modelle außer M200 und M300 sind von dieser Problematik NICHT betroffen!

Sonder-Promotion bis 31.03.2018: kostenfreie HA-Appliance ab M370

Bis zum 31.03.2018 gibt es eine High Availability Sonderpromotion:
Beim Kauf einer WatchGuard Firebox M370 (oder größer) mit 3 Jahren Total Security Suite (als Vollprodukt oder Competitive Trade-In) erhalten Sie GRATIS eine zweite, baugleiche WatchGuard Firebox HA-Appliance mit 3 Jahren Standard Support zum Betrieb eines Active/Passive Clusters dazu!

Die Varianten, welche für die Promotion qualifiziert sind, haben wir auf unseren Produktseiten jeweils rot markiert:

Dieses Angebot gilt NICHT in Verbindung mit anderen Promotions wie den regulären Trade-Ups oder den Sonderkonditionen für Behörden, Schulen und gemeinnützigen Organisationen. In diesen Fällen errechnen wir Ihnen gerne die günstigste alternative Kombination. Bitte benutzen Sie unser Kontaktformular.

Gateway Antivirus Probleme ab 01.01.2018 auf Fireware 11.10.5 und älter

Wie bereits vermeldet, hat WatchGuard mit der Fireware 12.x den Technologiepartner für Gateway Antivirus gewechselt. Bei den 11.x Versionen war es AVG, bei 12.x ist es nun Bitdefender. Als Übergangszeit wurde zunächst verkündet, dass die AVG-Antivirus-Engine und Signaturen noch bis April 2018 lauffähig sein sollen. Wie sich nun herausstellt, gilt dies aber nur für Softwareversion 11.10.7 und höher. Seit dem 01.01.2018 kommt es bei noch älteren Softwareversionen 11.10.5 und früher zu Scanning Errors. Und je nachdem wie die WatchGuard für diesen Fall konfiguriert worden ist, wird sie sich verhalten, z.B. indem die nun nicht (mehr) scanbaren Dateien ge-locked werden (mit Dateiendung *.clk versehen). Wir haben in unserem Blog auch einen älteren Artikel, der beschreibt, wie die *.clk Dateien wieder in den ursprünglichen Zustand versetzt werden können: https://www.boc.de/watchguard-info-portal/2016/06/lock-unlock-bei-smtp-e-mails.

2018-01-02 10:00:00 scand license init failed(The license has expired.) Debug
2018-01-02 10:00:00 scand Instance_Create failed. Debug

Die Application Proxies melden zudem “avg scanner is not created”.

Der o.g. Hinweis “The license has expired” bezieht sich hierbei auf die AVG-Lizenz (von WatchGuard) – nicht auf den Feature Key der eigentlichen Appliance. Vor dem Hintergrund, dass das gleiche Szenario wie jetzt im April 2018 auch alle anderen 11.x Softwareversionen ereilen wird, empfehlen wir nun den zeitnahen Umstieg auf eine 12.x Softwareversion. Bitte beachten Sie aber beim Umstieg unbedingt die Release Notes. Speziell bei ganz alten Softwareversionen ist mitunter ein Zwischenschritt erforderlich, damit die XML-Konfigurationsdatei nicht beschädigt wird. Auch ist es wichtig zu wissen, dass sich die WatchGuard-Box beim erstmaligen Starten mit einer Fireware 12.x erst noch die aktuelle Bitdefender-Engine und die Bitdefender-Signaturen herunterladen und installieren muss. Dies ist zwar ein automatischer Vorgang, er dauert aber nach unseren bisherigen Erfahrungen mindestens 10 Minuten, teilweise auch bis zu 30 Minuten. Während dieser Phase findet ebenfalls keine Antivirus-Überprüfung statt. Möglicherweise wollen Sie z.B. sicherstellen, dass zu dieser Zeit keine ungeprüften E-Mails durchrutschen. Hier könnten Sie z.B. vorübergehend die SMTP-Proxy Firewallregel deaktivieren oder den MTA Ihres Mailservers kurz anhalten.

Neue WatchGuard Box aktivieren

Um eine WatchGuard Firebox / XTM Appliance überhaupt sinnvoll nutzen zu können, muss diese über die WatchGuard Website aktiviert werden. Das bedeutet, dass die Seriennummer bei WatchGuard registriert werden muss, damit man anschließend den Feature Key (die Lizenzdatei) herunterladen kann. Der Feature Key wird dann bei der Inbetriebnahme über den Web Setup Wizard gebraucht.

Weiterlesen »

Neuer Security Service: Mobile Security und FireClient

Die mobile Anwendung (App) WatchGuard FireClient als Teil des Mobile Security Abonnements sorgt dafür, dass nur solche Mobilgeräte per WLAN oder VPN in Ihr Netzwerk gelangen, die vorgegebene Standards einhalten. Wie Sie FireClient unter Apple iOS bzw. Android verwenden, können Sie in der WatchGuard Knowledgebase nachlesen:

  • Knowledgebase Artikel zu iOS
  • Knowledgebase Artikel zu Android

WatchGuard erwirbt Threat Detection und Response-Lösung HawkEye G von Hexis

Integration ins Portfolio erweitert das Angebot um holistischen Netzwerkschutz

WatchGuard Technologies hat sein Security-Portfolio um die Threat Detection and Response-Lösung HawkEye G von der Hexis Cyber Solutions ergänzt. Unternehmen gleich welcher Größe sehen sich mit einer zunehmenden Gefahr von immer ausgefeilteren Zero-Day-Attacken konfrontiert. Häufig fehlen ihnen jedoch die Möglichkeiten, diese rechtzeitig zu erkennen und schnell darauf zu reagieren. Dadurch erhöht sich nicht nur das Risiko einer Attacke, oftmals lassen sich die Schäden auch nicht im erforderlichen Maße begrenzen. Die HawkEye G-Plattform von Hexis ermöglicht die Visualisierung dieser Bedrohungen und erlaubt mit automatisierten Tools eine schnelle Eindämmung der Auswirkungen.

Prakash Panjwani, CEO von WatchGuard, dazu: „Mit der Integration von HawkEye G in unsere Lösungen stellen wir uns dem Problem einer sich stets weiterentwickelnden Bedrohungslandschaft, indem wir für eine umfassende Perimeter-Sicherheit bis zum End-Point sorgen. Der Erwerb dieses führenden und bereits mehrfach ausgezeichneten Produkts erweitert unsere Strategie, unseren Kunden einfach zu implementierende und zu wartende Sicherheitslösungen zu liefern – unabhängig von deren Größe.“

Andrew Young, Vice President Product Management bei WatchGuard, geht auf die Technik ein: „Die Verbindung aus einer signaturfreien Heuristik von HawkEye G für statische und dynamische Hosts mit einem ‚Unified-Scoring-Modell’ bietet unvergleichbare Visualisierungsmöglichkeiten und Einsichten in die Vorgänge im Netzwerk. Aktuell arbeiten wir mit Hochdruck daran, diese innovative Technologie in unser Portfolio zu integrieren und unseren mehr als 75.000 Kunden weltweit sowie allen Partnern zur Verfügung zu stellen.“ Über die Integration in die ‚Management Security Service Provider’ (MSSP)-Plattform von WatchGuard können Service Provider ihren Anwendern – kleine und mittlere Unternehmen, Großkonzerne sowie Distributed Enterprises – zusätzliche Services und damit echten Mehrwert zur Verfügung stellen.

Über Hexis HawkExe G

Die HawkEye-Plattform findet und reagiert auf Bedrohungen, bevor diese Schäden anrichten. Dazu kommt eine Kombination aus Verhaltensanalysen am Endpoint, einer durchgängigen Aufzeichnung und Deep Packet-Inspektion im Netzwerk sowie weiteren Security-Analysen in einer regelbasierten, automatisierten bzw. maschinengeführten Architektur zum Einsatz. Anwender können eine Vielzahl von Erkennungs- sowie Visualisierungsmöglichkeiten nutzen, um die Schwere und die Auswirkungen eines Angriffs zu beurteilen und darauf entsprechend zu reagieren.

Über WatchGuard Technologies

WatchGuard Technologies ist ein globaler Anbieter von integrierten und multifunktionalen Business-Security-Lösungen, die Standard-Hardware mit erstklassigen Sicherheitsfunktionen sowie intuitiv zu bedienenden, Richtlinien-basierten Management-Werkzeugen gezielt miteinander vereinen. Mit Schutzmechanismen auf Enterprise-Niveau erfüllt WatchGuard die Anforderungen von hunderttausenden Unternehmen weltweit. Neben der Zentrale in Seattle im US-Bundesstaat Washington verfügt WatchGuard über Niederlassungen in ganz Nordamerika, Lateinamerika und Europa sowie im asiatisch-pazifischen Raum.

Technologiepartnerschaft: Kaseya

Kaseya ist ein führender Anbieter für cloudbasiertes IT-Management und Sicherheitssoftware. Lösungen von Kaseya dienen Managed Service Providern (MSPs) und IT-Organisationen zur effizienten Verwaltung und Absicherung ihrer IT, um damit sowohl den Betrieb der IT-Dienste wie auch den geschäftlichen Erfolg sicherstellen zu können.

Integration: Die problemlose Einbindung von WatchGuard Fireware OS in Kaseya VSA ermöglicht MSPs die Remoteüberwachung von WatchGuard Firebox-Appliances.

Dynamic NAT und Nicht-RFC-1918-Adressen

Eine Default WatchGuard Konfigurationsdatei, die per Setup Wizard erstellt wurde, geht davon aus, dass in einem LOKALEN Netzwerk (Trusted oder Optional) entweder RFC-konforme Private IP-Adressen nach RFC 1918 verwendet werden – also ein beliebiges Subnet innerhalb der Bereiche 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 – oder korrekt geroutete öffentliche IP-Adressen! Nur dann funktioniert der “Internet-Zugriff” auf Anhieb!
Verwenden Sie jedoch – meist aus “historischen Gründen” – in Ihrem lokalen Netzwerk “verbogene” öffentliche IP-Adressen (also zum Beispiel: 192.1.1.0/24) – müssen Sie folgende Einstellung im Policy Manager bearbeiten, damit die reguläre Internet-Nutzung überhaupt erst möglich wird: Network > NAT > Dynamic NAT.
Fügen Sie dort Ihren “verbogenen” lokalen IP-Bereich hinzu. Hierbei kann auch eine bestimmte Quell-IP festgelegt werden. Wird nichts definiert, wird die Primary IP des Interfaces verwendet, über das das Datenpaket gemäß Routing Table die WatchGuard verlässt:

WatchGuard Dynamic NAT 1   WatchGuard Dynamic NAT 2   WatchGuard Dynamic NAT 3

Technischer Hintergrund: Nur wenn die Quell-IP-Adresse in den Headern von ausgehenden IP-Paketen in den hier definierten Bereichen liegt, wendet die WatchGuard Firebox beim Durchfluss der Datenpakete Richtung Internet auch die erforderlichen NAT-Regeln an, ersetzt also die eigentliche Quell-IP-Adresse (des Client-PC) durch die korrekte öffentliche IP-Adresse der Firewall. Nur dann können die Daten aus dem Internet auch den korrekten Weg zu unserem lokalen Netzwerk zurück finden! – OHNE die NAT-Regel würde der angesprochene Server im Internet unsere Anfrage zwar erhalten – und sogar darauf antworten (!) – allerdings würden die Router im Internet die Antwort wegen ihrer Routing Tables sonstwohin schicken (Südamerika, Australien, Timbuktu…) – nur nicht zu uns, da die Router gar nicht wissen KÖNNEN, dass “wir” diese IP-Adressen “illegalerweise” in unserem lokalen Netzwerk in Hintertupfingen verwenden… 🙂

Fazit: o.g. NAT-Regel anpassen – oder dafür sorgen, dass in Ihrem lokalen Netzwerk KORREKTE private IP-Adressen nach RFC 1918 verwendet werden…

Dieser Artikel wurde erstmals am 11.12.2008 im “Technischen WatchGuard-Blog von Bernd Och” veröffentlicht. Hierher verschoben und aktualisiert in 2016.