OpenVPN-Client hinter DS-Lite-Anschluss

Guten Morgen allerseits,

darf ich eure Synapsen mit einem VPN-Problem belasten?

Ich betreibe eine Opnsense mit einem openvpn-Server darauf. Das läuft problemlos.
Auf den Windows-Clients läuft OpenVPN-Connect ('Roadwarrior'-Setup) und auf MXLinux-Clients tut das der NetworkManager.
Nur in einer Aussenstelle kämpfe ich mit einem DS-Lite-Anschluss. Dort kann ich ein Windows-Notebook betreiben und das VPN funktioniert. Aber dort steht ein Linux-Rechner. Dieser Rechner, der an einem anderen Ort alles tut (ja, hin und her getragen), was er soll, baut hinter dem DS-Lite-Anschluss (Fritte) zwar eine Verbindung auf, aber die Daten fließen nicht in beide Richtungen. Download geht, Upload nicht. Versucht man, eine Datei hochzuladen, wird auf dem Dateiserver in der Zentrale die Datei zwar angelegt, aber es bleibt bei 0 Byte Größe und dann TimeOut.

MTU heruntersetzen hat nichts gebracht.
IPv6-Einstellungen im NetworkManager-VPN stehen auf Automatik (DHCP).
OpnSense wird nur mit IPv4 betrieben.

Wie gesagt:

derselbe Linux-PC an einem anderem Anschluss funktioniert, ohne Änderungen an der Konfig.
Anderer Rechner (Win+Ovpn-Connect) an dem DS-Lite-Anschluss funktioniert auch.

Nun frage ich mich, was ich am Network-Manager noch ändern kann, damit das Ding mit DS-Lite klar kommt.
Besser gesagt: ich frage euch.

Details, wie Logfiles kann ich leider erst liefern, wenn ich wieder vor Ort bin bzw. Fernzugriff bekomme.

Vielen Dank einstweilen

KalleVirsh

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 669760

Url: https://administrator.de/forum/openvpn-client-hinter-ds-lite-anschluss-669760.html

Ausgedruckt am: 27.12.2024 um 03:12 Uhr

8 Kommentare

Neuester Kommentar

Ich betreibe eine Opnsense mit einem openvpn-Server darauf.

Ein bisschen antik und in die Jahre gekommen, da nicht Multithreading fähig und grottenschlechter VPN Durchsatz. Warum entscheidet man sich für sowas wenn man überall die in jedem Betriebssystem und Smartphone enthaltenen und deutlich besseren onboard VPNs benutzen kann, die viel sicherer und deutlich performanter sind?!
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Wenn man der Meining ist das es unbedingt ein VPN mit dem Zwang eines zusätzlichen VPN Clients sein muss, dann gäge es auch mit Wireguard noch eine andere moderne Alternative.
Beide können mit IPv6 (DS-Lite) deutlich besser umgehen.
Egal. Andere Baustelle und zurück zum Thema...

Nur in einer Aussenstelle kämpfe ich mit einem DS-Lite-Anschluss.

DS-Lite ist an den Außenstellen generell kein Problem solange diese Standorte der VPN Initiator (Client) sind. Also die VPN Seite die als Client aktiv die VPN Verbindung initiiert. Damit kann man problemlos das zentrale CG-NAT des Providers überwinden und bekommt auch einen funktionierenden Tunnel. Das der VPN Responder (Server) wie in deinem Falle die Firewall dann an einen normalen, öffentlichen IPv4 oder Dual Stack Anschluss arbeiten muss ist klar.

Da der Rechner an anderen Standorten funktioniert zeigt das per se sehr wahrscheinlich nichts falsch konfiguriert ist. Final kann man das aber leider nicht sagen da, die entsprechenden Information von dir dazu fehlen. Die Konfig der Server und Client Seite zu kennen wäre für eine zielführende Hilfe essentiell.
Wie sowas konfigtechnisch korrekt auszusehen hat für beide Seiten erklärt dir ein hiesiges Forentutorial und seine weiterführenden Links:
Merkzettel: VPN Installation mit OpenVPN

Ein Punkt den du leider nicht ausprobiert hast oder zu mindestens nicht geschildert hast ist der Versuch den OVPN Tunnel auf einem anderen UDP Port als dem klassischen 1194 laufen zu lassen. Viele der einfachen Provider die üblicherweise DS-Lite nutzen auf Consumer Anschlüssen filtern bzw. blocken die klassischen VPN Ports in ihrem Netz weil sie diesen Traffic teureren Business Verträgen vorbehalten.
Idealerweise setzt man also den OVPN Port testweise mal auf einen im Bereich 49152–65535 der Ephemeral Ports wie z.B. 51194 oder 61194 und checkt den Tunnelaufbau.

Leider fehlt von dir ebenso ein Verbindungs Log sowohl des VPN Clients als auch des VPN Servers was oftmals schon geneu Informationen zu möglichen Ursachen liefert. Auch das erschwert leider eine zielführende Hilfe.
Vielleicht auch eine Gelegenheit auf ein sinnvolleres VPN Protokoll zu wechseln und onboard Clients zu nutzen?!

Danke für die ausführliche Antwort.
Tatsächlich war der Durchsatz bislang kein Problem, OVPN tut es. Und darauf, dass es weniger sicher sei, als IPsec, hatte ich bislang keine Hinweise.
Den Port zu ändern wäre eine Idee, die ich noch nicht verfolgt habe, da es unter Windows ja auch mit dem Standardport funktionierte. Dürfte also nicht vom Netzbetreiber geblockt sein.

Vielleicht auch eine Gelegenheit auf ein sinnvolleres VPN Protokoll zu wechseln und onboard Clients zu nutzen?

Ja, bei Gelegenheit ... .

Und darauf, dass es weniger sicher sei, als IPsec, hatte ich bislang keine Hinweise.

Ein Angreifer kann dir jederzeit eine Kopie deines Servers unterjubeln und so alle Clients und ihren Traffic hijacken. OVPN hat im Vergleich zu IKEv2 keinerlei Absicherung dagegen.

Es gibt noch andere Nachteile. OVPN ist halt etwas in die Jahre gekommen...

da es unter Windows ja auch mit dem Standardport funktionierte. Dürfte also nicht vom Netzbetreiber geblockt sein.

Das ist in der Tat richtig. Dann helfen nur die Logs des Servers und Clients beim Verbindungsaufbau weiter. Dort sind sehr wahrscheinlich die Ursachen zu sehen.
Eine weitere mögliche Ursache wäre ggf. noch die DNS Auflösung sofern du beim VPN Server mit Hostnamen arbeitest. Der Client mit der Fehlfunktion nutzt in einem Dual Stack Netz primär immer IPv6. Wenn die DNS Auflösung des Server FQDNs eine IPv6 Adresse ergibt (oder gar keine) bzw. der Server selber nur für v4 konfiguriert ist scheitert ein Tunnelaufbau natürlich schon am DNS. Hier macht es in dem Falle dann Sinn am betroffenen Client einmal mit nslookup oder host zu prüfen ob der VPN Server FQDN bzw. ggf. DDNS Hostname korrekt auf die Ziel IPv4 aufgelöst wird.
Im Zweifel setzt man in der Client Konfig dann immer direkt die nackte IPv4 Adresse ein um einen IPv4 Tunnel zu erzwingen.
Arbeitet der Server an einem Anschluss mit einer dynamischen Provider IP ist der obige Check umso wichtiger, weil man damit dann zur Verwendung eines DDNS Hostnamens am VPN Client gezwungen ist der dann natürlich zwangsweise auf die v4 auflösen muss wenn kein v6 oder Dual Stack am VPN Server verwendet wird.
Siehe dazu auch HIER.

" ... die DNS Auflösung sofern du beim VPN Server mit Hostnamen arbeitest"

Um das zu vermeiden, habe ich Lesezeichen und Links auf dem Client mit IPs hinterlegt.

"Arbeitet der Server an einem Anschluss mit einer dynamischen Provider IP ist der obige Check umso wichtiger, weil man damit dann zur Verwendung eines DDNS Hostnamens am VPN Client gezwungen ist der dann natürlich zwangsweise auf die v4 auflösen muss wenn kein v6 oder Dual Stack am VPN Server verwendet wird."

Ja, das ist auch der Fall. Aber auch hier gilt, dass es mit Windows gut funktioniert.
Ich werde mir also bei nächster Gelegenheit die Logfiles vorknöpfen und berichten.
Besten Dank

Kalle

Moinsen,
da die Konfig ja grundlegend richtig zu sein scheint, mal so ins Blaue:
Auf dem OPNSense läuft nicht zufällig ein IDS / IPS das dir da reinpfuscht?
Habe was ähnliches mal auf der PfSense mit Snort gehabt...
VG
Buc

habe ich Lesezeichen und Links auf dem Client mit IPs hinterlegt.

Das mag verstehen wer will aber im OVPN Client bzw. dessen Konfig gibt es keine "Lesezeichen". 🤔 (Siehe o.a. OVPN Tutorial!)

Auf dem OPNSense läuft nicht zufällig ein IDS / IPS

Kann ja nicht wenn es am gleichen Standort mit einem anderen Client fehlerfrei rennt.
Ohne die Log Dateien von Server und Client und der vermeintlichen Ursache kommt man nicht weiter...
Konfig Datei des betroffenen Clients wäre ebenso hilfreich.

Auf dem OPNSense läuft nicht zufällig ein IDS / IPS das dir da reinpfuscht?

Danke, ja, läuft schon – aber wie aqui schon bemerkte: den openvpn-connect auf Win stört das ja auch nicht.
Log-Daten kommen in den nächsten Tagen. Bin gerade nicht vor Ort