OpenVPN ou WireGuard sur un vieux NAS ou routeur : j’ai changé de protocole avant de comprendre que le processeur fixait déjà la limite

Ma fibre venait d’être accélérée. Mon VPN, lui, n’avait pas bougé.

Sans tunnel, le portable dépassait régulièrement 900 Mbit/s en Ethernet. J’avais gardé mon ancien routeur sous OpenWrt parce qu’il fonctionnait encore très bien : Wi-Fi stable, réseau local rapide, aucune raison évidente de remplacer une boîte qui faisait son travail depuis des années.

Puis j’ai remis OpenVPN en route sur le routeur. Le débit est retombé autour de 70 Mbit/s.

Ce soir-là, je devais envoyer un dossier de sauvegarde d’un peu plus de 40 Go vers un stockage distant. J’avais largement assez de bande passante sur le papier. Pourtant, la durée estimée oscillait entre une heure et « on verra bien ».

J’ai changé de serveur VPN. Presque rien. Un deuxième.

Toujours pareil. J’ai alors fait ce que beaucoup de gens font lorsqu’ils commencent à chercher pourquoi leur VPN ralentit un routeur : j’ai décidé qu’OpenVPN était le problème et que WireGuard allait tout réparer.

WireGuard a effectivement amélioré les choses. Mais pas de la manière que j’imaginais.

Le firmware était neuf. Le processeur ne l’était pas.

J’avais justement mis OpenWrt à jour peu auparavant.

OpenWrt 25.12.5, publié le 1er juillet 2026, apportait plusieurs correctifs de sécurité et poursuivait la prise en charge de matériels embarqués parfois bien plus anciens que le logiciel qui tourne dessus.

J’aimais beaucoup cette idée : un ancien appareil peut rester utile longtemps grâce à un système actuel. Mais j’avais inconsciemment transformé cette idée en une autre, beaucoup moins vraie : logiciel actuel voulait dire performances actuelles.

Une mise à jour peut corriger le noyau, le réseau ou une faille. Elle ne rajoute pas de cœurs au processeur soudé dans le boîtier plusieurs années plus tôt.

J’ai donc laissé ouvert le graphique CPU du routeur et relancé mon transfert sous OpenVPN. Un cœur est monté presque immédiatement au plafond. Le débit, lui, est resté là où il était.

Pour la première fois de la soirée, j’avais quelque chose de plus utile qu’un test de vitesse. La fibre avait encore énormément de marge. Le serveur distant aussi.

Le portable attendait. Le petit processeur entre les deux travaillait déjà aussi vite qu’il pouvait.

OpenVPN faisait surtout sentir l’âge du boîtier

J’avais une explication toute prête : OpenVPN est vieux, WireGuard est moderne. C’était un peu trop simple.

Dans une installation OpenVPN traditionnelle sans Data Channel Offload, une bonne partie du traitement des paquets passe par le programme OpenVPN en espace utilisateur. Les données montent, sont traitées et chiffrées, puis redescendent vers la pile réseau.

Sur un ordinateur moderne, ce va-et-vient peut rester discret. Sur un petit processeur ARM qui doit en même temps router, faire du NAT, appliquer le pare-feu et parfois gérer le Wi-Fi, chaque détour compte davantage.

OpenVPN a précisément développé DCO pour raccourcir ce chemin : une plus grande partie du canal de données peut être traitée directement dans le noyau, avec moins de copies et moins de changements de contexte.

Autrement dit, dire simplement « OpenVPN est lent » ne suffit plus. Un OpenVPN moderne avec DCO sur une machine récente n’a pas grand-chose à voir avec le même protocole exécuté sur un petit routeur ancien.

Le chiffrement matériel joue lui aussi. La documentation d’OpenVPN souligne notamment l’intérêt d’AES-NI pour accélérer AES et montre à quel point l’absence d’accélération matérielle peut augmenter la charge nécessaire au chiffrement.

C’est là que mon diagnostic a changé. Le protocole comptait. Mais le processeur qui devait exécuter ce protocole comptait au moins autant dans mon cas.

WireGuard a presque triplé le débit… et le CPU est revenu au plafond

J’ai créé mon profil WireGuard et refait exactement le même test. Même routeur. Même câble.

Même serveur distant. Même portable. Cette fois, la différence était immédiate.

Le transfert a dépassé 100 Mbit/s. Puis 150. Il s’est stabilisé un peu au-dessus de 200 Mbit/s.

Après OpenVPN, cela ressemblait franchement à une victoire.

WireGuard a été conçu comme un protocole plus léger, avec une implémentation Linux étroitement intégrée au noyau. Sur ce matériel, cette différence se voyait immédiatement.

Puis j’ai regardé le graphique CPU. De nouveau au plafond. Et c’est là que j’ai compris ce que WireGuard avait réellement fait.

Il n’avait pas supprimé le goulot d’étranglement. Il avait permis au même processeur de transporter beaucoup plus de trafic avant d’atteindre sa limite.

La nuance peut facilement passer inaperçue. On passe de 70 à plus de 200 Mbit/s et on se dit : problème résolu. Puis on regarde la connexion gigabit disponible derrière et on réalise que le routeur continue de décider jusqu’où on peut aller.

Le même WireGuard, trois machines, trois débits

Une discussion publique publiée le 31 août 2026 donnait une comparaison particulièrement parlante. Avec le client WireGuard directement sur son PC Windows 11, un utilisateur indiquait atteindre environ 850 Mbit/s sur une connexion gigabit. En déplaçant le tunnel sur un routeur ASUS, il tombait autour de 250 Mbit/s.

Sur un MikroTik hEX S, il atteignait environ 90 Mbit/s.

Le protocole était toujours WireGuard. La connexion Internet n’avait pas changé. Ce qui changeait surtout, c’était la machine chargée de chiffrer et de transporter les paquets.

C’était exactement le test que j’aurais dû faire au début. Pas : « OpenVPN ou WireGuard, lequel est le plus rapide ? »

Mais : « Que devient mon débit si le VPN ne tourne plus sur ce petit processeur ? »

Les propriétaires de NAS rencontrent la même logique. Dans une discussion francophone consacrée aux performances VPN sur Synology, un utilisateur expliquait avoir obtenu un gain net en passant d’OpenVPN à WireGuard, avec environ 20 Mo/s dans son environnement.

Cela confirmait ce que je venais d’observer chez moi. Changer de protocole peut donner une vraie seconde jeunesse à un NAS ou à un routeur limité. Mais aucun protocole ne transforme un petit CPU embarqué en processeur de portable récent.

J’étais sur le point d’acheter un nouveau routeur pour un seul ordinateur

À ce stade, la suite me semblait évidente. Acheter du matériel. Un nouveau routeur.

Un mini-PC x86. Peut-être une appliance réseau avec davantage de puissance. J’avais déjà commencé à comparer des modèles.

Puis j’ai arrêté de regarder les fiches techniques et j’ai regardé les appareils autour de moi. Le NAS n’avait pas besoin de ce tunnel commercial. La télévision non plus.

Les objets connectés non plus. Ce soir-là, un seul appareil avait réellement besoin du VPN : le portable qui envoyait les 40 Go. Pourquoi obligeais-je alors mon vieux routeur à chiffrer le trafic de cette machine ?

La question paraissait presque idiote une fois formulée. J’ai désactivé le client VPN du routeur. Il est redevenu ce qu’il savait encore très bien faire : router.

Puis j’ai installé OnlydogVPN^↗ directement sur le portable.

L’application ne m’a pas demandé de choisir entre une longue série de protocoles, de ports et de profils. J’ai choisi le mode correspondant à mon usage, connecté, puis relancé le transfert.

Le routeur est resté calme. Le portable a pris en charge le tunnel. Et la barre de progression a dépassé sans difficulté le débit auquel WireGuard plafonnait sur l’ancien boîtier.

Le temps restant est tombé. J’ai laissé le dossier partir, préparé mes notes pour le lendemain, puis vérifié une dernière fois avant de fermer l’ordinateur. 100 %.

Le transfert était terminé. Je n’avais pas changé de fibre. Je n’avais pas acheté de routeur.

Je n’avais pas trouvé un réglage secret qui rendait soudainement l’ancien processeur plus rapide. J’avais simplement déplacé le travail de chiffrement vers la machine qui avait la puissance pour le faire.

Après ça, le choix du protocole est devenu secondaire

C’est seulement une fois les 40 Go envoyés que j’ai regardé ce que l’application utilisait derrière son interface. Le service repose sur un transport basé sur HTTP/3. Quelques heures plus tôt, cette information m’aurait probablement envoyé dans un troisième comparatif de protocoles.

Après mes tests, elle avait une autre signification. Oui, le transport compte. Le passage d’OpenVPN à WireGuard venait de me montrer à quel point il pouvait compter sur un processeur limité. Mais le changement décisif n’avait pas été de trouver un troisième protocole supposément meilleur.

Il avait été d’arrêter de faire passer mon trafic le plus lourd par le composant le moins puissant de mon réseau.

Le fonctionnement orienté par usage de l’application rendait aussi cette décision plus simple : je choisissais ce que j’essayais de faire, plutôt que de recommencer la soirée dans un menu de protocoles et de serveurs. Le service a publié des tests construits autour de la même idée : lorsqu’un routeur devient le facteur limitant, déplacer le VPN vers l’appareil qui en a réellement besoin peut supprimer ce plafond.

Cette approche a malgré tout une limite très concrète.

Si je veux faire passer un téléviseur, une console ou un autre appareil incapable d’exécuter lui-même l’application à travers le VPN, le routeur redevient important. Et si toute ma maison doit obligatoirement emprunter un tunnel central, un matériel plus puissant reste la solution logique.

Mais ce n’était pas ce que j’essayais de résoudre. J’étais sur le point de remplacer un routeur pour accélérer le VPN de toute la maison alors que mon besoin réel concernait un seul ordinateur.

Alors, OpenVPN ou WireGuard sur un vieux NAS ou routeur ?

Je commencerais aujourd’hui par regarder le CPU.

Si OpenVPN plafonne pendant qu’un cœur atteint 100 %, WireGuard mérite clairement d’être essayé. Sur un matériel ancien, le gain peut être suffisamment important pour conserver le routeur ou le NAS plusieurs années de plus.

Mais si WireGuard augmente fortement le débit puis finit lui aussi avec le processeur saturé, je ne passerais pas la soirée à chercher encore un autre réglage.

Je déplacerais temporairement le VPN sur un ordinateur plus puissant derrière le même routeur. Si le débit remonte pendant que le vieux boîtier cesse de saturer, la réponse devient très difficile à ignorer : le processeur était bien le plafond. Mon ancienne configuration OpenVPN était lente.

WireGuard l’a rendue nettement meilleure. Mais c’est seulement en sortant le chiffrement du routeur que ma connexion a cessé d’être définie par la puissance de cette petite boîte.

J’avais commencé la soirée en cherchant quel protocole ferait courir plus vite mon vieux routeur ; j’ai terminé mes 40 Go en comprenant qu’il n’avait jamais eu besoin de courir.