WireGuard keert terug naar pfSense als experimenteel pakket

WireGuard is teruggekeerd in pfSense Plus en pfSense CE in experimentele vorm. Netgate houdt de ontwikkeling van de code in de gaten en vraagt gebruikers om feedback. In maart verwijderde Netgate WireGuard uit pfSense, niet lang na de implementatie.

Netgate steunt een project van ontwikkelaar Christian McDonald, die WireGuard als add-on package naar pfSense wil brengen. McDonald publiceert op YouTube over die ontwikkeling. Het voordeel van zijn aanpak is volgens Netgate dat er geen low-level wijzigingen bij de pfSense-software vereist zijn. McDonald baseert de kerneldriver op net/wireguard-kmod van FreeBSD's portsproject.

Het gaat vooralsnog om experimentele code voor pfSense Plus en CE en Netgate hoopt deze met hulp van feedback van gebruikers te kunnen verbeteren. De introductie van het add-on-pakket volgt op het verwijderen van een kernel-mode-implementatie van WireGuard uit pfSense, in maart. Netgate besloot tot die stap omdat die port nog niet rijp werd bevonden voor release.

De betreffende port van WireGuard had namelijk zijn weg moeten vinden naar de 13.0-release van FreeBSD, maar dit gebeurde niet nadat WireGuard-ontwikkelaar Jason Donenfeld serieuze problemen aantrof in de port en de versie niet gereed achtte. PfSense is op FreeBSD gebaseerde router- en firewallsoftware en Netgate sponsorde de ontwikkeling van de port.

pfSense WireGuard

Door Olaf van Miltenburg

Nieuwscoördinator

06-05-2021 • 17:10

17

Submitter: Fidel

Reacties (17)

17
17
7
0
0
9
Wijzig sortering
Ik ben hier wel blij mee. Mits weer veilig uiteraard. We hebben getest met Wireguard in pfSense 2.5.0 en trokken daar zo 300Mbps mee dicht (linespeed) met niet eens veel CPU load, terwijl openVPN met AES-NI ondersteunde ciphers niet verder komt dan 120Mbps op dezelfde hardware.
Ik ben ook wel benieuwd of er veel verschil merkbaar is tussen de userspace en de kernelspace implementatie van WireGuard. Maar om dat goed te testen zul je waarschijnlijk vanilla FreeBSD moeten draaien en niet pfSense.

[Reactie gewijzigd door Maurits van Baerle op 1 augustus 2024 10:34]

Ja de kernel versie is veel efficienter, want de data moet niet 2x via de userspace passeren.
For a typical ‘SOHO gateway application’, on our SG-5100 appliance, using a 4 core C3558 Atom, the WireGuard implementation in pfSense 2.5 achieves 909Mbps, using iperf3, in a laboratory setting, setting the MSS to 1380. This is single-stream, with the firewall (‘pf’) enabled. This is 99.89% of what is theoretically possible.

Meanwhile, the “wireguard-go” port, running over FreeBSD 13-CURRENT on the same machine, achieves a mere 36.15% of theoretical maximum, only 329Mbps in the same setup.
Source: pfSense Blog
Dank! Dat is wel echt een imposant verschil. Dan begrijp je ook ineens beter waarom er werk gemaakt wordt van de kernelspace uitvoering.
Stond hardware acceleration wel aan in pfSense? Want AES met AES-NI ingeschakeld is sowieso sneller als ChaCha20 wat WireGuard gebruikt. https://gist.github.com/r...02b9ec9fb67b6443f16732080

Dus het komt er eerder op neer welke protocol sneller is en de enige vorm van benchmarks dat ik te zien krijg komen allemaal van WireGuard zelf: https://www.wireguard.com/performance/

En het volgende artikel bewijst eerder dat het onzinnige benchmarks zijn want er werden Jumbo frames gebruikt en 1011 Mbps is niet eens mogelijk met een MTU van 1500 op een Gigabit interface. En als je verder leest, vertraagt het uw applicaties ook omwille van GSO en het opdelen van grotere packets in kleinere packets. https://blog.ipfire.org/post/why-not-wireguard

Volgens dit artikel is WireGuard op UDP maar 14% sneller en OpenVPN sneller is qua upload. Maar met PIA VPN als client is OpenVPN in het geheel sneller als WireGuard. Dus het varieert ook per client.

https://vladtalks.tech/vp...0for%20OpenVPN%20on%20TCP.

Veiliger zou ik WireGuard niet noemen want je mist een hele wereld aan features zoals MFA, HIP profiles etc. Dit is ook de reden waarom het nog niet klaar is voor enterprise.
AES staat zeker aan in pfSense, en dmesg laat ook zien dat het netjes 'gezien' wordt en welke ciphers er ondersteund worden. Toch heeft OpenVPN nooit voor een meter performed bij ons. MFA enz is in deze niet van toepassing; dit is een connectie naar onze remote backup omgeving, het verkeer daaroverheen is vanuit de backup omgeving sowieso al encrypted. Het gaat me dus meer om het site to site verhaal dan encryptie, maar dubbelup is altijd mooi. Nu loopt dat nog over OpenVPN (historisch) maar ik wilde inderdaad al switchen naar IPSec. In het verleden lukte dat niet omdat we daar achter NAT zaten, maar inmiddels staat er aan de andere kant ook een pfSense doos aan de buitenkant, waarmee dat dus moet lukken.
Wireguard echter performde in onze tests zonder enige finetuning al enorm goed. Veel beter dan ik ipsec en openvpn ooit over onze lijnen heb zien doen. Ik was in elk geval wel enthousiast :)
Stond hardware acceleration wel aan in pfSense? Want AES met AES-NI ingeschakeld is sowieso sneller als ChaCha20 wat WireGuard gebruikt. https://gist.github.com/r...02b9ec9fb67b6443f16732080
Wel een opmerking over het nut van AES-NI: dit helpt alleen als de andere kant het bij kan houden. Als ik die benchmarkresultaten zie, dan bevestigen ze mijn ervaring: een router met een beperkte SoC zonder enige vorm van cryptografische acceleratie presteert met een WireGuard VPN een stuk beter dan met OpenVPN.

Dat het zich nog niet heeft bewezen als een VPN voor professioneel gebruik is een gegeven, maar voor persoonlijk gebruik met beperkte hardware heeft het zeker nut.
Want ChaCha20 kan je niet met OpenVPN/IPSEC gebruiken? Wel dus. Als je met een beperkte SoC prestatieproblemen hebt met OpenVPN zal dit ook zo zijn met WireGuard. Je hoort niet eens een OpenVPN/WireGuard server te draaien op je router als er te weinig resources voor zijn.

AES-NI zie je toch terug in moderne ARM SoC's, niet? Ben niet zo up-to-date betreft ARM etc.
Want ChaCha20 kan je niet met OpenVPN/IPSEC gebruiken?
Dat schrijf ik nergens.

Alle factoren gelijk, en WireGuard is een stuk sneller dan OpenVPN op beperkte hardware. Een efficiëntere codebase en protocol zorgen daarvoor.
Wel dus. Als je met een beperkte SoC prestatieproblemen hebt met OpenVPN zal dit ook zo zijn met WireGuard. Je hoort niet eens een OpenVPN/WireGuard server te draaien op je router als er te weinig resources voor zijn.
Je onderschat het verschil in CPU gebruik.
AES-NI zie je toch terug in moderne ARM SoC's, niet? Ben niet zo up-to-date betreft ARM etc.
Op MIPS is er geen AES acceleratie zonder aparte extra hardware. De meeste routers hebben dit niet.

[Reactie gewijzigd door The Zep Man op 1 augustus 2024 10:34]

Alle factoren gelijk, en WireGuard is een stuk sneller dan OpenVPN op beperkte hardware.
Je hebt gelijk als ChaCha20 wordt gebruikt ipv AES op een SoC zonder AES-NI, ja - alhoewel dit los staat van of je nu OpenVPN of WireGuard gebruikt. Maar je hebt nog altijd geen concreet bewijs hoeveel keren sneller het protocol is dan OpenVPN. WireGuard presteert het beste wanneer je met Jumbo frames werkt maar dit is alleen maar relevant in een datacenter en niet over het internet want het standaard is 1500 ipv 9000 MTU. Je mag dat artikel van ipfire eens doornemen, hoor. En ben er vrij zeker van dat je het gedeelte over GSO niet hebt gelezen.
[Dubbel]

[Reactie gewijzigd door Jerie op 1 augustus 2024 10:34]

MFA is geen taak van WireGuard. Dat doe je een laag hoger.

Verder is PIA en enterprise in 1 post vloeken in de kerk. Voor enterprise kan wg prima gebruikt worden bijv via Tailscale of Innernet.

Daarnaast is wg sneller qua verbinding opzetten. En dat is handig tijdens roaming.
MFA is geen taak van WireGuard. Dat doe je een laag hoger.
OpenVPN heeft LDAP authenticatie geïntegreerd en WireGuard niet en dit moet een vendor bv Cisco zelf gaan doen. Active Directory is vrij belangrijk voor enterprise. En als ik niet verkeerd ben is MFA vrijwel ingebakken in OpenVPN. Het duurde mij maar een paar minuten om het op te zetten met Duo MFA.

MFA vendors (bv Okta/Duo/PingID etc.) gaan geen WireGuard ondersteunen als geen enkele van de grote merken zoals Cisco/CheckPoint/Fortinet WireGuard implementeren.
Voor enterprise kan wg prima gebruikt worden bijv via Tailscale of Innernet.
En nee, het is nog altijd niet enterprise-ready. Kan je een hele lijst aan redenen geven waarom. Ik heb meer als een ander halfjaar gewerkt met GlobalProtect van Palo Alto Networks en deze features vind je niet terug in WireGuard omdat het gewoon niet klaar is. Bv HIP profiles; de VPN client controleert of je bv Windows Firewall hebt aanstaan of niet en als het niet zou aanstaan - wordt de verbinding verbroken. Natuurlijk kan je hier veel verder op ingaan tot en met Data Loss Protection etc.

Verder begrijp ik niet waarom Tailscale relevant zou zijn als je als enterprise het kan veroorloven om een Fortinet/PA/CheckPoint of dergelijke te gebruiken en dit zijn devices die je sowieso nodig hebt.
Daarnaast is wg sneller qua verbinding opzetten. En dat is handig tijdens roaming.
Wanneer ik verbind met mijn VPN server, gaat het eerst via de firewall naar een MFA vendor en vervolgens naar een van mijn Active Directory servers om de credentials na te gaan. Dus de authenticatie duurt wel eventjes. Maar met cookies enabled, is het vrijwel instant als ik de verbinding opnieuw zou opzetten. En dit is met SSL wat iets trager is dan IKEv2.
WireGuard heeft dat niet geïntegreerd omdat WireGuard meer de Unix filosofie volgt. Het doet een ding, en dat doet het goed (5k loc). Authenticatie doe je op een ander niveau, zoals bijvoorbeeld PAM of BSD Auth of iets anders zoals Tailscale Google gebruikt. En op Google accounts kun je MFA verplichten en gebruiken. Dat WireGuard geen authenticatie regelt, maakt het geen mindere oplossing. Bijvoorbeeld SSH doet ook zelf geen native authenticatie maar gebruikt daar frameworks voor. En LDAP kun je prima mee authen via BSD Auth of PAM. Geen idee waarom jij zo geweldig vind dat OpenVPN zelf het wiel uit heeft gevonden...
WireGuard heeft dat niet geïntegreerd omdat WireGuard meer de Unix filosofie volgt. Het doet een ding, en dat doet het goed (5k loc). Authenticatie doe je op een ander niveau, zoals bijvoorbeeld PAM of BSD Auth of iets anders zoals Tailscale Google gebruikt.
Dus je beweert dat authenticatie op de achterliggende host moet gebeuren via PAM - want WireGuard ondersteunt geen PAM. Wat al helemaal onlogisch is want je wilt dat de WireGuard service zelf de authenticatie doet en niet de achterliggende host tenzij je je gegevens wil blootstellen aan de host. Zeer veilige Unix filosofie dan. Uiteindelijk heeft WireGuard heeft geen vorm van authenticatie zoals PAM, RADIUS, LDAP, MFA met SSO/SAML. OpenVPN dus wel.

https://openvpn.net/acces...l/authentication-general/
https://openvpn.net/cloud-docs/saml-setup-with-okta/
Bijvoorbeeld SSH doet ook zelf geen native authenticatie maar gebruikt daar frameworks voor.
Wat bedoel je met frameworks? Lijkt me eerder gefantaseerd. SSH authenticatie is mogelijk via PKI of PAM met een MFA provider zoals Duo. Public key authentication is vrij standaard in SSH dus er is degelijk wel een vorm van native authenticatie aanwezig.

https://duo.com/docs/duounix
Dat WireGuard geen authenticatie regelt, maakt het geen mindere oplossing.
Feitelijk is het de mindere oplossing. Veiliger is het helemaal niet. Of het sneller is niet eens duidelijk bewezen. WireGuard komt niet eens in de buurt van GlobalProtect/Forticlient en kom je met de conclusie dat het niet enterprise klaar is.
Je kunt in de tussentijd ook IPSec gebruiken, dat zou ook netjes line speed moeten vol trekken als er AES extensies aanwezig zijn.
Ik heb wireguard tot de laatste pfsense update gedraaid onder pfsense, en was erg tevreden over de snelheden tov OpenVPN.

Ik vond de wireguard implementatie in pfsense voor mij als hobbyist nogal karig. Vooral het exporteren van client configs was eigenlijk niet aanwezig, in vergelijk met de client export van OpenVPN. Ik hoop dat ze dit ook gaan toevoegen om het wat gebruikersvriendelijker te maken. Ik draai nu wireguard op mijn unraid server en bij mijn ouders op een raspberry pi met pivpn, en het exporteren van een client config via qr code is natuurlijk erg handig om die aan mijn telefoon toe te voegen.

Op dit item kan niet meer gereageerd worden.