Fallback bei GW Groups ?
-
Hallo zusammen
folgende Ausgangslage:
PFsense mit 2 WAN Anschlüssen (DSL und GLAS)
Primär soll alles über den GLAS gehen - sollte der ausfallen soll alles über den DSL laufen.Ich bin daher wie folgt vorgegangen:
Externe Monitor IP´s für beide WAN Gateways
Dann eine Gateway Group angelegt:
Dann diese GW Group als Standard GW eingepflegt:
Das hat soweit funktioniert und noch bevor ich das mal testen konnte ist dann tatsächlich gestern der Glasfaser Anschluss ausgefallen.
Pfsense hat Brav auf DSL umgestellt (sowohl der normale Traffic als auch die ausgehenden VPN´s)
Nun kam heute Morgen der Glasfaser Anschluss wieder zurück.
Nun habe ich die Situation dass ein Teil des Traffics (ich kann noch nicht genau sagen welcher) über den Glasfaser Anschluss läuft und ein anderer Teil noch über den DSL Anschluss.Ist das ein normales Verhalten ? - das sich erst nach und nach auflöst oder habe ich einen Fehler in der config ?
Grüße
-
@gtrdriver Das kannst Du granular unter System-Advanced-Miscellaneous-Gateway Monitoring einstellen.
Einen Fehler sehe ich dabei nicht. Denn auch der Fail-Back muss ja Unterbrechungen erzeugen, die Du entweder in Kauf nehmen oder auf die Du lieber verzichten möchtest... -
Hallo
Ich finde unter dem von dir genannten Config Pfad nur diesen Bereich:
Übersehe ich hier irgendwas ?
Grüße
-
@gtrdriver Welche Version von pfSense nutzt Du genau? In der Plus gibt es da mehr einzustellen und ich vermute in der aktuellen CE auch.
-
Hallo ja das ist eine CE Version - ich meine 2.7.2..
-
Hallo nochmals...
wie gesagt CE Edition - und das Fallback ist tatsächlich ein Problem - ich dachte noch dass wenn die States auslaufen oder gelöst werden dann kehren alle Dienste wieder zu WAN1 (Glas) zurück aber - nein pustekuchen...
Man muss WAN2 offline schalten und in dem Moment switcht dann alles zurück ...
-
@gtrdriver
In 2.8 CE gibt es die Option "State Killing on Gateway Recovery".
Da kannst du einstellen, was du haben möchtest.Zeit für ein Uprade.
-
@gtrdriver said in Fallback bei GW Groups ?:
Nun habe ich die Situation dass ein Teil des Traffics (ich kann noch nicht genau sagen welcher) über den Glasfaser Anschluss läuft und ein anderer Teil noch über den DSL Anschluss.
Ist das ein normales Verhalten ? - das sich erst nach und nach auflöst oder habe ich einen Fehler in der config ?
Ja das ist normal. Wenn du Dienste laufen hast, die ihren State aufgebaut haben und nicht abbauen/timeouten oder irgendwie resetten, werden die auf dem DSL "kleben" bleiben. Daher gab es mit 24.03 und 24.11 dann die neuen Optionen zum Default GW Switching.
@gtrdriver said in Fallback bei GW Groups ?:
Übersehe ich hier irgendwas ?
Ja, du musst auf 2.8 updaten. Kein Grund auf alter Version zu bleiben ;)
Wichtig ist dann hier bei 2.8/24.11/25.07 der neue Part mit State Killing on Gateway Recovery (oben).
Die Einstellung Kill all states for lower-pro GWs macht genau das. DSL hat bei dir Tier 2 ist also kleinere Prio und wird dann absichtlich gekillt wenn Glas wieder da ist, damit sich die Verbindungen neu über Glas aufbauen.Der zweite Part mit GW failure drunter kann man ähnlich justieren. Nichts machen - führt ggf. zu langen timeouts wenn ein GW wegfällt. Kill states bezieht sich nur auf policy based Sachen + WAN/VPN GWs die per reply-to states erzeugt haben. Flush all ist hartes wegwerfen von allem Traffic auf einem GW, was vllt. ein bisschen hart ist ;)
Ich würde auch empfehlen wenn man mit PBR (policy based rules) arbeitet (bspw. bei VPNs) auf "Skip rules when GW down" zu setzen. Das letzte was man möchte ist, dass man eine Regel macht, die Traffic via VPN "forced" und wenn das VPN weg ist, wird der Traffic einfach ans Default GW (Internet) geschickt. Unschön. Dann lieber Regel skippen wenn das GW down ist, dann läuft auch kein versehentlicher Traffic drüber.
Cheers
-
@JeGr Hi
ERstmal danke für den tollen Hinweis - habe jetzt die Maschinen die in einer VM laufen geupdatet und ja - läuft ...
Danke auch für den Hinweis mit der neuen Funktion !In dem Zusammenhang habe ich noch eine Frage die nicht ganz dem Topic entspricht:
Auf der Seite des VPN die wir hier besprechen würde dann auf ein anderes GW geschaltet werden und die Verbindung zur Seite B kommt zustande. Soweit so gut.
Wir haben die Situation dass wir an den "seite B" PFsenses auch oft mehrer Wan´s haben. (die meisten mit Fixer IP.
Wie kann ich denn erreichen dass Seite A regulär eine Verbindung zum WAN1 auf SeiteB aufbaut und wenn WAN1 auf Seite B offline ist dann Wan2 auf Seite nimmt ?
Gibt es dafür irgendeinen Mechanismus ?
Grüße
-
@gtrdriver said in Fallback bei GW Groups ?:
Wie kann ich denn erreichen dass Seite A regulär eine Verbindung zum WAN1 auf SeiteB aufbaut und wenn WAN1 auf Seite B offline ist dann Wan2 auf Seite nimmt ?
Gibt es dafür irgendeinen Mechanismus ?
Das hängt davon ab welches VPN man nutzt. :)
1a) IPsec: schwieriger. Multiple Phasen mit gleichen Settings sind nicht parallel nutzbar. Man müsste also zwei VTI (routed) IPsecs bauen und über deren Transfernetze dann sowas wie OSPF sprechen. Früher gabs das noch mit Failover Gateways + Static Routes aber statische Routen können nicht (mehr) auf GW Gruppen aufgelegt werden da das irgendwelche seltsamen Nebeneffekte hatte. Ginge also nur entweder mit OSPF oder vielleicht dann policy based rules mit nem Failover GW über beide VTI Gateways auf beiden Seiten. Müsste man mal testweise bauen um das zu bestätigen. Aber so richtig schön nicht.
1b) IPsec: fummliger. Andere Möglichkeit statt 2 Tunnel wäre ein Tunnel, der statt gegen statische IP stattdessen gegen einen FQDN aufgebaut ist. Den kann man auf einen DynDNS Namen legen und auf Seite B dann einen Job einrichten, der bei Ausfall WAN1 die Adresse von WAN2 in den DynDNS Namen pusht. Dann baut die andere Seite bei < DNS TTL die Verbindung gegen die neue IP auf. Haben wir so tatsächlich schon mal umgesetzt. Läuft, hat aber etwas verzug, weil der DNS Push natürlich laufen muss, sonst klappts nicht. Aber wenn beides Sensen sind und da beide Seiten den Tunnel ja aufbauen können, kann es auch sein, dass dann Seite B via WAN2 initiiert und die andere Seite nur abnicken muss. Das klappt dann relativ zeitnah. Nicht sofort instant, aber in vernünftiger Zeit. Ist eben nur fummliger aufzusetzen.
-
OpenVPN: Da ist es easy was das Failover angeht. OpenVPN kann direkt mit mehreren
remotestatements konfiguriert werden, hat also Alternativwege schon eingebacken. Lediglich wenn auf Seite B WAN1 wiederkommt, gibt es kein automatisches Fallback. Dazu müsste der Tunnel kurz neugestartet werden. Das ist das einzige kleine Manko. Machen aber viele Firmen trotzdem so und monitoren einfach, mit welcher Gegenstelle verbunden ist und wenn WAN1 auf B wieder da ist wird kurz auf Seite A der Tunnelaufbau neu angestoßen. 1-2s und alles rennt wieder auf WAN1 statt 2. -
Wireguard. Wenn kein Cluster involviert ist macht WG ja eh was es will und spricht auf allen Interfaces. Wenn die Gegenseite nicht explizit auf WAN1 beschränkt ist und WAN1 ausfällt wird WG von sich aus via WAN2 weiterquatschen und sollte auf Seite A dann auch angenommen werden, weil Key/PSK und Co stimmen. Dann lernt die Seite dass sie jetzt mit WAN2 kommuniziert. Wenn WAN1 wiederkommt, switcht es ggf. sogar zurück. Sehr nett. Hat aber wie gesagt dann andere Problemchen wenn Cluster oder gezielte WAN Nutzung ins Spiel kommt.
-
Overlay VPNs. Also Tailscale, Netbird und Co. Bei denen ist es stark abängig wo der Endpunkt auf beiden Seiten läuft und wie sie konfiguriert sind. Aber da hier die Endpunkte mit der Control Plane sprechen und das primär ne ausgehende Verbindung ist, klappt die Verbindung da eigentlich immer und sollte bei Failover auch korrekt via anderen IPs sprechen. Solange die Standorte Netz haben, kommen auch die Clients raus und können ne Verbindung bauen. Je nachdem wo diese laufen kann man das dann steuern welches WAN sie nutzen.
Cheers :)
-
