Jul 02, 2019

10341

OpenVPN über LTE

Hallo Leute,

da ich Zuhause nur eine 16.000 Leitung habe, ich aber gerne einen VPN Zugriff in mein Netzwerk haben möchte, kam ich nun auf die Idee das ganze über LTE zu realisieren.
Schnell wurde ein GigaCube von Vodafone besorgt.

Ich habe einen kleinen Root-Server gemietet auf dem pfSense läuft. Dort ist ein openVPN Server eingerichtet.
Eingerichtet ist der Server als UDP / tap und die Clients dürfen untereinander kommunizieren.
Als Zusatz steht in jeder Config (Server/Client):
tun-mtu 1500
fragment 1300
mssfix

Im lokalen Netzwerk ist openVPN auf einer Windows Maschine installiert. Der TAP-Adapter und Ethernet sind via Netzwerkbrücke verbunden.
Dies ist nur testweise und soll durch eine weitere pfSense Instanz ersetzt werden.

Alle Geräte melden sich als Client am openVPN Server mit dem jeweiligen Benutzer an.

Route ich openVPN über den DSL Anschluss, klappt alles wunderbar. Der Ping ist vernünftig und RDP funktioniert zuverlässig.
Route ich openVPN über LTE, geht ein Teil der Ping Pakete verloren und der andere Teil kommt mit ca. 1100ms zurück.

Mein Problem scheint die VPN Verbindung über LTE zu sein. Auch wenn mein Konstrukt etwas abenteuerlich ist, funktioniert es über DSL.

Jemand eine Idee woran das liegen könnte?

Viele Grüße

Please also mark the comments that contributed to the solution of the article

Content-Key: 468153

Url: https://administrator.de/contentid/468153

Printed on: April 26, 2024 at 04:04 o'clock

20 Comments

Latest comment

Moin,

über LTE sollte eine derartige Standort Vernetzung funktionieren.
Solange wie ich über meine Backup Leitung (LTE) keine Last habe, bleibt der Ping so zwischen 70ms und 80ms.

Die Frage ist hier eben wie die Leistung und Qualität generell über LTE aussieht. Was passiert wenn du normal über die LTE Leitung nach extern pingst. Wie sehen da die Werte aus?

Gruß
Spirit

Tunnel MTU von 1500 ist Unsinn. Die muss ja durch den VPN Overhead per se schon immer kleiner sein als die LAN MTU bzw. MSS.
Dann durch falsche MTU noch die Fragmentierung zu aktivieren ist kontraproduktiv, denn das kostet erheblich Performance. Das wäre das Pferd von hinten aufzuzäumen. An den MTU Werten sollte man nicht fummeln denn OpenVPN macht das schon im Default sehr gut. Ein Blick in die Log Messages auf Client und Server würde hier Probleme offenbaren wenn man die simplen Defaults verwendet, sprich also keine extra Parameter in die Richtung.
Wenn, dann macht es nur Sinn die MSS Size zu verkleinern damit es gar nicht erst zu einer Fragmentierung im Tunnel Interface kommt. Fragmentierungen sind immer tödlich, was ja auch deine grottenschlechten Ping Zeiten beweisen.
Vermutlich machst du hier einen ziemlichen (MTU) Denkfehler ?!
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ...

LTE ist immer ein Vabanque Spiel wie schon der richtige Kommentar des Kollegen @Spirit-of-Eli sagt. Die Gesamtleistung richtet sich immer nach Anzahl der Benutzer in dieser Funkzelle. Die Provider überbuchen die Zellen massiv. Sind also eine Menge User Online geht auch die Performance in den Keller. Das sind aber im Gegensatz zur MTU/MSS immer Probleme die LTE System bedingt sind und die man nicht fixen kann bei. MTU/MSS hingegen schon...

Hallo Steffen,

auch per 16000er DSL Kann man schon ordentliche VPNs realisieren, solange man gute Hardware einsetzt, die Konfiguration nicht vermurkst (!) und der Einsatzzweck passt (klar, du wirst darüber nicht per GB-Ethernet Videos kopieren können).

Daher, geh wieder auf DSL.

VG

@Spirit-of-Eli
Der Ping über VPN wäre ein Traum.

Sorry. Das hätte ich natürlich direkt schreiben sollen.
LTE Verbindung ist spitze. Fast 200 MBit/s down, 50 MBit/s up. Grade gemessen.

@aqui
Dann lasse ich diese auf default.

@certifiedit.net
Nein. Ich habe einen upload von 1 MBit/s. Manchmal sogar weniger.
Diese Geschwindigkeit ist mit meinem Vorhaben nicht vereinbar.

Drehen wir die Sache ein bisschen.
Client im lokalen Netz über DSL.

Remote Zugriff über andere DSL Leitung: kein Problem.
Remote Zugriff über Notebook und LTE: gleiches Problem.

Diese Geschwindigkeit ist mit meinem Vorhaben nicht vereinbar.

Was ist dein Vorhaben?

Per GB-Ethernet Videos kopieren :P
Nein. Ich möchte mit einem Verwaltungsprogramm auf ein Share zugreifen.
Leider lädt das Programm Daten/Vorschauen, die ich gar nicht benötige.

Bis zum Programmstart gehen ca. 5 MB übers Netzwerk. Bei 1 MBit upload, zieht sich das ganze etwas.

Also der Cleint zu Hause hängt jetzt am DSL Anschluss.

Mit meinem Notebook sitze ich in der Stadt.

Ich nutze das integrierte LTE Modem. Damit habe ich auch Probleme.

Es scheint also ein grundsätzliches Problem mit dem openVPN Tunnel über LTE zu geben.
Nutze ich das freie WLAN, klappt die VPN Verbindung.

Hier mal das Client-Log von der Maschine mit der Netzwerkbrücke:

Tue Jul 02 11:11:28 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Tue Jul 02 11:11:28 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jul 02 11:11:28 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Tue Jul 02 11:11:29 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]999.999.999.999:1195
Tue Jul 02 11:11:29 2019 UDP link local (bound): [AF_INET][undef]:1194
Tue Jul 02 11:11:29 2019 UDP link remote: [AF_INET]999.999.999.999:1195
Tue Jul 02 11:11:29 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Jul 02 11:11:29 2019 [vpn-gateway] Peer Connection Initiated with [AF_INET]999.999.999.999:1195
Tue Jul 02 11:12:30 2019 SIGHUP[hard,] received, process restarting
Tue Jul 02 11:12:30 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Tue Jul 02 11:12:30 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jul 02 11:12:30 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Tue Jul 02 11:12:35 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]999.999.999.999:1195
Tue Jul 02 11:12:35 2019 UDP link local (bound): [AF_INET][undef]:1194
Tue Jul 02 11:12:35 2019 UDP link remote: [AF_INET]999.999.999.999:1195
Tue Jul 02 11:12:37 2019 [vpn-gateway] Peer Connection Initiated with [AF_INET]999.999.999.999:1195
Tue Jul 02 11:12:39 2019 open_tun
Tue Jul 02 11:12:39 2019 TAP-WIN32 device [Ethernet] opened: \\.\Global\{6E50187E-ED62-4E1D-9A7C-AD3A164FF35B}.tap
Tue Jul 02 11:12:44 2019 Initialization Sequence Completed

Mit openVPN über TCP geht es.
Das ist jedoch nicht sehr performant.

Per GB-Ethernet Videos kopieren :P

Über LTE wo in der Funkzelle noch tausende andere User sind..??? Träum mal weiter. Gigabit und LTE ist schon ein (Anspruchs) Widerspruch in sich. Kannst du gleich vergessen....

Mit openVPN über TCP geht es.

Das macht alles noch schlimmer wegen des TCP Overheads. OpenVPN rät selber dringend davon ab. Hier ist UDP also Pflicht !
Etwas ist auffällig oben im Log:
UDP link local (bound): [AF_INET][undef]:1194
UDP link remote: [AF_INET]999.999.999.999:1195
Die "999" hast du sicher editiert zur Anonymisierung aber was niemals klappen kann ist das Client und Server verschiedenen UDP Ports haben ! Der Wert nach dem ":" ist die Portnummer. Oder hast du die etwa auch editiert ?!

mit der Netzwerkbrücke:

Was für eine Netzwerkbrücke ??
Sowas ist immer kontraproduktiv bei einem VPN. Hier sollte man niemals bridgen sondern immer routen !!

Zitat von @aqui:

Per GB-Ethernet Videos kopieren :P

Über LTE wo in der Funkzelle noch tausende andere User sind..??? Träum mal weiter. Gigabit und LTE ist schon ein (Anspruchs) Widerspruch in sich. Kannst du gleich vergessen....

Das war eine scherzhafte Anspielung auf den Kommentar von certifiedit.net. Mein Vorhaben habe ich ja beschrieben.

Mit openVPN über TCP geht es.

Das macht alles noch schlimmer wegen des TCP Overheads. OpenVPN rät selber dringend davon ab. Hier ist UDP also Pflicht !

Das ist mir bewusst. Ich dachte es könnte helfen den Fehler einzugrenzen.

Etwas ist auffällig oben im Log: UDP link local (bound): [AF_INET][undef]:1194
UDP link remote: [AF_INET]999.999.999.999:1195
Die "999" hast du sicher editiert zur Anonymisierung aber was niemals klappen kann ist das Client und Server verschiedenen UDP Ports haben ! Der Wert nach dem ":" ist die Portnummer. Oder hast du die etwa auch editiert ?!

Genau. Die 999 sind zur Anonymisierung. Die laufen auf den gleichen Ports. Das war ein Tippfehler meinerseits.
Es funktioniert ja. Nur nicht über LTE.

mit der Netzwerkbrücke:

Was für eine Netzwerkbrücke ??
Sowas ist immer kontraproduktiv bei einem VPN. Hier sollte man niemals bridgen sondern immer routen !!

Ich sagte ja: testweise. Bis die LTE Thematik geklärt ist. Danach widme ich mich dem Routing.

Das eigentliche Problem ist UDP über LTE.
UDP von DSL zu DSL geht.

Viele Grüße

Es funktioniert ja. Nur nicht über LTE.

Viele LTE Provider mit billigen Surf Accounts filtern die Standard VPN Ports und behalten diese nur den teuren Business Accounts vor.
Du solltest einmal einen der Ephemeral Ports 49152 bis 65535 für OVPN verwenden mit UDP: https://en.wikipedia.org/wiki/Ephemeral_port
Z.B. statt 1194 mal 51194 oder 61194 nur um sicherzugehen das da im Mobilfunknetz nichts gefiltert wird.
Alternativ mal die "harte" Variante mit 22 oder 443. Das ist SSH oder HTTPS was nie gefiltert wird aber dann darfst du auf den beteiligten OVPN Rechnern keinerlei andere Dienste oder Anwendungen haben der diese IANA reservierten Ports nutzen.

Das werde ich mal versuchen.
Danke für den Hinweis.

Ich berichte

Port 49169, 80, 22 bringen leider den gleichen Fehler.

Er verbindet

Tue Jul 02 18:21:50 2019 Initialization Sequence Completed

Ich kann aber kein Gerät anpingen geschweige denn irgendwas übertragen.

Ping wird ausgeführt für 10.0.8.1 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 10.0.8.1:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Dann liegt es an der Bridge. Das der Port nicht ans Bridge Interface gebunden ist sondern an einen der physischen member Ports der Bridge.
Was anderes bleibt dann nicht mehr !

Die Bridge ging ja. Eben nicht via LTE.

Der Fehler wurde aber gefunden.

Ich habe mal schnell pfSense auf einen ESXi Server der Firma installiert. Portfreigaben eingerichtet und siehe da.
Es geht!

Den vServer hatte ich bei Hetzner. Damit geht es nicht.

Trotzdem vielen Dank für deine Hilfe

Also ist Hetzner der böse Buhmann ?? Das erklärt dann das schon komische Verhalten.

Mit hetzner läuft das richtig konfiguriert Einwand frei!

@aqui
Das habe ich nie behauptet. Hetzner ist ein klasse Laden. Die haben meiner Meinung nach, einen herausregenden Service!
Ich nutze einige vServer von denen. Alle laufen seit Jahren ohne Probleme.

Es läuft jetzt auch bei Hetzner. Allerdings auf einem Root Server.
Die Konfiguration von pfSense wurde aus dem ersten vServer exportiert, dann unter ESXi im Firmennetz getestet und läuft nun auf dem Hetzner Root Server.
Vielleicht muss beim vServer von Hetzner aufgrund der Virtualisierung, das WAN-Interface noch anders konfiguriert werden.

@Spirit-of-Eli
Wenn da Erfahrungen zur Konfiguration vorliegen, verrate sie mir doch bitte

Hatte das Problem auch mal.

Schaue mal wie deine MTU ist in dem du mit LTE auf diese Webseite gehst.
https://www.Speedguide.net/analyzer.php
Standard sind 1500.
LTE hat meist 1440
8Byte UDP Header 20Byte IPv4Header = 28Byte

Beispiel:
MTU(1440Byte) – 28Byte = Lösung(1412Byte)
Ovpn.config abändern bzw. hinzufügen.
Mssfix 1412

German solved Question Routers, Routing Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments