https://nixos.wiki/wiki/OpenVPN

De broncode is beschikbaar, dus ik zie het probleem niet. Overigens zou ik liever zien dat ze WireGuard gebruiken.

Die is er wel: https://search.nixos.org/packages?channel=26.05&query=openvpn#show=openvpn

Waarom sentyron er geen heeft moet je aan sentyron vragen

Verder geen idee wat sentyron is

Sentyron is volgens mij een partij die de HW/SW tak van Fox Crypto/Fox-IT heeft overgenomen. OpenVPN-NL is een “hardened” versie van OpenVPN.

Die versie van OpenVPN is niet de modernste. ;) Het is maar de vraag of daar geen kwetsbaarheden in zitten aangezien het laag gerubriceerde info mag transporteren.

Willen we dat?

Ja en nee, Wireguard werkt beter, als het werkt.
Het suffe is dat, omdat het UDP based is, de client altijd aangeeft geconnect te zijn ook al is de server down. Dat gaat heel veel gebruikers vragen opleveren.

Dat heeft niks speciaal met UDP te maken.

TCP heeft ook geen keepalive detectie in de core specificatie , alleen de (erg vaak geimplementeerde) _mogelijkheid_ (optional feature) van TCP keepalive.
Vaker zit er in een applicatie protocol (zoals bv SSH) een eigen keep alive optie.
Een VPN protocol, ongeacht encapsulatie methode zou een keepalive optie kunnen implementeren.


Verder is qua performance een encapsulatie zonder buffering/retransmit gewoon beter voor TCP-payload verkeer.
Of het nu UDP, GRE, IPSec is - de payload-TCP krijgt dan een correct beeld van de netwerk omstandigheden (drops, toenemende latency) om transmit rate bij te sturen zoals TCP ontworpen is.
TCP-in-TCP maskeert die karakteristieken en leidt tot slechtere performance van de interne TCP sessie wanneer er congestie of packet loss is.

https://en.wikipedia.org/wiki/Tunneling_protocol zie TCP meltdown.

Inderdaad UDPis connectieloos en er vind geen foutcorrectie plaats. Is bij een video stream ook niet echt nodig. Daar is throughput veel belangrijker. Bij TCP wordt er garantie geleverd dat de gegevens aankomen zoals ze verstuurd werden, en eventuele communicatiefouten, zowel in de gegevens zelf als in de volgorde van de gegevens kunnen worden opgevangen. Een keep alive bericht is op dit niveau onzinnig. Het enige wat van belang is, is of de lijn vrij is om een pakketje te versturen.

Uh ?
Het ging over VPN protocollen - je noemt een videostream gewoon als voorbeeld ? Of je vond dat een voorbeeld waarin 'wat' packetloss niet erg zou zijn ?

Voor internet-breed gebruik van services met een behoorlijk volume heb je een protocol/algorithme nodig dat ook aan congestie-controle doet .

En voor iets als een VPN _service_ wil je ook liever een vorm van keepalive, zodat je resources kunt vrijgeven van sessies die niet meer in gebruik zijn.
Er is echt wel wat te zeggen voor een VPN service die "weet" of de pseudo- "verbinding" up of down is - en als dat niet in het transport/encapsulatie protocol zit, kan het deel van het VPN control plane verkeer zijn.


Overigens : ook (juist) in een videostream is packetloss erg zichtbaar - En de streams van de bekende streamingdiensten (youtube,netflix, etc ) zijn in HLS of DASH - maar met een transport protocol dat retransmissie en congestion control doet . TCP of QUIC .
QUIC is UDP based maar heeft ook flow control en retransmissie in het QUIC protocl. Een tussenlaag-protocol dat UDP als drager gebruik dus. https://en.wikipedia.org/wiki/QUIC

In elk geval : voor een tunneling encapsulation wil je simpelweg retransmissie of flowcontrol overlaten aan het gedrag van de payload protocollen . UDP, GRE, IPIP, IPSec doen dat allemaal vanzelf.

Tuurlijk kun je alles stuk maken maar feit is dat TCP een ack stuurt en UDP shoot en forget is

Je redeneert alsof er iets wegvalt als UDP gebruikt wordt, maar dat is niet zo. Het ingepakte TCP-verkeer gebruikt gewoon acks, en die worden net als andere pakketjes ook in UDP-pakketjes ingepakt en verstuurd. Op IP-niveau maakt het voor de bezorgkans geen donder uit of er TCP of UDP of wat anders in zit. De acks uit de TCP-laag worden dus met of zonder Wireguard precies even betrouwbaar bezorgd, zou ik verwachten. Er gaat niets stuk, die acks van TCP zijn er gewoon.

Je maakt juist dingen stuk als je TCP in TCP gaat verpakken, omdat het mechanisme van TCP om netwerkcongestie te voorkomen dan op twee niveau's tegelijk werkt, mede gebaseerd op die acks, en die twee niveaus verstoren elkaars goede werking. Acks heb je maar op één niveau nodig, en je kan ze op meer dan één niveau tegelijk missen als kiespijn.

Dat is geen keep alive waar jij het over had.

Inderdaad. _RON_ haalt acknowledgement and keep-alive door elkaar, en dat zijn heel verschillende zaken.

En zoals 13:48 correct uitlegt - de ACKs van payload-TCP komen gewoon terug (of niet) ge-encapsuleerd in UDP wanneer je daarmee een VPN bouwt.
En dan kan payload-TCP opnieuw sturen als de ACK niet aankwam - en het TCP window vergroteren of verkleinen afhankelijk van de geobserveerde latency en packet loss.

OpenVPN-NL is een speciale versie (gecontroleerde cryptografische libraries, zonder 'slechtere' configuraites) die Sentyron voor de NL overheid onderhoudt. Zie: https://www.aivd.nl/documenten/2026/10/01/inzetadvies-openvpn-nl en https://openvpn.sentyron.com/

Recent gekeken naar OpenVPN NL maar deze schijnt gecertificeerd te zijn in 2020, dus loopt achter.
Het product loopt achter qua TLS versie 1.2 maar claimt dat gebruik van zwakke protocollen niet mogelijk is omdat ze Mbed TLS gebruiken i.p.v. OpenSSL.
Als je kijkt naar OpenVPN met OpenSSL dan zit deze op TLS 1.3 en kun je ook geen zwakke protocollen meer gebruiken.
Vraag me af in hoeverre OpenVPN NL nog iets toevoegt qua beveiliging.

OpenVPN met TOTP op OPNsense met GeoIP en blacklists lijkt met beter dan OpenVPN NL.

NixOS, naam zegt het al..

"We willen toch graag binnen Nederland overstappen naar NixOS?"
Dat bepalen we zelf wel, toch?

Laat iedereen vrij voor eigen keuze, lijkt me beter.
Tja, sorry hoor.. met zo'n reactie lokt je dit ook uit.

On-topic,
Suc6 met zoeken, hopelijk vind je een passende oplossing.

Het belangrijkste verschil is dat OpenVPN NL niet kijkt naar "features", maar naar "assurance".

Waar een standaard installatie van OpenVPN met OpenSSL enorm veel functionaliteit biedt, is dat in een high-security context juist een risico. OpenSSL is een enorm grote library; de complexiteit maakt het een geliefd doelwit voor exploits en maakt een volledige audit complex. OpenVPN NL gebruikt mbedTLS juist omdat dit een minimalistische footprint heeft. Minder code betekent minder plek voor bugs en maakt het daadwerkelijk mogelijk om de software volledig te auditen en te verifiëren.

Daarnaast is OpenVPN NL een "hardened fork". Het doel is het elimineren van zogenaamde 'footguns': complexe configuratie-opties die door een menselijke fout tot een onveilige setup kunnen leiden. Door onnodige functionaliteit simpelweg te verwijderen, wordt de kans op misconfiguratie weggenomen.

Wat betreft je suggestie voor OPNsense: GeoIP, blacklists en TOTP zijn vormen van perimeter security (extra muren om het huis), maar ze lossen geen kwetsbaarheden in de applicatie zelf op. Bovendien is GeoIP-filtering in feite een vorm van 'security through obscurity' een serieuze aanvaller huurt simpelweg een VPS of gebruikt een VPN in een land dat op jouw allowlist staat om de filter te omzeilen. Daarnaast is een VPN juist bedoeld voor gebruikers die onderweg zijn en geen vaste locatie of IP hebben, waardoor dergelijke filters vaak meer hinderen dan echt beveiligen.

Als er een buffer overflow of een logische fout in de VPN-binary zit, helpen die filters niet. OpenVPN NL richt zich op applicatiebeveiliging: het huis zelf onverwoestbaar maken. Voor wie maximale zekerheid wil, is een minimalistische, geauditeerde fork die menselijke fouten uitsluit fundamenteel veiliger dan een feature-rijke versie die wordt omringd door externe filters.*

lol. Ik gok dat de poster hier https://code.overheid.nl/MinBZK/DAWO-NixOS mee bedoelt, een door de overheid opgezette, op NixOS gebaseerde desktop environment. Dat verklaart waarschijnlijk waarom er specifiek over het overstappen binnen Nederland wordt gesproken. Zie ook https://dawo.community/

Je verhaal daar kan ik me in vinden maar ik ben niet overtuigd. Ben al langer bezig met OpenVPN en Wireguard en mijn voorkeur gaat uit naar Wireguard als je het hebt over een minimalistische footprint. Ik geloof niet dat OpenVPN NL uit 2020 beter scoort que beveiliging dan OpenVPN op OPNsense waar ik extra beveiligingslagen kan toevoegen achter de reguliere firewall.

En wat het nog obscuurder maakt is dat OpenSSL FIPS-gecertificeerd is en mbedTLS niet.

Voor overheidsprojecten of strikte Enterprise-beveiliging is een FIPS-certificering vaak verplicht; OpenSSL heeft deze certificeringen direct beschikbaar.

Dan zou ik nog voor een veel betere en veiliger TLS stack gaan dan OpenSSL, het stikt nog steeds van de dead-ends, met onvoorspelbare resultaten. LibreSSL is stukken beter en veel beter geaudit.

Interessant onderwerp wat te veel onderbelicht blijft en opmerkelijke verschillen toont die wellicht door andere factoren wat genuanceerder benaderd moeten worden.

De huidige status:

Het klopt dat OpenSSL historisch gezien een slechte reputatie heeft opgebouwd door complexe kwetsbaarheden (zoals Heartbleed).

Alternatieven zoals LibreSSL en mbed TLS zijn specifiek ontworpen met een focus op een kleinere codebasis en extreme focus op veiligheid.

Maar toch ligt de werkelijkheid tegenwoordig genuanceerder. Sinds de grote kwetsbaarheden uit de periode 2014-2016 is OpenSSL fundamenteel veranderd.

En hieronder e.e.a. naast elkaar gelegd:

1 - Bibliotheek: 2 - Focus / Sterkpunt: 3 - Grootste Beveiligingsvoordeel: 4 - Keerzijde:

1 - OpenSSL (3.x); 2 - Universele standaard, brede hardware-acceleratie; 3 - Enorm veel audits, snelle patches, moderne architectuur; 4 - Zeer grote en complexe codebasis (attack surface).

1 - LibreSSL; 2 - Veiligheid door eenvoud (schoongemaakte OpenSSL-fork); 3 - Geen legacy-code, proactieve mitigatie tegen geheugenfouten; 4 - Loopt soms achter op nieuwe standaarden; mist brede app-support.

1 - mbed TLS; 2 - Embedded systemen, IoT en extreem lichte code; 3 - Zeer leesbare, modulaire code; minimale footprint; 4 - Minder geschikt voor high-performance servers (beperktere crypto-optimalisatie).

Opmerkelijk:
OPNsense heeft jarenlang een officiële LibreSSL variant aangeboden naast OpenSSL maar is sinds OPNsense 22.7 volledig stopgezet vanwege incompatibiliteit met plugins en de trage adoptie van TLS 1.3

Dat OpenVPN NL nu gezien wordt als veilig lijkt me achterhaalt en gaat nog meer achterhaald worden gezien de traagheid in certificering die jaren op zich kan laten wachten en in tussentijd werk je nog steeds met een zwakker protocol TLS 1.2 i.p.v. TLS 1.3. Op dit moment is TLS 1.3 state-of-the-art security en niet TLS 1.2

Er is een keepalive optie waarbij elke x seconden een.packet wordt gestuurd...
Dus down detectie is mogelijk. De keep alive is nodig voor stabiele twee richting verkeer opties achter nat of zelfs cgnat. Het is een client side optie.

Ander voordeel van Wireguard is dat portknocking niet bruikbaar is voor verkenning, omdat alleen correcte pakketten een response opleveren.

Wireguard werkt gewoon en aan de netwerkstatistieken in de cliënt kun je prima zien of je verbinding hebt. En wat betreft gebruikersvragen , die blijven altijd bestaan want daar zijn het gebruikers voor, welk product je ook gebruikt.

Kijk op de website en zie dat ze iets met het Ministerie van Binnenlandse zaken etc. te maken hebben, meer in het bijzonder de AIVD

Ik ben het met je eens dat WireGuard een uitstekend, modern alternatief is, zeker met de integratie in de kernel en die extreem kleine footprint. Technisch gezien is het een simpel en duidelijk protocol.

Toch is er een wezenlijk verschil in wat deze tools bieden. In extreem gevoelige omgevingen waar je maximale 'assurance' wilt, zijn er features die WireGuard mist en die cruciaal kunnen zijn voor een veilige uitrol. Denk bijvoorbeeld aan de native ondersteuning voor TOTP, die bij WireGuard volledig ontbreekt.

Wat betreft FIPS: dat is in mijn ogen meer een kwestie van compliance dan van feitelijke security. Een FIPS-certificering is een stempel van de NIST die bevestigt dat specifieke algoritmes correct zijn geïmplementeerd onder bepaalde omstandigheden. Het is geen garantie dat de rest van de applicatie vrij is van bugs of kwetsbaarheden. Sterker nog, door het trage, bureaucratische proces loopt FIPS vaak significant achter op de actuele stand van de techniek.

WireGuard is prima voor veel scenario's, maar in high-security contexten waar je specifieke beheersmaatregelen en garanties nodig hebt, biedt een hardened fork zoals OpenVPN NL meer zekerheid. Zeker wanneer we kijken naar de toekomst: terwijl WireGuard nog niet post-quantum proof is, is dat met de SentryRon-implementatie binnen OpenVPN NL juist wel het geval. Dat maakt het op dit moment een toekomstbestendigere keuze voor bepaalde gevoelige data.

Dat "als het werkt" leek mij meer iets dat bij OpenVPN hoort.
Of... gewoon in deze thread; OpenVPN op NixOS.

In mijn optiek is het bijna moeilijk om WireGuard niet werkend te hebben.

Default UDP is shoot en forget, echter je kan in het protocol bovenop UDP wel een ACK mechanisme bouwen.
Ik heb ooit met een real time hoog volume messaging systeem gewerkt, > 100Mbit/sec, dat over UDP data verstuurde en werkte met een NACK, elk pakket had een sequence nummer en als de ontvanger binnen x tijd alle sequence nummers had ontvangen dan rapporteerde die niets terug en bleef die de ontvangen data verwerken.
Ontbrak er echter een sequence nummer in de ontvangen berichten dan stuurde de ontvanger een NACK bericht terug met het ontbrekende sequence nummer en als de verzender dat nog in zijn buffer had dan stuurde die dat opnieuw.
Had de verzender het het bericht niet meer dan rapporteerde de ontvanger het verlies van data.

Mee eens maar, zoals je zelf al aangeeft, door hetzelfde bureaucratische proces loopt nu dus ook OpenVPN NL achter omdat het niet meer dan TLS 1.2 ondersteunt en het nog jaren kan duren voordat TLS 1.3 geïmplementeerd wordt en kan OpenVPN NL mij die zekerheid zeker niet meer geven.

Je kijkt over 1 belangrijk detail heen, GeoIP-filtering zorgt ervoor de je de bomen door het bos weer kunt zien en waarom voor landen iets openzetten waar je sowieso niets mee te maken hebt. Je redenatie vind ik een te kort door de bocht genomen aanname en een zelfs een zeer gevaarlijke aanname.

GeoIP is 1 van datgene waar je gebruik van kunt maken naast nog een aantal andere voorzorgsmaatregelen waardoor OpenVPN of OpenVPN NL een stuk veiliger wordt. Om het nu 'security through obscurity' te noemen vind ik veel te kort door de bocht aangezien niemand kan garanderen dat de andere aangeboden oplossingen geen kwetsbaarheden bevatten.

Nee hoor heel makkelijk.

Vul in je client maar een random ip in en klik op connect. De client geeft aan dat hij happy is terwijl er aan de andere kant niet eens een WG server is. Het is al stuk zonder dat het ooit gewerkt heeft, gebruikers snappen er niets van dus een drama voor beheerders.

Ik ben ruim een jaar geleden met de OpenVPN=-L gestopt omdat deze niet meer ondersteund werd zonder een nieuw alternatief met bijvoorbeeld TLS1.3. Daarom bood OpenVPN geen enkele assurance meer. Dan is Wireguard beslist meer secure en zeker meer assurance.

Nee hoor blijkbaar een drama voor jullie helpdesk. Beheerders hebben andere dingen aan hun hoofd