OpenVPN über Unity Media Probleme

Exordium

Hallo

Ich hoffe, der ein oder andere Unity-Media User konnte schon erfolgreich OVPN über die pfSense anwenden, bzw. dort auftauchende Probleme lösen.
Ein Arbeitskollege kann den Tunnel zwar odentlich aufbauen, aber sobald ein größeres Stück Daten übertragen werden soll, stockt es gewaltig, bzw. es passiert gar nix.
Bei einer Serverübernahme über RDP kann man zeilenweise zusehen, wie sich der Screen aufbaut. Daten kopieren geht gar nicht. Hier startet nicht mal der Transfer.
Der Server ist von den TCP/IP Parametern unverändert. D.h. Standard-MTU, kein MSSfix oder Fragment. Alle anderen Benutzer (und wir haben viele!) die über Standard-T-DSL oder LTE oder DBahn-WLAN usw. arbeiten, haben bislang noch kein Problem gemeldet. Natürlich möchte ich jetzt möglich wenig an den Einstellungen herumschrauben. Ich habe eine Test-Sense im Netz, bei der ich den VPN-Server identisch aufbauen könnte und über diesen dann versuchen den Fehler einzugrenzen.

Von daher: Wo setze ich sinnvollerweise an?

JeGr

Nur zur Verifikation: Die Richtung ist UM als Client und irgendwas anderes als Server, korrekt? Nicht die UM Leitung als Server?

Gruß

Exordium

Genau. Der Kollege möchte ab und zu von zu Hause mal in der Firma einloggen (Client). Er hat privat Unity Media (100MBit). Der Firmenanschluß (Server) hat eine 100/100MBit SDSL (Telekom).

Wir haben schon mal versucht mittels diverser Tools und Pings mit verschiedenen Paketgrößen und no-fragment gesetzt, die max Size zu ermitteln. Hier ist UM und mein T_DSL deckungsgleich (Beide haben 1472 bytes, bevor er fragmentieren müsste). Bei mir läuft das VPN völlig problemlos und mit vollem Durchsatz.

Da eine Google-Suche nach UM und OVPN Problemen zu 1000 möglichen Ursachen und min. ebenso vieler Lösungen führt, bin ich momentan etwas ratlos.

Der Server hat Standard (1500er MTU und UDP) als Parameter gesetzt.

athurdent

Falls der Kollege DS-Lite hat, kannst Du mögliche Probleme mit dem CGN (Carrier Grade NAT) bei Unitymedia ggf. mit IPv6 umgehen, also Deinen OpenVPN Server auch via IPv6 verfügbar machen. Bei der Telekom solltest Du ja v6 haben?

Exordium

Dummerweise nicht. Unser kleiner, lokaler Provider hat die Leitung selbst nur bei der Telekom angemietet, stellt aber selbst noch kein v6 zur Verfügung. Wir werden in Kürze eine zweite Leitung bei einem anderen Provider bekommen. Hier stellt man uns dann auch einen fixen v6 Block zur Verfügung. Ich werde auf meiner Testsense einen identischen OVPN Server konfigurieren, auf dem ich dann aber mit verschiedenen Parametern gefahrlos herumexperimentieren kann. Komischerweise funktioniert der "alte" OVPN Zugang über die abzulösende ipfire sehr gut. Der Server hat ein älteres Release und kleinere Paketgrößen mit Fragment/MSSFIX und so Zeug konfiguriert. Bin dummerweise nur knapp bei Zeit…. wie immer :-)

slu

Ist das ein UPD oder ein TCP Tunnel?

Exordium

@Exordium:

Der Server hat Standard (1500er MTU und UDP) als Parameter gesetzt.

UDP (auch die alte Config)

D-Kun

Hi,

Dummerweise nicht. Unser kleiner, lokaler Provider hat die Leitung selbst nur bei der Telekom angemietet, stellt aber selbst noch kein v6 zur Verfügung.

https://tunnelbroker.net/ von he.net ist ein kostenloser Service, welcher Euch einen dauerhaften 6-in-4 Tunnel für IPv6 bereitstellt. Am Anfang erhält man ein /64. /48 sind auch möglich. Tunnelendpunkte kann man sich fast nach belieben aussuchen, FRA wäre jedoch sehr naheliegend. Meine v6 Tunnel laufen seit etwa 2012 bzw. 2013 anstandslos.

Exordium

Ja, aber was hat ein v6 Tunnel jetzt direkt mit dem OVPN Problem zu tun? Ich brauche kein v6 hier in der Firma vorerst, nur weil scheinbar die private Internetverbindung eines Mitarbeiters zickt. Alle anderen Roadwarrior funktionieren ja auch. Ich benötige eine Lösung, möglichst per OVPN Parameter/Konfig.

D-Kun

Hi,

dies war lediglich ein Lösungsansatz als Option. Dann wäre es nach dem Vorschlag von "athurdent" möglich gewesen, dass sich der Mitarbeiter mittels v6-Peer zum OpenVPN-Server verbindet.

Spaßeshalber kann ein mtu test clientseitig mit den Parameter –mtu-test durchgeführt werden. Zusammen mit einem verbosity loglevel von 4
Oder Testweise könntet Ihr versuchen das Problem über eine zweite Instanz mit TCP zu reproduzieren.

Exordium

Ja, ich habe inzwischen eine Testserverinstanz laufen und werde mit dem Kollegen dann div. Client/Server Setups testen.

Notfalls habe ich später 2 unterschiedlich konfigurierte Server zur Auswahl… Standard- und für Problemkinder mit vermutlich kleinerer mtu, etc. Ist vielleicht gar nicht so verkehrt, weil man nie weiss, wie sich gerade jemand connected. Inzwischen haben viele Geräte Internet über WLAN, LTE oder DSL/Kabel Möglichkeitkeit und nicht immer passt nur die eine Konfig.

slu

Ich hatte mal über Wochen ein Problem an einem Router untersucht.

Der VPN Tunnel wurde aufgebaut und man konnte auch Dateien öffnen.
Aber wehe man hat eine SIP/RTP Verbindung durch den Tunnel aufgebaut und damit den Router mit UDP Paketen geflutet, dann war die Leitung weg.

Seither haben wir diese Optionen im OpenVPN Server/Client:
fragment 1300;
mssfix;

Problem war damals wohl das der Router von einem Angriff ausgegangen war und einfach mal die Pakete geblockt hat.

Exordium

So in etwa sind auch die Optionen des vorherigen Servers gewesen. Mal schauen was der UM-Kollege berichtet. Ich habe ihm paar verschiedene Setups zur Verfügung gestellt.

Exordium

Kurz mal der Stand der Dinge:

Die Zugabe von

link-mtu 1400

in die Client-Konfig hat das Problem scheinbar behoben.
RDP funktioniert und die Datenübertragung beim Kopieren von Files startet jetzt. Der Durchsatz scheint sich im normalen Bereich zu bewegen.

Wir testen mal noch die Testinstanz mit fragment/mssfix, so wie der alte VPN-Server von der alten ipfire konfiguriert war.

Danke erstmal für die Antworten. Wenn ich neue Erkenntnisse habe, werde ich diese hier posten.