OpenVPN über Unity Media Probleme
-
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?
-
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 :-)
-
Ist das ein UPD oder ein TCP Tunnel?
-
Der Server hat Standard (1500er MTU und UDP) als Parameter gesetzt.
UDP (auch die alte Config)
-
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.
-
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.
-
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. -
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.
-
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.
-
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.
-
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.
