Fireware 12.7: Probleme mit BOVPN auf Secondary-IP auf einem nicht-primären externen Interface
Kunde hat nach Upgrade auf 12.7 Probleme mit zwei BOVPNs, die vor dem Upgrade funktionierten.
Category Archives: Technischer Blog
TDR Host Sensor und Veeam Backup v11 (Update => gelöst)
Wir haben heute (2021-06-29) eine Meldung aus dem Feld erhalten:
Wir haben kürzlich auf Veeam Backup v11 aktualisiert.
Wenn man den TDR-Agenten installiert hat, geht auf dem betreffenden Server die Einzeldateiwiederherstellung (FLR) nicht mehr.
Man muss den Agenten pausieren, Ausnahmen (program files\veeam und programdata\veeam) haben bisher nicht geholfen. Es gibt auch keine Meldung im TDR.
Ein entsprechender Case bei WatchGuard ist geöffnet.
Update 2021-07-05:
im Case mit dem WatchGuard-Support wurde eine Lösung gefunden:
Abhilfe brachte folgende TDR- “Exclusion” auf dem Veeam-Server:
"C:\Windows\temp\*\veeamflr*.flat"
CLI Kommandozeilen Befehle zur Hardware Status Abfrage der Firebox T80
Die Firebox T80 kann aufgrund der Lüfterkonzeption relativ warm werden ohne dass der Lüfter automatisch anspringt, was erfahrungsgemäß zur Verunsicherung einiger Kunden führen kann.
In diesem Artikel zeigen wir Ihnen die entsprechenden CLI-Befehle zur Abfrage der CPU-Temperatur und des Lüfterstatus und klären die Frage, wann bzw. ob der Lüfter der Firebox T80 permanent oder temperaturabhängig läuft.
Vorzeitiges Update auf eine neue Panda Adaptive Defense 360 Version
Die generelle Umstellung auf neue Versionen erfolgt immer Schritt-/Blockweise. Dabei wird man vorab via E-Mail seitens von WatchGuard/Panda informiert. Möchte man nicht mehr länger warten kann dies mit Hilfe eines WatchGuard/Panda Cases (Client ID wird benötigt) beschleunigt werden: Weiterlesen
Rotes LED Licht in einer WatchGuard T40/T40-W
Bei den WatchGuard Firebox Modellen T40 und T40-W kann es zu einem hellen roten Leuchten (durch das Gehäuse hindurch) kommen (siehe Foto). Dies ist aber kein Grund zur Sorge.
Das rote Leuchten auf der Abdeckung wird durch eine LED auf der verbauten Speicherkarte im Gerät verursacht. Die Firebox Modelle T40 und T40-W verwenden Weiterlesen
Funktionsweise des FQDN-Features
Das FQDN-Feature von WatchGuard kann u.a. in Regeln, Aliases und weiteren Konfigurationen verwendet werden:
FQDN Hostnames
Um das FQDN (full qualified domain name)-Feature zu verstehen, ist es wichtig zu wissen, dass die Firewall hierzu eine DNS-Anfrage ausführt. Um bspw. die folgende Regel anzuwenden,
From: 192.168.10.1 To: www.example.com Port: http
führt die Firewall einen DNS-Lookup auf die Domäne www.example.com durch. Der Unterschied liegt darin, WANN eine Firewallregel auf Basis eines Domänennamens anfängt zu WIRKEN. Bei einem FQDN wie bspw. www.example.com startet die Firebox sofort nach dem Abspeichern der Konfiguration eine DNS-Abfrage und merkt sich die IP-Adresse(n).
LTE in Kombination mit der Firebox
Ein LTE Router oder Modem kann gegenüber einer Standleitung eine praktikable Möglichkeit sein, um an einer Firebox einen zusätzlichen Internetlink bereitzustellen. Dies macht insbesondere dann Sinn, wenn an Ihrem Standort der Glasfaserausbau noch nicht umgesetzt wurde. Sie können diesen Internet-Link mit SDWAN-Actions nur für bestimmte Regeln nutzen (zum Beispiel um das LTE als Surfleitung zu verwenden) oder um eine Internetleitung als Failover/Backup einzusetzen.
Verwendung eines LTE-Modems:
Modem – cannot enable – Log-Meldung
Folgendes Szenario ist mir in meiner Testumgebung aufgefallen:
An einem USB-Anschluss der Firebox habe ich ein LTE-Gerät angeschlossen, um dann in der Fireware unter Netzwerk – Modem die Modem Konfiguration zu testen. Die Konfiguration konnte ich durchführen und das Regelwerk speichern. Im Log stellte ich aber folgende Meldung fest.
| FWStatus, [22540.239315] usb usb4-port1: Cannot enable. Maybe the USB cable is bad?, pri=3, proc_id=kernel, msg_id= |
AuthPoint Probleme (behoben).
Heute (25.03.2021) Vormittag wurden uns vermehrt AuhtPoint-Proleme gemeldet. (Update 25.03.21, 11:54 Uhr. Probleme inzwischen behoben).
Symptom:
- keine Authentifizierung möglich
- kein Push möglich
HOWTO – Exchange-Server mittels Reverse-Proxy (Access Portal) und Pre-Authentication absichern
Gerade in Zeiten von >> Hafnium stellt sich wieder die Frage, wie der externe Zugriff auf interne Systeme möglichst sicher umgesetzt werden kann. WatchGuard bietet bereits seit langer Zeit Proxies für die gängigen Mail-Protokolle POP3, IMAP und SMTP. Um mobile Geräte möglichst komfortabel in die Exchange Infrastruktur einzubetten, führt allerdings kaum ein Weg an ActiveSync oder MAPI vorbei. Der Zugriff via ActiveSync/MAPI erfolgt via 443 und kann ebenfalls mittels Proxy abgesichert werden, welcher durch Whitelisting von Pfaden, GEO-Blocking, Domain-Prüfung und IPS viele Sicherheitsfeatures erfolgreich umsetzen kann, siehe >> Blog-Artikel
Seit der Firmware v12.5 bietet WatchGuard durch seine Portal-Lösung „Access Portal“ eine weitere Möglichkeit, einen Exchange hinter den in der Firebox integrierten Reverse-Proxy zu verstecken. Durch das Access Portal kann die WatchGuard nicht nur Pfade filtern, sondern auch eine Pre-Authentication für den Exchange erzwingen. Da die Authentifizierung erst gegen die WatchGuard stattfindet und im Anschluss der Traffic in Richtung Exchange weitergeleitet wird, ist der IIS des Mailservers nicht direkt aus dem Internet erreichbar!
Durch eine Kombination mit AuthPoint kann übrigens der Zugriff auf OWA oder ECP zusätzlich über einen zweiten Faktor effektiv abgesichert werden.
*Folgende Installationsanleitung zeigt eine Testumgebung. Vom Standard abweichende Konfigurationen Ihres Exchange, AD, … können hier leider nicht berücksichtigt werden*
