Über die öffentliche IP bekomme ich ein Timeout, mit der LAN-IP geht's. Wie lässt sich das erklären? WAN Firewall-Regeln?
Ja, den Port musst du für die Tests natürlich in der Firewall öffnen. Aber es ist ein gutes Zeichen, dass er standardmäßig zu ist.
Teste niemals mit einem Stream. Da testest du TCP Parameter wie RWIN etc, aber nicht die Netzwerkperformance. Nimm mindestens 4 Streams besser 10. Macht die App der Bundesnetzagentur auch so.
Das sind jetzt Tests von dir zu Hause zur OpenSense? Oder vom Windows Server über VLAN?
Auf jeden Fall musst du gegen iperf3 auf der OpenSense testen.
Die Bandbreite von ca. 60 Mbits/sec im Mittel finde ich recht gut, zumal du ja deine Bandbreite für das VLAN auf 250 MBit/s begrenzt hast und die Verschlüsselung des VPN-Tunnels nicht vernachlässigt werden darf.
Bei der Messung ist ja kein VPN im Spiel. Und bei den Bandbreiten, über die die Geräte verfügen, ist das Ergebnis eher enttäuschend. Da packt ein Raspi2 ja mehr.
Ich meinte "-p 10".Ist auch falsch. Lies noch mal genau. Es ist "-P 10".
Ich würde einfach gerne, bevor ich einen (für mich) nicht ganz so kleinen Aufwand betreibe, sicherstellen, dass ich nicht unnötige Dinge mache.
Und deshalb tippt man kompletten Unfug in Kommandozeilen ein? Das Vorgehen erschließt sich mir nicht.
Ok, lass uns das einstellen. Es hat keinen Zweck. Du tust einfach gar nichts von dem, was man dir sagt.
iperf3.exe iperf -c ÖffentlicheIP -p 4546Was soll dieses iperf hinter dem iperf3.exe???? Was soll das da? Wer hat dir das gesagt? Wozu soll das gut sein???
Ich muss mir also über die Konsole iperf installieren?
Ja. iperf3 um präzise zu sein.
Das über das Webinterface installierte Plugin ist nicht ausreichend?
Davon rede ich seit Tagen. Das Plugin ist nicht ausreichend, da du nicht weißt, was es da eigentlich ausführt.
Mit "p -10" komme ich daher aktuell nicht weiter.
Was ist denn "p -10"? Liest du die Beiträge, die man dir schreibt? Das stand nirgendwo drin. Linux Kommandos ruft man selten auf, indem man einfach Klartext-Worte in die Befehlsoptionen schreibt.
Die letzte Frage verstehe ich nicht. Ich habe innerhalb des VLAN doch überhaupt kein Performance-Problem. Wie kann es da an einem der Clients hier liegen?
Doch, hast du. Du schreibst oben, dass du ein 1 GBit/s VLAN nutzt. Ich seh da nur 228 MBit/s zwischen Windows Server und OpenSense. Das ist katastrophal. Dafür muss es einen Grund geben, und den müssen wir finden, denn der hat mit Sicherheit Einfluss auf das Problem. Du hast allerdings auch auf die falsche IP gemessen, das hab ich ja oben schon geschrieben. Das kann schon was ausmachen, weil ggf. schon das Routing auf der Opensense reingrätscht.
Es handelt sich bei dem Client um einen Windows Server, wie man anhand der CMD Eingabe relativ gut erkennen kann.
Davon rede ich ja auch nicht. Auf der OpenSense ist entscheidend. Du sollst doch aus beiden Richtungen gegen die OpenSense messen, denn dort vermutest du doch das Nadelöhr. Deshalb ist die iperf3 Instanz auf der OpenSense entscheidend. Wenn du da gegen irgendeine Javascript oder PHP Variante von iperf misst, dann misst du die Leistungsfähigkeit des Webservers, aber nicht die des Netzwerkes. Deshalb NIEMALS iperf3 in der Weboberfläche der OpenSense starten, sondern nativ auf der Konsole in SSH.
Wenn ich auf die öffentliche IP des Servers messe, kommt die OPNsense nicht ins Spiel.
Doch natürlich. Du sollst von zu Hause auf die öffentliche IP des OpenSense Servers messen. Das ist doch ein VPS, oder? Also ein Server. Ohne VPN dazwischen. Darum geht es doch die ganze Zeit.
Die Aussagen/Herangehensweisen von euch beiden widersprechen sich.
Im Moment hast du jedenfalls uns beide nicht verstanden bei deiner Umsetzung.
Also, um es noch mal ganz deutlich zu sagen:
- du brauchst ein iperf3 nativ auf der OpenSense
- du misst von zu Hause auf die öffentliche IP der OpenSense
- du misst vom Windows Server auf die VLAN IP der Opensense
- Alle Messungen mit "-P 10" und einmal mit "-R" und einmal ohne.
Außerdem ist dein iperf Aufruf Unfug:
iperf3.exe iperf -c 192.168.133.1 -p 18871 -t 10streams -RDer müsste lauten
iperf3.exe -c <VLAN IP> -t 10 -P 10 (-R)Deine iperf Messungen sind alle unbrauchbar. Ich weiß nicht, was du mit diesem "-t 10streams" willst, aber das ist Unfug. Parallele Streams macht man mit "-P 10". Dazu bitte immer in beiden Richtungen messen (mit "-R" und ohne!).
Dazu hast du nicht - wie gefordert - gegen eine native Instanz auf dem Server getestet, sondern gegen irgendwas aus dem OpenSense Webinterface. Du hast wer-weiß-was gemessen, aber nicht die Netzwerkperformance.
Auch wichtig: Messe ohne VPN! Also auf die nativen IP-Adressen der Verbindungen. Von zu Hause aus auf die öffenltiche IP des Servers und vom VLAN Client auf die VLAN IP des Servers. Du machst die Messungen vom VLAN Client und von VPN Client auf die gleiche Ziel-IP. Das kann nicht richtig sein.
Was ist der VLAN Client für ein System? Ich beginne zu glauben, dass der eine entscheidende Rolle in den Performance Problemen spielt.
Vielleicht verhindert eine Firewall den Zugriff per Ping? Wie hast du die Firewall eingerichtet?
Der Rechner außerhalb, von dem du pingst, hat ein korrektes IPv6 Setup?
Wer weiß, wie viel Overhead das erzeugt. Die Messwerte sind ja so oder so katastrophal, man sieht nicht mal, in welche Richtung nun gemessen wurde.
Also: Ab auf die Konsole mit SSH, und dann sauber mit zwei nativen iperf3 Instanzen messen. Kein OpenSense, kein graphischer Klim-Bim oder sonstwas. Alles andere ist ein Ratespiel, aber keine Messung.
Ähh, was sind diese Screenshots? Mit iperf hat das jedenfalls nichts zu tun. Außerdem sehe ich da wg0 in der Übersicht. Das ist falsch, es geht ja darum, die Geschwindigkeit ohne VPN festzustellen. Vor allem bei der Verbindung übers VLAN kann wg0 ja keine Rolle spielen. Außerdem sind die Ergebnisse exakt gleich. Irgendwas stimmt da nicht.
iperf auf der Konsole, am besten iperf3. Mit 10 parallelen TCP Streams, und natürlich separate Messungen in beide Richtungen. Davon dann bitte das Ergebnis als Text in CODE Tags hier reinkopieren.
Ah, ok. Das hatte ich falsch verstanden.
Wie sieht denn die Netzwerkperformance zwischen Netcup OpenSense und Server aus und von der Netcup Opensense zu dir nach Hause? Am besten jeweils mit iperf messen.
Dann musst du herausfinden, welche Firewall und Routing Regeln die OpenSense aufsetzt. Macht sie NAT fürs VPN? Das braucht ja eigentlich nicht sein.
1. Woher weiß ich, ob ich die userspace oder die kernel Version bzw. wo kann ich dies ersehen?
Du hast es ja mal installiert und musstest dich dabei entscheiden. Das heißt, du solltest es am besten wissen.
Was genau meinst du mit Routing ins VLAN?
Machst du NAT Routing? Oder vollwertig? Oder bridged du die Interfaces vielleicht? Sind Filter aktiv, z.B. IP-Blacklisten und wie sind die realisiert? Halt alles rund um IP-Forwarding, IP-Tables, EP-Tables und nftables, was du so eingestellt hast. Da musst du dir ja Gedanken drüber gemacht haben, um zum einen deinen Server zu schützen und zum anderen den Zugriff auf den Windows Server zu realisieren. Unten schreibst du was von VM. Bei VMs hast du ja virtuelle Netzwerke im Host und zur VM, und das VLAN ist ja eine Netzwerkkarte auf dem Host. D.h., dein Routing muss vom Host durch die VM zum VLAN realisiert werden. Wie genau hast du das gemacht?
5. OPNsense läuft als VM auf einem VPS.
Als VM? Was kommt als Hypervisor zum Einsatz? Viele VMs lassen sich ja nicht einrichten aufgrund der fehlenden nested virtualization bei Netcup. Das kostet natürlich auch Performance.
Wenn ich mal mein Bauchgefühl rauslassen darf: Du hast das Routing Setup durch die VM verdaddelt. Dazu passt auch, dass die Performance einbricht, sobald die OpenSense im Spiel ist.
Das können wir dir alles nicht sagen, ohne Hintergrundinformationen über deinen Aufbau. Deshalb würde ich empfehlen, du beantwortest die offenen Fragen von oben, dann sehen wir weiter.
Vom Bauchgefühl her hätte ich das Problem eher in der vorgefertigten OpenVPN Distri gesucht. Solche Distris setzen gern auf NAT für den VPN Zugang, damit ist man mit Verbindungen von außen natürlich raus. Außerdem unterbinden sie gern die Kommunikation zwischen den VPN Clients. Für solche speziellen Setups empfehle ich immer eine manuelle Konfiguration. Und ggf. auch Wirwguard anstatt OpenVPN.
ABER:
Der Draytek Support sagt nach diversen Test-Session: das geht nicht ... mit deren L2L OpenVPN Client. Nun kann ein Draytek Router neben OVPN-AS andere L2L Verbindungen aufbauen mit diversen weiteren Protokollen (PPTP, IPsec Tunnel, L2TP with IPsec Policy, SSL Tunnel).
Warum geht es nicht? Und du schreibst, dass der Draytek neben OVPN auch andere L2L aufbauen kann. Das ist doch exakt das, was du willst.
aus Erfahrung: es gibt bei Kabel Deutschland / Vodafone Kabel seit jeher Geschwindigkeitsprobleme mit UDP VPNs
Das mag ja sein, das bestreite ich ja auch gar nicht. Man müsste halt schauen, woran es genau liegt.
Die Frage ist: Ist das wirklich ein VPN im eigentlichen Sinne, oder so ein Dienst wie NordVPN. Wenn es um NordVPN etc. geht, dann kommen halt Peering Effekte zum tragen. Ich hab gestern mal gegoogelt, und konnte keine Belege oder Threads finden, die von einem generischen Problem bei Wireguard oder OpenVPN berichteten. Von NordVPN und Konsorten allerdings viele.Für mich sieht das im Moment so aus, als ob man da mal wieder klassisch am Problem vorbei diskutiert.
Dazu gibt es einen interessanten Artikel
Ich hab jetzt gerade noch mal in einer freien Minute in den Artikel geschaut: Der meint gar nicht VPN im eigentlichen Sinne. Der redet von NordVPN und diesen komischen Proxy-Alternativen und ähnlichen Bauernfängern. Wenn es da Probleme im Kabelnetz gibt, dann hat das Millionen Gründe, aber mit Sicherheit nicht irgendwelche Signalisierungsdaten zwischen den Kabelmodems.
Je mehr ich davon lese, desto mehr regt der mich auf:
IPsec/IKEv2 wird wie SSL Datenverbindungen (Webseiten gehandhabt. Da aber auch Downloads eine hohe Datenlast erzeugen können, werden diese Daten üblicherweise bis zu einem erlaubten reservierten Maximum durchgelassen. Daher sind Beschränkungen meistens nur dann vorhanden, wenn zu viele Teilnehmer dieses Protokoll parallel verwenden oder zur selben Zeit auch Streaming von Netflix oder anderen Portalen verwenden.
Damit haben OpenVPN Nutzer gewonnen. Denn OpenVPN macht nichts anderes, als eine SSL Verbindung aufzubauen und darüber den Traffic zu tunneln. Demnach müsste VPN im Kabelnetz von allen Diensten am besten funktionieren. 
Ich könnte jetzt noch seine Beispielrechnung auseinandernehmen, die mit den 50 TV Programmen und den Management Daten usw, aber ich lasse es lieber, im Sinne meiner Gesundheit.
Vergiss alles, was du je aus diesem Artikel mitgenommen hast. Wer auch immer das geschrieben hat: Er hatte wirklich überhaupt keine Ahnung. Aber wirklich so überhaupt nicht.
Nur so am Rande, hab gerade eine Mail von Microsoft bekommen, dass sich die Microsoft 365 Business Preise erhöhen, und zwar ab sofort bereits mit der nächsten Abrechnung und um 24%. Aber mir wird angeboten, die "Automatische Verlängerung" des Abos zu beenden.
Nur im Büro oder zuhause in D (beides Kabel) ist es langsam. Egal ob Provider- oder eigenes Kabelmodem.
Ich will gar nicht ausschließen, dass es im Kabel-Internet ein Problem gibt. Aber so, wie es im Artikel beschrieben wurde, ist es einfach nur grober Unfug. Da müsste man sich genauer ansehen, was schief geht.
Außer die MTU zu verändern kann ich ja wenig machen. Hat leider nichts gebracht.
Das sehe ich komplett anders. Bei Wireguard ist die Einflussnahme zwar begrenzter, dennoch gibt es auch da Ansätze abseits der MTU. Bei OpenVPN sind die Konfigurationsmöglichkeiten schier unendlich - allein die Kombinationen aus den verschiedenen Algorithmen, Topologien und Transportprotokollen erlauben tausende Konfigurationen mit Einfluss auf die Performance.
Dazu gibt es einen interessanten Artikel
Ich hab selten einen Artikel gelesen, in dem so viele grundlegende Fehler drin sind, wie der. Beispiel:
UDP und TCP arbeiten beide auf Layer 4. Bei TCP können sich die Congestion Control der Payload und der Übertragungsebene ins Gehege kommen und sich gegenseitig beeinflussen: Das ist keinesfalls bedingungslos zu empfehlen.
Mit OpenVPN sind üblicherweise nie mehr als 350MB/s nutzbar, nur in Ausnahmen auch bis zu 400MB/s, was an der Architektur des Protokolles „OpenVPN“ selbst liegt.
Bei der Aussage kann man echt nur weglaufen. Ob und wie schnell OpenVPN nutzbar ist, hängt von vielen Faktoren ab, vor allem aber von der Rechenleistung der Endpunkte und der Geschwindigkeit der Übertragungsstrecke. Auf 2.5 GBIt/s Verbindungen lassen sich mehr als 350 oder 400 MBIt/s erreichen, auch mit OpenVPN.
Ich bin kein Netzwerkprofi, aber es könnte an UDP und Traffic Shaping seitens des Providers liegen. Die Kabelmodems kommunizieren intern über UDP Layer 3. Damit die Verwaltung des Netzwerks sichergestellt bleibt, gibt es meistens eine Drosselung der eingehenden Daten.
Davon höre ich zum ersten Mal. Ich kann es allerdings auch nicht vollständig ausschließen. Fakt ist jedenfalls, dass der Zusammenhang in dem Artikel vollkommen falsch dargestellt wird: Das ist einfach nur Bullshit. Wenn die Ursache für langsame VPN Verbindungen wirklich in der Signalisierung der Kabelmodems liegt, dann müssten die anderen Dienste wie TCP ja auch betroffen sein. Oder warum sollte man nur UDP ausbremsen, wenn jede TCP Verbindung die Modem-Signalisierung dann ausbremst? Das macht ja gar keinen Sinn. Außerdem zeigen seine Messungen über VPN gut 100 MBit/s auf einer 1 GBIt/s Verbindung: Wenn 90% der Leitung für Signalisierung draufgehen, dann geht aber irgendwas schief ...
Ganz ehrlich: Der Artikel ist vollkommen substanzlos. Das ist in dieser Form einfach nur Quatsch. Ich könnte zig weitere Argumente finden, wo Dinge in diesem Artikel einfach nachweislich falsch beschrieben werden. Deshalb glaube ich auch nicht an einen Einfluss der Signalisierung auf die UDP Datenraten. Jedenfalls nicht in der Größenordnung.
