Netgate verwijdert WireGuard uit pfSense na bugs FreeBSD-implementatie

Netgate heeft de kernel-mode versie van WireGuard uit zijn op FreeBSD gebaseerde router- en firewallsoftware pfSense gehaald. De stap volgt na een besluit om de WireGuard-module wegens meerdere problemen nog niet mee te nemen in de 13.0-release van FreeBSD.

Netgate meldt WireGuard uit pfSense te halen om de software grondig door te lichten. Als WireGuard uiteindelijk toch in FreeBSD belandt, bekijkt het bedrijf het toevoegen aan een toekomstige versie van pfSense weer. Netgate introduceerde halverwege februari pfSense Plus versie 21.02 en pfSense Community Edition versie 2.5.0 met daarbij in preview kernelimplementatie voor WireGuard.

De ontwikkeling van WireGuard voor pfSense werd gesponsord door NetGate. De ontwikkeling duurde meer dan een jaar en in november werd de port committed naar FreeBSD door ontwikkelaar Matt Macy. De bedoeling was dat deze in de kernel van FreeBSD 13.0 zou verschijnen, een release die op korte termijn zou uitkomen.

Na de aankondiging van Netgate over de implementatie in de pfSense-releases maakte WireGuard-grondlegger Jason Donenfeld bekend dat hij samen met andere FreeBSD- en OpenBSD-ontwikkelaars serieuze problemen gevonden had in de port en dat de versie niet gereed was voor release. Hij had het daarbij over onder andere kernelpanics, buffer overflows en andere showstoppers.

Een week lang bugfixen door Donenfeld en FreeBSD-ontwikkelaars Kyle Evans en Matt Dunwoodie mocht niet baten. "Een opvallend noemenswaardig iets is dat er 40.000 regels van geoptimaliseerde crypto-implementaties uit de Linux-kernel compat module zijn gehaald, maar niet correct aangehaakt, en onherstelbaar gemangeld zijn met doolhoven van Linux-naar-FreeBSD-ifdefs", meldt Donenfeld hierover, zoals uitgelicht door Ars Technica. Donenfeld beklaagt zich over de gebrekkige communicatie door een niet nader genoemde populaire leverancier van firewalls, die een ontwikkelaar opdracht gaf voor een WireGuard-implementatie, zonder contact op te nemen met het project.

Reacties (40)

[job_h]

Het idee van Netgate was erg netjes. Er zijn user-space implementaties van Wireguard voor FreeBSD (welke bijvoorbeeld door OPNsense gebruikt wordt), maar Netgate/pfSense leek het een beter idee om een kernel implementatie te maken, om hogere prestaties te behalen. Daarna hebben ze deze beschikbaar gesteld voor FreeBSD 13.

Helaas lijkt het ontwikkel traject niet heel soepel verlopen te zijn en toen de Netgate code klaar stond voor FreeBSD 13 oordeelde Jason Donenfeld (de originele ontwikkelaar van Wireguard) dat de code van Netgate ondermaats was. Hierna is een ware soap in open source land ontstaan en staat Netgate/pfSense (helaas alweer) negatief in de spotlight.

De soap-achtige tijdlijn vanaf 16 maart, inclusief bronnen:
1. Jason Donenfeld (de ontwikkelaar van Wireguard) doet zijn verhaal. Hij geeft aan dat er nauwelijks samenwerking was met de ontwikkelaar van Netgate en dat de code die klaar stond om over 2 weken in FreeBSD 13 te komen ondermaats was. Quote: "I imagined strange Internet voices jeering, “this is what gives C a bad name!”". Hij vertelt daarna dat hij, Kyle Evans (FreeBSD kernel ontwikkelaar) en Matt Dunwoodie (ontwikkelaar die Wireguard naar OpenBSD geport heeft) een week praktisch non-stop gewerkt hebben om de implementatie enigszins acceptabel te krijgen. https://lists.zx2c4.com/p...rd/2021-March/006494.html
2. Scott Long (Netgate) stuurt een prive mail naar Jason. (zie punt 4 voor bron)
3. Scott Long (Netgate) plaatst een blog over de situatie. Hij geeft aan dat hij de aanpak van Jason niet kan waarderen, noemt het een aanval en geeft aan dat de Netgate implementatie veilig is. https://www.netgate.com/b...curity-and-community.html
4. Jason Donenfeld (Wireguard) reageert publiekelijk op de prive mail van Scott. Hij stelt dat hij teleurgesteld is in de gang van zaken en dat hun belangen helemaal niet veel verschillen, ze willen beiden een stabiele Wireguard implementatie in de FreeBSD kernel en hij zou graag samenwerken. De kernel implementatie van Wireguard wordt voor nu uit FreeBSD gehaald en verder ontwikkeld als out of tree module. https://lists.zx2c4.com/p...rd/2021-March/006499.html
5. Scott Long (Netgate) update zijn blog post, waardoor het iets genuanceerder is. (zie punt 3 voor bron)
6. Jim Thompson (Netgate) plaatst een blog post waar hij stelt dat ze hun Wireguard implementatie onder de loep gaan nemen en voor nu uit pfSense 2.5 en pfSense Plus 21.02 gaan verwijderen. https://www.netgate.com/b...fsense-plus-software.html
7. Kyle Evans (FreeBSD) reageert. Ik zou het samenvatten als "Jason heeft het niet heel netjes aangepakt, maar hij had wel gelijk dat de code ondermaats was". https://lists.zx2c4.com/p...rd/2021-March/006525.html

[Reactie gewijzigd door job_h op 26 juli 2024 10:25]

[GekkePrutser]

Waarbij ik wel een kanttekening moet plaatsen dat Jason Donenfeld bekend staat om zijn uitstekende en minimalistische (hoe minder regels hoe minder kans op fouten) code.

Dus zijn woord telt wat dat betreft wel zwaarder voor mij; hij heeft immers uitgebreid aangetoond verstand van zaken te hebben.

Ik vind ook dat dit heel anders had gekund hoor. Maar inhoudelijk klopt het allemaal wel, dat beaamt die Kyle ook.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 10:25]

[job_h]

Het is zeker opvallend hoeveel compacter de code van Jason/Kyle/Matt is ten opzichte van de Netgate code. Ik geloof ook zeker dat het nettere code is en een goede zaak is dat dit gebeurt is.

De relevante commit in FreeBSD: https://cgit.freebsd.org/...48da19004c58b3581cd367843

Jason had zijn verhaal anders kunnen verwoorden, maar ik vind vooral de manier waarop Netgate hier op gereageerd heeft jammer. Het is geen reactie die ik bij een professioneel bedrijf vind passen en het is ook niet de eerste keer dat ze in de aanval gaan als iets niet loopt zoals verwacht.

Trixwood heeft het hieronder wat rommelig verwoord, maar hij heeft wel gelijk, de manier waarop Netgate een aantal jaar geleden actief OPNsense zwart gemaakt heeft verdient niet de schoonheidsprijs. Dat was destijds voor mij voldoende reden om over te stappen van pfSense naar OPNsense. Qua functionaliteit zijn ze grotendeels gelijk, ik heb het gevoel dat OPNsense actiever ontwikkeld wordt en ik vind de UI fijner (al vind ik dat niet heel belangrijk in een firewall). Ik ben ondertussen al een paar jaar een tevreden OPNsense gebruiker

[Reactie gewijzigd door job_h op 26 juli 2024 10:25]

[SB[NL]]

hoe minder regels hoe minder kans op fouten

Het probleem is volgens zelden het te veel aan regels code, maar juist te weinig regels
1 regel code kan immers nog steeds fouten bevatten

Juist de deel stappen volledig uitschrijven maakt het voor jezelf en anderen makkelijker te begrijpen en dus ook te debuggen/onderhouden en dus minder kans op fouten. Dat is mijn inziens de beste manier om fouten te voorkomen (zichzelf uitleggende code).

ps
Eerlijkheidshalve vond ik het als jonge programmeur echt een sport om alles te minimaliseren tot ik die ene geniale regel voor elkaar had ....met vervolgens weer tig regels aan comments erbij voor het geval ik vergat wat ik daar precies aan het doen was >:D

[farlane]

Het probleem is volgens zelden het te veel aan regels code, maar juist te weinig regels

Het gaat er om dat je zo veel code gebruikt als nodig, maar niet meer. Maar..

Eerlijkheidshalve vond ik het als jonge programmeur echt een sport om alles te minimaliseren tot ik die ene geniale regel voor elkaar had

is precies niet de bedoeling

[DancingMonkey]

Ik neem aan dat je met minimalistisch bedoelt dat er minder if statements of andere condities in zitten?

Condities en if statement zijn vaak de punten waar het fout gaat, helemaal als je nested if statements gebruikt en de cyclomatic complexity omhoog schiet

[darkfader]

Of als je exception handling moet toepassen of te maken hebt met communicatie met talloze foutcodes. En vervolgens meerdere lagen aan software hebt waarbij je deel van die afhandeling op andere niveaus afhandelt.
Soms kun je ook gewoon af met asserts en het proces helemaal opnieuw laten opstarten in geval er een fout optreedt.

[trixwood]

Netjes...

Zoals netgate website die ze over opfsense maakte... zoals je al benoemde?
Wauw...

https://opnsense.org/opnsense-com/

Het inhuren van een hele rare developer...

https://arstechnica.com/gadgets/2021/03/in-kernel-wireguard-is-on-its-way-to-freebsd-and-the-pfsense-router/?comments=1&post=39747020

Het aanvallen van de developer

https://lists.zx2c4.com/pipermail/wireguard/2021-March/006499.html

En het pushen van buggy code... totdat... deze "soap"

Je kan het goedlullen wat je wil... maar een soap kan ik het niet noemen, meer toxic... en dit is zeker niet de eerste keer...

Je mag je afvragen hoe de rest van hun code base is... en of je wel vertrouwen heb in een bedrijf die zo reageerd. Maar owwww... ze staan "weer" in een negatief spotlight. Tsss...

Er zijn meer van hun netwerk producten zo lek als een mandje... blijkbaar ligt de focus niet op security en vriendelijkheid...

Bedrijf om te vermijden. It's like an abuse boyfriend, if you smart you don't go back... and definitely not defend them..


ps in the wayback machine gezien wat voor website ze hadden gemaakt over opnsense?
de manier waarop ze reageren op dit totdat het publiek werd? de artikelen over hun secure "smart" switches, die ze dan voor de helft patchte na jaren? waar ik nog steeds handig gebruik van maakt om ze uit te lezen als tweaker. Etc..

Een soap noem je het... of het een cable tv show is... wauw... security is a soap... nothing to see here... move along...

soap bubble does "pop"...

[Reactie gewijzigd door trixwood op 26 juli 2024 10:25]

[WeiserMaster]

En het pushen van buggy code... totdat... deze "soap"

Een soap noem je het... of het een cable tv show is... wauw... security is a soap... nothing to see here... move along...

zonder om op de inhoud van dit commentaar in te gaan - kan iemand anders deze tekst zonder moeite lezen?
Ik heb het een aantal geprobeerd, die punten maken het nogal apart om de inhoud te verwerken

[trixwood]

Sorry... vrijdag avond en ik blijf een nerd.

punt 1. https://web.archive.org/w.../http://www.opnsense.com/ ging behoorlijk ver, veel rancune... das geen soap, das pure haat...
punt 2. mailing list van https://lists.zx2c4.com, veel boosheid van netgear poppetje(s) t.o.v. wireguard devs. ongeveer hetzelfde als punt 1 maar nog steeds na jaren. mooi om te zien dat de wireguard devs het toch proberen het vriendelijk te houden en de netgear poppetjes dachten, jah dat publiceren ze toch niet... :-)
helaas bleef het niet "in house"
punt 3. het steeds goedpraten, van dingen die behoorlijk fout gaan, op het enge af. Maar welk bedrijf en/of mensen met een vested interest doen dat niet? soap klinkt heel erg schoontjes, net zoals de toon van het artikel van tweakers, en dit is een shit show. Helaas is het heel menselijk gedrag om, met wat voor reden dan ook, dingen goed te praten, die het niet zijn...
punt 4. het zo lek als een mandje zijn netgear producten, uhm github voor de gewone tweaker waar je genoeg terug kan vinden voor toegang tot netgears (oude) apparaten inclusief code vooral omdat ze nog steeds oude zooi verkopen (in een nieuw jasje), of enige andere uhm pro security site (niet alles heeft helaas een CVE). google is your friend. en jah ik gebruik het. scheelt behoorlijk veel geld voor sommige pro functionaliteit. Elk nadeel heeft een voordeel. En tevens zijn er ook andere gebruiken mogelijk.
punt 5. het haastig toevoegen van features, door onbekwame mensen (of het nou devs zijn of management)... en dan als er backlash is het proberen goed te spinnen... punt 3?
punt 6. als deze code, die door een brakke dev & management werd gepushed om wat voor rede dan ook, en alleen door backlash word gecancelled, al niet klopt. Zou jij nog vertrouwen hebben in de rest van de code base? zie ook punt 4.

punt 7. Mea culpa :-) Dingen opschrijven is niet mijn ding...

[t_o_c]

Heb je het nou over Netgear of Netgate? Dat zijn verschillende bedrijven...

[GewoonWatSpulle]

Dingen (na)lezen is ook niet zijn sterkste punt, ben inmiddels wel erg benieuwd naar wat zijn sterke punten dan wel zijn!

[Jogai]

Waarom is een kernel implementatie zo veel verschillende tov een userspace implementatie? Lijkt me dat de core hetzelfde is en dat er eea anders ingehaakt/geïnitieerd moet worden?

[johnbetonschaar]

Waarom is een kernel implementatie zo veel verschillende tov een userspace implementatie? Lijkt me dat de core hetzelfde is en dat er eea anders ingehaakt/geïnitieerd moet worden?

Ik heb geen kennis van FreeBSD maar als ik het artikel goed begrijp lijkt het er op dat de FreeBSD kernel standaard nog niet over de benodigde crypto infrastructuur beschikte en dat die min of meer gecopy/paste is van de Linux versie en vervolgens alle Linux-specifieke code paden zijn omgelegd naar FreeBSD-specifieke code paden middels #ifdefs. Als je daar fouten in maakt door bijvoorbeeld verkeerde parameters of buffer sizes of wat dan ook te gebruiken in kernel calls, dan zou dat tot een enorm veiligheidslek kunnen leiden. In de kernel draait code met privileges om zo ongeveer al het geheugen van elk proces in het systeem te kunnen benaderen en andere aspecten van het system uit te lezen en te beïnvloeden. Daarom moet alle code die in kernel space draait extreem defensief geschreven zijn, het absolute minimum noodzakelijk doen, en zeer intensief gereviewed zijn.

[matty___]

Ondertussen is Kyle niet meer de maintainer en heeft Jason hem van de mailinglist verwijdert (volgens hem op Reddit)
Nadat Kyle de initiële mail van Jason heeft genuanceerd
https://lists.zx2c4.com/p...rd/2021-March/006525.html

[Jazco2nd]

Wel handig om erbij te vermelden dat dit iets anders is dan de userspace Wireguard die gewoon prima werkt en nog steeds op freebsd probleemloos geïnstalleerd kan worden en werkt.

De kernel versie zou wat sneller zijn, maar als eind gebruiker maakt dit hele verhaal dus eigenlijk niks uit.

[The Zep Man]

De kernel versie zou wat sneller zijn, maar als eind gebruiker maakt dit hele verhaal dus eigenlijk niks uit.

Klopt. Het is een luxeprobleem. WireGuard in user space presteert beter dan OpenVPN in user space, dus voor die paar use cases waarvoor WireGuard de voorkeur geniet is het gewoon mogelijk om het te gebruiken. Voor al het andere is er... OpenVPN.

Waar WireGuard overigens echt uitblinkt zijn embedded devices met beperkte CPU capaciteit. Denk aan OpenWRT (Linux) routers. Daarop met de kernel module is het zoveel sneller en lichter dan bijvoorbeeld OpenVPN.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 10:25]

[Zer0]

Klopt. Het is een luxeprobleem.

Voor clients misschien, maar voor een router/firewall kan de performance wel degelijk een issue zijn. En laat pfSense nu net een router/firewall OS zijn.....

[The Zep Man]

[...]

Voor clients misschien, maar voor een router/firewall kan de performance wel degelijk een issue zijn.

Als prestaties met WireGuard een probleem zijn, dan zijn ze dat ook met OpenVPN. De simpelste oplossing is om er meer hardware tegenaan te gooien.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 10:25]

[Zer0]

Dat is inderdaad een simpele oplossing... maar ik zie liever intelligente oplossingen, zoals een goede kernel-mode implementatie. Is ook zeker niet onmogelijk, linux laat dat zien.
En wat heeft OpenVPN er mee te maken? Ik gebruik wireguard voornamelijk als alternatief voor ipsec tunnels, OpenVPN is voor mij nog nooit een alternatief geweest, juist vanwege performance.

[_JGC_]

Het voordeel van Wireguard zit hem vooral in het snelle encryptie algoritme die zonder hardware offloading ook snel kan zijn op beperkte apparaten. Als ik een VPN gateway ergens optuig, zorg ik voor AES-NI en werk ik met AES-GCM ciphers.
Overigens gaat de voorkeur dan nog steeds uit naar IPsec ipv OpenVPN of Wireguard.

[nopcode]

Ja maar ik wil IPSec vervangen

[tweaknico]

En ook telefoons etc. De lage overhead voorkomt een aanslag op de batterijen.

[N8w8]

Wat dat betreft is IPsec (IKEv2) ook wel noemenswaardig.
Dat kan nog sneller zijn dan Wireguard, en is mooi geintegreerd in Windows/Android etc.

Ik vond het wel lastig op te zetten, mede omdat ik Windows niet snap en daarom zelf Linux draai.
Maar toen de stand van Neptunus eenmaal gunstig was, heb ik het werkend kunnen krijgen en het goed gedocumenteerd.

Wireguard (of OpenVPN) zou ook gekund hebben, als dat voor users even makkelijk aan/uit te zetten is. Sowieso zou dat makkelijker geweest zijn voor mijzelf.
Maar nu IPsec eenmaal werkt zie ik daar weinig meerwaarde in.
iig, ten opzichte van IPsec is het voordeel van Wireguard niet de snelheid maar de eenvoud.

[job_h]

Op FreeBSD en OPNsense kan je inderdaad al een paar jaar de userspace versie gebruiken en die werkt prima.

Netgate/pfSense had er echter voor gekozen een kernel implementatie te maken en heeft deze daarna beschikbaar gesteld aan FreeBSD. De kwaliteit van deze versie bleek helaas ondermaats. Hierop is het uit de FreeBSD development tree verwijderd en later (na een hele soap aan verwijten over en weer) ook uit pfSense 2.5 zelf.

Dit is dus een hele soap in open source land. Netgate staat helaas negatief in de spotlight, nu over hoe de ontwikkeling gegaan is en hoe ze daarna reageerden op de 3 mensen (de maker van wireguard, een FreeBSD developer en een OpenBSD developer) die de code wilden verbeteren voordat het in FreeBSD 13 terecht zou komen.

Ik zal na m'n werk m'n reactie wat aanpassen met wat bronnen

Edit: Ik heb de bronnen in een aparte post gezet, anders zou deze reactie wel wat te lang worden: job_h in 'nieuws: Netgate verwijdert WireGuard uit pfSense na bugs FreeBSD-im...

[Reactie gewijzigd door job_h op 26 juli 2024 10:25]

[Maurits van Baerle]

Een goeie zet dit. Beter iets later dan buggy code in je kernel hebben zitten. Al helemaal voor iets als een VPN waar je niet alleen stabiliteit wil maar ook de garantie dat de encryptie ook echt werkt.

Voorlopig gebeurt de ontwikkeling hier in de git repository van Donenfeld: https://git.zx2c4.com/wireguard-freebsd. Als die versie een beetje redelijk werkt zullen we wel eerst een optionele 'kernel mod' versie zien die mensen van Freshports kunnen halen en als kmod in hun kernel laden. De verwachting is nu dat hij met FreeBSD 13.1 in de kernel meegeleverd kan worden.

[Rolfie]

Mijn eerste reactie zou zijn, hoe zit dit met OPNSense die hiervoor ook een plugin heeft.

[Maurits van Baerle]

Dat is een userspace versie, die wordt hier niet door beinvloed. Het betekent hooguit dat OPNSense iets langer moet wachten tot ze een kernel-space versie kunnen aanbieden.

[3dmaster]

Jammer, ik had net al een aantal tunnels van openvpn naar wireguard gezet ivm de enorme snelheidswinst.

Het moddergooien is trouwens al begonnen in deze blog
https://www.netgate.com/b...curity-and-community.html

[freshy98]

Daar is Netgate nou eenmaal erg goed in :-)

[3dmaster]

Ik ben groot fan van pfsense, maar dit is toch altijd weer jammer

[freshy98]

Ik was geen fan, en al helemaal niet meer sinds opnsense bestaat en welke shit bepaalde figuren van netgate en hoe het vroeger heette) ze gegeven hebben.
Ik blijf er al 6 jaar ver van weg.

[sfranken]

Je kunt toch de userspace implementatie blijven gebruiken dan?

[Q]

Voor wie het leuk vind, dit onderwerp is ook besproken in de podcast 2.5 Admins. Onder andere FreeBSD ontwikkelaar Allan Jude zit in deze podcast. Ze gaan iets meer in op de achtergrond, ik vond het informatief.

[CAPSLOCK2000]

Jammer dat nog niet klaar is voor productie, maar mooi om te zien dat het proces zo goed werkt dat Netgate zelf kan beslissen om die module weg te laten. En dan bedoel ik niet alleen dat ze mogelijkheid hebben om het weg te laten (bits weghalen is niet zo moeilijk) maar vooral dat ze het inzicht hebben om een onderbouwde beslissing te nemen.

Wel jammer dat die developer zo lang in isolatie heeft gewerkt, dat van die 40.000 regels crypto-code uit de compatibility-laag klinkt niet zo best. Zo zie je maar weer: "Release early, release often!"

Gaaf om te zien hoe snel Wireguard groeit. Vijf jaar geleden bestond het nog niet en nu is het een van de belangrijkste VPN-protocollen en wordt het ondersteund door alle grote platforms. Het gemak en de snelheid waarmee het werkt is dan ook vrij overtuigend.

Ik moet er wel bij zeggen dat Wireguard wat minder features heeft dan OpenVPN. Vanuit het "doe 1 ding en doe dat goed"-principe is dat een prima keuze, maar daarom is het niet altijd geschikt als drop-in-replacement. Je zou zelfs kunnen argumenteren dat WG daarom minder veilig is dan OVPN, bv omdat WG geen 2FA ondersteunt. Je moet WG dus vooral zien voor wat het is: een flinterdun laagje om verkeer door een versleutelde tunnel te laten gaan. Dat doet het geweldig.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 10:25]

[i-chat]

Ik moet er wel bij zeggen dat Wireguard wat minder features heeft dan OpenVPN
[...]
Je zou zelfs kunnen argumenteren dat WG daarom minder veilig is dan OVPN, bv omdat WG geen 2FA ondersteunt.

ik heb die discussie wel eens eerder gezien maar het komt er bij mij toch steeds weer op neer dat 2fa op networkstack niveau in zekere mate ook weinig te bieden heeft.
Een combinatie tussen een userbase in bijvoorbeeld ldap combineren met een toegangs-token in je vpnserver is een connectie die ik persoonlijk liever niet zou maken.

een kennelijk vaker voorgestelde optie zou zijn om achter je vpn een captive portal te hangen dat identificatie en authorisatie afhandelt.
Simpel gezegd: met een private-key-file krijg je toegang tot de portal en met je username, wachtwoord en je token krijg je toegang tot je digitale werkplek.

De beveiliging is dan ook 'beter' gescheiden, met een username + password en toegang tot het mobieltje, moet je dan nog steeds een geautoriseerd systeem bemachtigen om in te loggen, maar met een gestolen laptop heb je nog steeds weinig kans op toegang tenzij je iemands online identiteit weet te bemachtigen.

Ik vind het daarom meer dan logisch dat er geen MFA of LDAP sync in wiregard thuis zou moeten horen. het vernauwd namelijk alleen maar de attacksurface

[Reactie gewijzigd door i-chat op 26 juli 2024 10:25]

[CAPSLOCK2000]

Ik ben het helemaal met je eens. Het is een beetje appels en peren vergelijken.
Als je in isolatie kijkt naar WG en OVPN dan kun je zeggen dat OVPN wel MFA heeft en WG niet.
Dus dat WG in totaal minder veilig is.

Maar je moet zo'n systeem niet in isolatie bekijken maar je kan beter naar het grotere plaatje moet kijken.
Ik ben het ook eens met je stelling dat het beter is om de verschillende onderdelen te scheiden en dat het dus prima is dat WG zich op precies 1 functie richt. Dat je die andere fucnties beter ergens anders kan onderbrengen.

Het heeft ook wel te maken met het ouderwetse model van een netwerk als een kasteel met dikke muren om de binnenkant veilig gescheiden te houden van de boze buitenwerld. In dat model was een VPN een extra deur en uiteraard moet je zo'n deur zwaar beveiligen met een ophaalbrug en valhek. Maar dat is dus een ouderwets model dat sinds BYOD niet meer houdbaar is en sinds de Cornoa Lockdown al helemaal niet meer.
Ik zie OpenVPN als de kasteelmuur met een poort. Ik zie Wireguard als een harnas. Je gebruikt het om losse mensen veilig te houden als ze van A naar B moeten, verder niks.

[Faifz]

Dus in principe stel je gewoon voor dat we het model zero-trust relationship niet moeten volgen? Captive Portal gebruik je voornamelijk voor BYOD devices om IP-adressen aan LDAP credentials te koppelen. En dat is hard nodig want in een fatsoenlijke omgeving heb je security policies op je firewall staan die LDAP users alleen maar toegang bieden voor bv web-browsing.

Verder is het de bedoeling dat je een Identity Provider (zoals Okta of Duo) gebruikt en vaak wordt SAML gebruikt (single-sign-on) hiervoor i.p.v. RADIUS. Als je SAML gebruikt voor je VPN dan is het echt zinloos om nog Captive Portal erachter te hangen. Het is erg belangrijk dat je MFA hebt wanneer je SAML gebruikt.

[Borromini]

Jammer dat nog niet klaar is voor productie, maar mooi om te zien dat het proces zo goed werkt dat Netgate zelf kan beslissen om die module weg te laten. En dan bedoel ik niet alleen dat ze mogelijkheid hebben om het weg te laten (bits weghalen is niet zo moeilijk) maar vooral dat ze het inzicht hebben om een onderbouwde beslissing te nemen.

Da's een rooskleurige weergave van de feiten. Die zijn:

• Netgate betaalt een programmeur om een kernel-implementatie van WireGuard voor FreeBSD te schrijven. De oorspronkelijke ontwikkelaar (Jason Donenfeld) krijgt daar lucht van en biedt hulp aan maar Netgate negeert 'm.
• Netgate roert de trom over WireGuard in hun volgende release. Jason heeft dan zelf al aangegeven dat hij die code nog niet klaar acht voor upstreaming. Opnieuw doet Netgate alsof zijn neus bloedt.
• De door Netgate betaalde code wordt onder de loep genomen naar aanloop van de op handen zijnde FreeBSD-release en blijkt niet te voldoen aan de standaarden voor crypto en/of FreeBSD (in dat tweede geval kan je je afvragen waarom de code überhaupt gemerged werd).
• Jason beslist met twee andere BSD-ontwikkelaars (waarvan één van FreeBSD zelf) de code drastisch te herschrijven, en daarbij wordt duidelijk dat de code niet klaar is voor productie en dus ook niet voor de volgende FreeBSD-release (wat een streep is door de plannen van Netgate).
• Oa. door het artikel op Ars Technica krijgt het hele verhaal (en de houding van Netgate) ruchtbaarheid en Netgate vindt opeens dat zijn goede naam geschonden is, en zij reputatieschade lijden.

Je zou Netgate het voordeel van de twijfel kunnen geven, ware het niet dat 1) de oorspronkelijke ontwikkelaar van een killer feature zijn pogingen tot contact negeert (want werd breed rondgebazuind dat WireGuard in de nieuwe pfSense zou zitten) en 2) ze al eerder tegenover opnSense een heuse lastercampagne hebben opgezet.

Ik denk dat Jason te allen prijze wou vermijden dat dit een 'release early, release often' zou worden .