![\"\"](\"http:\/\/1.bp.blogspot.com\/-rKWrJCJkHTU\/Tjk9CjC779I\/AAAAAAAAAN4\/uijsie3HzhY\/s1600\/Multi-WAN-Failover.JPG\")
<\/a><\/p>\nDie angezeigte Reihenfolge der Interfaces entspricht auch dem tats\u00e4chlichen Verhalten der WatchGuard Firebox f\u00fcr ausgehende Verbindungen: sofern keine PBR-Regel ein anderes Verhalten vorschreibt, werden die Interfaces gem\u00e4\u00df dieser Liste von oben nach unten bedient. Will hei\u00dfen: Wenn das ganz oben aufgef\u00fchrte Interface “ACTIVE” ist, dann wird auch genau dieses per Default bedient, ansonsten wird das n\u00e4chste Interface in der Liste verwendet…<\/p>\n
Wie erkennt nun die WatchGuard, ob ein Interface “ACTIVE” ist oder nicht? Auch dies wird \u00fcber die Registerkarte Multi-WAN gesteuert:<\/p>\n
F\u00fcr jedes der am Multi-WAN Verhalten beteiligten Interfaces muss nun definiert werden, woran die WatchGuard die Verf\u00fcgbarkeit des Interfaces festmachen soll. Das Default-Verhalten ist in der roten Markierung und den darunter aufgef\u00fchrten Settings beschrieben. Demzufolge pingt die Firebox alle 15 Sekunden eine IP-Adresse an (standardm\u00e4\u00dfig 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.<\/p>\n Daraus ergeben sich zwei Problematiken:<\/p>\n <\/p>\n Es ist nun also erkennbar, dass man sich im Multi-WAN-Umfeld von der Verf\u00fcgbarkeit von externen Systemen abh\u00e4ngig macht, auf die man selbst keinen Einfluss hat! Ich verwende hier meist “bekannte” IP-Adressen, die in sich oft hochverf\u00fcgbar 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\u00e4ngig lautet meine Empfehlung generell:Verwenden Sie hier nach R\u00fccksprache mit Ihrem Leitungs-Provider eine IP-Adresse im Backbone Ihres Providers, die nachweislich hochverf\u00fcgbar ausgelegt ist – und die sich nicht in absehbarer Zeit \u00e4ndern wird!<\/p>\n (Mit der 141.1.1.1 hatte ich letzte Woche z.B. Probleme, weil die Betreiber wohl irgendwelche Wartungsarbeiten auf dem System durchgef\u00fchrt haben, und die IP eine Zeitlang nicht erreichbar war – mit den Konsequenzen, die man sich sicher gem\u00e4\u00df o.g. ausmalen kann… War zum Gl\u00fcck an einem Wochenende…)<\/p>\n Nachdem nun die Voraussetzungen f\u00fcr das korrekte Funktionieren von mehreren Interfaces im Multi-WAN-Umfeld gegeben sind, kann man an das Konfigurieren der tats\u00e4chlichen PBR (Policy Based Routing) Firewall-Regeln herangehen.<\/p>\n Die Voraussetzung f\u00fcr die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface f\u00fcr den Multi-WAN-Betrieb (vgl. z.B.http:\/\/de.watchguard-blog.com\/2011\/08\/multi-wan-und-policy-based-routing.html<\/a>). Sinn macht an dieser Stelle nat\u00fcrlich – speziell f\u00fcr ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interfaceauszuw\u00e4hlen (im Beispiel das Interface “VDSL50” anstelle der defaultm\u00e4\u00dfigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende<\/u>HTTP\/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic \u00fcber das “zweite” externe Interface gef\u00fchrt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite f\u00fcr die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.<\/p>\n","protected":false},"excerpt":{"rendered":" Wenn auf einer WatchGuard die Zusatz-Option “Fireware Pro” bzw. “XTM Pro” aktiviert ist, k\u00f6nnen bis zu vier Interfaces als External Interface konfiguriert werden. Hier k\u00f6nnen jeweils unterschiedliche Internet-Anschl\u00fcsse angebunden werden. Ein typisches Anwendungs-Szenario sieht so aus: Kunde x hat eine Standleitung mit x Mbit Bandbreite, die bisweilen \u00fcberlastet ist, weil “zu viel” HTTP\/HTTPS-Traffic (Eigennutzung, sprich Surfen und Downloads) die Leitung “dicht” macht und zu wenig … Weiterlesen Multi-WAN und Policy Based Routing<\/span> <\/a><\/p>\n\n
\n
\n
\nAnschlie\u00dfend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und \u00fcber die dort erscheinenden, eigentlich selbsterkl\u00e4renden erweiterten Einstellungen l\u00e4sst sich das gew\u00fcnschte Verhalten im Multi-WAN-Umfeld bestimmen:<\/p>\n<\/a><\/p>\n