Tag Archives: T-DSL

WatchGuard XTM und Telekom VDSL

5 Comments

Mich erreichen zahlreiche Anfragen bezüglich des Betriebs einer WatchGuard XTM an einem VDSL Anschluss der Telekom. In einem früheren Post hatte ich bereits darauf hingewiesen, dass das Speedport 221 Modem ohne umständliche VLAN-Konfiguration direkt funktioniert, wenn auf der WatchGuard die üblichen PPPoE (V)DSL-Zugangsdaten eingetragen werden. Leider ist dieses Modem auf dem Markt nur noch gebraucht zu bekommen. Ein weiterer VDSL-Kunde hat mir nun berichtet, dass er eine WatchGuard XTM über einen Telekom Speedport W923v Router an VDSL 50 anschließen konnte. Dies ist die beschriebene Vorgehensweise: zunächst den W923v als Router einrichten und mit den PPPoE VDSL-Zugangsdaten versehen. Anschließend den W923v vom “Router” auf “Modem” umstellen, die VDSL-Zugangsdaten aber drin lassen! Auf der WatchGuard dann ebenfalls im Interface die PPPoE VDSL-Zugangsdaten eintragen! Vielleicht kann hier jemand diese Vorgehensweise bestätigen oder gerne auch andere Wege aufzeigen, wie eine WatchGuard XTM erfolgreich an einem VDSL-Anschluss betrieben werden kann.

Multi-WAN und Policy Based Routing

1 Comment

Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, können bis zu vier Interfaces als External Interface konfiguriert werden. Hier können jeweils unterschiedliche Internet-Anschlüsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen überlastet ist, weil “zu viel” HTTP/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig Bandbreite für VPN-Anbindungen, E-Mail und andere unternehmenskritische Anwendungen übrig bleibt…
Statt einfach die Bandbreite der Standleitung für teuer Geld beim Provider hochsetzen zu lassen, kann auch darüber nachgedacht werden, einen – deutlich billigeren – ADSL, VDSL oder Kabel-TV-Anschluss als zweiten Internet-Anschluss an die gleiche WatchGuard anzubinden und über das Firewall-Regelwerk festzulegen, dass der typische HTTP und HTTPS Traffic über eben diese billigere DSL-Leitung geführt wird (Policy Based Routing, PBR). Damit wird die (teure) Standleitung von eben diesem Traffic ENTLASTET.

Die unternehmenskritischen Services können so evtl. auch auf längere Sicht auf dem bisherigen Stand zu deutlich geringeren laufenden Kosten versorgt werden.

Wenn nun mindestens ein zweites Interface der WatchGuard als “External” konfiguriert wird, sind zusätzliche Einstellungen erforderlich, ohne die das gewünschte Verhalten eventuell nicht zum Tragen kommt! Insbesondere muss im Policy Manager unter Network > Configuration die Registerkarte Multi-WAN beachtet werden, die bei Verwendung nur eines einzelnen externen Interfaces “ausgegraut” war.
Hier wähle ich in der Regel als Default-Verhalten im Multi-WAN-Betrieb anstelle des voreingestellten Verfahrens “Routing Table” das Verfahren “Failover” aus und aktiviere hinter dem Button “Configure” die am typischen Multi-WAN-Betrieb beteiligten externen Interfaces (die Zahlen in Klammern entsprechen der Interface-Nummer auf der WatchGuard: z.B. 0=eth0, 6=eth6):

Die angezeigte Reihenfolge der Interfaces entspricht auch dem tatsächlichen Verhalten der WatchGuard Firebox für ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gemäß dieser Liste von oben nach unten bedient. Will heißen: Wenn das ganz oben aufgeführte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das nächste Interface in der Liste verwendet…

Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird über die Registerkarte Multi-WAN gesteuert:

Für jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verfügbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgeführten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardmäßig das Default Gateway des jeweiligen Interfaces). Wenn die angepingte IP-Adresse (3+1) = 4 x 15 => 60 Sekunden) nicht antwortet, wird das Interface auf “INACTIVE” gesetzt. Kommen wieder drei aufeinanderfolgende Antworten im Abstand von 15 Sekunden, wird das Interface wieder auf “ACTIVE” gesetzt und nimmt am Multi-WAN-Verfahren teil.

Daraus ergeben sich zwei Problematiken:

  • Problem 1 (Szenario Standleitung) => “Wo befindet sich das Default Gateway einer Standleitung?” Antwort: “Das ist der Übergaberouter des ISP, der sich in der Regel beim Kunden vor Ort befindet und per Kabel direkt an der WatchGuard angeschlossen ist”. Wenn nun eben dieser Router auf “ping” antwortet: Ist das eine zuverlässige Aussage darüber, ob nun die eigentliche Internet-Anbindung durch diesen Router hindurch funktioniert? Antwort: “Nein”. Typischerweise sollte also hier eine EXPLIZITE IP-ADRESSE konfiguriert werden, die irgendwo tatsächlich im Internet liegt.

  • Problem 2 (Szenario PPPoE oder DHCP-Einwahl) => Das Default Gateway des Interfaces wird dem Interface vom Provider erst bei der Einwahl zugewiesen. In vielen Fällen (providerabhängig!) antwortet aber genau diese als Default Gateway zugewiesene IP-Adresse nicht auf ping. Was ist also das Resultat im Default-Zustand? Das Interface arbeitet zunächst (3+1) x 15 => 60 Sekunden ordnungsgemäß, wird dann jedoch von der WatchGuard als “INACTIVE” eingestuft und aus dem Multi-WAN-Verfahren herausgenommen… Insbesondere in diesem Fall sollte also UNBEDINGT eine tatsächliche IP-Adresse im Internet als ping-Ziel definiert werden…

Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verfügbarkeit von externen Systemen abhängig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverfügbar ausgelegt sind: 8.8.8.8, 4.2.2.3, 141.1.1.1 oder die typischen DNS-Server der Telekom 194.25.0.60, 194.25.0.68, 194.25.0.52, 194.25.2.129 etc. Providerunabhängig lautet meine Empfehlung generell: Verwenden Sie hier nach Rücksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverfügbar ausgelegt ist – und die sich nicht in absehbarer Zeit ändern wird!

(Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgeführt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gemäß o.g. ausmalen kann… War zum Glück an einem Wochenende…)

Nachdem nun die Voraussetzungen für das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tatsächlichen PBR (Policy Based Routing) Firewall-Regeln herangehen. Mehr dazu später heute Abend, wenn ich vom Strand zurück bin. Schließlich bin ich nun mal diese Woche im Urlaub… 🙂

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.

Zeitgesteuerter PPPoE Reconnect oder Reboot bei 11.2

2 Comments

Die Fireware XTM v11.2 stellt für alle Plattformen ein neues Feature bereit, das speziell für den deutschen Markt mit seiner berühmten 24 Stunden DSL-Zwangstrennung interessant ist. Wenn ein External Interface auf PPPoE eingestellt ist, kann über Network > Configuration > [External] > Configure > Advanced Properties (Button ganz unten) ein täglicher PPPoE Reconnect zu einer bestimmten Uhrzeit ausgelöst werden.

Legt man diesen Zeitpunkt in eine betriebsarme Zeit (Nacht), kann man bei sonst stabiler DSL-Verbindung dadurch verhindern, dass durch eine eventuell sonst tagsüber erfolgende DSL-Zwangstrennung eine kurzzeitige Betriebsunterbrechung erfolgt.
In diesem Zusammenhang: auch bei dem Tarif T-DSL Business mit fester IP-Adresse erfolgt alle 24 Stunden eine Zwangstrennung. Bei der sofort danach erfolgenden Wieder-Einwahl wird lediglich nur wieder die gleiche IP-Adresse zugewiesen!

Alternativ dazu gibt es auch die Möglichkeit, einen zeitgesteuerten Reboot der gesamten Firewall durchzuführen – zum Beispiel einmal pro Woche. Dies ist interessant, weil dadurch regelmäßig wieder ein sauberer Ausgangszustand hergestellt wird und eventuelle Memory Leaks nicht dazu führen, dass die Firebox nach sehr langen Laufzeiten ggfs. instabil wird. Dieses Feature befindet sich unter Setup > Global Settings:

Probleme mit DSL-Modem Speedport 201

6 Comments

Es gibt offenbar Probleme im Zusammenspiel zwischen einer WatchGuard Firebox und dem derzeitigen Standard-DSL-Modem der Telekom, dem Speedport 201. Ich musste dies nun schon mehrfach feststellen – hauptsächlich mit einer X Edge unter Software 10.2.x. Die PPPoE-Einwahl kommt nicht zustande, im Logging ist aber nichts Ungewöhnliches zu sehen, auch nicht im PPPoE-Debugging-Modus. Die Vorgängerversion Speedport 200 hat immer einwandfrei funktioniert, ist aber wohl nicht mehr verfügbar. Eine Alternative wäre ein DSL-Modem eines anderen Herstellers.

Kernel Crash bei Fireware 10.2.x

Comment

Im Zusammenhang mit meinem Posting “Upper Port Problem bald gelöst” vom 08.01.09 kam folgende Frage auf: “Wie kann man feststellen, ob/wann überhaupt ein Kernel Crash aufgetreten ist?” Hier die Antwort: Starten Sie den WatchGuard System Manager (WSM), verbinden Sie sich mit Ihrer Firebox und rufen Sie über Rechtsklick den Firebox System Manager auf. Gehen Sie dort auf die Registerkarte “Status Report” und scrollen Sie bis ganz unten. Endet die Anzeige mit

** Routing Protocol (BGP)
**
bgp is not enabled

liegt kein unmittelbarer Kernel Crash vor. Gibt es darunter jedoch noch ein paar Zeilen zum Thema VM Dump, dann sind ein oder mehrere Kernel Crashes aufgetreten:

**
** VM Dump
**
Found kernel crash, time of crash was Sun Jan 11 21:14:26 2009
Crash dump data recovered on Sun Jan 11 21:15:08 CET 2009
Crash dump data saved in /var/log/vmdump/vmdump.3.

In diesem Beispiel bedeutet die Ziffer 3 ganz zum Schluss, dass aktuell sogar vier Kernel Crashes in den internen Support Logfiles der WatchGuard Firebox protokolliert sind. Ein Kernel Crash löst anschließend einen Reboot der Firebox aus.

“Wie kann ich die internen Support Logfiles auslesen?”

Antwort: Ganz rechts unten in der Ecke des Status Reports (vgl. auch den o.g. Screenshot) findet sich ein Button “Support…”:

Mit Klick auf “Retrieve” kann man alle internen Logfiles in einer gemeinsamen Datei namens support.tgz auf die Windows Management-Station herunterladen. Dort kann sie z.B. mit Hilfe von WinZip oder WinRAR ausgepackt werden. Im Unterverzeichnis varlogvmdump finden sich im aktuellen Beispiel die Dateien vmdump.0, vmdump.1, vmdump.2 und vmdump.3 – jeweils mit Datum und Uhrzeit des tatsächlichen Kernel Crashes:

Da alle Uhrzeiten recht ähnlich sind, liegt ein Vergleich mit den Uhrzeiten der 24-stündigen T-DSL Zwangstrennung durch die Telekom nahe (adsl.log). Und siehe da: ja, passt. Im vorliegenden Beispiel steht die T-DSL-Zwangstrennung im direkten Zusammenhang mit den Kernel Crashes… 🙁

X Edge: Zeitgesteuerter Reboot

Comment

Ab der Softwareversion X Edge v10.1 gibt es die Möglichkeit, bei den Modellen X10e, X20e und X55e einen zeitgesteuerten Reboot zu hinterlegen – um so z.B. der 24-stündigen PPPoE Zwangstrennung bei T-DSL zu entgehen und stattdessen lieber zu einer festen Uhrzeit (z.B. jeden Morgen um 05:00 Uhr) die X Edge neu zu booten und dadurch eventuell vorhandene VPN-Tunnel kontrolliert neu aufbauen zu lassen. Dadurch kann besser verhindert werden, dass VPN-Tunnel und damit Verbindungen zu den Servern am anderen Ende des VPN-Tunnels während der normalen Arbeitszeit unterbrochen werden: Menüpunkt Administration (direkt auf “Administration” klicken!). Hierzu müssen natürlich auch NTP-Server konfiguriert sein, damit das Gerät “weiß”, wie spät es ist (in der GUI direkt darunter).