Category Archives: Technischer Blog

Verlust der Default-Route bei PPPoE-Reconnect – Fireware 12.1.1

Kürzlich ist uns ein unschöner rare Case untergekommen:

Symptom:

  • das externe PPPoE-Interface hat eine IP-Adresse
  • das externe PPPoE-Interface ist bei Multi-WAN “als available” markiert
  • “das Internet geht nicht” – von Innen kein DNS/Ping/Whatever über dieses Interface möglich
  • nach physikalischem Disconnect/Reconnect des Kabels zum Modem wird ein neuer PPPoE-Handshake erzwungen und alles funktioniert, wie es soll
  • alternativ: nach einem Reboot (ebenfalls neuer PPPoE Handshake) ebenfalls wieder alles OK.

Ursache:

  • beim PPPoE-Reconnect wird eine IP-Adresse zugewiesen
  • in seltenen Fällen kann es aber passieren, daß irgendwie die Default-Route über dieses Interface verloren geht

Abhilfe:

Eventueller Workaround:

  • eventuell ein geschedulter täglicher Reboot der WatchGuard, soweit uns bekannt, trat der Fehler nicht oder zumindest deutlich seltener beim Booten einer Box auf, sondern nur beim PPPoE-Reconnect.

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!

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

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.