Wir haben folgend für Sie die bekannten Probleme die von Watchguard im Dezember geteilt wurden aufgelistet und zusammengefasst.
HTTPS Proxy no longer works on a Firebox in Bridge Mode after upgrade to v12.9
In Fireware v12.9 kann es vorkommen, dass der HTTPS-Proxy fehlschlägt, wenn die Firebox im Bridge-Modus mit einer statischen IP auf der Schnittstelle konfiguriert ist. Um dieses Problem zu lösen, sollte man die Schnittstellenkonfiguration der Firebox von einer statischen IP auf DHCP ändern und den DHCP-Server so konfigurieren, dass er eine statische IP der Firebox zuweist.
Mobile VPN with SSL (12.7.2 B644702) fails to connect on macOS Ventura 13 when you use a self-signed or default Web Server certificate
macOS Ventura 13.0 akzeptiert keine SSL-Verbindungen mehr zu unvertrauenswürdigen selbst signierten Zertifikaten. macOS Ventura-Benutzer, die sich mit SSL-Servern per IP-Adresse verbinden oder die ein selbst signiertes Zertifikat verwenden, erhalten einen Verbindungsfehler und können sich nicht verbinden. Um dieses Problem zu lösen, gibt es zwei mögliche Workarounds. Der empfohlene Workaround ist, ein von einer CA signiertes SSL-Zertifikat zu installieren und Mobile VPN with SSL so zu konfigurieren, dass es sich mit dem entsprechenden Hostnamen verbindet, anstatt den default Fireware Web CA zu verwenden. Informationen darüber, wie man ein von einer CA signiertes Zertifikat generiert und installiert, finden Sie unter http://www.watchguard.com/help/docs/fireware/12/en-us/Content/en-US/certificates/thirdparty_webserver_certificate_c.html.
AuthPoint external identity does not sync users
Wenn man seine AuthPoint-externe Identität so konfiguriert hat, dass Benutzerkonten jeden Tag um 12:00 Uhr morgens oder abends synchronisiert werden, schlägt die Synchronisierung fehl. Um dieses Problem zu lösen, kann man die Synchronisierungsintervalle der externen Identität bearbeiten. Dazu geht man auf cloud.watchguard.com und loggt sich in WatchGuard Cloud ein. Falls man einen Service Provider-Account hat, wählt man diesen in Account Manager aus. Dann geht man zu Konfigurieren > AuthPoint und wählt im AuthPoint-Navigationsmenü Externe Identitäten aus. Klickt dann auf den Namen der externen Identität, wählt im Dropdown-Menü “Synchronisierungsintervall” ein neues Synchronisierungsintervall aus (es sollte nicht 12 Uhr morgens oder abends sein, falls man alle 24 Stunden synchronisieren möchte) und klickt auf Speichern.
Cannot configure a link aggregation interface to use both built-in and interface module 10G SFP ports (M590/M690)
Auf M590- und M690-Geräten können die integrierten 10G SFP-Ports und die 10G SFP-Ports auf einem Schnittstellenmodul nicht zur selben Link Aggregation Interface hinzugefügt werden. Die integrierten eth8- und eth9-SFP-Ports sind fest auf 10000 Mbps, Full Duplex eingestellt. Um diese Ports zu einer Link Aggregation Interface hinzuzufügen, muss diese ebenfalls manuell auf 10000 Mbps, Full Duplex eingestellt werden. Die A0/A1-Schnittstellenmodul-Ports sind fest auf Auto Negotiate eingestellt. Damit diese Ports zu einer Link Aggregation Interface hinzugefügt werden können, muss diese ebenfalls auf Auto Negotiate eingestellt werden. Wenn man versucht, eth8/eth9 zu einer Link Aggregation Interface zuzuweisen, die auf Auto Negotiate eingestellt ist, erhält man den Fehler: “The link speed setting configured for the link aggregation interface is not supported by the physical interface 8”. Analog dazu erhält man den Fehler “The link speed setting configured for the link aggregation interface is not supported by the physical interface A0”, wenn man versucht, A0/A1 zu einer Link Aggregation Interface zuzuweisen, die auf 10000 Mbps, Full Duplex eingestellt ist. Um dieses Problem zu lösen, kann man zwei separate Link Aggregation Interfaces erstellen: Eine Link Aggregation Interface, die auf 10000 Mbps, Full Duplex für eth8/eth9 eingestellt ist und eine Link Aggregation Interface, die auf Auto Negotiate für A0/A1 eingestellt ist. Danach kann man VLANs beiden Link Aggregation Interfaces zuweisen. Die VLANs werden dann gleichzeitig auf beiden Link Aggregation Interfaces vorhanden sein.
Traffic monitor might not display all logs compared to Log Server and Dimension
Der Traffic Monitor in der Fireware Web UI und in Firebox System Manager (FSM) könnte nicht alle Protokolle im Vergleich zu dem anzeigen, was in dem Log Server und Dimension erscheint. Dieses Problem tritt auf, weil Traffic Monitor bei jedem Refresh-Intervall einen gepufferten Teil der Protokolle empfängt. Bei Fireboxes mit hohem Traffic, die eine große Menge an Protokolleinträgen generieren, gibt es manchmal Fälle, in denen nicht alle Protokolleinträge an Traffic Monitor gesendet werden. Die Protokolle, die an den Log Server und Dimension gesendet werden, enthalten alle Protokolle und man kann überprüfen, ob alle Protokolldateien, die man in Traffic Monitor nicht findet, vorhanden sind.
Cannot fully uninstall the DNSWatchGO client through Group Policy Object (GPO)
Wenn man den DNSWatchGO-Client über GPO installiert hat, können Upgrades des Clients mit Fehlercode 1638 fehlschlagen, weil der alte DNSWatchGO-Client nicht vollständig deinstalliert wurde. Um dieses Problem zu lösen, kann man den beigefügten PowerShell-Skript verwenden, um DNSWatchGO zu deinstallieren. Dieses Skript sollte nur auf Anweisung von WatchGuard Support verwendet werden. Danach sollte man den Computer neu starten und DNSWatchGO neu installieren.
Microsoft Azure logon services unavailable when you use DNSWatch or DNSWatchGO
Benutzer des DNSWatchGO Clients oder Benutzer, die von einer Firebox mit aktiviertem DNSWatch geschützt werden, könnten unerwartete DNSWatch-Fehlerseiten sehen, wenn sie versuchen, sich bei Microsoft-Diensten anzumelden, die Azure zur Authentifizierung verwenden, wie zum Beispiel portal.azure.com. Diese Azure-Domains verwenden Kettenartige CNAME-Einträge, um Benutzern den Weg zum nächstgelegenen Azure Gateway zu weisen. Einige der CNAMEs in der Kette sind in der DNSWatch Content Filtering-Datenbank nicht kategorisiert. Jede Content Filtering-Richtlinie, die uncategorized Domains blockiert, wird von der default DNSWatch Content Filtering-Richtlinie blockiert. WatchGuard arbeitet mit unserem Content Filtering-Datenbank-Anbieter zusammen, um die betroffenen CNAMEs korrekt zu kategorisieren. Als Workaround kann man alle Content Filtering-Richtlinien überprüfen und “Miscellaneous > Uncategorized” zulassen. Wenn man uncategorized Domains mit DNSWatch blockieren möchte, kann man Ausnahmen für diese Domains (einschließlich Subdomains) hinzufügen: fdv2-t-msedge.net, fbs1-t-msedge.net, trafficmanager.net, t-msedge.net.