Category Archives: Technischer Blog

Hardware-Problem bei einigen M200 und M300

Comment

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!

bd scanner is not created filename – Probleme mit Pattern? Update 17:35

10 Comments

seit gerade treten Probleme mit eingehenenden E-Mails auf.

wir haben bisher folgende Gemeinsamkeiten festgestellt:

  • seit ca. 13:00
  • Bitdefender Patternfile 20180206.1700
  • Attachements mit UTF8-Zeichen im Filename
  • Attachements mit Leerzeichen im Filename
  • CASE Bei WatchGuard ist geöffnet.
  • Update aus dem CASE: Scheint nur M200/M300/T35 zu betreffen

Der Fehler tritt auch beim HTTP-Proxy auf, wie uns von weiteren Kunden mitgeteilt wurde.

Update 14:20 Uhr:
gerade wurde ein neues Pattern File veröffentlicht: 20180207.100 – behebt das Problem leider nicht.

Update 16:27 Uhr: 

We are currently experiencing an issue for the GAV updates for this signature set. This is effecting M200/ M300 / T35 devices.

We will contact you as soon as a workaround / fix is deployed.

Update 17:35 Uhr:
siehe Kommentare, es gab wohl ein Rollback auf ein altes Patternfile.

Fireware 12.1 / Probleme mit HTTP und SMTP Proxy

Comment

bei Fireware 12.1 gibt es ein Problem mit dem HTTP und mit dem SMTP Proxy.

unter bestimmten Voraussetzungen kann es vorkommen, daß der Proxy zu große Pakete erzeugt, und diese nicht korrekt routen kann, weil er sich an MTU und „fragmentation needed“ stört. Das Fehl-Verhalten ist unabhängig von der MTU-Einstellung beim jeweiligen Device.

Workaround:

  • Policy Manger => Settings => Global Settings => Tab Networking => TCP MTU Probing => Always enabled

Weiterlesen »

Webblocker Server is not available (seit 25.01.2018)

5 Comments

[UPDATE, 26.01.2018, 10:39 Uhr]: Das Problem scheint mittlerweile behoben zu sein!

Seit dem 25.01.2018 abends gibt es offenbar Probleme mit der WebBlocker-Infrastruktur.

Symptome / Notification E-Mail:

  • WebBlocker.<name der webblocker action>
    Appliance: <name der appliance>
    Time: Fri Jan 26 07:42:42 2018 (CET)
    Process: https
    Message: Policy Name: Internet.HTTPS-proxy.Out-00 Action: ProxyAllow: Reason: HTTPS service unavailable
    Source IP: x.x.x.x Source Port: 64223 Destination IP: y.y.y.y Destination Port: 443
    error: Webblocker server is not available service: WebBlocker.Standard cats: dstname: xxx.xxx.xxx

  • Surfen im Web ist allgemein langsam

Wenn der Webblocker Server nicht erreichbar ist, läuft für jeden Webzugriff ein voreingestellter Timeout von 5 Sekunden, ab dem dann die ausgewählte Action greift.
Zu finden unter: Policy Manager => Setup => Actions => Webblocker => <Webblocker action auswählen> => Tab Advanced.

Als System Default ist dort hinterlegt: Deny access to the web site, was dazu führt, dass eben auf gar keine Webseiten mehr zugegriffen werden kann, weil die Zugehörigkeit zu einer WebBlocker-Kategorie nicht überprüft werden kann. Wir empfehlen grundsätzlich, auf Allow the user to view the web site umzustellen (nicht nur wegen der aktuellen Situation). Im Zustand „Allow“ würde dann trotz Nicht-Errreichbarkeit der Webblocker-Infrastruktur der Zugriff auf HTTP / HTTPS Webseiten möglich sein – wenn auch durch den Timeout zeitverzögert, aus Usersicht also „langsam“. Um dies in der aktuellen Situation etwas zu entzerren, empfehlen wir, den Timeout auf einen niedrigeren Wert von z.B. 2 Sekunden einzustellen. Auch Alarm, sprich die Notification per E-Mail sollte derzeit temporär ausgeschaltet werden.

Vorsicht bei Fireware 12.1

2 Comments

Bei Support-Einsätzen kommen nun leider vermehrt einige seltsame Verhaltensweisen zutage.

Derzeit scheint es Probleme zu geben mit

  • HTTP-Proxy in Verbindung mit PPPoE-Leitungen (möglicherweise MTU Aushandlungsproblem)
  • DNS-Requests von der Firewall selbst, die in MultiWAN-Umgebungen unter bestimmten Voraussetzungen auf der falschen Leitung gesendet werden

Wir raten daher zum derzeitigen Stand vom Einsatz der 12.1 ab.

Warum wird das erst jetzt sichtbar?

Fireware 12.1 wurde Mitte Dezember veröffentlicht (kurz vor Weihnachten). Der typische Administrator spielt Feature-Updates nicht kurz vor Weihnachten ein, so daß sich etwa folgendes Schema etabliert haben könnte: nach den Weihnachtsferien (also je nach Bundesland nach Dreikönig oder nochmal eine Woche später) wird zunächst der während der freien Tage angesammelte Stapel durchgesehen und ggf. abgearbeitet und danach wird das Feature-Update eingespielt. So kommt es, daß die „breite Masse“ erst Mitte/Ende Januar (also jetzt) mit der 12.1 Erfahrungen sammelt.