Tag Archives: DynDNS

Neuer Knowledge Base Content im Juli 2016

Comment

WatchGuard erstellt ständig neue Inhalte in der Knowledge Base. Die folgenden Artikel wurden im Mai 2016 hinzugefügt. Um die WatchGuard Knowledge Base zu durchsuchen, verwenden Sie die Technische Suche (Technical Search) im WatchGuard Support Center.

Known Issues (Login auf der WatchGuard Website erforderlich)

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services(WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.

Neuer Knowledge Base Content im Februar 2016

Comment

WatchGuard erstellt ständig neue Inhalte in der Knowledge Base. Die folgenden Artikel wurden im Februar 2016 hinzugefügt. Um die WatchGuard Knowledge Base zu durchsuchen, verwenden Sie die Technische Suche (Technical Search) im WatchGuard Support Center.

Artikel

Known Issues (Login auf der WatchGuard Website erforderlich)

WatchGuard und Telekom VDSL 25, VDSL 50

4 Comments

In der Vergangenheit stellte die Deutsche Telekom VDSL nur in Verbindung mit dem TV-Paket “Entertain” zur Verfügung. Das hat sich geändert: Mittlerweile kann VDSL auch als reiner Hochgeschwindigkeits-Anschluss gebucht werden, als Call & Surf Comfort VDSL in zwei Geschwindigkeits-Varianten: VDSL 25 mit 25/5 Mbit und VDSL 50 mit 50/10 Mbit, jedoch nur mit dynamischer IP-Zuweisung (und ggfs. DYNDNS). Daher wird es künftig auch häufiger vorkommen, dass eine WatchGuard Firebox an einem VDSL-Anschluss betrieben werden soll. Bisher war die korrekte Konfiguration des dazugehörigen “External” Interfaces der WatchGuard eher umständlich, da das Interface als VLAN-Interface mit einem Tagging für die VLAN ID 7 konfiguriert werden musste. Mit Verfügbarkeit des Telekom Speedport 221 VDSL2 Modems entfällt dieser Umweg. Das VDSL-Modem übernimmt das VLAN-Tagging, so dass in der WatchGuard “nur noch” die üblichen PPPoE-Zugangsdaten hinterlegt werden müssen.
Wenn der VDSL-Zugang im Rahmen von “Multi-WAN” als “zusätzlicher” Anschluss für schnelles Surfen verwendet werden soll, beachten Sie bitte auch den folgenden Blog-Beitrag:http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html

Kein DYNDNS-Update bei VPN-Tunnel Routing 0.0.0.0/0

Comment

In manchen VPN-Projekten kommt es vor, dass nicht nur der netzinterne Verkehr von Außenstellen durch einen VPN-Tunnel zur Zentrale geroutet wird, sondern auch der gesamte Internet-Traffic. Dann können nämlich z.B. auch die möglicherweise nur in der Zentrale vorhandenen UTM Security Services (WebBlocker, spamBlocker, Gateway Antivirus, Intrusion Prevention Services, Reputation Enabled Defense) auf den Internet-Verkehr der Außenstellen angewendet werden, wo möglicherweise nur WatchGuard Firebox Produkte mit Live Security eingesetzt werden.
Dabei muss natürlich berücksichtigt werden, dass über die Internet-Leitung in der Zentrale eben auch der komplette Internet-Traffic der Außenstelle(n) läuft – und das nicht nur einmal, sondern DOPPELT (aus dem Internet in die Zentrale und weiter über den VPN-Tunnel in die Filiale).
Im Branch Office VPN Tunnel wird dies häufig über die Verwendung der BOVPN Tunnel Route Local Network <-> 0.0.0.0/0 realisiert.
Wenn in der Außenstelle jedoch keine feste IP-Adresse existiert, sondern mit einem DYNDNS-Hostname gearbeitet wird, führt dies gerade in Verbindung mit dem WatchGuard Management Server zu Problemen. Der auf der WatchGuard laufende DYNDNS-Updater meldet eine Adressänderung nämlich per http an einen Webserver von DYNDNS. Dieser http-Verkehr wird jedoch von der Firebox oder XTM Appliance nicht direkt ins Internet hinaus geroutet, sondern durch den 0.0.0.0/0 Tunnel zunächst in die Zentrale geschickt und von dort aus weiter zu DYNDNS. Das hat aber zur Folge, dass die “gemeldete” IP-Adresse nicht zu der Quell-IP-Adresse passt, von der die Meldung bei DYNDNS eingeht. DYNDNS verweigert daher das Update des DNS-Eintrags, und der WatchGuard Management Server und die am VPN-Tunnel beteiligte zentrale Firebox haben ein Problem, die Außenstelle zu “finden”.
In einem solchen Fall sollte die Außenstelle in einen Internet-Tarif wechseln, bei dem eine feste öffentliche IP-Adresse möglich ist.

SSL-VPN bei Multi-WAN auf einer X Edge

1 Comment

Bei Vorhandensein der Edge Pro (Standard bei X55e, Nachrüst-Option bei X10e und X20e) können beide WAN-Anschlüsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL für Multi-WAN oder einmal DSL und einmal UMTS als Fallback).

Obwohl die GUI auch andere Einstellungen zulässt, terminieren VPN-Verbindungen immer auf WAN1, solange WAN1 aktiv ist. Insofern handelt es sich bezüglich VPN bei WAN2 um ein reines Failover-Interface. Hat man die Konstellation, dass z.B. zunächst auf WAN1 ein normaler ADSL-Anschluss liegt (z.B. T-DSL 6000 mit 512 kBit Upload) – und nach einiger Zeit kommt ein SDSL-Anschluss hinzu (2 Mbit symmetrisch), der gerade wegen des höheren Upload für VPN-Verbindungen genutzt werden soll – sollte man die External Interface neu zuordnen, so dass der SDSL auf WAN1 und der ADSL auf WAN2 zu liegen kommt.

Im Falle von Mobile User SSL-VPN kann man eine Primary IP und eine Secondary IP angeben. Hierbei sollte Primary immer die WAN1-IP sein (bzw. der DYNDNS-Hostname) und Secondary immer die WAN2-IP. Der Client ist zwar in der Lage, die Secondary IP zu connecten und bekommt von dort auch die VPN-Konfig zugewiesen, die eigentliche VPN-Verbindung wird dann aber zu der Primary IP (sprich WAN1) aufgebaut, solange dieses Interface aktiv ist. Sind die IPs vertauscht oder wird z.B. nur die WAN2-IP in die Konfiguration eingetragen, kommt keine Verbindung zustande. Der Client zeigt im Log die Fehlermeldung “Connection refused (WSAECONNREFUSED)” und steht im Logon-Fenster in einer Endlosschleife “Paused, waiting 5 seconds”.

Support kennt hierzu auch ähnliche Berichte aus der Praxis:
BUG30110: Cannot construct SSL VPN and MOVPN on WAN2 while WAN1 is up und BUG23704: Cannot construct a tunnel on WAN2 while WAN1 is up. Diese wurden aber abgeschlossen mit dem Hinweis, dass dieses Verhalten “normal” und “by design” ist.

Sichere Fernwartung einer X Edge

Comment

Um eine entfernt stehende Firebox X Edge auch per HTTPS direkt über das Internet administrieren zu können, füge ich normalerweise bei Firewall > Incoming eine Custom Packet Filter Policy hinzu, die eingehenden HTTPS-Verkehr direkt auf das Webinterface der Firebox leitet (Static NAT). Damit nicht jeder beliebige Rechner aus dem Internet bis zur Anmeldeseite gelangt, lasse ich jedoch nur die bekannten festen IP-Adressen z.B. des Hauptstandorts des Kunden (und unsere eigenen) zu:

Hat die X Edge eine feste externe IP-Adresse, erfolgt der Zugriff über https://EXTERNE-IP. Bei einer dynamischen externen IP-Adresse nehme ich mir einen kostenfreien DYNDNS-Hostname zu Hilfe, der bei Network > Dynamic DNS eingetragen wird:

Befindet sich die X Edge in einer (VPN-)Außenstelle unseres Unternehmens, sorgt diese Einrichtung natürlich auch dafür, dass wir die X Edge über das Internet erreichen können, auch wenn der reguläre VPN-Tunnel dorthin gerade einmal nicht zur Verfügung steht 🙂 Wenn ich parallel dazu auch die SSL-VPN-Möglichkeit der X Edge nutzen möchte, um dort mobile User zu terminieren, lege ich den Port für Remote-HTTPS meist von 443 zum Beispiel auf 444 um: Administration > System Security: