Nach einem Upgrade des WatchGuard AuthPoint Gateway auf die aktuelle Version letzte Version kann es passieren, dass das Gateway sich nicht mehr sauber zur WatchGuard Cloud verbinden kann.
uns erreichen derzeit folgende Meldungen von Kunden:
Der Traffic Monitor der Firebox bleibt leer, es wird keine Logzeile mehr angezeigt.
Aus einem Case bei WatchGuard haben wir die folgende Infos erhalten:
Bevor die Content Inspection aktiviert werden kann, wird ein Proxy Zertifikat für die WatchGuard Firebox benötigt, welchem Ihre Clients vertrauen.
Um zu erfahren, wie ein Zertifikat importiert, ein Certificate Signing Request erstellt oder das selbstsignierte WatchGuard Zertifikat im AD bekannt gemacht wird, empfehlen wir folgende Blog-Artikel:
Im letzten Blog-Artikel >> Keine Fehlermeldung von HTTPS Proxy (deny message) haben wir erklärt warum Benutzer bei gesperrten HTTPS Webseiten keine Blockbenachrichtigung angezeigt bekommen. In diesem Artikel zeigen wir Ihnen wie Sie die Content Inspection aktivieren und konfigurieren können, sodass entsprechende Deny Messages ausgegeben werden.
Sie haben den HTTPS-Proxy sowie den WebBlocker für Ihr Unternehmen aktiviert und Ihre Benutzer erhalten beim Aufruf der gesperrten HTTPS Seiten keine explizite Benachrichtigung, dass die Seite durch Sie gesperrt bzw. weshalb der Zugriff blockiert wurde:
Im Gegensatz dazu erhalten Sie bei gesperrten HTTP Seiten eine Benachrichtigung, die wie folgt aussehen kann:
Im Folgenden erklären wir Ihnen warum Benutzer bei gesperrten HTTPS Webseiten keine Blockbenachrichtigung angezeigt bekommen.
In diesem Blogartikel geht es um die Erstellung von WatchGuard WLAN Tickets welche Sie bspw. auf Visitenkarten o.Ä. drucken können.
Microsoft Teams gewinnt (neben anderer Kommunikationssoftware) im Alltag immer mehr an Bedeutung. Da MS-Teams Mitarbeiter rund um den Globus vernetzt, gibt es bei der Schnittstelle in Richtung Internet einiges zu beachten. Im folgenden Beispiel möchte ich ein einfach zu implementierendes, aber gut funktionierendes Lösungskonzept vorstellen.
Problem: Schlechte Sprach- und Bildqualität.
Idee: Identifizieren und Priorisieren von MS-Teams Traffic oder umleiten auf zweite Internetleitung (wenn verfügbar)
Microsoft stellt uns die benötigten Ports und Endpoints unter folgendem Link bereit: https://docs.microsoft.com/de-de/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide
Meine Kollegen nutzen das bereitgestellte JSON-File und erzeugen daraus ein Text-File, welches unkompliziert in das Regelwerk der WatchGuard importiert werden kann. Das File wird beim Abruf automatisch mit den aktuellen Daten generiert.
Mobilfunk eignet sich spätestens seit LTE nicht nur als „Notlösung“ in schwach ausgebauten Regionen, sondern auch als performanter Failover ohne auf Kabelinfrastruktur angewiesen zu sein (Kupfer/Glas/Koax nutzt häufig die gleiche Gebäudeeinführung und dient daher nur bedingt als Ausfallsicherheit).
LTE bietet zudem die Möglichkeit einen Standort temporär anzubinden, welcher sich noch im Aufbau befindet (Schalttermin des Providers steht aus, Baumaßnahmen notwendig, etc.)
Labor-Umgebung:
WatchGuard T35-W (v12.5.7)
MikroTik LtAP mini (6.47.10)
Telekom SIM-Karte mit Datentarif
Ziel:
Anbindung der WatchGuard an das LTE-Netz und Terminierung der ext. IP direkt auf der WatchGuard.
Konfiguration MikroTik:
Den MikroTik via LAN an ein Notebook anschließen und mittels WinBox die Konfigurationsoberfläche öffnen:
Bei einem Kunden wurde die externe Leitung (600Mbit Glas) durch das Microsoft Office CDN komplett ausgelastet. Symptome/Ursache/Abhilfe/Workaround:
Update: 13.07.2021 18:05:
resolved. Der jeweils aktuelle Status ist unter https://status.watchguard.com/ abrufbar.
Jul 13, 2021Resolved – All AuthPoint services have fully recovered and all systems are operating normally. This incident is now resolved.
At this time, we’re working on completing an in-depth analysis of this incident while also working to resolve all contributing problems fully. We sincerely apologize for the impact on our affected partners and the inconvenience this may have caused.
Jul 13, 16:05 UTCMonitoring – We have completed mitigation actions for AuthPoint Administration and are seeing failure rates recover to normal levels on the remainder of AuthPoint services.
Jul 13, 15:36 UTCUpdate – We have completed initial mitigation actions and are seeing failure rates recover to normal levels on AuthPoint Authentications. We are now working to mitigate impacts on AuthPoint Administration services.
Jul 13, 15:07 UTCIdentified – There are elevated failure rates in the AuthPoint Services, including Authentication, that is impacting users’ ability to authenticate and manage AuthPoint in the Europe WGC Region. The problem has been identified as an underlying AWS infrastructure problem. WatchGuard teams are actively working to mitigate the impact on users and restore the ability to authenticate.
Jul 13, 14:36 UTC
Update: 13.07.2021 17:15:
Das Engineering arbeitet noch daran. Der aktuelle Status ist unter https://status.watchguard.com/ abrufbar.
Update: 13.07.2021 16:45:
Scheinbar doch noch nicht global behoben.
Push Nachrichten aus dem AuthPoint Portal scheinen zu funktionieren, aber alles was von der WatchGuard via Radius zum AuthPoinmt Gateway Server zur Cloud geht, scheinbar nicht.
Das Problem scheint intermittierend zu sein, zwischendurch konnte ich mich anmelden.
Update: 13.07.2021 16:20:
gerade nochmal getestet, Push geht wieder.
13.07.2021 15:15 Uhr:
Aktuell erhalten wir mehrere Meldungen von Kunden, dass sie keine Push-Nachrichten mehr von AuthPoint erhalten, und damit die AuthPoint authentifizierung nicht möglich ist.
Kunde hat nach Upgrade auf 12.7 Probleme mit zwei BOVPNs, die vor dem Upgrade funktionierten.
