Wireguard vs. OpenVPN

tiermutter

Well-known member
[PROLOG]
Wireguard... Wireguard?! Als würde sich die Welt plötzlich um diesen "Drahtschutz" drehen. Tja, scheint wohl so...
Wireguard ist schon länger ein heiß diskutiertes Thema, das immer heißer wird. Dieses VPN Protokoll gibt es seit 2016, als stabil kann es erst seit 2020 betrachtet werden, nachdem das Protokoll im Linux und FreeBSD Kernel Einzug fand und begann auch andere Betriebssysteme wie Windows oder Android zu erobern. Ein sehr junges Protokoll also, aber wieso der Hype um das Protokoll? Weil es neu ist und neu geil ist? Eher nicht, nein.
Ich möchte im Folgenden meine Eindrücke von dem neuen Protokoll teilen und es dem OpenVPN Protokoll gegenüberstellen, was ich bislang verwendet habe.
Als Experte für Kryptographie und VPN Techniken kann ich... Ok, das ist dezent übertrieben, ich bin auch nur ein einfacher Anwender, aber ich kann meine Beobachtungen mit euch teilen und ein oder zwei Wörter darüber hinaus verlieren :)

[THEORIE]
Anwendung
Während OpenVPN insbesondere für Roadwarrior, also die Verbindung einzelner PCs mit dem VPN, Anwendung findet, ist Wireguard auch bestens dafür geeignet ein Side to Side VPN aufzubauen, also eine Verbindung von zwei Standortnetzwerken. Letzteres habe und hatte ich aber nie imEinsatz, sodass ich mich auf die Roadwarrior beschränke, die für die meisten sicherlich auch interessanter sind.

Verschlüsselung
In OpenVPN kann man zwischen etlichen Verschlüsselungsalgorithmen (Ciphern) sowohl für den Verbindungsaufbau, als auch für die Verschlüsselung des Tunnels in unterschiedlichen Stärken wählen. Bewährt hat sich hier SHA1 - SHA256 für den Verbindungsaufbau und AES-GCM mit 128-256 bit für den Tunnel selbst. Die richtige Auswahl ist hier entscheidend, da andere Cipher, wie z.B. das ebenfalls häufig verwendete AES-CBC anfällig für bestimmte Angriffe sind. Je nachdem was verwendet wird, benötigt man auf Server- und Clientseite entsprechend starke Prozessoren, die unbedingt AES-NI beherrschen sollten, damit die Performance nicht leidet.
Wireguard hingegen bietet keine Möglichkeit andere Cipher zu verwenden und setzt hier fest auf Curve25519 für den Verbindungsaufbau und ChaCha20 (basierend auf Salsa20) für die Verschlüsselung des Tunnels. Curve25519 zeichnet sich dadurch aus, dass der Schlüsselaustausch sehr rasant erfolgt, eine Verbindung also sehr schnell aufgebaut werden kann. ChaCha20 ist ein Algorithmus der ebenso sicher ist wie z.B. AES-GCM, dafür aber auch deutlich performanter ist, insbesondere auch auf Geräten die kein AES-NI unterstützen (z.B. ARM Geräte und Smartphones). Wireguard genießt hier also zumindest in der Theorie einen Geschwindigkeitsvorteil auf entsprechenden Geräten, außerdem besteht nicht die Gefahr, dass das VPN durch Fehlkonfiguration der Verschlüsselung unsicher gemacht wird.

Verbindungsaufbau
Beide Protokolle haben gemeinsam, dass beim Verbindungsaufbau Zertifikate und/oder Schlüssel ausgetauscht werden, damit sich ein Client beim Server legitimieren kann. Bei OpenVPN kann optional zusätzlich Benutzername und Passwort verwendet werden, oder nur Benutzername und Passwort (unsicher!). Wireguard hingegen bietet keine weitere Möglichkeit das VPN abzusichern. Ein extremer Nachteil, denn jeder der Zugriff auf das Clientgerät (oder die dort hinterlegten Schlüssel) hat kann sich ohne weitere Legitimerung mit dem VPN verbinden, weshalb ich Wireguard aktuell nicht im geschäftlichen Umfeld sehe und die Verwendung nur dann empfehlen kann, wenn unlegitimierte Zugriffe bestmöglich ausgeschlossen werden können. Die Möglichkeit die Client App mit einem Passwort zu schützen gibt es zumindest bei Android und Windows derzeit nicht, das wäre schonmal ein Anfang. Als zusätzliche Sicherheitsebene ist es möglich einen Pre Shared Key (PSK) in Wireguard zu verwenden. Da ich hier keinen wirklichen Zugewinn an Sicherheit sehe verwende ich diesen nicht, Auswirkungen auf die Performance hätte dies aber nicht und würde den Verbindungsaufbau allenfalls marginal verzögern.

Allgemeines
Der Code von Wireguard wurde sehr schlank gehalten, was zum Einen für gute Performance und zum Anderen für hohe Sicherheit/ wenig Sicherheitslücken spricht, außerdem ist er im Gegensatz zu OpenVPN fest im Linux Kernel (ab v5.6) und FreeBSD (u.a.) integriert, sodass man auf darauf basierenden Geräten erneut einen Performanceschub erwarten kann. Die feste Integration in weiteren Betriebssystemen scheint in Arbeit zu sein, OpenVPN hingegen ist auch nach vielen Jahren in noch keinem Betriebssystem fest integriert. Außerdem wird dem Wireguard Protokoll weniger Overhead, also Zusatzinformationen die zusätzlich zu den eigentlichen Daten übertragen werden müssen, zugesprochen als OpenVPN, was ebenfalls für eine höhere Geschwindigkeit spricht.

[PRAXIS]
Einrichtung/ Konfig

Als eingesessener OpenVPN User fiel mir die Einrichtung von Wireguard gar nicht so leicht, natürlich spielt da viel Gewohnheit mit rein, aber allein die Tatsache, dass im Wireguard Protokoll mehrfach von "allowed Adresses" gesprochen wird, hat mir sehr zu schaffen gemacht, denn je nachdem an welcher Stelle davon gesprochen wird, hat es eine völlig andere Bedeutung: Mal wird hier die IP angegeben, die einem Client zugewiesen wird, und mal wird angegeben, welche Adressen oder Subnetze durch den Tunnel geroutet werden sollen. Somit hatte ich auch meine Schwierigkeiten, den Tunnel so zu konfigurieren, dass der gesamte Traffic darüber geroutet wird. Während man in OpenVPN lediglich einen Haken setzen oder den Befehl "redirect-gateway" in die Konfiguration einsetzten muss, scheint es in Wireguard partout keine Möglichkeit zu geben dies auf ähnlich einfache Weise zu gestalten, stattdessen muss die default Route durch entsprechende Einstellung unter "allowed Adresses" manuell übergangen werden. Ebensowenig finde ich weitere Informationen für erweiterte Konfigurationen, die aber allenfalls unter bestimmten Bedingungen benötigt werden. Ich habe hier keine weiteren Anforderungen, sodass ich bisher auch gut mit den Standardmöglichkeiten zurechtkomme.
Ich bin mir sicher, dass Wireguard nach etwas Eingewöhnung ebenfalls sehr einfach einzurichten ist, in OpenVPN muss man sich ja schließlich auch erstmal reinfuchsen und die Konfiguration gestaltet sich ob der vielen Optionen doch deutlich komplexer.

Geschwindigkeit
In einem VPN zählen vor allem zwei Dinge: Sicherheit und Geschwindigkeit.
Da ich der Sicherheit mangels Wissen nicht näher auf den Grund gehen kann, muss ich mich auf den Test der Geschwindigkeit beschränken.

Die Testsituation stellt sich wie folgt dar...
Server (OVPN und WG): Intel Atom E3845 (mit AES-NI), 4GB RAM, Bandbreite Internet 300/150Mbit/s

Client A1: Samsung Galaxy S20+, WLAN
Um etwaige Empfangsprobleme/ niedrige Bandbreiten im Mobilfunknetz ausschließen zu können, habe ich zunächst getestet, wie sich die Geschwindigkeit im WLAN darstellt, getestet wurde mit iperf3 in beide Richtungen (Download/ Upload).
(Bild 1: WLAN iperf3 Download) WLAN_download.jpg (Bild 2: WLAN iperf3 Upload) WLAN_upload.jpg

Ohne VPN betrug der Download 418Mbit/s und der Upload 430Mbit/s,
bei OpenVPN 55/70 Mbit/s und
bei Wireguard 121/151 Mbit/s

Unter diesen Testbedingungen (kein Internet dazwischen) erzielt Wireguard also mehr als die doppelte Bandbreite, respekt!

Client A2: Samsung Galaxy S20+, 5G Mobilfunk
Der 5G Empfang war hier grenzwertig zu LTE+, die Geschwindigkeit des Netzes (ohne VPN) habe ich mittels Speedtest von Ookla gemessen, die VPN Geschwindigkeiten zusätzlich nochmal mit iperf3.
Bei den Bildern nicht wundern, die Messung ohne VPN weist eine LTE Verbindung aus, die beim Start der Messung nur kurz bestand, aber sofort auf 5G wechselte, diese Messung ist ohnehin eher informativ. Insgesamt ist das Mobilfunknetz an dem Standort und zu der Uhrzeit nicht sonderlich stabil (Dorfkind an der Autobahn 7 ;) ), daher erzielt WG auch bessere Ergebnisse als das Netz vermeintlich hergibt. Die Messung sollte aber aussagekräftig genug sein.

(Bild 3: 5G Mobilfunk, Ookla) 5g_ookla.jpg (Bild 4: 5G Mobilfunk, iperf3) 5G_iperf.jpg

Ohne VPN betrug der Download 89Mbit/s und der Upload 36Mbit/s,
bei OpenVPN 24/11 Mbit/s (Ookla) und
bei Wireguard 45/39 Mbit/s (Ookla)
sowie
bei OpenVPN 11/19 Mbit/s (iperf3) und
bei Wireguard 20/28 Mbit/s (iperf3)

Auch hier erzielt Wireguard stets fast die doppelte Geschwindigkeit von OpenVPN. Auffällig ist hier der erhöhte Jitter (schwankende Latenz) sowie der damit zusammenhängende Paketverlust bei Wireguard, ich konnte dies aber nicht nochmal nachstellen und kann das Problem daher nicht auf das Wireguard Protokoll schieben, sondern vermute das Mobilfunknetz selbst als Verursacher.


Alles in allem kann man bereits jetzt sagen, dass das Wireguard Protokoll einen sehr deutlichen Geschwindigkeitsvorteil gegenüber OpenVPN hat. Etwaige Messtoleranzen, etc. dürften daran nichts mehr rütteln. Dennoch sind diese "praktischen" Messungen eher theoretischer Natur, da beide Messverfahren nicht die üblicherweise eingesetzten Dateiübertragungsprotokolle wie z.B. SMB oder FTP berücksichtigen, die ebenfalls durch den Tunnel laufen müssen. Dies werde ich (zumindest für SMB) zu einem anderen Zeitpunkt in einem anderen Erfahrungsbericht testen und euch daran teilhaben lassen. Auch ein Test mit einem potenteren PC (Stichwort AES-NI) über kabelgebundenes Internet steht noch aus.
 
Zuletzt bearbeitet:

tiermutter

Well-known member
[WEITERE BEOBACHTUNGEN]
Während man bei OpenVPN die Wahl hat, auf welchem Interface (LAN, WAN, ... , IPv4, IPv6) der Server lauscht, fehlt diese Möglichkeit bei Wireguard, sodass der Server hier stets auf allen zur Verfügung stehenden Interfaces lauscht, zumindest konnte ich keine offensichtlichen Einstellungsmöglichkeiten ausmachen. Einen wirklichen Nachteil sehe ich im Heimgebrauch hierbei aber nicht wirklich, auch wenn ich mir schon die Kontrolle darüber wünsche.

In Wireguard wird die dem Client zugewiesene IP serverseitig (Peer/Allowed IPs) und auch clientseitig (Address) konfiguriert; der Sinn dahinter erschließt sich mir nicht. Auch scheint es in Wireguard keine Möglichkeit zu geben bestimmte Einstellungen zu pushen, also vom Server vorzugeben. So wird der DNS und die zu tunnelnden IPs auf dem Client konfiguriert, sodass jeder User die Möglichkeit hat hier rumzupfuschen. Eine entsprechende Push-Funktion wie bei OpenVPN wäre hier wünschenswert.

Bei meinen Tests hat es der Wireguard Client einmal geschafft das gesamte Routing des Rechners durcheinander zu wirbeln. Wird eine Verbindung aktiviert bei der etwas nicht stimmt, so kann man den Verbindungsversuch nicht mehr unterbinden. In meinem Fall ging es so weit, dass ich den Wireguard Client (mehrfach) über den Taskmanager beenden musste. Bis zum Neustart des Rechners war Wireguard nicht mehr verwendbar.
Auch ist es mir ein übler Dorn im Auge, dass die Wireguard Clients auf Android und Windows oftmals eine erfolgreich bestehende Verbindung ausweisen, auch wenn gar keine (funktionierende) Verbindung zustande gekommen sein kann. Das bringt mich auch direkt zum nächsten Punkt...

... es gibt kein ordentliches Logging, weder auf Seiten des Servers, noch auf Seiten des Clients. Eine Fehlersuche ist unmöglich, denn mehr als den letzten Handshake oder die übertragene Datenmenge wird nicht ausgespuckt, jedenfalls nicht offensichtlich.

Die fehlende Möglichkeit der Autenthifizierung mittels User/ Passwort am Client bei Wireguard hatte ich bereits angesprochen, muss ich hier der Dramatik wegen aber nochmals ins Gedächtnis rufen.

[FAZIT]
Das Wireguard Protokoll ist nicht nur interessant, sondern unter den Testbedingungen äußerst performant und für den Heimbedarf als ausreichend sicher einzustufen. Für mich steht fest, dass ich zukünftig auf dieses Protokoll setzen möchte und es bereits schon in Teilen tue. Allerdings wird OpenVPN parallel weiter betrieben, denn die Tatsache dass mir ein Client das gesamte Routing zerschossen hat und ich dank fehlender Logs keine Ahnung habe warum, führt dazu, dass ich die Clients als nicht ausreichend stabil einstufe und OpenVPN wenigstens als Fallback behalten werde.

Mangels Authentifizierung am Client selbst um eine Verbindung aufbauen zu können ist der Einsatz im gewerblichen Umfeld (für mich) ausgeschlossen, zu hoch ist die Gefahr, dass Mitarbeiter ihren Laptop vergessen oder Fremde Zugriff in unbeaufsichtigten Zeiträumen darauf erlangen. Hier werde ich weiterhin auf OpenVPN setzen. Diese Gefahr besteht natürlich auch im privaten Umfeld, allerdings gibt es hier (bei mir) deutlich weniger Nutzer und der Verlust eines Geräts oder fremder Zugriff wird relativ zeitnah bemerkt, sodass man entsprechende Maßnahmen einleiten kann.

Unterm Strich gibt es bei Wireguard noch viel Wünschenswertes, was das Protokoll aber teils komplexer macht; der Grad zwischen Einfachheit und guten Konfigurationsmöglichkeiten ist eben sehr schmal! An den Wireguard Clients selbst zumindest sehe ich noch dringenden Handlungsbedarf und werde eben daher vorerst zweigeleisig mit OpenVPN und Wireguard fahren. Beides hat hier seine Vor- und Nachteile, aus denen sich jeder für seine Situation und Anwendung die entsprechenden Schlüsse ziehen muss. Meine Highlights aus dem Vergleich:

OpenVPN
+ Viele optionale Konfigurationsmöglichkeiten
+ Sehr zuverlässig (bisher keine größeren Probleme gehabt; wenn doch was klemmte konnte das Logging Aufschluss geben)
- Starke Hardware/ AES-NI erforderlich, sonst drastische Geschwindigkeitseinbußen

Wireguard
+ Sehr schnelle Übertragungsgeschwindigkeit, insbesondere auf schwächerer Hardware
- Keine Möglichkeit den Zugang mittels User/ Passwort abzusichern
- Kein Logging zwecks Fehlersuche, daher für mich unzuverlässig da Fehlersuche erschwert
o Konfiguration einfach, aber wenig schlüssig/ verwirrend

[EPILOG]
Wie schon angemerkt stehen noch weitere Geschwindigkeits-Tests aus, die der Praxis auch wirklich gerecht werden. Ein erstes Bild kann man sich sicherlich jetzt schon machen.
Ich habe meinen Job fürs Erste getan und habe viel Zeit zum Testen in den VPN verbracht... wird Zeit dass ich das VPN mal wieder praktisch nutze... vielleicht in etwa 8 Stunden, dann geht es in das 420km entfernte Eindhoven. Was war da doch gleich? Achja, Punkrock-Festival. Cheers! 🍻
 
Zuletzt bearbeitet:

frosch2

Active member
Vielen Dank für diesen ausführlichen Bericht, sehr sachlich und angenehm zu lesen.
Da ich VPN nur auf einigen Clients nutze (Laptop, Handy) kommt Wireguard, wegen der mangelnden Passwortabfrage, für mich nicht in Frage.
Sollte ich mein Handy verlieren, möchte ich nicht, dass der Finder in mein Netzwerk kommt.
 

tiermutter

Well-known member
... Dabei dürfte es gar nicht so schwer sein den Clients eine Passwortabfrage einzupflanzen, wir reden hier ja nicht davon dass die Authentifizierung am Server erfolgt.
Wenn ein Handy mit Pin, Muster,... Oder PC mit Kennwort gesichert ist, ist das finde ich alles halb so wild. Meine Kollegen hingegen haben ihre Laptops auf den Baustellen und generell beim Kunden stehen, da bleibt es nicht aus dass das Teil nach der Anmeldung bei Windows unbeaufsichtigt rumsteht... Da geht sowas gar nicht.
 

the other

Well-known member
Moinsen,
Ich habe wireguard noch nicht benutzt. Habe also lediglich theoretisch was davon mitbekommen und diverse Meinungen in Foren gelesen. Was mich dabei ganz klar fasziniert, ist der schlanke Ansatz und die recht universelle Umsetzung. Die Geschwindigkeit ist unbestritten ein Hammer.
Ich bin bei meiner eigenen VPN Nutzung sehr bescheiden, es ist einfach nur selten nötig, mich daheim einzuwählen per Tunnel. Das allermeiste kann warten. Deswegen ist für mich der Vorteil Geschwindigkeit weniger relevant. Dafür ist mir (rein aus dem Bauch, nicht dass hier wichtige Datenschätze schlummern würden :ninja:) der IMHO Nachteil mangelnder Sicherheit (fehlende Authentifizierung beim Zugangsaufbau) wesentlich wichtiger. Und da beisst es sich eben. Wireguard ist vom Konzept her schlank und lässt bis auf den key authentication part alles weg AFAIK. Ich dagegen bin paranoid genug und will nicht, dass nur meine Handy pin die Schwelle zum Heimnetz (oder Teilen davon) ist. Ich mag den Aufwand, dass ich die eh schon dicke openvpn Zertifikat-Austausch-Orgie zusätzlich noch mit radius und 2fa absichere. Ich will gar nicht wissen, was da an overhead abgeht...aber ich hab so das Gefühl, dass der Zugang zum heiligen Heimnetz doch etwas behüteter ist, und das ist mir persönlich im VPN Kontext wichtiger.
;)
Würde ich mehr Nöte haben, weil es echt flutschen muss via VPN, dann wäre wireguard in Kombination mit ner DMZ, in der der zielserver steht, vielleicht eher mein Ding...
 

tiermutter

Well-known member
Wäre sicherlich einen eigenen Bericht wert :)
Was ich noch nicht geblickt habe: Wie funktioniert das Ganze? Sieht mir ja so aus als würden sich die Clients mit einem entsprechend beim Entwickler stehenden Server verbinden um anschließend P2P Daten mit allen Teilnehmern austauschen zu können?!
 

underwood

Active member
Es gibt da Moon und Planet Server. Was was ist habe ich gerade vergessen. Gibt da ne menge Videos zu, größtenteils in Englisch.

Die einen Server stellen die Authorisierung und Benutzeroberfläche zur Verfügung. Die anderen haben die IPs von den Clients und sorgen dann dafür, das die sich direkt verbinden können. Alles über einen UDP-Port.

Man kann alle Clients und Server in einem SDN (Software Defined Network) verbinden und mit Regeln auch limitieren. Z.B. auf bestimmte Ports. Läuft auch auf OPNsense als virtuelle Netzwerkkarte.
 

tiermutter

Well-known member
Um das Thema nochmal aufzugreifen... es stehen ja noch weitere Testmessungen aus...
Gestern bei der Abendrunde mit dem Hund habe ich spontan nochmal ein paar Speedmessungen durchgeführt, der 5G Empfang war diesmal sehr stabil.
Bei der Messung mit Ookla hatte OVPN diesmal deutlich die Nase vorn (ca 80/40), WG hatte nur etwa die Hälfte bei mehreren Messungen.
Das Ergebnis bei iPerf war allerdings identisch zu dem beim letzten Mal, wo WG deutlich besser abgeschnitten hat.

Die Tests mit der Datenübertragung mittels SMB stehen noch aus. Außerdem noch ein Hinweis, der mich ohnehin zu einer neuen Testreihe verleiten wird:
Bei mir ist in der OPNsense derzeit noch Wireguard-go aktiv anstatt Wireguard-kmod, mein WG ist also noch nicht im Kernel implementiert, was -wenn es soweit ist- weitere Geschwindigkeitsverbesserungen mit sich führen kann.
Sobald ich den kmod verwende werde ich die Tests samt SMB also nochmal neu aufziehen und die Ergebnisse hier bereitstellen.
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
586
Beiträge
8.672
Mitglieder
204
Neuestes Mitglied
sina27
Oben