Category Archives: Technischer Blog

DCHP Server Probleme mit 12.6.2

Comment
Symptom:

“WLAN geht nicht mehr”

Ursache:

im VLAN wurde keine IP mehr vergeben. DHCP-Server verteilt keine IP-Adressen mehr.

Recherche:

>> Knowledge-Base-Artikel bei WatchGuard

Der DHCP-Prozess scheint sich hier mit erhöhter CPU-Last zu verklemmen und liefert keine IP-Adressen mehr aus.

Laut KB vorgeschlagener Workaround:
  • Reboot (hat in diesem Fall nur für 10-12h geholfen, danach ging es wieder los)
  • Alle DHCP Reservierungen in allen Scopes entfernen (ist hier nicht sinnvoll, da sehr intensiv mit Reservierungen gearbeitet wurde)
Verwendeter Workaround
  • Downgrade auf 12.5.4 (die Version lief vorher seit dem Upgrade stabil).

Swyxit! IPS false positive

Comment
Setup:

SwyxIt!-Softphone greift auf Swyx-TK-Anlage via BOVPN-Tunnel zu.

Symptom:

Swyxit Softphone Client zeigt keinen Status nach Login.

Beobachtung:

auf der Firewall sind folgende Log-Einträge zu sehen:

2020-09-07 10:14:43 Deny 10.xxx.xxx.xxx 10.xxx.yyy.zzz sip/udp 5070 5060 [...] IPS detected [...] proc_id="firewall" rc="301" msg_id="3000-0150" 
src_ip_nat="10.xxx.xxx.xxx" signature_name="SIP Digium Asterisk SIP CSeq Heap Buffer Overflow (CVE-2017-937" 
signature_cat="Buffer Over Flow" signature_id="1133858" severity="4" [...]

Scheinbar triggert der Swyx-Client hier beim Verbindungsaufbau zur Swyx-TK-Anlage gelegentlich das IPS.

Abhilfe:
  • Policy-Manager
    => Subscription-Services
    => [Exceptions] => Entsprechende ID einfügen => ADD => OK => OK
    => Policy auf Firewall schreiben.

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.