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

Keine Mitglieder online.

Letzte Anleitungen

Statistik des Forums

Themen
4.796
Beitr├Ąge
48.630
Mitglieder
4.456
Neuestes Mitglied
Fahren
Zur├╝ck
Oben