Category Archives: Technischer Blog

WatchGuard Hotspot Administration nicht erreichbar – ERR_TOO_MANY_REDIRECTS

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 und des SSLVPN-Clients

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

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.

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

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

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

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 »

Fireware 12.5.2 SSLVPN – Probleme mit mehreren gleichzeitigen SSLVPN-Sessions

Ein Kunde hat uns gerade folgende Info zukommen lassen:

  • Fireware ab 12.5.2
  • SSLVPN
  • Ein gemeinsamer SSLVPN-Benutzer-Account
  • mehrere gleichzeitige SSLVPN-Sessions mit diesem Account
  • von der gleichen Source-IP (Public IP) aus

In diesem Falle gibt es wohl Probleme, dass es nicht mehr möglich ist, sich mit diesen beiden SSLVPN-Sessions gleichzeitig anzumelden.
Vermutlich greift hier ein interner Session-Takeover oder/und die beiden Verbindungen spielen Ping-Pong.

Abhilfe/Workaround:

  • mehrere SSLVPN-User => damit werden es getrennte Sessions.