Software-update: OpenVPN 2.6.0

OpenVPN logo (79 pix) OpenVPN is een robuuste en gemakkelijk in te stellen opensource-vpn-daemon waarmee verschillende private networks aan elkaar geknoopt kunnen worden door 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.6 uitgebracht en de belangrijkste veranderingen daarin zijn hieronder voor je op een rijtje gezet.

Keying Material Exporters (RFC 5705) based key generation

As part of the cipher negotiation OpenVPN will automatically prefer the RFC5705 based key material generation to the current custom OpenVPN PRF. This feature requires OpenSSL or mbed TLS 2.18+.

Compatibility with OpenSSL in FIPS mode

OpenVPN will now work with OpenSSL in FIPS mode. Note, no effort has been made to check or implement all the requirements/recommendation of FIPS 140-2. This just allows OpenVPN to be run on a system that be configured OpenSSL in FIPS mode.

mlock will now check if enough memlock-able memory has been reserved,

and if less than 100MB RAM are available, use setrlimit() to upgrade the limit. See Trac #1390. Not available on OpenSolaris.

Certificate pinning/verify peer fingerprint

The --peer-fingerprint option has been introduced to give users an easy to use alternative to the tls-verify for matching the fingerprint of the peer. The option takes use a number of allowed SHA256 certificate fingerprints.
See the man page section "Small OpenVPN setup with peer-fingerprint" for a tutorial on how to use this feature. This is also available online under https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst

TLS mode with self-signed certificates

When --peer-fingerprint is used, the --ca and --capath option become optional. This allows for small OpenVPN setups without setting up a PKI with Easy-RSA or similar software.

Deferred auth support for scripts

The --auth-user-pass-verify script supports now deferred authentication.

Pending auth support for plugins and scripts

Both auth plugin and script can now signal pending authentication to the client when using deferred authentication. The new client-crresponse script option and OPENVPN_PLUGIN_CLIENT_CRRESPONSE plugin function can be used to parse a client response to a CR_TEXT two factor challenge.
See sample/sample-scripts/totpauth.py for an example.

Compatibility mode (--compat-mode)

The modernisation of defaults can impact the compatibility of OpenVPN 2.6.0 with older peers. The options --compat-mode allows UIs to provide users with an easy way to still connect to older servers.

OpenSSL 3.0 support

OpenSSL 3.0 has been added. Most of OpenSSL 3.0 changes are not user visible but improve general compatibility with OpenSSL 3.0. --tls-cert-profile insecure has been added to allow selecting the lowest OpenSSL security level (not recommended, use only if you must). OpenSSL 3.0 no longer supports the Blowfish (and other deprecated) algorithm by default and the new option --providers allows loading the legacy provider to renable these algorithms.

Optional ciphers in --data-ciphers

Ciphers in --data-ciphers can now be prefixed with a ? to mark those as optional and only use them if the SSL library supports them.

Improved --mssfix and --fragment calculation

The --mssfix and --fragment options now allow an optional mtu parameter to specify that different overhead for IPv4/IPv6 should taken into account and the resulting size is specified as the total size of the VPN packets including IP and UDP headers.

Cookie based handshake for UDP server

Instead of allocating a connection for each client on the initial packet OpenVPN server will now use an HMAC based cookie as its session id. This way the server can verify it on completing the handshake without keeping state. This eliminates the amplification and resource exhaustion attacks. For tls-crypt-v2 clients, this requires OpenVPN 2.6 clients or later because the client needs to resend its client key on completing the hand shake. The tls-crypt-v2 option allows controlling if older clients are accepted.
By default the rate of initial packet responses is limited to 100 per 10s interval to avoid OpenVPN servers being abused in reflection attacks (see --connect-freq-initial).

Data channel offloading with ovpn-dco

2.6.0+ implements support for data-channel offloading where the data packets are directly processed and forwarded in kernel space thanks to the ovpn-dco kernel module. The userspace openvpn program acts purely as a control plane application. Note that DCO will use DATA_V2 packets in P2P mode, therefore, this implies that peers must be running 2.6.0+ in order to have P2P-NCP which brings DATA_V2 packet support.

Session timeout

It is now possible to terminate a session (or all) after a specified amount of seconds has passed session commencement. This behaviour can be configured using --session-timeout. This option can be configured on the server, on the client or can also be pushed.

Inline auth username and password

Username and password can now be specified inline in the configuration file within the <auth-user-pass></auth-user-pass> tags. If the password is missing OpenVPN will prompt for input via stdin. This applies to inline'd http-proxy-user-pass too.

Tun MTU can be pushed

The client can now also dynamically configure its MTU and the server will try to push the client MTU when the client supports it. The directive --tun-mtu-max has been introduced to increase the maximum pushable MTU size (defaults to 1600).

Improved control channel packet size control (max-packet-size)

The size of control channel is no longer tied to --link-mtu/--tun-mtu and can be set using --max-packet-size. Sending large control channel frames is also optimised by allowing 6 outstanding packets instead of just 4. max-packet-size will also set mssfix to try to limit data-channel packets as well.

OpenVPN

Versienummer 2.6.0
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.)

Door Bart van Klaveren

Downloads en Best Buy Guide

28-01-2023 • 14:27

13

Submitter: Munchie

Bron: OpenVPN

Update-historie

03-04 OpenVPN 2.6.14 0
15-01 OpenVPN 2.6.13 28
07-'24 OpenVPN 2.6.12 22
06-'24 OpenVPN 2.6.11 0
03-'24 OpenVPN 2.6.10 3
02-'24 OpenVPN 2.6.9 0
11-'23 OpenVPN 2.6.8 9
11-'23 OpenVPN 2.6.7 1
08-'23 OpenVPN 2.6.6 38
06-'23 OpenVPN 2.6.5 2
Meer historie

Reacties (13)

13
13
12
1
0
1
Wijzig sortering
Als je betere management tools wilt, layer 2 ondersteuning zoekt, of een tunnel over TCP wilt, dan kom je automatisch bij OpenVPN uit i.p.v. WireGuard. Het is allemaal niet zo vlot als WireGuard, maar het is er wel op vooruit gegaan. Recentelijk met de WinTun drivers en later nog met OpenVPN 3.
Direct TCP connection without VPN: close to 7Gbit/sec
OpenVPN 3 Windows reference client, using wintun: 904 Mbit/sec
OpenVPN 2 Windows client, using wintun: 737 Mbit/sec
OpenVPN 3 Windows reference client, using tap-windows6: 652 Mbit/sec
OpenVPN 2 Windows client, using tap-windows6: 414 Mbit/sec
https://community.openvpn...PerformanceTestingOpenVPN

Dit zijn precies de redenen waarom ik nog OpenVPN gebruik, waarbij een hoge doorvoersnelheid secundair is. Af een toe een potje "LAN" gaming op een TAP instantie voor games die aan UDP broadcasting doen, en vaak genoeg een hotspot omzeilen die alleen TCP 80 en 443 door laat (vakantie, hotels, enz).

Voor de rest erg benieuwd naar de nieuwe client-crresponse in deze release voor deferred authentication. Als je MFA doet op je OpenVPN server heeft het authenticatie proces interactie met een gebruiker. Als deze gebruiker ligt te slapen bij het invoeren van bijvoorbeeld een TOTP code dan blokt de OpenVPN server het authenticatie proces voor andere gebruikers.

Dat wordt binnen kort mijn user auth script aanpassen :) .
Het ligt inderdaad heel erg aan wat je nodig hebt. WireGuard is qua protocol gewoon sneller/moderner, alleen het schort aan tooling/managementsoftware.

Voor privé gebruik (naar huis ‘inbellen’, een VPS in je netwerk zetten, eventueel zelfs de netwerken van je ouders en jijzelf samenbrengen, in elk geval relatief statische zaken (opzetten en afblijven), is WireGuard gewoon practiser.
Maar zodra je het (klein)zakelijk gebruikt is toch meer controle nodig hebt of zaken als wat wanneer wel en niet en voor wie wel en niet dan is OpenVPN logischer.

Uiteraard is bovenstaande koort door de bocht en is er niks generieks te zeggen over wie wat nodig heeft.
Ik ben zelf in elk geval jaren geleden overgestapt naar WireGuard en het was met dezelfde hardware zo’n ongelofelijk snelheidsverschil, en ik bovenstaande zaken voor mijn gebruik niet nodig heb, dat ik geen reden ziet om zelfs nog maar te kijken naar OpenVPN.
Hoe is UDP only modern dan? Natuurlijk is dat sneller, dat is inherent aan het protocol.

Trouwens voor management kijk eens naar PiVPN

[Reactie gewijzigd door pennywiser op 24 juli 2024 00:31]

De drager UDP/TCP zie ik niet als modern of conservatief/ouderwets (afhankelijk van hoe je het wel verwoorden)

WireGuard is slechts circa 4000 regels code. Het is relatief nieuw en daarmee ‘modern’, het opzetten is kinderlijk simpel.
Het is snel en veilig. (Aldus auditeurs). Het heeft geen poespas of legacy (heeft het nog geen tijd voor gehad)
Het ondersteund alleen sterke cryptografie (kan je ook als een beperking zien)

OpenVPN kan je ook als ‘alleen UDP’ gebruiken. Toch is WireGuard vele malen sneller.
OpenVPN heeft ongeveer 20% overhead op UDP, WireGuard 4%

Wat ik met management bedoel, is met de PKI en dergelijke (sleutelrotatie, enz) en het op afstand beheren van de cliënts. OpenVPN heeft hier diensten voor. WireGuard vooralsnog niet. Daarmee is OpenVPN beter geschikt voor (klein)zakelijk gebruik dat Wireguard. Producten als PiVPN focussen zich voornamelijk op de server-kant, waar dit met WireGuard eigenlijk niet relevant is. (Qua protocol is iedere node gelijkwaardig)
Ik zeg nadrukkelijk niet dat PiVPN geen goed product is, maar het is niet waar ik op doelde :)
Ik zit nog is naar die synthetische benchmarks te kijken, maar een vertraging van een factor 7. Dat is eigenlijk best heftig. Hoe zit het eigenlijk met de latency en CPU-belasting met OpenVPN?
Vind het zelf vrij lastig om goede (beschreven) synthetische benchmarks te vinden. OpenVPN is zelf niet heel erg efficiënt dus gebruikte CPU, de verwachte doorvoersnelheid, eventuele netwerk optimalisaties en gebruikte ciphers kunnen heel veel verschil uitmaken. Met een oude OpenVPN en OpenTAP driver ben ik wel eens tegen een belachelijke factor 20 gelopen waar Wireguard een factor 2 deed over 10 gbps. In mijn privé opstelling haal ik een factor 1.3 over 1 gbps met OpenVPN 2.5.5 en WinTUN. Latency in deze opstelling heb ik niet in depth bekeken, want dat was gemiddeld +0 ms voor Wireguard en +1 ms voor OpenVPN. De resolutie waar ik op keek was echter 1 ms, dus waarschijnlijk gemiddeld 0.0-0.5 ms voor Wireguard en 0.5-1.5 ms voor OpenVPN.
En heb je ook praktijktests gedaan met jouw (test)opstelling? Dus bijvoorbeeld een groot bestand kopiëren via ssh/scp of FTP of juist een zwik kleine bestandjes?
Ik zal het zelf is doen, maar mijn VPS heeft dacht ik maar een uplink van 200MBit ofzo, dus ik weet niet hoe reëel het verschil dan wordt.

Dat is natuurlijk ook eigenlijk interessanter dan een synthetische benchmark als met iperf. Ik bedoel. Als je echt protocollen aan het debuggen bent is een synthetische test natuurlijk leuk, maar uiteindelijk moet het gewoon werken :)

Dus gewoon hetzelfde bestand ((een grote ISO ofzo, dus met echte data)) scp’en of via een Windows share of wat dan ook.
Uiteraard heb je dan met veel meer factoren te maken, maar het geeft wel een realistischer beeld van het ‘echte’ praktijkverschil.
Ter info mochten anderen ook problemen ervaren, heb persoonlijk 2 dagen geleden tweemaal geprobeerd mijn installatie te updaten naar deze versie. Beide keren leidde een reboot daarna tot een gebrickte Windows installatie die vast blijft hangen op het bootscherm met eindeloos draaiend cirkeltje, beide keren d.m.v. opstartherstel kunnen fixen waarna de update weer teruggedraaid was.
Je maakte mij wat huiverig om te updaten. Eerst maar eens een backup image gemaakt en daarna pas geïnstalleerd. Geen problemen ervaren op Windows 11 Pro 22H2
Hmm... nav je reactie toch nogmaals geprobeerd, draai zelf Windows 10 Pro 22H2, maar deze keer handmatig zowel OpenVPN als de TAP driver verwijderd, reboot en toen pas geprobeerd 2.6.0 te installeren. Dacht dat ik het probleem gevonden had aangezien ik een foutmelding kreeg bij het installeren van het TAP device en realiseerde me dat ik vergeten was dat WireGuard + OpenVPN op hetzelfde systeem al vaker voor problemen heeft gezorgd. Meestal kwestie van WireGuard verwijderen, OpenVPN installeren/updaten en dan weer WireGuard installeren. Werkte echter deze keer nog steeds niet, kon het TAP device pas installeren nadat ik mijn PIA client ook verwijderd had. Daarna gereboot en geprobeerd WireGuard en PIA te installeren, met weer een gebrickte windows installatie tot gevolg. Denk zelf dat het te maken heeft met een combinatie van OpenVPN 2.6.0 en de meest recente PIA client, ik blijf zelf voor nu nog even op 2.5.6 hangen, ga hier nu verder geen tijd meer in steken.

EDIT: kan bevestigen dat de combinatie OpenVPN 2.5.6 + meest recente PIA & WireGuard clients werkt zoals voorheen, maar OpenVPN 2.6.0 + meest recente PIA client is een recept voor ellende (op mijn systeem dan)

[Reactie gewijzigd door SW Simplicity op 24 juli 2024 00:31]

Mooi dat het is opgelost. Dat van die TAP drivers gaan we onthouden.. :)
Bor Coördinator Frontpage Admins / FP Powermod @SW Simplicity28 januari 2023 23:02
Ik heb geen enkel probleem ervaren op meerdere installaties. Weet je zeker dat het issue niet aan jouw kant ligt?
Hier op meerdere machines wel dit issue, ook zonder wireguard.
Al 3 machines in een boot-freeze, dus het is zeker iets wat vaker voorkomt.

Nu onze installers maar eens terug zetten naar de vorige versie tot dat dit gefixt word. Heb nog geen bug report gezien in de OpenVPN GitHub, dus misschien moeten we die maar eens even gaan maken...

Op dit item kan niet meer gereageerd worden.