Category Archives: Technischer Blog

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 »

Fireware 12.5.2 SSLVPN – Probleme mit mehreren gleichzeitigen SSLVPN-Sessions

2 Comments

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.

Cloud FQDNs für AuthPoint und WatchGuard Cloud

Comment

WatchGuard AuthPoint Gateway und andere WatchGuard Cloud Dienste benötigen einen direkten HTTPS-Zugriff der lokalen Komponenten auf die Cloud. Das führt immer dann zu einem Problem, wenn ein HTTPS-Proxy mit Deep Inspection (Content Inspection) verwendet wird. Hier müssen entsprechende Ausnahmen definiert werden.

Eine Sammlung der uns bekannten Cloud-URLs finden Sie in diesem Artikel.

Weiterlesen »

HOWTO: DNS-Proxy für SIP

Comment

Aktuell hatten wir den Fall, dass eine WatchGuard-Neuinstallation beim Kunden teils 40 Sekunden Verzögerung bei der SIP-Telefonie mit sich gebracht hatte. Eine Auswertung der Logs zeigte, dass die dortige TK-Anlage eine Namensauflösung via NAPTR (DNS Query-Typ 35: https://en.wikipedia.org/wiki/List_of_DNS_record_types) für die Einwahl in den DeutschlandLAN SIP-Trunk ausführte.  Weiterlesen »