117471
25.04.2018
2099
5
0
PfSense vs. LANCOM Multi-WAN optimieren
Hallo,
ich habe eine pfSsense über IKEv1 mit einem LANCOM-Router gekoppelt.
Die pfSense verfügt letztendlich über zwei Gateways, die ich zu einer Gatewaygruppe und einer Interfacegruppe zusammengefasst habe. Das Netzwerk von der pfSense dackelt auch relativ zügig der Verfügbarkeit von den Gateways hinterher (gefühlte Ausfallzeit: 1 Sekunde).
Beim IPSec-Tunnel habe ich ebenfalls die Gatewaygruppe als Default Gateway angegeben. Auch dieser läuft letztendlich "irgendwie, irgendwo, irgendwann" der Verfügbarkeit der einzelnen Gateways hinterher. Allerdings sind mir da ein paar Sachen aufgefallen:
1. Das VPN springt nur dann um, wenn ich Pakete aus dem LAN der pfSense in Richtung Tunnel schicke. Da ich i.d.R. auf der anderen Seite des Tunnels sitze, hätte ich gerne, dass es automatisch umspringt - damit ich auch dann via Tunnel zum LAN der pfSense komme, wenn der Failover gegriffen hat und auf der Gegenseite kein Netzwerkgerät eingeschaltet ist (z.B. um Wake on LAN Pakete zu schicken).
2. Wenn WAN (Tier 1) ausfällt und der Tunnel auf OPT1 (Tier 2) gesprungen ist und WAN irgendwann wieder verfügbar ist, verbleibt der Tunnel auf OPT1. Mir wäre es nur Recht, wenn der Tunnel dann wieder auf WAN zurückspringt.
Grundsätzlich habe ich das Gefühl, eine große Trägheit dadurch entsteht, dass die abgelösten Tunnel nicht zeitnah verschwinden. Es sieht z.B. so aus:
Lange Rede, kurzer Sinn: MultiWAN und Tunnel läuft und "eigentlich" ist es auch schon praktikabel, es hapert eher am Zusammenspiel.
Vielleicht hat ja der Eine oder Andere eine Idee, an welchen Schrauben (LANCOM / pfSense) man grundsätzlich drehen kann, um einen oder mehrere der o.g. Punkte zu optimieren.
Gruß,
Jörg
ich habe eine pfSsense über IKEv1 mit einem LANCOM-Router gekoppelt.
Die pfSense verfügt letztendlich über zwei Gateways, die ich zu einer Gatewaygruppe und einer Interfacegruppe zusammengefasst habe. Das Netzwerk von der pfSense dackelt auch relativ zügig der Verfügbarkeit von den Gateways hinterher (gefühlte Ausfallzeit: 1 Sekunde).
Beim IPSec-Tunnel habe ich ebenfalls die Gatewaygruppe als Default Gateway angegeben. Auch dieser läuft letztendlich "irgendwie, irgendwo, irgendwann" der Verfügbarkeit der einzelnen Gateways hinterher. Allerdings sind mir da ein paar Sachen aufgefallen:
1. Das VPN springt nur dann um, wenn ich Pakete aus dem LAN der pfSense in Richtung Tunnel schicke. Da ich i.d.R. auf der anderen Seite des Tunnels sitze, hätte ich gerne, dass es automatisch umspringt - damit ich auch dann via Tunnel zum LAN der pfSense komme, wenn der Failover gegriffen hat und auf der Gegenseite kein Netzwerkgerät eingeschaltet ist (z.B. um Wake on LAN Pakete zu schicken).
2. Wenn WAN (Tier 1) ausfällt und der Tunnel auf OPT1 (Tier 2) gesprungen ist und WAN irgendwann wieder verfügbar ist, verbleibt der Tunnel auf OPT1. Mir wäre es nur Recht, wenn der Tunnel dann wieder auf WAN zurückspringt.
Grundsätzlich habe ich das Gefühl, eine große Trägheit dadurch entsteht, dass die abgelösten Tunnel nicht zeitnah verschwinden. Es sieht z.B. so aus:
- Tunnel läuft auf WAN
- Ausfall WAN-Verbindung
- Tunnel springt auf OPT1
- auf WAN erfolgen weiterhin Verbindungsversuche (Status "Connecting"), auf OPT1 läuft der Tunnel
- wenn WAN jetzt wieder aktiv wird, dann springt er nicht auf die aktuellen Verbindungsversuche der ersten Verbindung auf, sondern versucht, eine dritte Verbindung zu etablieren - was relativ lange dauert. Anders ausgedrückt: Ich habe WAN und OPT1 auf "Connecting" und unten taucht eine dritte Verbindung als "Disconnected" auf.
Lange Rede, kurzer Sinn: MultiWAN und Tunnel läuft und "eigentlich" ist es auch schon praktikabel, es hapert eher am Zusammenspiel.
Vielleicht hat ja der Eine oder Andere eine Idee, an welchen Schrauben (LANCOM / pfSense) man grundsätzlich drehen kann, um einen oder mehrere der o.g. Punkte zu optimieren.
Gruß,
Jörg
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 372194
Url: https://administrator.de/forum/pfsense-vs-lancom-multi-wan-optimieren-372194.html
Ausgedruckt am: 05.05.2025 um 21:05 Uhr
5 Kommentare
Neuester Kommentar
Moin,
du brauchst nur den "heart beat" im Tunnel zu aktivieren. Ansonsten, führt das Scenario zu deinem beschriebenen Problem.
Ich suche gleich mal den Punkt.
// Ich habe es auf die Schnelle leider nicht gefunden, eine Alternative ist jedoch diese Thematik durch nen Schedular zu lösen, der die GWs überwacht.
Gruß
Spirit
du brauchst nur den "heart beat" im Tunnel zu aktivieren. Ansonsten, führt das Scenario zu deinem beschriebenen Problem.
Ich suche gleich mal den Punkt.
// Ich habe es auf die Schnelle leider nicht gefunden, eine Alternative ist jedoch diese Thematik durch nen Schedular zu lösen, der die GWs überwacht.
Gruß
Spirit
Hallo,
auf der pfSense habe ich irgendwo gesehen dass man da in der Ühase 2 eine IP im entfernten Netz angeben kann - die scheint damit aber nichts zu tun haben, oder?
In der Gatewaygroup monitore ich die beiden öffentlichen DNS-IPs von Quad9, das stelle ich nach Auslieferung auf die jeweiligen Provider-DNS um.
Vielleicht findest Du die Option noch? Ist wie gesagt ein pfSense vs. LANCOM Szenario (IKEv1).
Ansonsten - danke schonmal für den Suchbegriff.
Gruß,
Jörg
auf der pfSense habe ich irgendwo gesehen dass man da in der Ühase 2 eine IP im entfernten Netz angeben kann - die scheint damit aber nichts zu tun haben, oder?
In der Gatewaygroup monitore ich die beiden öffentlichen DNS-IPs von Quad9, das stelle ich nach Auslieferung auf die jeweiligen Provider-DNS um.
Vielleicht findest Du die Option noch? Ist wie gesagt ein pfSense vs. LANCOM Szenario (IKEv1).
Ansonsten - danke schonmal für den Suchbegriff.
Gruß,
Jörg
Ich kann mich morgen noch mal damit auseinander setzen. Gerade fehlt mir leider die Zeit.
Welche Version der Sense ist denn installiert?
Ist das flag "Dead Peer Detection" gesetzt?
Übergangs weise könnte die life time runter gesetzt werden. (Ist keine dauer Lösung wegen der Last durch den reauth).
Welche Version der Sense ist denn installiert?
Ist das flag "Dead Peer Detection" gesetzt?
Übergangs weise könnte die life time runter gesetzt werden. (Ist keine dauer Lösung wegen der Last durch den reauth).
Hallo,
2.4.3
Auf der pfSense (Initiator) 10 Sekunden, 5 Failures.
Auf dem LANCOM (Responder): 10 Sekunden
Gruß,
Jörg
2.4.3
Ist das flag "Dead Peer Detection" gesetzt?
Auf der pfSense (Initiator) 10 Sekunden, 5 Failures.
Auf dem LANCOM (Responder): 10 Sekunden
Gruß,
Jörg
Hallo,
Nachtrag: Ich habe das Gefühl, dass sich das Verhalten deutlich verbessert hat, nachdem ich diese Einstellung hier auf "No" gesetzt habe:
Beim letzten Test:
Während der Ausfallphase habe ich beide Tunnel gesehen, der von der Hauptleitung stand auf "Connecting...", der andere war (natürlich) "Connected".
Was ich nicht geprüft habe ist, ob während des Failovers der Tunnel von der Hauptleitung (der auf "Connecting..." stand) irgendwann verschwindet.
Ich bin ich so ehrlich zuzugeben, dass ich so gut wie gar kein Englisch kann und meine IPSec-Kenntnisse sehr übersichtlich sind.
Mit anderen Worten: Könnte das eine praktikable Lösung für eine oder mehrere der oben genannten Beobachtungen sein? Was genau habe ich damit eigentlich eingestellt?
Gruß,
Jörg
Nachtrag: Ich habe das Gefühl, dass sich das Verhalten deutlich verbessert hat, nachdem ich diese Einstellung hier auf "No" gesetzt habe:
Beim letzten Test:
- war nach Ausfall der "Hauptleitung" nach 9 Ping-Anforderungen wieder im Tunnel
- ist der Tunnel nach Wiedererscheinen der "Hauptleitung" nach ca. 2 Minuten auf diese zurückgesprungen
- ist der abgelöste Tunnel auf der Ersatzleitung unmittelbar danach verschwunden
Während der Ausfallphase habe ich beide Tunnel gesehen, der von der Hauptleitung stand auf "Connecting...", der andere war (natürlich) "Connected".
Was ich nicht geprüft habe ist, ob während des Failovers der Tunnel von der Hauptleitung (der auf "Connecting..." stand) irgendwann verschwindet.
Ich bin ich so ehrlich zuzugeben, dass ich so gut wie gar kein Englisch kann und meine IPSec-Kenntnisse sehr übersichtlich sind.
Mit anderen Worten: Könnte das eine praktikable Lösung für eine oder mehrere der oben genannten Beobachtungen sein? Was genau habe ich damit eigentlich eingestellt?
Gruß,
Jörg
