VPN Abbrüche nach Update auf 2.6.0?
-
Hi *,
ich habe seit einiger Zeit Abbrüche von VPN-Verbindungen, bin mir aber nicht sicher, ob die Ursache beim Update auf 2.6.0 liegt oder irgendeine anderen Grund hat.
Ausgangslage:
2 x Fritzbox (Cable, VDSL) -> 2 x pfSense (HA, failover) -> internes Netz- VPN: Externe Clients per Wireguard durch die o.a. Struktur auf einen internen Wireguard-Server
- VPN: pfSense als OpenVPN Client raus auf einen externen OpenVPN-Server.
Beide Wege zeigen das verhalten, dass die VPN-Verbindungen immer wieder einfach hängen bleiben, d.h. kein Traffic durchgeht. Bei Wireguard ist es dann so, dass man das VPN beenden und wieder starten muss, dann gehts wieder. Bei OpenVPN kommen dann tausend Fehlermeldungen, z.B. dass die TLS-Sqeuences out of sync sind. Man muss dann die pfSense restarten, ein Neustart des OpenVPN-Service reicht nicht.
Bei OpenVPN ist dazu noch zu beobachten, dass im Dashboard bei den Gateways immer "Pending" steht, auch wenn die Connection steht und sauber funktioniert - das ist definitv neu seit 2.6.0. Ich habe das OpenVPN als Gateway definiert.Hat Jemand eine Idee, ob das am Update der pfSensen liegen könnte, oder ob ich woanders suchen muss?
Die generellen Konfigurationen von Wireguard-Clients und -Server sowie von OpenVPN-Client und -Server haben sich nicht geändert.Danke und ciao.
Michael. -
- bitte mal einen grafischen netzwerkplan
- hast du das upgrade so gemacht wie empfolen?
- ich habe bei mir auch openvpn/wireguard/ipsec für fritzboxen laufen, keine probleme
- ist deine sense hardware oder eine vm?
-
@micneu said in VPN Abbrüche nach Update auf 2.6.0?:
- bitte mal einen grafischen netzwerkplan
- hast du das upgrade so gemacht wie empfolen?
Kommt drauf an, was du mit "empfohlen" meinst ;)
Wenn du https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide-ha.html meinst, dann ja.- ich habe bei mir auch openvpn/wireguard/ipsec für fritzboxen laufen, keine probleme
Ich hab das aber nicht für Fritzboxen laufen, sondern bei Wireguard auf Clients außerhalb und einem Server innerhalb, bei OpenVPN auf den pfSensen gegen einen externen Server.
Die Fritzen spielen hier keine Rolle.- ist deine sense hardware oder eine vm?
Hardware.
Und wie gesagt und im Bild zu sehen - HA.Danke und ciao.
Michael. -
@nobanzai Ist der Plan wirklich aktuell und korrekt?
Wenn ja ist das HA Konstrukt direkt schon sehr fragwürdig. Wie sind die entsprechenden Interfaces vergeben? Ich sehe hier vogelwild alle möglichen IFs zwischen Master und Backup hin und her und dazu noch ganz andere Hersteller IFs. Das liest sich nach "Backup Kiste hat andere Hardware". Wenn jetzt dazu noch die Interfaces nicht in der korrekten Reihenfolge von wan, lan, opt1, ... vergeben sind, wundert es mich leider weniger, warum das Konstrukt SEHR am Wackeln ist, denn es steht nicht umsonst in der Doku, dass 2 verschiedene HW Kisten im Cluster nicht wirklich supportet sind und Probleme machen können. Zudem kommt hinzu, dass die Interfaces auch noch in anderer Reihenfolge (igb2 ist Kabel auf Master, aber DMZ auf dem Backup) vergeben sind.
Das sieht nach einem sehr zerwürfelten Setup aus. Da würde ich dich bitten erstmal genauere Hardware Daten, Interface Daten/Listen und die Assignments zu posten sowie was im HA konfiguriert ist. Wenn da nämlich lustig "falsche Daten" vom Backup an den Master zurückgespielt werden (durch den State Sync) wundert mich nicht, dass der Cluster ständig Aussetzer hat.
Cheers
\jens -
Danke für deine Antwort zunächst.
Zu deinen Punkten:
Der Plan ist aktuell, aber irgendwie kann ich deine Hinweise auf "alle möglichen" IFs nicht nachvollziehen. Beide Router haben die gleichen IFs, nämlich igb0 bis igb3, und es sind die passenden IF-Paare zu jeweils einem VHID zusammengefasst.
Evtl. ist der Plan nur zu chaotisch gepinselt!?!
Das Ganze ist in jedem Fall seit mindestens drei Jahren voll funktionsfähig - alles, auch die HA-Features funktionieren, und es wackelt auch nix.Das Einzige, was seit kurzem eben nicht so recht klappen will, sind die VPNs.
Aber auch da kristallisiert sich heraus, dass das nix mit den pfSensen zu tun hat, sondern mit der MTU bei den Wireguard Verbindungen und bei OpenVPN mit der neuen OpenVPN-Version auf den pfSensen, die mit der älteren OpenVPN-Version auf dem externen Server irgendwie nicht so ganz klar kommt. -
@nobanzai said in VPN Abbrüche nach Update auf 2.6.0?:
Der Plan ist aktuell, aber irgendwie kann ich deine Hinweise auf "alle möglichen" IFs nicht nachvollziehen. Beide Router haben die gleichen IFs, nämlich igb0 bis igb3, und es sind die passenden IF-Paare zu jeweils einem VHID zusammengefasst.
Evtl. ist der Plan nur zu chaotisch gepinselt!?!OK dann lese ich den vielleicht auch falsch - dann vergebe man mir bitte - aber ich sehe da bei "roadrunner" als SYNC ein igb0 und bei "coyote" ein em0 was grundverschieden ist.
Zudem beim VDSL ein igb3 => igb0 (VDSL opt1) und igb2 => igb1 (CABLE opt2).
Das sieht für mich nicht gleich aus?
@nobanzai said in VPN Abbrüche nach Update auf 2.6.0?:
Das Einzige, was seit kurzem eben nicht so recht klappen will, sind die VPNs.
Die VPNs wären bei "Schluckauf" bei WANs weil CARP instabil läuft auch betroffen. Und HA Probleme können mitunter sehr unterschiedliche Ausprägungen und Wirkungen haben, daher frage ich nach :)
Cheers
-
Mea culpa - du hast natürlich recht 8-(
Das hatte ich schon wieder komplett verdrängt.-
Ich musste den zweiten Router tauschen, weil er defekt war - und es gab exakt denselben nicht mehr. Der heißt zwar genauso, aber er hat statt igb3 ein em0 IF. igb0 bis igb2 sind dadurch die IFs 2-4.
Und dadurch ist
Master <-> Backup
igb0 <-> em0
igb1 <-> igb0
igb2 <-> igb1
igb3 <-> igb2 -
Dazu passt dann auch der Plan nicht ganz, weil ich offenbar geschlampt habe 8-(
Schande über mein Haupt - und das, wo ich mir immer einbilde, so ordentlich zu sein.
Danke fürs Aufzeigen der Ungereimtheiten!
Ciao.
Michael. -
-
@nobanzai Du kein Problem, ich dachte nur ich hab da irgendwie Tomaten auf den Augen. Nach 3 Tagen durchkonfigurieren bei Kunden hätte das schon sein können ;)
Aber ja, genau solche Mapping Verschiebungen mag CARP bzw. pfsync so gar nicht, daher könnte das schon sein, dass es tatsächlich ein sync Thema ist auch wenn die Probleme vielleicht eher vom VPN kommen. Wäre auf jeden Fall anzuraten das nach Möglichkeit wieder glatt(er) zu ziehen :)
Cheers
-
@nobanzai
Ich antworte mir dann nochmals selber.
Für wireguard war weder pfSense noch die MTU das Problem, sondern ein fehlender PeristentKeepalive, der nötig ist, weil alle Geräte hinter mindestens einem NAT-Router hängen.
Für openvpn konnte ich den Grund noch immer nicht rausfinden. Das Phänomen ist, dass im Regelfall alles funmktioniert. Erst wenn man die Master-pfSense rebootet, kriegt er danach keine Verbindung mehr. Rebootet man dann nochmals beide pfSensen, dann klappt wieder alles. Ist zwar eigentlich nicht der Sinn einer HA-Lösung, aber was Anderes konnte ich bisher nicht als Lösung finden.
