Category Archives: Technischer Blog

Anzeigefehler: WatchGuard System Manager zeigt Zertifikate als expired

Comment

Wenn sehr langlaufende Zertifikate auf einer Firebox installiert sind, werden diese unter Umständern als abgelaufen angezeigt obwohl sie noch viele Jahre gültig sind.

Das folgende Bild zeigt links die Anzeige des WatchGuard System Managers – er zeigt bei Zertifikaten (gültig bis 2038 oder 2049) ein “expired” an; auf der rechten Seite ist die identische Box abgebildet, allerdings stammt der Screenshot vom Firebox System Manager – Hier ist die Anzeige korrekt.

WatchGuard Hotspot Administration nicht erreichbar – ERR_TOO_MANY_REDIRECTS

5 Comments

Symptom:

beim Zugriff auf die HotSpot-Admin-Seite unter https://<ip-der-firewall>:8080/wirelessguest/ beschwert sich der Browser über ERR_TOO_MANY_REDIRECTS.

Ursache:

Dies tritt unter aktueller Fireware (uns sind derzeit bekannt: 12.5.3/12.5.4) in bestimmten Konstellationen auf, falls der Hotspot über den Policy Manager konfiguriert wurde.

Workaround:

  • Einloggen über in das Admin-Panel der Webui (Firewall-Administration, nicht HotSpot Administration), und dort auf der Hotspot Konfiguration irgendetwas ändern und neu speichern.
    (damit die Konfiguration über die WebUI neu geschrieben wird).

Bereinigen der Most-Recently-Used Liste des WatchGuard System Managers, System Manager Server und des SSLVPN-Clients

Comment

Die Drop-Down-Liste des WatchGuard System Managers beim Connect auf die Fireboxen bzw. Management-Server

Die Connect-Liste des System Managers kann wie folgt mit Regedit bearbeitet werden:

[Computer\HKEY_CURRENT_USER\Software\WatchGuard Technologies, Inc.] "fbMRU" 

Das “fb” in “fbMRU” steht für Firebox.

Analog dazu ist folgender Registry Key für die Liste der Management-Server vorhanden:

[Computer\HKEY_CURRENT_USER\Software\WatchGuard Technologies, Inc.] "vpnMRU"

Der Name “vpn” in “vpnMRU” ist vermutlich historisch bedingt, da damals[tm] der Management-Server zunächst nur für eine zentrale Verwaltung der BOVPNs verfügbar war. Solche Namensgebungen halten sich aber bekannterweise sehr hartnäckig 😉

Vielen Dank an Hr. Brian Schneider für die Anregung zu diesem Blog-Post.

Die Liste des SSL-VPN Clients findet sich hier:

[Computer\HKEY_CURRENT_USER\SOFTWARE\WatchGuard\SSLVPNClient\Settings] "Server"

BOVPN-Tunnel WatchGuard <=> Fortinet, IKEv1 – Mismatched ID Setting

Comment

Ein Kunde hatte gerade ein Problem, einen IPSec BOVPN-Tunnel zwischen WatchGuard und Fortinet / Fortigate aufzubauen.

Setup: physikalische WatchGuard => Oracle Cloud => NAT => Virtuelle Fortinet

In einer Telko mit dem Kunden und dem Techniker, der die Fortinet konfiguriert, konnten wir debuggen.

Alle Settings (IKEv1) haben soweit gepasst, allerdings kam immer ein Fehler (auf der WG gemeldet):

IKE phase-1 negotiation from xx.xx.xx.xx:500 to yy.yy.yy.yy:500 failed. Gateway-Endpoint='name-des-gateways' Reason=Authentication failure due to mismatched ID setting

Laut Aussage des Technikers kann man bei der Fortigate die ID aber nicht einstellen; die Fortinet würde
die ID erst auf Anfrage der Gegenstelle überhaupt senden, und dann dort die externe IP reinschreiben.
(also ID = externe IP, nicht die „externe IP aus dem Transfernetz“.  => bei der WatchGuard dann remote ip = remote id).

Ein Erhöhen des Diagnostic log level auf info hat nichts wirklich Neues gegeben.

Ein Erhöhen des Diagnostic log level auf debug brachte dann eine Meldung zutage:
„invalid payload type (FQDN)“ oder so ähnlich. Wir haben leider keinen Screenshot dazu.

die WG hat also Type=IP erwartet und Type=FQDN erhalten.

Ich habe danach die Remote-ID umgestellt:

( ) By IP Address
(*) By Domain Information
=> (*) Domain Name
=> Die remote IP-Adresse als Domain Name eintragen

hat geholfen:

nach dem Abspeichern kam der Tunnel sofort hoch.

Kompatibilität HTTPS-Reverse-Proxy und Exchange/Outlook

1 Comment

Um Pfade wie /ECP/ (Exchange Admin Center) vor Zugriffen aus dem Internet zu schützen, können Sie wie >> hier beschrieben eine HTTP-Content-Action inkl. Deep Inspection verwenden. Damit der Zugriff auf Mails, OWA, etc. wie gewohnt funktioniert, ist Folgendes zu beachten:

  1. Zertifikat, welches den Exchange-Server inkl. AutoDiscover abdeckt (Bsp.: autodiscover.maildomain.xy, mx.maildomain.xy)
  2. Exchange-Server und Client müssen >> MAPI over HTTP unterstützen:

    Quelle: Microsoft

Weitere Informationen und eine Hilfestellung finden Sie in unserem Blogartikel HTTP-Content-Action am Beispiel von OWA – Blocken von /ecp/.

Known Issue: AP120 und AP320 können nach Update den GWC nicht mehr erreichen

Comment

Beschreibung:
Die Access Points AP120 und AP320 können nach dem Update der AP-Firmware auf Version 8.8.1-101 möglicherweise nicht mehr den Gateway Wireless Controller (GWC) erreichen. Das Problem entsteht dadurch, dass bei einem Upgrade die Konfiguration der Access Points verloren geht und der Access Point den GWC nicht mehr discovern kann (falls der AP nicht direkt mit der WatchGuard verbunden ist).  Der Access Point verfügt dann nicht mehr über eine funktionierende Netzwerkkonfiguration. Auch bei gerouteten Netzen ist dieses Problem aufgefallen.

Weiterlesen »