Software-update: OpenVPN 2.5.5

OpenVPN is een robuuste en gemakkelijk in te stellen opensource-vpn-daemon waarmee verschillende private networks aan elkaar geknoopt kunnen worden door middel van een encrypted tunnel via internet. Voor de beveiliging wordt gebruikgemaakt van de OpenSSL-library, waarmee alle encryptie, authenticatie en certificatie kunnen worden afgehandeld. De ontwikkelaars hebben versie 2.5.5 uitgebracht en de belangrijkste veranderingen daarin zijn hieronder voor je op een rijtje gezet.

User-visible Changes

• SWEET32/64bit cipher deprecation change was postponed to 2.7
• Windows: use network address for emulated DHCP server as default this enables use of a /30 subnet, which is needed when connecting to OpenVPN Cloud.
• require EC support in windows builds (this means it's no longer possible to build a Windows OpenVPN binary with an OpenSSL lib without EC support)

New features

• Windows build: use CFG and Spectre mitigations on MSVC builds
• bring back OpenSSL config loading to Windows builds. OpenSSL config is loaded from %installdir%SSLopenssl.cfg (typically: c:program filesopenvpnSSLopenssl.cfg) if it exists.
• This is important for some hardware tokens which need special OpenSSL config for correct operation. Trac #1296

Bugfixes

• Windows build: enable EKM
• Windows build: improve various vcpkg related build issues
• Windows build: fix regression related to non-writeable status files (Trac #1430)
• Windows build: fix regression that broke OpenSSL EC support
• Windows build: fix "product version" display (2.5..4 -> 2.5.4)
• Windows build: fix regression preventing use of PKCS12 files
• improve "make check" to notice if "openvpn --show-cipher" crashes
• improve argv unit tests
• ensure unit tests work with mbedTLS builds without BF-CBC ciphers
• include "--push-remove" in the output of "openvpn --help"
• fix error in iptables syntax in example firewall.sh script
• fix "resolvconf -p" invocation in example "up" script
• fix "common_name" environment for script calls when "--username-as-common-name" is in effect (Trac #1434)

Documentation

• move "push-peer-info" documentation from "server options" to "client" (where it belongs)
• correct "foreign_option_{n}" typo in manpage
• update IRC information in CONTRIBUTING.rst (libera.chat)
• README.down-root: fix plugin module name

Versienummer	2.5.5
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website	OpenVPN
Download	https://openvpn.net/community-downloads
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (22)

[Videopac]

Kan Wireguard zich volledig meten aan OpenVPN, wat beveiliging betreft?

[rbr320]

Wat beveiliging betreft zeker. Sterker nog, de code van Wireguard heeft al een audit ondergaan, wat redelijk snel kon omdat het relatief weinig regels code zijn. De code van OpenVPN is volgens mij nog nooit in zijn volledigheid aan een audit onderworpen.

Wat features betreft missen er in Wireguard misschien nog wat dingen, zie daarvoor de andere reacties hier.

[The Zep Man]

Wat beveiliging betreft zeker. Sterker nog, de code van Wireguard heeft al een audit ondergaan, wat redelijk snel kon omdat het relatief weinig regels code zijn. De code van OpenVPN is volgens mij nog nooit in zijn volledigheid aan een audit onderworpen.

Wat een OpenVPN code review complex maakt is dat OpenVPN afhankelijk is van grote user-space libraries, zoals OpenSSL en anderen. Via die libraries kunnen een waaier aan ciphercombinaties geburikt worden. Doordat er zoveel keuze is, maakt het niet dat er een 'enkele' OpenVPN is om aan een audit te onderwerpen.

De WireGuard code is zo compact, inclusief de code voor cryptografie, dat een audit daarop makkelijk te doen was. Een voordeel van de simpelheid van WireGuard is dat je ook minder ruimte hebt om het slecht te implementeren. Dit in tegenstelling tot OpenVPN, die nog bijzonder veel legacy configuraties ondersteunt.

Wat features betreft missen er in Wireguard misschien nog wat dingen, zie daarvoor de andere reacties hier.

Sommige dingen zullen nooit aan WireGuard toegevoegd worden, doordat WireGuard stateless is. Het zal hierom geen totaaloplossing zijn voor veel situaties waarin OpenVPN dat wel is. Voor een point-to-point verbinding of een 'standaard' VPN provider verbinding werkt het echter goed.

[rbr320]

Bedankt voor je aanvullingen, klopt inderdaad helemaal. Overigens onderhoudt FoxIT een fork van OpenVPN genaamd openvpn-nl waar ze de afhankelijkheid van OpenSSL uit gesloopt hebben en die ook van een aantal van de vele configuratieopties die jij al noemt veilige defaults af dwingt. Deze fork wordt veel gebruikt binnen de Nederlandse overheid weet ik uit ervaring.

Ik heb zelf nog nooit iets met Wireguard gedaan maar dat wil ik zeker wel gaan doen binnenkort, ik ben benieuwd hoe makkelijk het is in gebruik.

[wica]

@Drobanir
OpenVPN en OpenVPN AS (het plaatje) zijn 2 verschillende producten.OpenVPN is opensource en heeft geen web interface, waar OpenVPN AS wel de web interface heeft, maar vanaf 3 gebruikers een licentie nodig en is onder tussen al op 2.10 zit

[Reactie gewijzigd door wica op 22 juli 2024 22:10]

[Drobanir]

ik zal kijken of ik een ander plaatje vinden kan,

[The Zep Man]

Alstu.

[GeroldM]

Volgens de link van @The Zep Man is het aantal VPN verbindingen tegelijkertijd teruggeschroefd van 3 naar 2, als je er gratis gebruik van wil maken. Op moment van het schrijven van deze post: tot 10 verbindingen tegelijkertijd moet er al 75 USD per maand worden afgerekend. Tot aan 25 connecties tegelijkertijd? 150 USD per maand.

[AddictIT]

Kan je met WireGuard elke client dan een eigen IP geven als die door de tunnel heen zijn gekomen?
Voor zover ik tot nu toe gevonden heb, gebruikt de NAT-translatie dan altijd het IP van de host waarop de tunnel getermineerd wordt.


Met OpenVPN kan je heel gemakkelijk een client IP toekennen, om vervolgens daarmee te gaan routeren server-side.

[The Zep Man]

Kan je met WireGuard elke client dan een eigen IP geven als die door de tunnel heen zijn gekomen?
Voor zover ik tot nu toe gevonden heb, gebruikt de NAT-translatie dan altijd het IP van de host waarop de tunnel getermineerd wordt.

Je kan met WireGuard voor een enkele peer gewoon meerdere IP's (of zelfs hele ranges) toewijzen, zonder dat je NAT nodig hebt. Dat de bekende VPN providers een enkel IPv4 adres (/32) en IPv6 adres (/128) toestaan voor jouw peer heeft te maken met zuinigheid aan hun kant.

Waar je zelf al naar hint is dat WireGuard geen IP beheer doet bij gebrek aan een (pseudo-)DHCP implementatie, in tegenstelling tot OpenVPN. WireGuard is hierom leuk voor kleinschalige implementaties of enterprise implementaties die out-of-band mechanismen hebben voor beheer. OpenVPN is uiteraard nog steeds een goede keuze in alle gevallen, zeker als CPU capaciteit geen probleem is.

Overigens is het gebrek van IP beheer voor WireGuard onderdeel van het ontwerp, als 'stateless' VPN oplossing. IP beheer is per definitie niet stateless, tenzij je het bijvoorbeeld hebt over SLAAC (IPv6). Daarmee zit je echter weer vast aan /64 ranges, waar men weer huiverig voor is. Of dat terecht is of niet, is een andere discussie.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:11]

[Faifz]

[...]
Je kan met WireGuard voor een enkele peer gewoon meerdere IP's (of zelfs hele ranges) toewijzen, zonder dat je NAT nodig hebt. Dat de bekende VPN providers een enkel IPv4 adres (/32) en IPv6 adres (/128) toestaan voor jouw peer heeft te maken met zuinigheid aan hun kant.

Ik begrijp je redenering helemaal niet. Wat bereik je met remote access VPN zonder NAT? Niets. Natuurlijk wordt al je traffic vertaald achter uw eigen publiek adres. Als je google zou bezoeken wordt het geNAT'ed achter het publiek adres van je VPN gateway.

Bedoel je dat je als een client een publiek /32 adres krijgt? Want je hebt het over zuinigheid en NAT. Je krijgt nooit een publiek adres toegewezen aan je VPN adapter.

Het klopt dat je NAT niet nodig hebt als je het internet niet oploopt, maar dit geldt ook voor OpenVPN of IPSec en je bent enkel alleen maar aan het routen en dit wordt gedaan door je router. Dus dat is niet gebonden aan de VPN keuze.

Verder is het niet echt zo aantrekkelijk om een statisch adres in te stellen op een VPN interface (client). Daar bereik je weinig mee en je bent sowieso beter af met IP beheer zoals jij het had genoemd een pseudo DHCP.

[Reactie gewijzigd door Faifz op 23 juli 2024 06:11]

[Sandor_Clegane]

Niet alle firewalls laten UDP door. Het heeft nog steeds een functie.

[The Zep Man]

WireGuard kan je over TCP draaien.

Of je dat echt zou moeten doen is een andere discussie.

[GieltjE]

Lastige is dan weer dat er geen android clients zijn die werken zonder root.
Eigenlijk is de ideale oplossing wireguard --> webserver --> websocket --> android client, dan zou je practisch alle firewalls kunnen omzeilen

[Tom Paris]

OpenVPN kan layer 2, WireGuard niet...

[The Zep Man]

OpenVPN kan layer 2, WireGuard niet...

Buiten uitzonderingsgevallen is layer 2 (TAP) tunneling niet echt interessant. Volgens mij gebruiken de meeste OpenVPN configuraties enkel layer 3 (TUN).

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:11]

[Tom Paris]

Klopt, voor de meeste use cases zal layer 3 inderdaad voldoende zijn. Maar er zijn dus wel degelijk use cases waar WireGuard (nog) geen volledig alternatief is voor OpenVPN, dat was de reactie.

[snoopdoge90]

Layer 2 TAP aangemaakt naast mijn TUN voor remote LAN parties tijdens COVID. Voor die oude games die nog aan layer 2 UDP broadcasting doen .

[Waswat]

Op pfSense is de wireguard package nog gemarkeerd als experimenteel

https://docs.netgate.com/.../vpn/wireguard/index.html

Dus wel leuk, maar dat laat nog even op zich wachten. Ik gebruik persoonlijk graag openvpn, vind het erg fijn en gaat prima. Weinig reden om momenteel over te stappen op iets experimenteels.

[Tom Paris]

Dat heeft te maken met de integratie in FreeBSD, niet zozeer met WireGuard zelf

[JeroenED]

Wireguard is leuk als je het kan opzetten. En dat laatste is in mijn ogen nog steeds een probleem.

Het werkt "anders" dan vb OpenVPN of ipsec waardoor sysadmins zich een nieuw paradigma moeten aanleren/gewoon worden. Het paradigma namelijk waarbij iedere peer evenwaardig is en je geen server/client model hebt. (had ikzelf ook moeite mee)

Daarnaast ondersteuning vanuit hardware vendors. Ik heb zelf op mijn Unifi Gateway het package wel geïnstalleerd staan. Ik kan eventueel een Docker Container voor opzetten. Maar installatie dmv een simpele gui aanpassing is bij de meeste vendors niet mogelijk, of enkel mogelijk vanuit experimental packages. Om dan nog maar te zwijgen van system updates die je DKMS-module verwijderen.