WAN-Failover ist leicht gemacht. Aber warum funktioniert der Fallback nicht so ganz? Und vorallem – wie kann man das lösen?

Auf den Fortigates ist es recht einfach, ein automatisches WAN-Failover zu konfigurieren, wenn man zwei ISP-Leitungen auf der Fortigate anbinden kann.

Durch die entsprechende Konfiguration der Distances und Priorities der Default Routen zu den beiden ISPs kann das Routing automatisch vom Haupt-ISP zum Backup-ISP wechseln, sobald die Anbindung zum Haupt-ISP aus irgendeinem Grund nicht mehr funktioniert. Wie das WAN-Failover konfiguriert wird, ist bestimmt geläufig. Der Vollständigkeit halber haben wir das im Anhang weiter unten noch einmal aufgeführt.

Über das so konfigurierte Failover werden Sessions automatisch auf den zweiten WAN-Link umgeleitet (oder genauer gesagt: über den zweiten WAN-Link neu aufgebaut), sobald der Haupt WAN Link nicht mehr zur Verfügung steht.

Doch was passiert, wenn der Haupt WAN-Link wieder zurück kommt? Eigentlich ganz einfach – neue Sessions werden automatisch wieder über die Haupt-Leitung ins Internet geroutet. Dieses passiert ebenfalls automatisch, ohne dass man manuell eingreifen muss.

Das Problem ist aber, dass das nur für “neue” Sessions passiert – nicht aber für bestehende Sessions. Und das bekommen z.B. viele VoIP Nutzer leidvoll zu spüren. Diese bemerken nämlich, dass die VoIP Session auch lange nachdem die Hauptleitung wieder zurück kommt, immer noch über die Backup-Leitung läuft und dieses ohne manuelles Eingreifen (also das explizite Löschen der Session auf der Fortigate oder das Rebooten des internen Telefons) auch weiterhin tun wird.

Schauen wir uns das einmal genauer an.

Solange der Haupt WAN Link in Ordnung ist, werden neue Sessions immer über diese Leitung geroutet. Beim ersten Paket einer neuen Session entscheidet die Routing Engine der Fortigate anhand Ihrer Routing Table – und solange die Haupt Default Route funktioniert (und damit als beste Route in der Routing Table existiert) wird diese auch verwendet. Danach geht’s zu den Firewall Policies, hier haben wir sicher gestellt, dass es für beide WAN Anbindungen eine entsprechende Firewall Regel gibt, so dass der Traffic erfolgreich über die Firewall geroutet wird.

Der Clou hierbei ist, dass sowohl die Routing- als auch die Policy-Entscheidung im entsprechenden Session-Eintrag der Session Table gespeichert wird. Hier ein Beispiel eines solchen Eintrags in der Session Table:

Rot markiert erkennt man die Routing- und Policy-Entscheidung.

Sobald nun die Haupt WAN Leitung ein Problem bekommt und die Default Route für diese Leitung inaktiviert wird, werden alle Sessions, die über dieses Interface geroutet werden, auf den State “dirty” gesetzt und die Routing Entscheidung wird aus der Policy gelöscht. Die States kann man ebenfalls in der Session Table sehen. In der obigen Abbildung sind diese grün umrandet. Bei dieser Session scheint noch alles in Ordnung, denn “may_dirty none” heisst hier so viel wie “es ist alles i.O.”.

Kommt nun ein weiteres Paket über eine mit “dirty” markierte Session, so weiss die Firewall, dass sie eine neue Routing- und Policy-Entscheidung treffen muss und tut dies aufgrund der aktualisierten Routing Table.

Und genau das ist unser WAN-Failover.

Aber was passiert, wenn die Haupt-Leitung nun wieder zurückkommt? Eigentlich genau das gleiche – die Session wird auf “dirty” gesetzt und beim nächsten Paket dieser Session werden neue Routing- und Policy-Entscheidungen getroffen.

Allerdings gibt es hier eine Ausnahme. Und genau diese kann uns beim WAN-Fallback Probleme machen.

Wenn auf einer Session Source NAT konfiguriert ist – und das ist bei Sessions übers WAN-Interface ja meistens der Fall – dann würde durch das Zurück-Routen auf die Haupt-Leitung die Session eine neue Source-NAT-Adresse bekommen. Und das wäre für den Server auf der anderen Seite ziemlich irritierend… Genau deshalb denkt sich die Fortigate ganz schlau: “hm, wenn die alte Route ja noch funktioniert, dann bleibe ich besser mal bei dieser Routing-Entscheidung, damit die Session beim Server im Internet keine Probleme bekommt.”.

Beim Failover war dies kein Problem, da die alte Route ja komplett weg war. Sie hat nicht mehr funktioniert und deswegen war die Fortigate zum Failover gezwungen. Beim Fallback haben wir aber oft die Situation, dass die Backup-Leitung prinzipiell noch funktioniert und deshalb bleibt sie bei allen Sessions, welche Source-NAT machen, auf der alten Route. Somit wird ein Fallback verunmöglicht.

Zum Glück nehmen wir das meistens gar nicht wahr. Wenn wir Surfen und es hakt mal irgendwo, machen wir ein Reload und es wird eine NEUE Session aufgebaut. Mit der neuen Session gibt es eine komplett neue Routing-Entscheidung und die wird dann natürlich auf die reaktivierte Haupt-Leitung gefällt.

Ein Problem haben wir aber bei lang andauernden Sessions, wie z.B. der VoIP Signalisations-Session auf UDP/5060. Auf dieser Session wird kein Fallback gemacht, solange die Backup-Leitung prinzipiell noch funktioniert und solange das interne Telefon regelmässig Daten schickt, wodurch verhindert wird, dass die Session auf der Fortigate aus-timed.

Ein Workaround ist es, diese Session händisch aus der Session Table der Fortigate zu löschen. Ohne Eintrag in der Session Table wird das nächste Paket des internen Telefons eine neue Routing-Entscheidung auslösen, die dann natürlich wieder auf die Haupt-Leitung zeigt. Alternativ kann man auch das oder die internen Telefone rebooten, so dass sie hierüber eine neue Session aufbauen.

Aber es gibt eine viel elegantere Möglichkeit, Herr über diese Situation zu werden. Ab FortiOS v5.4 gibt es einen Schalter, der das beschriebene Verhalten der Fortigate ändert:

config system global
set snat-route-change [enable/disable]
end

Per default ist der Schalter auf “disable” gestellt. Wird dieser aber auf “enable” umgelegt, so ignoriert die Fortigate das Source NAT auf den Sessions und routet Sessions unabhängig davon wieder auf die Haupt-Leitung zurück. Somit hat man ein sofortiges Fallback für alle Sessions.

Anhang:

Es gibt prinzipiell zwei Varianten, so ein WAN-Failover zu konfigurieren. Zum einen die herkömmliche Konfiguration einzelner Default Routen und entsprechender Firewall Policies über beide ausgehenden WAN-Interfaces. Zum anderen die Konfiguration des WAN Link-Load-Balancers (WAN-LLB) unter FortiOS v5.4 oder des unter v5.6 sogenannten SD-WAN (Software-Defined WAN).

WAN-Failover – Variante 1:

Da ein Teil dieser Konfiguration im CLI stattfindet, zeigen wir die gesamte Konfiguration dieser Variante im CLI.

Interfaces

Die WAN-Interfaces werden in diesem Beispiel als statische Interfaces auf Port1 und Port2 konfiguriert. Jedoch können auch ohne Probleme WAN-IF mit dynamischen IPs (PPPoE, DHCP) verwendet werden. In diesem Beispiel werden private WAN-IP-Adressen verwendet – sie sollen hier als öffentliche IP-Adressen verstanden werden. Die nachfolgende Konfiguration kann ebenso gut im WebUI gemacht werden

config system interface
  edit port1
    set mode static
    set ip 10.200.1.1 255.255.255.0
  next
  edit port2
    set mode static
    set ip 10.200.2.1 255.255.255.0
  next
end

Default Routen

Im zweiten Schritt werden die dazugehörigen Default Routen oder Default Gateways definiert. In diesen statischen Routen wird über die Distanz oder die Priorität gesteuert, welche Route bei einer neuen ausgehenden Session verwendet wird. Bei gleichen Routen (also z.B. beides mal die Destination 0.0.0.0/0) wird die Route mit der besseren (also kleineren Distanz) verwendet. Bei gleicher Distanz entscheidet die bessere Priorität (in diesem Fall auch wieder der kleinere Zahlenwert) über die Wahl der Route.

Bei der Wahl der Distanz und Priority gelten folgende Faustregeln:

• Wird immer nur eine WAN-Leitung verwendet und steht die zweite WAN-Leitung ausschliesslich als Fallback zur Verfügung, so können die beiden Default Routen mit unterschiedlichen Distanzen konfiguriert werden. Als Beispiel bekommt die Default-Route zum Haupt-ISP die Distanz 10 und die Route zum Fallback-ISP die Distanz 20.
• Wird die zweite WAN-Leitung nicht nur als Fallback für die Hauptleitung genutzt, sondern zeitgleich auch für andere Dienste (z.B. als VPN-Zugang von aussen oder über eine VIP zum Zugriff für interne Server von aussen) – sollen also beide Leitungen auf irgendeine Weise gleichzeitig genutzt werden, so sollten die Distanzen für beide Default Routen gleich sein. Über die Priorität entscheidet sich dann, welche Route für den ausgehenden Traffic gewählt wird.

In diesem Beispiel verwenden wir die ISP-Leitung auf Port2 als reine Backup-Leitung. Die nachfolgende Konfiguration kann ebenfalls im WebUI getätigt werden:

config router static
  edit 1
    set dst 0.0.0.0 0.0.0.0
    set gateway 10.200.1.254
    set device port1
    set distance 10
  next
  edit 2
    set dst 0.0.0.0 0.0.0.0
    set gateway 10.200.2.254
    set device port2
    set distance 20
  next

Link Monitors

Der Routing Prozess auf der Fortigate entscheidet hier über die Distanzen, welche der beiden Routen in die Routing Table kommt. In diesem Fall natürlich die erste Route mit der besseren Distanz. Aber natürlich spielen auch andere Faktoren eine Rolle. Wird das Kabel von Port1 zum ISP Router entfernt, so stellt die Fortigate auf Port1 einen Link-Down fest. Automatisch werden alle Routen für Port1 inaktiviert und somit ist die Default Route von Port2 die Default Route mit der besten Distanz.

Ebenso könnte es aber auch sein, dass statt einem Ausfall zwischen Fortigate und ISP Router ein Ausfall zwischen dem ISP Router und dem POP auftritt (der berüchtigte Bagger vor der Haustüre…). In diesem Fall bleibt der Link auf dem Port1 oben, trotzdem kann der Internet Zugang über diese Leitung nicht mehr hergestellt werden.

Diese Situation kann mit den sogenannten Link Monitoren (früher auch “Pingserver” genannt) überwacht werden. Nachfolgende Konfiguration kann nur im CLI gemacht werden.

config sytem link-monitor
  edit port1-monitor
    set srcintf port1
    set server x.x.x.x y.y.y.y
    set gateway-ip 10.200.1.254
    set update-static-route enable
  next
  edit port2-monitor
    set srcintf port2
    set server x.x.x.x y.y.y.y
    set gateway-ip 10.200.2.254
    set update-static-route enable
  next

x.x.x.x und y.y.y.y stellen hier die Server dar, welche über einen Ping geprüft werden. Aus Sicherheitsgründen geben wir hier immer zwei Server an, z.B. die DNS-Server des Providers. Solange einer der beiden Servern auf unseren Ping antwortet, wird die Route als passierbar angesehen. Erst wenn unsere Pings von beiden Servern nicht mehr beantwortet werden, erachtet die Fortigate das Default GW auf dem angegeben Interface als temporär nicht mehr funktionsfähig und wird alle Routen auf diesem Interface temporär deaktivieren.

Firewall Policies

Als letzter Konfigurationsschritt müssen noch die Firewall Policies konfiguriert werden. Diese müssen sowohl für Port1 als auch für Port2 konfiguriert werden, damit ausgehender Traffic erlaubt wird, egal welche Route gerade verwendet wird. Diese Konfiguration kann natürlich auch im WebUI erfolgen.

config firewall policy
  edit <n>
    set srcintf "port3"
    set dstintf "port1" "port2"
    set srcaddr "LOCAL_SUBNET"
    set dstaddr "all"
    set schedule "always"
    set service "ALL"  <-- das ist nur ein Bsp, in der Realität bitte etwas besser konfigurieren... ;-)
    set action accept
    set nat enable
  next
end

WAN-Failover – Variante 2:

Der Vorteil dieser Variante ist, dass man alle Konfigurationsschritte (auch den für das Link Monitoring) im WebUI machen kann – sofern man das als Vorteil ansehen mag. Es gibt noch weitere Vor- und Nachteile, doch wollen wir diese für diesen Artikel mal ausser acht lassen.

In dieser Variante müssen ebenfalls erst die WAN Interfaces konfiguriert werden. Für die nachfolgende Konfiguration ist es wichtig, dass auf diesen Interfaces keine weiteren Konfigurationen liegen. Die Interfaces müssen komplett “frei” sein.

Konfiguration vom WAN LLB:

Mit dieser Konfiguration wird ein sogenanntes “Equal Cost – Multiple Path” (ECMP) konfiguriert. D.h., dass beide Default GW absolut gleichwertig sind – um genau zu sein: sie haben die gleichen Distanzen und die gleichen Prioritäten. Allein der Load Balancing Algorithmus bestimmt nun, über welches Gateway eine neue Session geroutet wird. Darüber hinaus können mit den WAN LLB Rules (Menüpunkt weiter unten) weitere Regeln definiert werden, welcher ausgehende Traffic über welches Gateway geroutet wird.

Konfiguration der Default Route

Da das WAN LLB Interface als ein logisches IF angesehen wird, muss auch nur noch eine Default Route konfiguriert werden. Da die IP des Default GW aber vom physikalischen WAN Link abhängt, werden diese schon bei der Konfiguration des WAN LLBs angegeben und nicht hier in der Route.

Konfiguration der WAN Status Checks

Diese Konfiguration entspricht der Konfiguration der Link Monitors aus der vorherigen Variante.

Konfiguration der Firewall Policy

Da das WAN LLB Interface als ein logisches Interface angesehen wird, muss auch nur eine Policy Rule für den ausgehenden Traffic erstellt werden.

Auch hier gilt wieder – das ist nur eine Beispiel-Rule – in der Realität bitten wir um eine bessere Konfiguration der Rules… 😉