OpenVPN vs WireGuard pfSense (incl benchmarks)

[Faifz]

Omdat ik zoveel buzz heb gehoord over WireGuard en sterk mijn twijfels erover heb, had ik besloten om het zelf eens te testen. pfSense werd gebruikt als VPN server waar een lokaal netwerk achter hangt met een target server met iperf3 geïnstalleerd. Het zijn 2 verschillende firewalls want voor een of andere reden wou de WG plugin nooit werken op de andere firewall.

Er werd gekozen voor een split-tunnel methode waarbij we x aantal subnets routen (192.168.25.0/24 & 192.168.30.0/24) over de VPN tunnel. De VM's hebben ieder 4 vCPUs/4GB toegewezen. Voor de OpenVPN server heb ik gekozen voor AES256GCM/SHA256 als de cipher suites.



OpenVPN 2.5.2 als client (322Mbps):



OpenVPN Connect 3.3.2 als client (637Mbps):



WireGuard als client (762Mbps):



Verder heb ik het ook getest met verschillende OpenVPN implementaties, bv de OpenVPN Access Server en de prestaties zijn aanzienlijk lager. Dus je gaat het erg ver moeten zoeken als je het maximale eruit wil halen. Dit nadeel heb je niet met WireGuard omdat de implementaties vrijwel hetzelfde zullen zijn van vendor tot vendor. Persoonlijk vind ik de prestaties van OpenVPN goed genoeg en het gemis aan MFA met WireGuard (bv. push notificaties werken met PKI/TLS) maakt het voor mij de mindere veilige optie.

Het opzetten van de VPN server en client is wel gemakkelijker met OpenVPN - als we het strict hebben over pfSense's implementatie. Je volgt een wizard waar je wat namen verzint voor een CA certificaat, een tunnel netwerk instelt, split-tunnel access routes en dat is het enige dat je echt moet doen. Er is ook een client export tool beschikbaar die .ovpn files inbakt in een .exe installatiebestand - wat het erg gemakkelijk maakt voor een client.

WireGuard opzetten vond ik iets moeilijker omdat ik het nooit eerder heb gedaan in pfSense. Aan de server kant heb je dan 'AllowedIPs' waar je het host adres toevoegt met een /32 mask en vreemd genoeg is het een adres uit het tunnel netwerk (172.16.56.0/24). Maar aan de client kant stelt 'AllowedIPs' totaal iets anders voor, namelijk de split-tunnel access routes of als je een default-route (0.0.0.0/0) ingeeft forceer je alles door de tunnel. Het lijkt me wel logischer dat dit ingesteld wordt op de server en niet vanuit de client. De client configuratie is wel simpel als je het zou vergelijken met een .ovpn file.

[Faifz]

Was benieuwd hoe IPSec het zou doen tegenover WireGuard, dus heb ik beide protocollen gebruikt voor een site-to-site tunnel en tot mijn verbazing doet IPsec het veel beter. AES-256GCM werd gebruikt voor P2, SHA256 is overbodig wanneer AES-GCM gebruikt wordt. Wanneer je 3DES zou gebruiken over AES, merk je wel degelijk dat het trager is zonder hardware-acceleration extensions zoals AES-NI. Ik vermeen mij te herinneren dat het rond 130Mbps lag en dan spreken we over een encryptie algoritme dat niet meer veilig beschouwd wordt.

WireGuard gebruikt ChaCha20 wat sneller zou moeten zijn dan AES wanneer je geen hardware-acceleration extensions zou hebben. Maar zelfs recente smartphones ondersteunen AES-NI, dus ChaCha20 is in theorie niet zo interessant als AES tenzij je een apparaat gebruikt die geen ondersteuning heeft voor AES-NI.

IPsec (825 Mbps):


WireGuard (702 Mbps):

[Thralas]

Faifz schreef op zondag 17 oktober 2021 @ 21:30:
Dit nadeel heb je niet met WireGuard omdat de implementaties vrijwel hetzelfde zullen zijn van vendor tot vendor.

Is niet helemaal waar. De originele implementatie van WireGuard is geschreven voor Linux en is in-kernel, ondersteuning voor andere OS'en (Windows/Android/BSD) is in eerste instantie geschreven met het oog op portabiliteit boven snelheid (de golang-versie).

Dat is qua implementatie niet heel veel anders dan OpenVPN, behalve dat de ciphers inherent iets sneller zijn. Tegen IPsec kun je het afleggen omdat dat altijd in-kernel is en je dan vaker gebruikt kunt maken van allerlei acceleratieopties.

en dan spreken we over een encryptie algoritme dat niet meer veilig beschouwd wordt.

Er is niets fundamenteel mis met 3DES. Er is alleen weinig reden meer om géén AES te gebruiken.

Maar zelfs recente smartphones ondersteunen AES-NI, dus ChaCha20 is in theorie niet zo interessant als AES tenzij je een apparaat gebruikt die geen ondersteuning heeft voor AES-NI.

Dat klopt niet. AES-NI is een extensie voor x86 CPUs. In smartphones bestaan vergelijkbare AES-instructies pas sinds ARMv8-A, eveneens als extensie. In tegenstelling tot x86 is ARM een knip-en-plakarchitectuur waarbij SoCs erg verschillen, ik vermoed dat de extensies daarmee veel minder breed worden ondersteund dan op x86 het geval is.

Als het inderdaad optioneel is dan is de kans erg groot dat je er sowieso geen gebruik van maakt omdat men software meestal compileert voor de grootste gemene deler.

---

Zoek eens uit of de implementaties van je benchmarks de in-kernel-variant gebruiken - bij pfSense was er wat controverse rondom WireGuard, maar als ik de handleiding mag geloven zit het inmiddels in de kernel (edit: blijkt het geval volgens je screenshots). Maar op Windows is dat standaard niet het geval, terwijl er juist net een experimentele kernelmodule uit is (WireGuardNT) die een stuk interessanter is om te testen.

Nog beter zou het zijn om te benchmarken tegen een machine die Linux draait. Dat is de originele implementatie die met gemak line rate haalt. Dan weet je zeker dat de bottleneck daar niet snel ligt.

[Faifz]

Thralas schreef op dinsdag 2 november 2021 @ 19:33:
[...]

Is niet helemaal waar. De originele implementatie van WireGuard is geschreven voor Linux en is in-kernel, ondersteuning voor andere OS'en (Windows/Android/BSD) is in eerste instantie geschreven met het oog op portabiliteit boven snelheid (de golang-versie).

Dan heb je het enkel alleen maar over de client. En nee, het is pas vanaf een bepaalde kernel versie waar WG standaard ingebakken zit. Ik merk wel dat de kernel-mode wel in algemeen achterloopt qua ondersteuning op platformen zoals Windows/BSD, maar pfSense (BSD) gebruikt de kernel-mode. Het zou me niet verbazen dat heel veel vendors de user-mode zouden gebruiken, dus de implementatie verschilt dan niet tussen die vendors.

Wat ik ermee bedoelde was, als je OpenVPN zou draaien bv met pfSense of de OpenVPN Access Server - verschillen de prestaties wel enorm. Dit zie ik niet zo zeer gebeuren met WireGuard waar de prestaties sterk varieren van vendor tot vendor, tenzij je user-mode vs kernel-mode vergelijkt.

Dat is qua implementatie niet heel veel anders dan OpenVPN, behalve dat de ciphers inherent iets sneller zijn.

Iets sneller zijn? Op moderne hardware bv een 1800x, is AES tot 6x sneller als ChaCha20

https://calomel.org/aesni_ssl_performance.html

Tegen IPsec kun je het afleggen omdat dat altijd in-kernel is en je dan vaker gebruikt kunt maken van allerlei acceleratieopties.

Klopt helemaal niet, hoor. Het doet er helemaal niet toe of je nu draait in de user of kernel-mode als je gebruik wil van maken hardware-acceleration extensions. Dan heb je het enkel over de VPN protocol, maar AES of ChaCha20 kun je natuurlijk ook zonder een VPN protocol gebruiken.

Er is niets fundamenteel mis met 3DES. Er is alleen weinig reden meer om géén AES te gebruiken.

AES presteerde voor mij zo'n 8x sneller en 3DES en ondertussen is het niet eens meer opgenomen in TLS 1.3 en NIST heeft het enkele jaren geleden gepensioneerd. Over een jaar mag het zelfs niet meer gebruikt worden. Maar volgens u is er fundamenteel niks mis met 3DES? Vind het maar een vreemde mening.

https://www.cryptomathic....-officially-being-retired

En hier vind je de research artikel terug over 3DES: https://sweet32.info/

Dat klopt niet. AES-NI is een extensie voor x86 CPUs. In smartphones bestaan vergelijkbare AES-instructies pas sinds ARMv8-A, eveneens als extensie. In tegenstelling tot x86 is ARM een knip-en-plakarchitectuur waarbij SoCs erg verschillen, ik vermoed dat de extensies daarmee veel minder breed worden ondersteund dan op x86 het geval is.

Geen idee hoe ze die extensions noemen in ARM chips? Maar ze hebben in ieder geval hardware-acceleration voor AES.

Als het inderdaad optioneel is dan is de kans erg groot dat je er sowieso geen gebruik van maakt omdat men software meestal compileert voor de grootste gemene deler.

Snap niet wat je hiermee bedoelt. Waarom zou het optioneel zijn in een markt waar concurrentie bestaat?

Zoek eens uit of de implementaties van je benchmarks de in-kernel-variant gebruiken - bij pfSense was er wat controverse rondom WireGuard, maar als ik de handleiding mag geloven zit het inmiddels in de kernel (edit: blijkt het geval volgens je screenshots). Maar op Windows is dat standaard niet het geval, terwijl er juist net een experimentele kernelmodule uit is (WireGuardNT) die een stuk interessanter is om te testen.

Nog beter zou het zijn om te benchmarken tegen een machine die Linux draait. Dat is de originele implementatie die met gemak line rate haalt. Dan weet je zeker dat de bottleneck daar niet snel ligt.

De tunnel leeft tussen de twee peers in een site-to-site setup, dus tussen de firewall/routers en niet de hosts tenzij het remote-access setup is. In mijn 2de WG benchmark werd het getest in site-to-site. Daar draai je natuurlijk geen WG of IPsec client.

pfSense gebruikt wel inderdaad de kernel-mode versie. pfSense had WG eerder verwijderd omdat het gewoon niet klaar was voor FreeBSD en mogelijk niet veilig was.

'At this time this code is new, unvetted, possibly buggy, and should be considered "experimental". It might contain security issues. We gladly welcome your testing and bug reports, but do keep in mind that this code is new, so some caution should be exercised at the moment for using it in mission critical environments.'

[jurroen]

Faifz schreef op dinsdag 2 november 2021 @ 23:04:
[...]

https://calomel.org/aesni_ssl_performance.html

Let op, Calomel geeft soms ook wat rare en/of verkeerde adviezen. Vanuit de BSD community en devs is daar al vaker kritiek op geweest.

pfSense gebruikt wel inderdaad de kernel-mode versie. pfSense had WG eerder verwijderd omdat het gewoon niet klaar was voor FreeBSD en mogelijk niet veilig was.

'At this time this code is new, unvetted, possibly buggy, and should be considered "experimental". It might contain security issues. We gladly welcome your testing and bug reports, but do keep in mind that this code is new, so some caution should be exercised at the moment for using it in mission critical environments.'

Zit wat meer drama achter. In de woorden van Netgate lijkt het alsof FreeBSD de boeman was. Netgate had echter een random developer betaald om de implementatie te doen, heeft dit in een technical preview versie gepushed zonder enige vorm van auditting.

Voor wat meer context, zie onder andere: https://lists.zx2c4.com/p...rd/2021-March/006494.html

[Faifz]

jurroen schreef op dinsdag 2 november 2021 @ 23:15:
[...]


Let op, Calomel geeft soms ook wat rare en/of verkeerde adviezen. Vanuit de BSD community en devs is daar al vaker kritiek op geweest.

Beter?

https://gist.github.com/r...02b9ec9fb67b6443f16732080

Zit wat meer drama achter. In de woorden van Netgate lijkt het alsof FreeBSD de boeman was. Netgate had echter een random developer betaald om de implementatie te doen, heeft dit in een technical preview versie gepushed zonder enige vorm van auditting.

Voor wat meer context, zie onder andere: https://lists.zx2c4.com/p...rd/2021-March/006494.html

Heb je dat artikel wel gelezen? Want het komt van Jason (WG founder) zelf die meewerkte aan de FreeBSD kernel-mode implementatie. Hij en een deel andere BSD developers hebben samen besloten om de stekker eruit te trekken omwille van stabiliteit/security. Natuurlijk dropt Netgate ondersteuning voor WG 2-3 dagen later. Het heeft niks te maken met het feit of Netgate nu een random dev heeft betaald voor de plugin.