Wireguard vs. OpenVPN

Kommt für mich nicht in Frage, weil ich es nicht hinkriege :D
Da kann ich immer wieder auf jenen verweisen... 🤣

Najo, OpenVPN ist schon relativ schwergewichtig (finde ich jedenfalls), umgeht aber div. Probleme, welche z.B. IPSec hat (z.B. NAT auf beiden Seiten "vor" den VPN-Gateways, Portanpassungen, usw. weisst schon). Wireguard ist bisher angetreten mit? Achja: 1) Wir sind toll!, 2) alle anderen sind doof!, 3) RFC brauchen wir nicht!... Eines der wohl gewichtigsten Argumente "überhaupt"... wo ist Wireguard denn bei den ganzen "Schwergewichten"? Cisco? Nix von gesehen, die werden auch bei IPSec bleiben... Juniper? Jo, auf irgendeinem Werbeblättchen war mal was von "Telearbeitern" zu lesen (also Roadwarrior auch kein S2S), Sophos? Bisher keine Spur von gefunden... und ansonsten eigentlich auch nix...

Man bedenke: Nur weil irgendwer neuen Spielkram auf den Markt schmeisst, rennen nicht sofort alle drauf los (das ist der Unterschied zwischen den "Bastlern" und den "anderen"). Die "anderen" werden sich i.d.R. auch "garnicht" bewegen, solange nicht RFCs und sonstige Dokumentationen vorhanden sind + das ganze ausreichend erprobt ist (und da reden wir nicht von "Jo, lief ne Woche ganz prima...").

Aber mal davon ab: https://blog.ipfire.org/post/why-not-wireguard ... ist auch nicht alles so 1000%ig meiner Meinung nach (grade das Beispiel mit den VPN-Clients, das würde man schon auf die ein oder andere Art lösen, aber sei's drum...), gedanklich entspricht das aber auch eher meiner Haltung dazu.
 
Bei mir geht über OVPN alles durch den Tunnel, da kommt nichts dran vorbei, zumindest habe ich noch nicht mitbekommen, dass etwas über andere Wege läuft, auch DNS leakt nicht.
Ich verwende OpenVPN for Android von Arne, der ja Coremember im OVPN Projekt ist, von daher wird diese Version sicherlich nicht abgespeckt sein.
Ok, wenn das wirklich so ist, wäre das nochmals einen Versuch wert.
Ich hatte damals die offizielle OpenVPN-App in Betrieb, und diese leitete nur Web-Traffic über den Tunnel.
Ich hab das mit einen SIP-Client (VoIP) bemerkt, die Anfragen des Clients kamen beim Server immer von der IP des Mobilfunkanschlusses.
 
Warum nicht direkt via IKEv2? Wesentlich flotterer Verbindungsaufbau als via IKEv1, dazu noch on-demand (im besten Fall alles via MDM ausgerollt) und die Welt (des Admins) ist wieder ein Stückchen besser geworden 😇


Also mir persönlich wäre das jetzt neu... bzw. anders formuliert: Ist mir so noch nicht untergekommen, aber ich nutze VPN i.d.R. auch eher so, dass ich mich nicht selbst künstlich limitiere (durch irgendwelche VPN-Routing-Geschichten, die dann noch über div. andere Standorte gehen). Hat man eine entsprechende Infrastruktur, wo bestimmte Auflagen erfüllt sein "müssen", sieht das sicherlich anders aus (s. z.B. Konzernwesen), aber so .... davon ab, stehen dann auch entsprechende Bandbreiten zur Verfügung und wie kleinere Kunden halt auch nunmal so sind (verständlicherweise)... mal so 1300€/Monat für 1Gbit synchron... haben die meisten kein Bock drauf und auch bei 100Mbit bei ~400€/Monat sehen die meisten das nicht ein. Also schluckt man dann das Upload-Limit des VPN-Gateway-Standortes.

Macht also nicht so wirklich Sinn, denn was nicht durch den Tunnel "muss" (ganz ganz zwingend), das "muss" auch nicht durch den Tunnel. Anders sieht es mitunter aus, wenn Du sagst: reines Firmenhandy, nix mit irgendwas, nur Mail und ggf. eigene interne Software (oder extern via FQDN/Domain/IP) und jut.

Nur damit ich hier nicht falsch verstanden werde... Nur weil man etwas machen "kann", heisst es nicht, dass man es machen "muss" und es heisst auch noch lange nicht, dass es Dinge "besser" macht. Könnte mir beim Autofahren sicherlich auch einen Integral-Helm aufsetzen, wenn ich etwas schneller fahre, haben die Rennfahrer ja auch! Macht es irgendwas "besser" (abgesehen davon bei normalen Geschwindigkeiten einfach nur tierisch zu stören)? Klar, der Kopf ist besser geschützt... das bringt es auch total, wenn der restliche Teil des Körpers überall verstreut ist... mh...... ich weiss ja nicht, ich weiss ja nicht...

Davon ab würde so ein Routing über einen bestimmten Standort natürlich noch bedingen, dass dort auch entsprechende Mechanismen vorhanden sind. Proxy wäre z.B. so ein Thema, etc. ansonsten bringt das alles nix und ist nur reine Verschwendung von Ressourcen/Bandbreiten. Einfach "nur" ein bisschen Firewall auf Layer 3/4 macht die ganze Nummer definitiv nicht sicherer für den Client. Aber: Kommt auch immer auf die Umgebung und die Umstände an (und natürlich auf: "Ist mir alles egal, ich will das einfach so machen, basta!") ☺️
Mein Gedanke ist primär den vom Smartphone per Funkprotokoll (vor allem in fremden WLAN) versendete Traffic lässt sich mit VPN so einfach vor fremden Augen verbergen, insbesondere VoIP per SIP ist halt leider meistens immer noch unverschlüsselt.
Und den Web-Traffic des Smartphone leite ich zuhause über einen PiHole, das möchte ich auch nicht mehr missen.
 
Ich hatte damals die offizielle OpenVPN-App in Betrieb
OpenVPN for Android ist die offizielle (freie) App.
OpenVPN connect ist zwar auch offiziell, aber eigentlich für den connect Server von OVPN gedacht. Damit kann man (mittlerweile) zwar auch eigene OVPN Server nutzen, aber die "richtige" App ist das finde ich nicht.
 
Ja genau, mit der "App OpenVPN Connect - OpenVPN App von OpenVPN" konnte ich SIP-Traffic nicht durch den Tunnel routen.
 
Die App kenne ich nicht, aber prinzipiell
müsste das dort auch mit "route 0.0.0.0 0.0.0.0 vpn_gateway" in der Client Config gehen, wenn es in der app keine eigene Funktion dafür gibt. Oder es wird halt vom Server gepusht...
 
Ich bevorzuge grundsätzlich auch IPsec, da braucht man auf einem Android auch keinerlei App oder so, das kann Android von Natur aus. Aktuell hat man als FritzBox-Nutzer nur die Herausforderung, dass das aktuelle FritzOS bei IPsec nur IKEv1 macht und Android nur noch IKEv2 akzeptiert. Erst mit dem neuen FritzOS, das auch Wireguard bringt, kommt IKEv2 auf die FritzBox.
 
Moinsen,
Nutze wie @tiermutter die openvpn app für Android von Arne und bin bisher ebenfalls absolut zufrieden. Von leaks habe ich nichts bemerkt bislang.
Mit wireguard hab ich bisher null Erfahrungen gemacht. Gehört allerdings so ziemlich alles von "kann alles, kann alles besser, ohje, ich mach mir vor Begeisterung in die Hose " bis zu "ganz okay, AAAber...., geht gar nicht".
Da ich eh eher selten vpn nutze (weil ich sehr selten mobil surfen oder aufs nas zugreifen muss) und noch seltener große datenmengen darüber gehen, bin ich mit openvpn bisher insgesamt zufrieden. Es funktioniert, ist ausreichend auditiert, kann nahezu immer genutzt werden, wenn richtig konfiguriert.
Interessant find ich da schon eher die Idee hinter tailscale und zerotier.
 
So, nachdem OPNsense per default WG kmod statt Wireguard Go verwendet, habe ich nun nochmal eine weitere Testreihe gefahren... mit eher gemischten Gefühlen was das Ergebnis angeht:
1675083809818.png
Die fetten roten Zahlen sind jene, wo die Übertrgaung entgegen meinen Erwartungen mit kmod langsamer ist als mit Go.
Der kmod überzeugt im Wesentlichen nur im Upload bei großen Dateien über SMB und in theretischen Tests mit iperf oder Speedtest.
Manche Messung ist eventuell nicht 1 zu 1 mit der alten Go Messung vergleichbar, vor allem beim Smartphone ist fraglich, ob es nicht auch ander mittlerweile anderen Hardware liegen könnte. Absolute Grenze scheint jedenfalls 250 Mbit/s zu sein. Bei größeren Transfers musste ich außerdem feststellen, dass die CPU meiner Firewall zu teils über 80% ausgelastet wurde, ich erinnere mich nicht daran, dass es mit Go auch so war.
Warum kmod in vor allem den wichtigen Disziplinen derart versagt ist mir ein Rätsel. Ich werde das noch eine Zeitlang beobachten und dann entscheiden, ob ich nicht doch zu Go zurückkehre, auch wenn der Durchschnittliche Speed insgesamt doch deutlich besser ist.

Alles in allem ist die Umstellung für mich dann doch sehr enttäuschend ausgefallen.
 
So, wie hier https://forum.heimnetz.de/threads/o...ackup-und-restore-von-booteinvironments.3598/ angekündigt nun die Ergebnisse nach dem Router-Hardwaretausch.

Hier wurde ausschließlich WG mit kmod betrachtet. Von QNAP zu QNAP mit OVPN habe ich mir erspart zu testen, da ich diese Verbindung komplett neu einrichten müsste, die Ergebnisse von WG bei diesem Test fließen nicht in die Durchschnittswerte ein.

1700820973651.png

Bei Mobilfunk 5G erkennt man auch hier ständige Schwankungen die im Netz selbst begründet sind, die Werte sind daher nicht aussagekräftig.
Insgesamt kann man bei OVPN eine Verbesserung von 40-530(!) % verzeichnen. Da ich mittlerweile ein neues Mobiltelefon habe, wurden die OVPN Messungen mit dem neuen Gerät gemacht, hier ist es wahrscheinlich, dass die Ergebnisse bei diesen Tests deswegen besser sind. Dennoch zeigt sich auch bei den Tests mit demselben Rechner eine deutliche Geschwindigkeitszunahme durch die neue Router-Hardware. Am Rechner konnte OVPN nun mit WG gleichziehen, am Smartphone insbesondere im Mobilfunknetz hat aber weiterhin WG mit seinem geringeren Overhead die Nase vorn, hier könnte etwas Tuning an der MTU jedoch deutlich bessere Ergebnisse erzielen.

Neues Fazit:
Bei starker Client Hardware kann die Router-Hardware für OVPN der Flaschenhals sein, bei schwächeren Mobilfunkgeräten (bzw. durch das Netz bedingt) hat die Routerhardware kaum Auswirkungen. Auch Wireguard profitiert leicht von der neuen Hardware, doch können die dezent besseren Werte auch auf Toleranzen zurückzuführen sein.

Auf dem Smartphone werde ich vorerst bei Wireguard bleiben, auf Rechner werde ich wieder zurück auf OVPN wechseln, denn nun wo die Geschwindkeit identisch ist, mag ich WG gerne verbannen, da es mir am Rechner immer wieder Probleme mit dem Routing bereitet (keine Ahnung warum).
Da ich aber ohnehin stets beide VPNs auf den Geräten eingerichtet habe, kann ich auch spontan immer mal wechseln.

Für demnächst irgendwann nehme ich mir vor, nochmal OVPN von QNAP zu QNAP zu testen um mich auch hier neu entscheiden zu können.
Als weiteren Test nehme ich mir das MTU Tuning vor, das wird aber sicherlich noch einige Zeit dauern, ist ja schließlich eine etwas komplexere Aufgabe (die MTU muss hier entsprechend der verwendeten Internetzugänge angepasst werden, auch IPv4 und v6 machen hier Unterschiede und es muss ein brauchbarer Mittelwert gefunden werden).
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
5.688
Beiträge
55.680
Mitglieder
5.566
Neuestes Mitglied
TheEagle
Zurück
Oben