WireGuard is opgenomen in OpenBSD

Ontwikkelaars hebben de in-kernel driver voor WireGuard geïmplementeerd in OpenBSD. De verwachting is dat het opensourceplatform voor vpn zijn debuut maakt in versie 6.8 van het besturingssysteem.

De integratie van WireGuard in OpenBSD is bekendgemaakt op de mailinglijsten van WireGuard en OpenBSD. Het gaat om de WG-kerneldriver in het besturingssysteem, waaraan WireGuard-ontwikkelaars Matt Dunwoodie en Jason Donenfeld het nodige werk hebben gehad.

Ze verklaren dat het upstreamen van de code een prettige ervaring was en dat ze veel hebben gehad aan de feedback op de drie patchrevisies die nodig waren. Ook spreken ze de verwachting uit dat de WireGuard-implementatie in de uiteindelijke release van OpenBSD 6.8 verschijnt.

De integratie volgt op de komst van WireGuard naar de Linux-kernel 5.6. WireGuard is een opensourceapplicatie en -protocol, en heeft in korte tijd sterk aan populariteit gewonnen door zijn beperkte codebase. De software moet het instellen van vpn gemakkelijk maken en snelle, veilige verbindingen opleveren. Door de beperkte codeomvang is de software snel door te lichten op beveiligingsproblemen.

Door Olaf van Miltenburg

Nieuwscoördinator

22-06-2020 • 10:37

59

Submitter: Rafe

Reacties (59)

59
59
36
1
0
4
Wijzig sortering
Ik vraag me af hoe ze dat licentie technisch voor elkaar gekregen hebben.
De kernel onderdelen van Wireguard zijn vrijgegeven onder de GPLv2 maar
OpenBSD gebruikt de BSD licentie voor de kernel :?
De originele ontwikkelaars behouden de volledige rechten over de originele code. Die hebben ze daarna een keer aangepast voor Linux en onder de GPL vrijgegeven en daarna nogmaals voor OpenBSD onder de BSD licentie.

Het wordt pas een probleem als je code van anderen onder een andere licentie probeert te gebruiken, zoals het geval is bij OpenZFS, dat oorspronkelijk onder de CDDL is vrijgegeven. Daarom kan het ook niet in de Linux kernel worden opgenomen, totdat Oracle de code onder een GPL-compatible licentie vrijgeeft.
Iemand een idee of het zo vlot in FreeBSD kan geraken? Draai nu de GO-implementatie en die draait moo stabiel maar een native kernel-implementatie lijkt me toch beter en sneller.
En daarmee dus pfsense?
Pfsense/OPNsense is FreeBSD, dus wel te verwachten. Wel moet er dan nog een uitbreiding gemaakt worden door iemand om er een frontend php op te plakken maar gezien de populairiteit zal dat ook niet al te lang duren
OPNsense heeft de plugin "os-wireguard" al. Daarmee lijkt het mij dat je wireguard kan instellen. Wireguard hoeft niet perse in de kernel te zitten.
PFSense gebruikt de FreeBSD kernel. Dus ik denk dat we voorlopig nog even moeten wachten.. helaas.
Gebruik pfSense zelf niet dus geen idee.

Als het al in de kernel opgenomen wordt zal het waarschijnlijk in de laatste zijn: 12.2 (misschien backporten naar 12.1). De huidige versie van pfSense draait voor zover ik kan zien op 11.3 en de volgende versie 2.5 staat gepland om FreeBSD 12.0 te gebruiken. Dus of het snel in pfSense beschikbaar zal zijn hangt af wie het wil backporten in de oudere kernels.
Tenzij je hele bijzondere setup hebt zal je het verschil niet merken. Je ziet vaak gedeelde code, bij FreeBSD ligt de lat net wat anders dus dat kan je inderdaad wel verwachten!
Is wat ik vermoed. In het begin had ik wat last om een deftige snelheid te halen (3 MB/s op een 100MBps lijntje) maar tegenwoordig haar ik toch vlotjes 8-9MB/s. Dus meer zal ik er niet uit persen.
Dat WireGuard sneller is heb ik zelf een tijdje terug ondervonden. Ik draaide altijd OpenVPN of een variant. Ik haal nu een stuk hogere snelheid met langzame zuinige hardware. Het instellen is gemakkelijk.

GL inet heeft veel travel routertjes (die met USB power werken) en WireGuard ondersteunen. Vind ze heerlijk werken.

Even ter vergelijking Onderstaande met dezelfde "slappe" hardware:
OpenVPN: 150Kb/s
WireGuard: 3,5MB/s (mijn max upload)

[Reactie gewijzigd door Cave_Boy op 27 juli 2024 15:10]

Kan Wireguard inmiddels TCP? Overigens haal ik 100 Mbit (sneller is mijn lijn niet) met Openvpn, TCP, op een eenvoudige Pi.
Indien TCP nodig is kan je UDPTunnel in combinatie met WireGuard proberen.
TCP Mode
WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard's UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.
https://www.wireguard.com/known-limitations/

[Reactie gewijzigd door job_h op 27 juli 2024 15:10]

Geen wonder dat het zo snel is dan. Daarbij heb je dan nog steeds te maken met de praktijk dat tegenwoordig vrijwel alle openbare wifi netwerken udp niet doorlaten en/of de Wireguard udp poort blokkeren.

@job_h TCP (over poort 443) is bijna altijd nodig, tenzij je bijna nergens VPN wilt kunnen gebruiken. Ik ga er eens naar kijken inderdaad, maar zie niet direct de meerwaarde boven Openvpn.

[Reactie gewijzigd door pennywiser op 27 juli 2024 15:10]

Welke netwerken zijn dat dan? WhatsApp gesprekken (voice of video) gebruiken ook UDP en die werken doorgaans prima.
Ik gebruik OpenVPN nu gemultiplexed over poort 443 met regulier SSL verkeer. Daarnaast ook nog OpenVPN op poort 53/UDP en 123/UDP. Ik ben nog geen netwerk tegengekomen waar ik niet gewoon doorheen kom. Wireguard is leuk, maar zolang deze scenario's niet werken zal ik gewoon OpenVPN moeten gebruiken.
Heb je 2 instances draaien welke op UDP en TCP luisteren? Multiplexen doe ik zelf met SSLH.
Ik zou er even in moeten duiken, maar ik had uiteindelijk OpenVPN op poort 443 draaien alles wat geen OpenVPN verkeer is wordt naar een Apache reverse proxy op poort 443 op een andere host in de DMZ doorgezet.
Oh ja ook handig op die manier, tnx.
Bedrijfsnetwerken. Ik werk zelf in een bedrijf dat poort 80 en 443 open heeft, en de rest is dicht.

IMAP/SMTP? Nee. Videobellen? Enkel met de applicatie die het bedrijf goedgekeurd heeft. Iets over UDP? Tuurlijk niet.

Dan is het wel fijn als je VPN op poort 443 draait, kan je tenminste je mail ophalen e.d.
Die poort zal dan ook heel bekend zijn en vrijwel overal openstaan denk je niet? Net als TCP poort 25, 80, 443.
Wireguard is niet gebonden aan een specifieke poort. Je kunt elke willekeurige poort gebruiken. Ook poort 443/UDP zoals gebruikt door QUIC (en straks HTTP/3).

Wellicht dat WhatsApp IP adressen zijn ge-whitelist op de netwerken die bent tegengekomen. Zelf heb zelf nog maar 1 keer meegemaakt dat WireGuard niet werkte.
En niets belet jouw om diezelfde poort te gebruiken. Op UDP is dat 3478. Er is een zeer goede reden waarom je geen TCP over TCP wenst te encapsuleren, je loopt het risico van een zogenaamde TCP meltdown
Nee dat kan ook, ik volg echter de meest beschreven methode: 443. TCP meltdown, het zal allemaal wel. Dat komt ook alleen voor bij TCP stacking volgens mij.

[Reactie gewijzigd door pennywiser op 27 juli 2024 15:10]

Poort 25 is voor onderlinge communicatie tussen mailservers. De meeste publieke AP's zullen die dicht hebben staan zodat je niet een klant hebt die tijdens het koffiedrinken even een fikse spamrun komt doen.

Een vriend van mij was ooit betrokken bij het vervolgen van spammers en die pakten eens een spammer op die een mailserver draaide op de laptop op de passagiersstoel. Even parkeren voor een horecagelegenheid en er een miljoen spammails uitsturen...
Goed punt, niet alleen onderling maar Outlook bv. ook, die zal dan op zo'n hotspot niet kunnen uitmailen inderdaad.
Mail clients horen poort 587 of 465 te gebruiken voor het versturen, niet 25.
Wireguard kan gebruik maken van meerdere poorten, dus makkelijk dit protocol blokkeren is niet aan de orde. Dit in tegenstelling tot IKEv2 wat gebruik maakt van een vaste poort.

Overigens kan je ook gebruik maken van "gewoon" OpenVPN met de Wintun driver. Dit levert een aanzienlijke snelheidsverbetering op:

Performance numbers:
Server - openvpn 2.4.4
tap-windows6: 390Mbit/s
wintun: 730Mbit/s
Server - openvpn3 with kernel acceleration
tap-windows6: 405Mbit/s
wintun: 1.05Gbit/s

bron: http://staging.openvpn.net/openvpn2/
Bijna alle poorten, op enkele lage poorten na, staan vrijwel altijd dicht, overal op bijna elk zakelijk, openbaar netwerk. Uitzonderingen genoeg uiteraard. Behalve TCP 443 (https), want anders kan je niet surfen op dat netwerk. En dat is dan ook waar mijn Openvpn overheen gaat.

Ik heb geen behoefte aan snelheidswinst, ik heb het snel zat nu.
Ik heb hem op poort 21 gezet, sindsdien nergens problemen meer (en wie gebruikt er nu nog FTP?)
dat is niet mijn ervaring. heb in februari een vakantie in de VS gevierd en kon daar op zon beetje elk open netwerk (maar ook in NL, ik heb geen data op mijn telefoonabbo!) prima over UDP communiceren met mijn WireGuard op ene PI Zero.
Mijn 3 internet verbindingen lopen met redundancy al een jaartje over wireguard, dus alle protocollen gaan gewoon over wireguard heen via udp, inclusief TCP.

Zo goed als alles gaat prima over UDP aangezien het send en forget is. Beetje vergelijkbaar met analoge signaal, of het komt aan, of niet.

Mocht een applicatie TCP gebruiken dan zorgt TCP er wel voor dat er retransmissie plaatsvind ;)

Wel zorgen dat je MTU goed ingesteld op 1440 (of 1420 voor ipv6 :P)

[Reactie gewijzigd door Marctraider op 27 juli 2024 15:10]

Kun je op publieke hostspots over udp connecten? Welke bijvoorbeeld? Dat zullen er niet veel zijn. Hoe een applicatie connect is niet zo belangrijk, dan werkt je vpn al.
ik heb het hier in NL nog nooit meegemaakt dat op ik hotspots of gastennetwerk niet kon connecteren. kijk bedrijsnetwerken is wat anders dan blokkeren ze vaak alles op de bekende poorten maar hotspots en gastenWiFi.. nooit meegemaakt
De vraag is volgens mij ook niet hoe vaak dit voor komt, die discussie is voor mij niet belangrijk, maar hoe verhoog ik mijn kans om op zoveel mogelijk plekken te kunnen connecten. Het is niet zo dat je je config wel even om kan gooien onderweg.
OpenVPN kan met een Raspberry pi 3 (versie 4 heb ik niet getest) haalde ik met medium settings (met beveiliging) 50Mbit/s a 60Mbit/s behalen.

Het kan wel over TCP maar het schijnt wel iets in snelheid in te kakken.
Ik heb een Orange Pi Zero Plus (met gigabit).
life is too short for tcp
Ik kom moeiteloos tot 12 MB/s (via OPNsense (limiet op 150 Mb/s) naar OpenBSD in hetzelfde netwerk (gastennetwerk naar interne netwerk fw, die verzorgt de uiteindelijke link naar buiten, moet nog veranderen). Gaat nog wel verder toenemen denk ik. OPNsense is oude i7, OpenBSD draait op oude i5, linksnelheid is 500 Mb/s up/down, intern is gigabit netwerk. Test via speedtest.xs4all.nl. Test vanaf mijn android telefoon. :)

[Reactie gewijzigd door daemonix op 27 juli 2024 15:10]

De kracht van WireGuard is juist je hoeft geen energieslurpende hardware te gebruiken om hoge snelheden te behalen. :Y)
De i5 is niet energieslurpend (25 W), en ik wil wel zeker stellen dat ik de 500 Mbit/s vol kan krijgen met allerlei filtering en IPS technieken. :P Daar volstaat een RPI echt niet. Bovendien valt dat verbruik in het niet bij de grote servers die hier draaien.
Tenslotte wil ik wel de AES zaken die ik heb ook in hardware laten afhandelen en niet door de processor in software. Het zou zo maar kunnen dat het een tunnel endpoint is van meer VPN netwerken. :+
Dat hoeft met Openvpn ook niet. Zit dat in Opnsense btw?

[Reactie gewijzigd door pennywiser op 27 juli 2024 15:10]

precies ik heb een PI Zero. zon beetje de minste variant en het vliegt er over!
Knappe prestatie van de Wireguard auteurs om opgenomen te worden in de OpenBSD kernel! Hulde. Zo langzaam aan krijgen we overal een ingebakken VPN

Edit: typo

[Reactie gewijzigd door Aanwezig op 27 juli 2024 15:10]

<mierenneuken>
Correctie Wireshark = Wireguard.
</mierenneuken>

Maar zeker knap ja. Want openbsd is naar ik meen nog steeds security first. Dus de constatering van Linus dat de code van Wireguard heel helder was/is zou zo maar waar kunnen zijn ;)
<mierenneuken>
Correctie Wireshark != Wireguard.
</mierenneuken>
ftfy
Inderdaad een knappe prestatie om dit in zo'n korte tijd voor elkaar te krijgen. Ik verwacht dat het iets te maken heeft met gebruik van bewezen externe onderdelen (bv voor encryptie), dan hoef je dat namelijk niet meer te ontwikkelen.

Het gaat hier overigens niet om Wireshark (ook handig), maar om WireGuard. Een andere applicatie dus ;)
Ik heb ooit WireGuard gebruikt en vond het fijn, maar ik ben gestopt omdat je niet een traditioneel login/wachtwoord (of enkel wachtwoord) kan gebruiken.

Mijn use-case voor VPN (gebruik nu L2TP/IPSec):

Ik ben bij een collega/vriend/klant en moet even prive-gegevens zien te benaderen die alleen beschikbaar zijn op mijn LAN.

Voor wireguard moet ik vooraf op de server een public key toevoegen. Het is onmogelijk om vooraf de publieke key te weten die gegenereerd wordt op de machine van de client. En meerdere keren dezelfde publieke/private key her-gebruiken werd streng afgeraden of was onmogelijk (herinner ik mij niet meer zo goed).

Is dit ondertussen verbeterd?

Verder is mijn ervaring dat WG een Point-To-Point verbinding is, ik kan dus niet met meerdere WG clients naar 1 server verbinden, en dan met meerdere WG clients tussen elkaar praten. Is hier ook al vooruitgang in geboekt?

Eigenlijk heb ik altijd de volgende wensen gehad:

- Server eenmalige setup doen, nooit meer aanraken of veranderen (dus inloggen met server IP+wachtwoord)
- VPN clients moeten tussen elkaar kunnen communiceren

Als dit ondertussen mogelijk is in WireGuard dan denk ik dat ik het nogmaals ga proberen.

[Reactie gewijzigd door grasmanek94 op 27 juli 2024 15:10]

meerdere keren dezelfde publieke/private key her-gebruiken werd streng afgeraden of was onmogelijk (herinner ik mij niet meer zo goed). Is dit ondertussen verbeterd?
Nee, en dat zie ik ook niet zo snel gebeuren want een wachtwoord is erg zwak qua beveiliging. Keys hergebruiken wordt idd afgeraden maar kan wel. Ik zou voor je eigen apparaten een unieke key genereren en een aparte key voor het "inloggen vanaf een vertrouwde computer die niet van mij is"-scenario. Mocht die laatste onbedoeld ergens rondslingeren waar het niet hoor dan kan je die verwijderen als vertrouwde public key van je server.
Verder is mijn ervaring dat WG een Point-To-Point verbinding is, ik kan dus niet met meerdere WG clients naar 1 server verbinden, en dan met meerdere WG clients tussen elkaar praten. Is hier ook al vooruitgang in geboekt?
Is dit niet een kwestie van routeren? https://jrs-s.net/2018/08...nterfaces-with-wireguard/
En hoe zit het met DHCP bijvoorbeeld? Als ik de situatie nu zie moet je bij WG zelf je IP vanaf de client invoeren. Dan moeten meerdere gebruikers onthouden welke IP's ze al gebruikt hebben en nog mogen gebruiken. Heel onpraktisch en kan voor IP conflicts zorgen.

Ik denk dat ik nog wel ff wacht met dit als mijn main VPN gebruiken :( Jammer want is wel vele malen sneller dan alle andere VPN's.
Ik ben niet zo'n VPN goeroe, maar ik kreeg het één en ander niet voor elkaar. Bij OpenVPN kan ik split tunnel gebruiken, maar bij WireGuard niet, iemand een idee?
Dit kan bij wireguard ook. Ik heb in wireguard profiel op mijn telefoon dns server veranderd van 10.6.0.1 naar het ip van mijn raspberry pi en bij peer allowed ip's ook veranderd naar het ip van mijn pi. Dat is alles.

Je kan controleren of het werkt op www.ipleak.net
Bij ip zou dan ip van je mobiele provider moeten staan en bij dns het ip van de door jouw gebruikte dns server.
Thanx, ik ga morgen nog even verder prutsen :)
Gefeliciteerd WireGuard! Ik draai al geruime tijd WireGuard op mijn Raspberry Pi naar volle tevredenheid. Supermakkelijk te configureren op mijn iPhone en heel snel.

Ik zie inmiddels de melding dat WireGuard niet in productie omgevingen moet worden gebruikt ook niet meer op hun website staan dus ze beschouwen zichzelf nu ook als betrouwbaar en volwassen.
edit; Verkeerde link, foutje

[Reactie gewijzigd door GameNympho op 27 juli 2024 15:10]

Dat is WireCARD we hebben het hier over WireGUARD. :)
Holy moses, 1 lettertje en ik nagel m al neer. Ik zal m aanpassen thnx
Dacht echt het zelfde bedrijf :F

Op dit item kan niet meer gereageerd worden.