"Mark gateway down" unerwartetes Verhalten
-
Ich kann zwar dein Problem nicht direkt lösen aber etwas seltsam verhält sich das schon.
Bemerke bei meiner Vodafone Kabel Leitung aktuell ein ähnliches Verhalten.
Default Gateway ist eine FailoverGroup, Member ist Tier1 Vodafone Kabel und Tier2 VVDSL. Wird der Schwellwert bei Tier1 erreicht und ist nicht mehr verfügbar, wird auf Tier2 gewechselt. Soweit alles korrekt. Nur wenn Tier1 wieder da ist, wechselt die pfSense des öfteren NICHT zurück und noch viel schlimmer ist, Tier2 verliert die PPPoe Verbindung, welche auch nicht wieder automatisch aufgebaut wird. -
@m0nji
Hm, das hört sich aber irgendwie nach einem anderen Problem an, das meinem eher vorgelagert ist. -
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
ich verwende hier zwei pfSensen mit der neuesten Version 2.4.5-RELEASE-p1 im Multi-WAN-Betrieb.
Wieso verwendest du zwei mal pfSense?
-
@Bob-Dig
HA-Lösung, d.h. Failover mit zwei Leitungen. -
Aber beide Leitungen auf beiden Geräten aufgelegt oder? :)
-
@JeGr said in "Mark gateway down" unerwartetes Verhalten:
Aber beide Leitungen auf beiden Geräten aufgelegt oder? :)
Jepp!
-
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
@JeGr said in "Mark gateway down" unerwartetes Verhalten:
Aber beide Leitungen auf beiden Geräten aufgelegt oder? :)
Jepp!
OK ich hatte schon Puls ^^
Was den VPN Client connect nach draußen angeht klingt das merkwürdig, dass es die Verbindung zerlegt, wenn der nicht genutzte lower Tier Provider wiederkommt. Das ist aber eine Client Verbindung von einem Client (also PC) oder ein Client in der pfSense konfiguriert?
Ansonsten hilft bei sowas auch die reconnect/ping/keepalive Werte zu tunen, dann sind die mitunter so gering bzw. bauen sich neu auf, dass man das bei 1-2x gar nicht wirklich mitbekommt. Wenn da allerdings häufiger am Tag mal der eine oder der andere Provider Aussetzer haben, dann wäre es vielleicht sinnvoller da anzusetzen um da erstmal Ruhe reinzubekommen. -
@JeGr said in "Mark gateway down" unerwartetes Verhalten:
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
@JeGr said in "Mark gateway down" unerwartetes Verhalten:
Aber beide Leitungen auf beiden Geräten aufgelegt oder? :)
Jepp!
OK ich hatte schon Puls ^^
hehe :)
Was den VPN Client connect nach draußen angeht klingt das merkwürdig, dass es die Verbindung zerlegt, wenn der nicht genutzte lower Tier Provider wiederkommt. Das ist aber eine Client Verbindung von einem Client (also PC) oder ein Client in der pfSense konfiguriert?
Ne, das ist ein Client im internen Netz, der durch die pfSensen auf einen Server im Internet connected.
Ansonsten hilft bei sowas auch die reconnect/ping/keepalive Werte zu tunen, dann sind die mitunter so gering bzw. bauen sich neu auf, dass man das bei 1-2x gar nicht wirklich mitbekommt. Wenn da allerdings häufiger am Tag mal der eine oder der andere Provider Aussetzer haben, dann wäre es vielleicht sinnvoller da anzusetzen um da erstmal Ruhe reinzubekommen.
Ja, naja, das war dann auch der Grund, warum ich das Gateway down gesetzt habe.
Mit den "reconnect/ping/keepalive Werte"n meinst du die des openvpn Client?Danke.
Ciao.
Michael. -
Hab quasi Null Ahnung von dem Thema, aber würde es die Sache vielleicht einfacher machen, auf eine pfSense zu verzichten?
-
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
Mit den "reconnect/ping/keepalive Werte"n meinst du die des openvpn Client?
OK also der Client sitzt dahinter, sprich die States laufen ganz regulär wie alles andere auch via xyLAN zu WAN rüber. Dann wundert es mich noch mehr. Ja mit den Werten sind die des OVPN Clients gemeint. Die sind normalerweise recht großzügig gesetzt bis da ein "down" erkannt und ein reconnect versucht wird. Da kann man natürlich feilen. Aber eventuell liegt es einfach daran, dass der OVPN Client natürlich dann Probleme bekommt, wenn ein ISP wieder kommt und er auf den zurückfallen soll. Da OVPN ohne zusätzliche Konfig auf dem Server keine gleitende IP unterstützt (also dass sich deine IP des Clients ändern darf), wird das unweigerlich zu Aussetzern führen. Ich würde da den OVPN Client dann einfach fix auf die Leitung packen, die von Geschwindigkeit her OK und von der Zuverlässigkeit besser ist. Einfach mit ner PBR fix auf das entsprechende GW setzen (und dann eben nur die Ziel-IP/OVPN Port), dann sollte das - außer das GW geht down - fast immer funktionieren.
-
@Bob-Dig said in "Mark gateway down" unerwartetes Verhalten:
Hab quasi Null Ahnung von dem Thema, aber würde es die Sache vielleicht einfacher machen, auf eine pfSense zu verzichten?
Und wie soll mit einer pfsense HA funktionieren?
-
@JeGr said in "Mark gateway down" unerwartetes Verhalten:
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
Mit den "reconnect/ping/keepalive Werte"n meinst du die des openvpn Client?
OK also der Client sitzt dahinter, sprich die States laufen ganz regulär wie alles andere auch via xyLAN zu WAN rüber. Dann wundert es mich noch mehr. Ja mit den Werten sind die des OVPN Clients gemeint. Die sind normalerweise recht großzügig gesetzt bis da ein "down" erkannt und ein reconnect versucht wird. Da kann man natürlich feilen. Aber eventuell liegt es einfach daran, dass der OVPN Client natürlich dann Probleme bekommt, wenn ein ISP wieder kommt und er auf den zurückfallen soll.
Da genau liegt das Problem - er muss nicht zurückfallen.
Weg ist ja der secondary Tier - und er läuft über den Primary.
Warum interessiert es dann, wenn der wieder da ist, den er eh nicht nutzt? Und das auch nur, wenn der Haken für den State flush nicht gesetzt ist.Da OVPN ohne zusätzliche Konfig auf dem Server keine gleitende IP unterstützt (also dass sich deine IP des Clients ändern darf), wird das unweigerlich zu Aussetzern führen. Ich würde da den OVPN Client dann einfach fix auf die Leitung packen, die von Geschwindigkeit her OK und von der Zuverlässigkeit besser ist. Einfach mit ner PBR fix auf das entsprechende GW setzen (und dann eben nur die Ziel-IP/OVPN Port), dann sollte das - außer das GW geht down - fast immer funktionieren.
Ja, wäre ne Lösung.
Gefällt mir aber deswegen nicht, weil ich das andere Problem gerne verstehen würde. Danach kann ich auch mit einem Workaround leben, vorher nicht :) -
@nobanzai said in "Mark gateway down" unerwartetes Verhalten:
Gefällt mir aber deswegen nicht, weil ich das andere Problem gerne verstehen würde. Danach kann ich auch mit einem Workaround leben, vorher nicht :)
Verständlich :) Müsste man wirklich mal versuchen irgendwie nachzustellen, aber bislang konnte ich so ein Verhalten noch nirgends beobachten.
-
@JeGr
Wie es aussieht, hat das Umsetzen der "ping", "ping-restart" und "ping-exit" Parameter irgendwie geholfen. Bei längeren Tests damit heute ist auf jeden Fall am Ende die Verbindung bei einem Dutzend Schwenks stabil geblieben. Wir beobachten das weiter.
Leider haben wir ja auch genug Gelegenheit dazu, nachdem das Geferkel mit der KD-Leitung nun in die siebte Woche geht 8-((ping 30
ping-restart 30
ping-exit 600
