Unitymedia Speed Problem mit VPN (Technologie sogut wie egal)

[Andre86]

Hallo Zusammen,

eines vorab, ja ich habe die Suchfunktion verwendet und bin bis 10 Seiten zurückgegangen -> ohne Erfolg.
Vielleicht ist mein Problem auch einfach zu spezifisch?

Bin seit ewigen Jahren bei Unitymedia und habe zuletzt im März 2017 ein Vertragsupgrade auf 2play FLY 400 durchgeführt.
Als langjähriger Kunde habe ich natürlich auf meine IPv4 bestanden und auch immer schön behalten :zwinker:
Als Endgerät kommt eine eigene FRITZ!Box 6490 Cable zum Einsatz.

Es geht um folgendes:
Ohne VPN Verbindung habe ich den vollen Speed von durchschnittlich 430 Mbit/s down und 18 Mbit/s up.
Mit VPN Verbindung (IPSec/IKEv2, L2TP/IPSec, OpenVPN) ist der Speed nur noch bei durchschnittlich lächerlichen 32 Mbit/s down und weiterhin 18 Mbit/s up.
Dabei spielt es keine Rolle wo sich der Endpunkt befindet! Das Speed Problem besteht bei allen Endpunkten (selbst bei einem Endpunkt nur ca. 50km von mir entfernt)

Soweit so gut... Jetzt kommt der lustige Teil...
Mit der neuen WireGuard Technologie (www.wireguard.com) habe ich auf sämtlichen Endpunkten weltweit immer schön einen durchschnittlichen Speed von 150 Mbit/s down und die 18 Mbit/s up.

Also denk ich mir muss UM da die Pakete bei den älteren Technologien wohl filtern?
So hab ich mir gedacht heute mal anzurufen und nachzuhören -> Ergebnis es werde nichts gefiltert oder gar gedrosselt! Man hat mir angeboten mich von IPv4 only auf DS umzustellen.
Hab das Angebot angenommen und wurde binnen 30 Minuten von IPv4 only auf DS umgestellt...
Doch bis auf das Ergebnis wie oben beschrieben hat sich nichts getan (ja, auch nicht beim Verbindungsaufbau per nativer IPv6)

Da ich nun langsam keine Lösung mehr sehe und es leid bin für 2 Leitungen (1x UM, 1x Telekom) zu bezahlen, muss eine weg... Kündigungsfrist zu 2019 ist noch ca. 2 Wochen möglich...
Daher dachte ich, frage ich hier mal um mögliche Vorschläge was man noch so anstellen kann?!

MTU Wert ändern hat übrigens keinen Unterschied gemacht.

Getestet wurde mit folgenden Anbietern:
Perfect Privacy: sämtliche Länder
NordVPN: sämtliche Länder
ExpressVPN: sämtliche Länder (wobei es hier erstaunlicherweise ab und zu auch mal bis 85-86 Mbit/s ging)
oVPN: per Quick Connect
VyprVPN: sämtliche Länder
Mullvad: sämtliche Länder (wobei es hier erstaunlicherweise ab und zu auch mal bis 91 Mbit/s ging)
CyberGhost: sämtliche Länder (und bitte kein Vortrag über das Logging, ist mir durchaus bewusst :smile

Vultr mit vServer in DE, NL, FR, UK, US, CA
DO mit vServer in DE, NL, UK, US
Hetzner mit vServer in DE, FI
Edis mit vServer in AT, CH und SE
Und noch so ein kleinerer Anbieter mit einem vServer in RO

Und das kann es irgendwo nicht sein - denn über die Telekom Leitung gibt es bei allen Verbindungen mindestens 80/100 Mbit/s down und 25/40 Mbit/s up.

Schon mal danke!

 

[addicted]

Was für ein Gerät terminiert denn bei Dir die VPN-Verbindung?

 

[Andre86]

Zuhause:
1x Mac mit Mojave und Shimo als Client (hab aber auch schon Viscosity und Tunnelblick ausprobiert) oder Alternativ der jeweilige Client des Anbieters
1x PC mit Windows 10 und OpenVPN als Client (auch hier schon Viscosity ausprobiert) oder Alternativ auch hier der jeweilige Client des Anbieters

Angebunden sind die Geräte wahlweise per 1 Gbit/s CAT6a LAN oder WLAN-AC (beides schon durchprobiert)

Und auf der Gegenseite eben am jeweiligen Serverstandort, sozusagen grad so wie ich es brauch (für z.B. BBC iPlayer etc.)

Ist das normal, dass bei DS die IPv6 als "nativ" über www.ipv6-test.com angezeigt wird obwohl in der FRITZ!Box IPv4 als native Verbindung gewählt wurde?

Oder bezieht sich das "nativ" auf den IPv6-Typ, dass es eben eine native und keine getunnelte ist :kratz:

 

[Andreas1969]

Dann tu doch die UM Leitung weg und behalte die schnelle Telekom Leitung, darüber läuft's ja.
Der Fehler wird mal wieder, wie bei so vielen Dingen, bei UM liegen. :winken:

 

[Andre86]

Dann tu doch die UM Leitung weg und behalte die schnelle Telekom Leitung, darüber läuft's ja.
Der Fehler wird mal wieder, wie bei so vielen Dingen, bei UM liegen. :winken:

Gibts wirklich so häufig Probleme mit UM?
Bis auf diese Geschichte mit dem VPN ist mir in den letzten Jahren nicht wirklich was aufgefallen.

Außer vielleicht das Routing... ist manchmal schon etwas komisch was die sich da zurecht routen

Doch wenn UM so viele Kunden hat muss es doch noch welche geben mit ähnlichen "Problemen" oder einer Lösung...

 

[addicted]

Nativ bedeutet "nicht getunnelt". Bei DSLite beispielsweise wird IPv4 getunnelt aber IPv6 ist nativ.

Die lokalen Endgeräte scheinen potent genug. Keine Ahnung, woran es sonst liegen kann.

 

[Andre86]

Hab gerade noch mal Tests mit den einzelnen Konfigurationen von PP gemacht ohne irgendeinen Clienten dazwischen zu haben...
Es scheint so als würde IPSec/IKEv2 doch performen (native Verbindung vom Mac, kein Shimo als Client) ... OpenVPN hingegen bleibt auf der Durststrecke von 30-40 Mbit/s.

Dennoch möchte ich herausfinden was die Ursache für das Problem per OpenVPN sein soll... Nicht alle bieten für alles IPSec/IKEv2.

 

[tq1199]

Getestet wurde mit folgenden Anbietern:
Perfect Privacy: sämtliche Länder
NordVPN: sämtliche Länder
ExpressVPN: sämtliche Länder (wobei es hier erstaunlicherweise ab und zu auch mal bis 85-86 Mbit/s ging)
oVPN: per Quick Connect
VyprVPN: sämtliche Länder
Mullvad: sämtliche Länder (wobei es hier erstaunlicherweise ab und zu auch mal bis 91 Mbit/s ging)
CyberGhost: sämtliche Länder (und bitte kein Vortrag über das Logging, ist mir durchaus bewusst :smile

Versuch mal mit einem eigenen OpenVPN-Server (Dienst), statt mit diesen Anbietern.

 

[addicted]

Hat er scheinbar, tq:

Vultr mit vServer in DE, NL, FR, UK, US, CA
DO mit vServer in DE, NL, UK, US
Hetzner mit vServer in DE, FI
Edis mit vServer in AT, CH und SE
Und noch so ein kleinerer Anbieter mit einem vServer in RO

 

[tq1199]

Hat er scheinbar, tq:

Ja, ich war nicht deutlich genug in meinem Beitrag. Ich meine ohne vServer (Provider/Anbieter für vServer).
Z. B. ein geeigneter Internet-Anschluss bei einem Freund (oder gleichwertig) bei dem er einen OpenVPN-Server (temporär für die Zeitdauer des Tests) installieren kann.

 

[addicted]

Naja, aber wieso, das Testfeld ist eigentlich doch breit genug?

Ich kann die Beobachtung selbst auch bestätigen, hatte nen Plaintext-OpenVPN-Tunnel zu einer Maschine (keine VM) in Düsseldorf, da gingen bei Speedtests ~35Mbit/s drüber, mehr nicht. Mit normalen Traffic kam ich dann aber oft auf 60-80Mbit/s, das hat mir dann ausgereicht.
Trotzdem meilenweit von der iperf3-Bandbreite entfernt, da hab ich immer konstant >= 380Mbit/s gehabt.

In meiner Vorstellung liegt das irgendwie am UM-Backbone. Ist aber vermutlich nicht absichtlich gedrosselt, vermutlich eher schlecht konfiguriert/eingestellt.

 

[Andre86]

Hat er scheinbar, tq:

Ja, ich war nicht deutlich genug in meinem Beitrag. Ich meine ohne vServer (Provider/Anbieter für vServer).
Z. B. ein geeigneter Internet-Anschluss bei einem Freund (oder gleichwertig) bei dem er einen OpenVPN-Server (temporär für die Zeitdauer des Tests) installieren kann.

Was würde der Test über einen anderen Anschluss bringen? Lediglich beweisen, dass UM mit sehr hoher Wahrscheinlichkeit OpenVPN Pakete filtert?
Denn (s.o.) über WireGuard und scheinbar auch über IPSec/IKEv2 läuft es bei den genannten Anbietern (WireGuard auf den vServern, IPSec/IKEv2 bei dem Rest) ... reicht mir nur nicht :zwinker:
Und die CPU-Last sollte ja nur bei den jeweiligen Endpunkten liegen, nicht beim Gateway.

Wenn es wirklich so ist, dass noch mehr betroffen sind... warum findet man sich dann damit ab und versucht es nicht an UM zu melden :kratz:

 

[tq1199]

Was würde der Test über einen anderen Anschluss bringen?

Bei dem "anderen" Anschluss weißt Du wie dieser konfiguriert ist bzw. hast evtl. die Möglichkeit etwas zu ändern bzw. zu optimieren. So wie Du jetzt getestet hast, gibt es diese Möglichkeit nicht.

 

[Andre86]

Was würde der Test über einen anderen Anschluss bringen?

Bei dem "anderen" Anschluss weißt Du wie dieser konfiguriert ist bzw. hast evtl. die Möglichkeit etwas zu ändern bzw. zu optimieren. So wie Du jetzt getestet hast, gibt es diese Möglichkeit nicht.

Ich glaube ich kann dir gerade nicht ganz folgen?!

Die vServer sind alle komplett selbst konfiguriert und bei einem dieser Server habe ich sogar Kontakt zum Geschäftsführer des Unternehmens gehabt (welches auch gleichzeitig Betreiber des RZ ist) und bin die Sache mal mit ihm durchgegangen 2 Tage lang (hatte eigentlich andere Gründe)
Ergebnis war auch hier, dass es nicht an der Anbindung des Servers liegt (denn über die Telekom Leitung geht komplett alles durch und über UM eben nur per WireGuard im Test)

 

[tq1199]

Die vServer sind alle komplett selbst konfiguriert ...

Habe ich was bzgl. vServer geschrieben? Es geht um den Internetanschluss an dem der OpenVPN-Server betrieben wird.

 

[addicted]

tq, er hat halt die Schwierigkeit den relevanten Unterschied zwischen einem Internetanschluss und einem Rechenzentrum zu verstehen. Das geht mir auch so, ich sehe keinen Mehrwert in einem Test an irgendeiner weiteren Leitung (noch dazu mit asymmetrischer Bandbreite). Vielleicht kannst Du erläutern, wieso Du das für einen wertvollen Test hälst bzw. was Du dabei erwartest?

Andre, meine Erfahrung mit UM ist, dass es sich nicht mit vertretbarem Aufwand machen lässt, eine kompetente Person mit den Befugnissen und technischen Möglichkeiten ans Telefon tu bekommen, damit man wirklich an einer so technischen Problemstellung arbeiten könnte. Da das VPN bei mir nur für den v6-Tunnel da war, und mein Upstream lange auf 20Mbit/s beschränkt war, störte es mich nicht genug, um es zu versuchen.
Du wirst bei UM in keinem Fall einen Geschäftsführer ans Rohr bekommen (geschweige denn, dass der dann irgendeinen Schimmer hätte, wovon Du redest).

 

[why_]

Hab mir auch mal OpenVPN auf nen Server installiert, unoptimiert ist bei mir auch bei ~100 mbit/s schluss, upload kommt komplett durch

Mit ein bisschen optimieren sollte aber mehr drin sein.

 

[Andre86]

Du wirst bei UM in keinem Fall einen Geschäftsführer ans Rohr bekommen (geschweige denn, dass der dann irgendeinen Schimmer hätte, wovon Du redest).

Bereits nach meinem Umzug vor gut 2 Jahren hatte ich schon erhebliche Probleme, dass UM bei mir die Leitung ans laufen bekommen hat... Der ganze "Spaß" hat 3 Monate gekostet mit 4x vor Ort Einsatz von verschiedenen Technikern und der Klärung über eine führende Person bei UM (ob das nun ein Teamleiter war oder was auch immer sollte mir ja egal sein)

Was die Rechenzentren Geschichte angeht sehe ich keinen Mehrwert darin einen Test über eine Heimleitung zu machen wenn diese einfach nicht über genügend Bandbreite verfügt (mindestens 100 Mbit/s im FD sind da schon Voraussetzung!)
Der Unterschied in der Konfiguration der Komponenten gegenüber einer Heimkonfiguration ist mir durchaus bewusst, da ich selber gute 5 Jahre in einem Rechenzentrum gearbeitet habe und auch schon mehrere Rechenzentren von Innen gesehen habe (inkl. eigenem Housing über knapp 3 Jahre)
Da waren u.a. auch einige Namhafte aus FFM dabei :smile:

Hab mir auch mal OpenVPN auf nen Server installiert, unoptimiert ist bei mir auch bei ~100 mbit/s schluss, upload kommt komplett durch
Mit ein bisschen optimieren sollte aber mehr drin sein.

Ein reiner OpenVPN oder sowas wie Pritunl, bzw. Streisand?
Und welche Verschlüsselung? AES-256-CBC, DH2048 mit SHA-512?

So ein Ergebnis hätte ich auch gerne mit OpenVPN:

Das ist jetzt per WireGuard ... und damit wär ich dann auch zufrieden (eben alles über mindestens 80 Mbit/s)

 

[why_]

Hab mir auch mal OpenVPN auf nen Server installiert, unoptimiert ist bei mir auch bei ~100 mbit/s schluss, upload kommt komplett durch
Mit ein bisschen optimieren sollte aber mehr drin sein.

Ein reiner OpenVPN oder sowas wie Pritunl, bzw. Streisand?
Und welche Verschlüsselung? AES-256-CBC, DH2048 mit SHA-512?

So ein Ergebnis hätte ich auch gerne mit OpenVPN:

Das ist jetzt per WireGuard ... und damit wär ich dann auch zufrieden (eben alles über mindestens 80 Mbit/s)

Reines OpenVPN auf einem Debian Stable
NAT mit iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Nutze zwar AES 256 aber im GCM mode mit SHA384

 

[Andre86]

Reines OpenVPN auf einem Debian Stable
NAT mit iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Nutze zwar AES 256 aber im GCM mode mit SHA384

Danke! Dann versuch ich das nachher auch mal... Bin bisher immer mit den oben genannten Einstellungen gegangen.

Hier noch mal ein Speedtest vom gleichen Server, nur diesmal mit IPSec/IKEv2 (StrongSwan)

Wenn OpenVPN nun auch noch so performen würde wärs ein Träumchen

Wie zu Beginn beschrieben hab ich einfach das Gefühl als würden OpenVPN Pakete gefilert, nur scheinbar nicht bei jedem :kratz:
Da der aktuelle "Testserver" nur IPv4 macht kann es hier also schon mal nicht am IPv6 liegen.
Aber auch das werd ich nachher noch mal auf einem anderen Server testen.

 

[Andre86]

So ein kleines Update...

Mit OpenVPN (AES-256-GCM, SHA256 und DH2048) denk ich mir gerade so... WTF?

Jetzt versteh ich gar nichts mehr :kratz:

Gleiches Ergebnis auch per Wget aufm Mac...

Kann man per OpenVPN den Hoster austricksen was eine Bandbreitenbeschränkung angeht?
Meines Wissens nach nicht, da fest beim (in dem Fall KVM) Image in den Einstellungen hinterlegt.

Wie kann der Speedtest über 100 Mbit/s bringen wenn der vServer selbst nur mit 100 Mbit/s angebunden ist?!
Ich meine Ping und Upload sind realistisch um die Uhrzeit.

 

[addicted]

Oft ist die tatsächliche Anbindung höher, aber es wird nur der vertraglich vereinbarte Wert garantiert.
OpenVPN kann aber optional auch noch Kompression. Der Ookla-Test benutzt dafür aber imho randomisierte Daten, damit das ausgehebelt wird.

 

[tq1199]

Wie kann der Speedtest über 100 Mbit/s bringen wenn der vServer selbst nur mit 100 Mbit/s angebunden ist?!

Die Kompression kannst Du deaktivieren (comp-lzo no).
Welche Topology hast Du konfiguriert? Sind evtl. mehrere Tunnels aufgebaut worden?
Bei p2p kannst Du mit shaper die Bandbreite drosseln. Evtl. auch mit einer absichtlich "schlechten" MTU als Test, kann man Bandbreite auch drosseln.

 

[Andre86]

Oft ist die tatsächliche Anbindung höher, aber es wird nur der vertraglich vereinbarte Wert garantiert.
OpenVPN kann aber optional auch noch Kompression. Der Ookla-Test benutzt dafür aber imho randomisierte Daten, damit das ausgehebelt wird.

Bzgl. der Anbindung ist das ganze offiziell wie folgt beschrieben:

"[highlight=yellow]What is the guaranteed bandwidth of my server?
All servers are innately equipped with a 100 Mbit/s connection. If you need a fast line, you can upgrade the connectivity of your VPS to 1000 Mbit/s at an extra cost.

Is there a traffic limit for my VPS server?
We keep it simple: The first 2 TB of traffic each month are included. We reserve the right to throttle the bandwidth of individual VPS types above 2 TB.
If you need additional traffic, do contact our support team. There are at no times additional costs.[/highlight]"

Damit deute ich es so, dass die 100 Mbit/s fest sind. Denn im Webinterface gibts eine Upgrade Option auf 1 Gbit/s für 10€/Monat.

Bzgl. OpenVPN: Da ich mir schon so etwas in die Richtung gedacht habe gabs noch mal einen direkten Speedtest ohne über die Webseite zu gehen.
Dieser bestätigt jedoch das gleiche...

Die Kompression kannst Du deaktivieren (comp-lzo no).
Welche Topology hast Du konfiguriert? Sind evtl. mehrere Tunnels aufgebaut worden?
Bei p2p kannst Du mit shaper die Bandbreite drosseln. Evtl. auch mit einer absichtlich "schlechten" MTU als Test, kann man Bandbreite auch drosseln.

Die Kompression ist gar nicht aktiviert (auskommentiert in den Configs)
MTU steht auf Standardwert von 1500.

Der Aufbau sieht so aus: Mac mit Shimo/WireGuard CMD -> Router/ISP -> VPN Endpunkt -> Internet
Es besteht keine Kaskadierung. Aber ja, diese konnte ich per WireGuard schon erfolgreich testen.

Das witzige ist, dass ich selbst mit OpenConnect dieses Ergebnis erziele
IPSec/IKEv2 und WireGuard geben hingegen die korrekten Werte :kratz:

 

[tq1199]

Das witzige ist, dass ich selbst mit OpenConnect dieses Ergebnis erziele

50MB/s sind ja ca. 400 Mbit/s.
Versuch mal mit IPv4 statt mit IPv6. Z. B.:

<i>
</i>wget -4 -c --no-cache --max-redirect=0 -O /dev/null http://speedtest.belwue.net/1G