Mullvad heeft OpenVPN volledig uitgefaseerd en vervangen door Wireguard

Mullvad heeft het OpenVPN-protocol volledig uitgefaseerd uit zijn vpn. De servers daarvoor zijn niet meer te gebruiken, nadat het protocol eerder ook uit de code was gehaald. Mullvad kondigde eerder al aan te stoppen met OpenVPN.

OpenVPN is sinds donderdag niet meer te gebruiken in Mullvad. Die datum was al bekend; Mullvad waarschuwde daar in december nog voor. Sinds donderdag is het niet meer mogelijk te verbinden via OpenVPN. Mullvad ondersteunt alleen nog Wireguard. Het bedrijf raadt gebruikers aan om te upgraden naar dat protocol.

Mullvad verwijderde de code voor OpenVPN al in versie 2025.14 van de app. Die kwam halverwege december uit. Mullvad hield de servers waarop OpenVPN werkte nog wel een maand open, maar heeft die nu alsnog gesloten.

Mullvad maakte in 2024 al bekend dat het OpenVPN zou uitfaseren. Ook noemde het toen al een exacte datum. Mullvad vindt al jaren dat Wireguard een beter protocol is, omdat dat makkelijker is voor beheerders en omdat de algoritmes makkelijker kunnen worden geroteerd.

Reacties (18)

[gertvdijk]

omdat de algoritmes makkelijker kunnen worden geroteerd

Wat een onzin. Wireguard kan juist by design helemaal niet over op andere algoritmes, omdat het geen control channel heeft. De protocolspecificatie heeft het allemaal vastgelegd.

The following protocols and primitives are used:

• ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction
• Curve25519 for ECDH
• BLAKE2s for hashing and keyed hashing, described in RFC7693
• SipHash24 for hashtable keys
• HKDF for key derivation, as described in RFC5869

Juist OpenVPN heeft hier allemaal opties net als met TLS om tot een overeenkomstig ondersteund algoritme te komen (data-ciphers / ncp-ciphers, tls-ciphers, etc.). Het niet hebben van die feature en alles predefined/hardcoded doen is ook een voordeel voor de veiligheid (simpeler is soms juist beter).

[Reactie gewijzigd door gertvdijk op 16 januari 2026 14:01]

[noskill]

Back in early 2015, we were asked by TorrentFreak which cryptographic primitives we recommend. Our answer: "...ideally we would recommend Ed25519 for certificates, Curve25519 for key exchange (ECDHE), and ChaCha20-Poly1305 for data streams but that suite isn’t supported by OpenVPN."

These are the exact primitives that WireGuard contains, but at that time, they were nothing more than a wish list.

Uit: https://mullvad.net/nl/blog/wireguard-future

[Halfscherp]

Wat overigens wel jammer is. Tegenwoordig hebben de meeste apparaten waar Wireguard op draait wel hardware AES-extensies. Zou dus nog een stukje energiezuiniger zijn dan ChaCha20. Zou fijn zijn als ze over een stukje future proofen hadden nagedacht.

De enige reden waarom je ChaCha20 boven AES zou verkiezen is dat het véél sneller is te doen in software. Ten tijde van de introductie van Wireguard hadden een boel telefoons en routers nog geen ARM processoren met AES.

[Reactie gewijzigd door Halfscherp op 16 januari 2026 17:23]

[Rubbaa]

Ik heb sinds een aantal weken plots problemen met mijn Mullvad Wireguard configuratie op een Unify systeem. Mijn DNS werkt niet meer dus de VPN blijft aan en uit gaan. Contact gehad met Mullvad en zij kunnen het niet uitklaren. Zou de storing te maken hebben met deze overstap?

[GertMenkel]

Er is niets aan WireGuard dat dit gedrag veroorzaakt, maar er zijn wel redenen dat protocolwijzigingen impact kan hebben op netwerkniveau.

Zo heb ik zelf de MTU van mijn WireGuard-VPN omlaag moeten zetten omdat sommige providers (vooral mobiele netwerken en Ziggo in mijn ervaring) niet goed samenwerkten met de automatische MTU-detectie. Ook dingen als vaker keepalives sturen lijken een effect te hebben op netwerk"optimalisaties" die sommige ISP's doen.

Ik heb op mijn telefoon de MTU helemaal naar 1360 omlaag gegooid en dat werkt tot nu toe met alle ISP's. Natuurlijk zou WireGuard het prima moeten doen met 1420-1380 (op ethernet, 8920 met jumbo frames, minder dan 1380 als je ISP intern ~1500 gebruikt en meer overhead toevoegt zoals bij sommige DSL-opstellingen), maar ergens lijkt fragmentatie op te treden als ik de tunnel het maximum op laat zoeken en dan gaan er dingen mis.

Vooral UDP-protocollen zonder herstelmechanismes zoals DNS hebben hier last van. TCP, QUIC en SCTP zouden hier een stuk vloeiender mee om moeten gaan.

[Reactie gewijzigd door GertMenkel op 16 januari 2026 14:42]

[Rubbaa]

Kun je eventueel een link sturen naar een how-to? Ik heb een Unify Cloud Gateway Ultra en ben niet heel erg thuis in dit soort zaken. Het fijne was dat het vrijwel plug& play werkte.

[GertMenkel]

Ik ben niet thuis in Unifi's software, ik heb WireGuard via de command line op Linux ingesteld met wg-quick en op mijn telefoon met de Android app. In de Android-app is het gewoon een veldje, in de Linux-setup is het een configuratiesleutel in het WireGuard-configuratiebestand.

Als je de config als bestand importeert, kun je het blokje [Interface] proberen op te zoeken en daaronder MTU = 1360 neer te zetten, of het getal te verlagen als je VPN-boer al een MTU-configuratie in zijn bestand heeft gestopt. Deze website heeft een uitleg over hoe een WireGuard-configuratiebestand eruit ziet in zijn algemeen. Als je Unifi configureert met een QR-code, dan zul je die QR-code moeten scannen, de tekst die eruit komt moeten aanpassen, en daar een nieuwe QR-code van maken.

Je zou ook PersistentKeepalive nog kunnen instellen als dat nog niet in je config staat. Deze sleutel geeft aan om de hoeveel seconden je router een leeg pakket over de verbinding moet gooien zodat firewalls tussen jou en je VPN-boer niet de verbinding als gesloten behandelen. Voor hele strikte firewall zet je die op 1 (iedere seconde een pakketje), voor netwerken die geen gekke dingen doen kun je het ook helemaal weglaten. Mocht je issues hebben dat bijvoorbeeld het internet even gek doet nadat je thuis komt (en de verbinding moet worden opgebouwd na een tijd niks gedaan te hebben) dan kan een keepalive een oplossing zijn. Let wel dat deze extra pakketjes gewoon data kosten, dus als je op een mobiele bundel zit dan wil je deze keepalive waarschijnlijk niet continu aan hebben staan.

Voor optimale snelheid wil je de MTU eigenlijk zo hoog mogelijk hebben zonder dat er problemen optreden.

[Halfscherp]

Als je de officiële VPN client van een vendor gebruikt hebben die vaak ook "MTU compatibility" of "ISP compatibility" oid toggle. Die zet dan de MTU rond de 1200 of 1300.

[RobertMe]

Had OpenVPN niet wat voordelen zoals te gebruiken met TCP, en dan op poort 443 waardoor het vaker voor firewalls heen komt? (Want de firewall ziet dan verkeer dat in ieder geval over de TCP poort van HTTPS gaat).

* RobertMe gebruikt zelf ook al veel langer Wireguard. Zowel van buiten naar binnen voor onderweg als naar buiten via een andere VPN provider.

[The Zep Man]

Had OpenVPN niet wat voordelen zoals te gebruiken met TCP, en dan op poort 443 waardoor het vaker voor firewalls heen komt?

Dat is een voordeel vanuit het maken van een initiële verbinding, maar een nadeel voor het hebben van een langdurig stabiele verbinding. TCP over TCP is gewoon een slecht idee, zoals 25 jaar geleden al eens werd omschreven. Dat probleem is nog steeds niet verdwenen.

Soms is er geen alternatief en moet je wel TCP (en poort 443) gebruiken voor een VPN-verbinding. Vanuit het perspectief van Mullvad kan je voor deze situatie beter uitwijken naar een concurrent.

Er zijn wel trucs om TCP te misbruiken op een manier waar het niet voor bedoeld is die dit probleem omzeilen, maar dat zijn hooguit workarounds. Het lost het onderliggende probleem (te restrictieve firewalls) niet op.

[Reactie gewijzigd door The Zep Man op 16 januari 2026 14:05]

[Bedge85]

In principe maak je een valide punt.

Het is wel zo dat de genoemde problemen zich vooral voordoen op instabiele verbindingen. Op een stabiele verbinding zijn de genoemde problemen voornamelijk theoretisch en in de praktijk niet merkbaar.

[The Zep Man]

Het is wel zo dat de genoemde problemen zich vooral voordoen op instabiele verbindingen. Op een stabiele verbinding zijn de genoemde problemen voornamelijk theoretisch en in de praktijk niet merkbaar.

Klopt, maar een verbinding hoeft niet stabiel te blijven. Geen garanties, zeker niet over het internet. Daarvoor is juist TCP/IP ontworpen zoals het is.

Voor vaste VPN-verbindingen heb ik liever dat de verbinding stabiel blijft of dat het volledig wegvalt door onstabiliteit van de onderliggende verbinding. Onstabiele verbindingen zijn veel lastiger te diagnosticeren.

[Faifz]

Firewalls zijn vaak geconfigureerd met security policies die 443/TCP toelaten, maar de meeste firewalls zien niet of het nu HTTPS traffic of OpenVPN traffic is. Dat kunnen enkel next-gen firewalls met application filtering zoals FortiGate/Palo Alto etc. Maar ik zag vaak in productie, zelfs met next-gen firewalls, dat ze nooit security policies op basis van applicaties maken omdat ze gewoon lui zijn.

Ik werk voornamelijk met VPN zoals GlobalProtect van Palo Alto, heel soms met OpenVPN in een lab. Beide werken op TCP of UDP en eenderwelk poort.

WireGuard werkt blijkbaar niet over TCP, maar je kunt wel 53/UDP gebruiken want meestal laten ze DNS ook toe. Ze gaan waarschijnlijk ook stilletjes 443/UDP toelaten voor QUIC traffic (wat youtube/google gebruikt).

[The Zep Man]

Een logische keuze voor het bedrag dat Mullvad vraagt. Niet alleen is WireGuard makkelijker te beheren en te onderzoeken, maar het kost ook minder systeemmiddelen. Voor een enkele client maakt het niet uit, maar voor een server tellen vele complexe verbindingen snel op. Voor de prijs die Mullvad vasthoudt (5 EUR/maand) moet men efficient en zuinig zijn.

Andere partijen zoals ProtonVPN ondersteunen nog wel OpenVPN, voor degenen die dat echt nodig hebben.

[Reactie gewijzigd door The Zep Man op 16 januari 2026 14:40]

[_JGC_]

Ik draai zowel servers met OpenVPN als met Wireguard, maar vind persoonlijk OpenVPN makkelijker in beheer en uitrollen. Je kunt heel makkelijk settings vanuit de server naar de clients pushen, bij Wireguard mag je dan de config voor elke cliënt langs.

Verder is wireguard niet per definitie sneller dan OpenVPN. ChaCha heeft als voordeel dat het dusdanig simpel is dat je met een goedkope CPU een goede snelheid kunt halen, maar AES-GCM heeft op vrijwel elke x86 CPU van de afgelopen 10 jaar hardware versnelling dmv AESNI instructies. Vrij recent zijn daar nog snellere implementaties bijgekomen die AVX2 of AVX512 gebruiken.

[lamlion]

Wireguard is natuurlijk makkelijker te onderhouden. Een veel kleinere codebase dan OpenVPN. In de toekomst betekent dat dan ook voor Mullvad om sneller te kunnen inspelen ook defects en kwetsbaarheden. Wireguard presteert ook nog een keer veel beter. Ook energiezuiniger. Als je vaak van netwerken wisselt, denk ik ook dat je beter af bent met Wireguard. Wellicht zijn er nog genoeg argumenten te noemen om voor OpenVPN te kiezen, maar deze zullen op een gegeven moment opgedroogd zijn.

[Llopigat]

Ja een van de redenen dat ik ben gestopt met mullvad. Ik heb OpenVPN nodig voor een niche gebruik waarbij ik af en toe moet tunnelen over tcp.

De andere reden was het stoppen van port forwarding dat erg helpt met torrents. Ik gebruik nu protonvpn.

[Reactie gewijzigd door Llopigat op 16 januari 2026 16:50]

[Niema]

Wat mij verbaasd is dat eigenlijk geen enkele bekende vpn serieuze moeite doet om protocollen te ondersteunen die ook werken in landen waar proxies en vons geblokkeerd worden. Bijvoorbeeld naiveproxy of vless+reality. Wss gen te veel werk, maar zou veel potentiële klandizie kunnen opleveren in geblokkeerde landen. De vpns met hun. Eigen anti blokeer systeem hebben veelal gwn een nier functionerend anti blokeer systeem waar soortgelijke proxies wel werken. Blijkbaar zit er meer geld bij de privacy gurus dan de iranezen