Urplötzlich keine VPN Verbindungen (OVPN und Wireguard) möglich

[tiermutter]

Moin,

ich hab da mal wieder ein Problem:
Ich kann plötzlich keine VPN Verbindungen mehr aufbauen, weder mit OpenVPN noch mit Wireguard.
Die Verbindungen kommen allerdings bei der Sense auf der die VPN Server laufen an und die Server registrieren auch, dass eine Verbindung hergestellt werden soll.
Bei WG kann ich mangels Logs leider nicht mehr sehen, OVPN verrät mir dass der Handshake fehlschlägt. Anhand der OVPN Logs sehe ich, dass das Problem gestern um ca. 16:30 aufgetreten ist (da ein VPN Client dauerhaft verbunden ist und es seit dem nicht mehr geht).
Es wurden keinerlei Änderungen an der Sense in diesem Zeitraum vorgenommen. Es kann sein, dass ich um diesen Zeitpunkt eine LTE Verbindung mit einem Modem hergestellt habe, was schon länger an der Sense hängt (hierbei kam das LTE Gateway in der Sense "up" und dem Interface wurde eine IPv6 zugewiesen). Einen Zusammenhang damit konnte ich ausschließen, da das Deaktivieren des LTE Interface zu keiner Besserung führt.
Anhand der Logs von der Sense sehe ich, dass zu diesem Zeitpunkt ein Renewal der WAN DHCP stattgefunden hat (IP hat sich aber nicht geändert), anschließend gibt es keine Auffälligkeiten in den Logs, alle Interfaces sind up und haben entsprechende v4 und v6 Konnektivität.

Jemand eine Idee was ich jetzt mal wieder übersehe?

 

[tiermutter]

Achja:
Ein OVPN Client hängt bei mir im LAN und ist ebenfalls dauerhaft mit dem VPN verbunden (über IPv6), dieser verbindet sich tadellos mit dem VPN.
Es scheint also einen Unterschied zu machen, ob die Verbindung aus dem eigenen v6 Netz kommt oder von Außerhalb.

 

[-jody-]

Hi,

hier wäre jetzt noch die Info entscheidend, ob Du versuchst die VPN-Verbindung aus dem LAN oder von extern aufzubauen...
Grundsätzlich müssten zwar beide Varianten gehen, aber...

Wenn Du versuchst den Tunnel aus dem internen LAN aufzubauen, ist dies nicht unbedingt sinnvoll denn Du versuchst dann einen Tunnel in ein Netz zu buddeln, in dem Du schon drin bist (es gibt Firewalls die das richtig erkennen und etablieren können)
Wenn Du bspw. einen VPN-Tunnel vom Handy über LTE aufbaust, sollte es gehen.

Im Zweifelsfall hilft die gute AEG-Methode:
Ausschalten
Einschalten
Geht wieder


Es könnte auch damit zusammenhängen, dass der Verbindungsaufbau genau zu jenem Zeitpunkt erfolgte, als die WAN-Schnittstelle das DHCP_Renew durchgeführt hat, was dazu führt, dass der Handshake nicht klappen kann

 

[tiermutter]

Bin mittlerweile ein Stückchen weiter:
Ein Packet Capture hat mir verraten, dass die Anfragen korrekt über das WAN reinkommen, die Antworten hingegen werden über das LTE Interface gesendet, das klappt natürlich nicht.
Ein Blick in den Routing Table hat gezeigt, dass das LTE Interface für IPv6 als default drinsteht. Wieso auch immer, das muss passiert sein, als das LTE Interface Konnektivität hatte.
Das IPv6 Gateway von LTE ist allerdings deaktiviert, fraglich ist auch, warum das Problem bestehen bleibt, wenn das komplette LTE Interface deaktiviert ist. Mittlerweile ist auch diese ominöse default Route raus, geht trotzdem noch nicht...

 

[tiermutter]

ob Du versuchst die VPN-Verbindung aus dem LAN oder von extern aufzubauen...

Na von außen, wie ich es in der Praxis nutze

Im Zweifelsfall hilft die gute AEG-Methode:

AEG (mein Vater nannte es immer "Alles ein Gammel") hat auch nicht geholfen

als die WAN-Schnittstelle das DHCP_Renew durchgeführt hat

Der Verbindungsaufbau wird alle paar Minuten/ Sekunden neu versucht, irgendwann war also ein "guter" Zeitpunkt dabei...

 

[tiermutter]

Nächstes Update:
Scheinbar werde ich diese komische Route einfach nicht los, sie kommt irgendwie immer wieder.



Das Gateway ist allerdings deaktiviert und zusätzlich manuell als "down" gekennzeichnet...



Jemand eine Idee wo diese Route immer wieder herkommen kann? Sonst muss ich das ganze Wochenende weinen...

 

[-jody-]

Manuelles Löschen der Route hilft auch nicht?

 

[tiermutter]

Manuelles Löschen der Route hilft auch nicht?

Nein, tauchte bislang irgendwann immer wieder auf. Aktuell ist sie schon recht lange verschwunden, hilft aber auch nichts.

 

[-jody-]

Und eine Manuelle Route setzen, die den VPN-Traffic zwingend über das WAN-Interface treibt?

Sorry, muss erstmal los, schaue aber nachher nochmal rein

 

[blurrrr]

Also um es mal ganz trocken zu sagen: Wenn Du das ganze in einer active/active-Config betreiber (2 aktive WAN-Interfaces) und dort nicht priorisierst was wohin soll, wird immer das Gateway mit der momentan höheren Gewichtung genutzt. Heisst konkret:

Eingang: x.x.x.x -> WAN-IP-DSL -> Firewall
Ausgang: Firewall -> WAN-IP-LTE -> x.x.x.x (wobei x.x.x.x das Paket logischerweise verwerfen wird, weil von der IP nix angefragt wurde

Helfen würde a) auf active/passive umzuschalten (bedeutet primär DSL, fällt DSL aus, wird umgeschwenkt auf LTE), dann hätte sich die gesamte Problematik direkt erledigt (kann aber gut sein, dass durch den Schwenk der Leitung dann auch die entsprechenden Geräte nicht mehr erreichbar sind, da die Interfaces evtl. dann einfach solange deaktiviert werden), oder b) es bleibt bei active/active, da muss dann aber eine Gewichtung der Interfaces stattfinden (und wenn man es noch bunter treiben will, ebenso eine Zuordnung von bestimmten Services zu bestimmten Interfaces(WAN)).

Da ich mich nie sonderlich groß mit der pfSense beschäftigt habe, hier einfach mal ein paar Anhaltspunkte:

1) Gatewaymonitoring -> Haken bei State-Killing und Skip Rules
2) Gateway-Gruppe mit entsprechender Priorisierung der einzelnen Gateways
3) Standardgateway -> Gateway-Gruppe

Für mich sieht es derzeit so aus, als würdest Du versuchen Dich via DSL mit dem VPN zu verbinden, die Firewall sieht derzeit aber die LTE-Verbindung als aktives Gateway an und kümmert sich auch nicht darum, woher die Pakete kommen. Ergo kommst Du via DSL rein, die Antwort geht aber via LTE raus und mit dieser IP hat Dein Client eindeutig nicht gesprochen und wird die Pakete somit verwerfen (bzw. wird das der davor gelagerte Router vermutlich schon einfach tun (sofern man z.B. in einem fremden WLAN ist).

EDIT: Bzgl. TLS-Handshake (mhm, RFCs sind einfach eine GEILE Erfindung ) schau Dir mal RFC7918 an, direkt den ersten Teil, dort wird der Kommunikationsablauf beschrieben. Der Client schickt dem Server ein Paket (z.B. an die DSL-IP) und der Server antwortet entsprechend (in Deinem Fall anscheinend mit der LTE-IP, Paket wird vom Client verworfen). Somit schlägt auch ein TLS-Handshake fehl. Kann sein, muss aber nicht, nichts genaues weiss man nicht, müsste man sich dann doch eher im Detail anschauen, ist halt nur eine Vermutung

 

[tiermutter]

Gatewaygruppen sind natürlich als Failover eingerichtet (habe ich auch schon immer so, ich teste gerade ja eine zweite LTE Verbindung als Failover mit anderem Modem). Das scheint aber für IPv6 nicht ganz zu klappen, darauf wird die VPN Verbindung ja aufgebaut. Bislang hatte ich kein v6 am LTE. Fraglich ist, warum es auch nicht funktionierte nachdem die neuen LTE Gateways (v4 und v6) und das gesamte Interface deaktiviert wurden.

Letztlich hat ein nochmalige AEG geholfen, damit wären wir wieder beim Tagesthema

Ich lasse es erstmal sein mit dem neuen LTE und setze meine Sense mit der 22.1 und FBSD mit ZFS komplett neu auf, der RC1 wird heute oder morgen angekündigt denke ich.
Ich glaube meine Sense ist insgesamt etwas vermurkst, weil ich sie mal von anderer Hardware umgezogen ist...

 

[blurrrr]

Siehste, auch wieder so eine Lebensweisheit... wenn Reboot nicht hilft -> neu installieren...

 

[the other]

Moinsen,
demnächst dann in der Service Hotline:
"haben Sie ihren PC schon neuinstalliert?
Haben Sie dabei daran gedacht, auf unseren SCh§$% zu verzichten und ein vernünftiges OS zu nutzen?"