Comment j'ai explosé le record français Nperf : mon homelab à 15 Gb/s de débit Internet en détail

Laurent Henric

11 sept. 2025 — 9 min read

Le 8 septembre 2025, j’ai réalisé un test de débit sur nPerf avec un résultat intéressant :

Download : 15 466 Mb/s
Upload : 8 698 Mb/s

Ce score bat le record français de débit recensé par la plateforme, largement au-dessus des précédents records et de la moyenne nationale.

Dans ce billet, je vais partager en détail la configuration matérielle, logicielle et les optimisations qui m’ont permis d’atteindre ce résultat.

⚙️ Le matériel

Mon setup repose sur un Serveur ESXi "custom", monté comme une tour "gaming" mais optimisé pour la virtualisation et le réseau :

CPU : AMD Ryzen 9 9900X (12 cœurs / 24 threads, Zen 5)
RAM : 128 Go DDR5 (2x64)
Stockage : 2 × SSD NVMe Samsung 990 Pro 4 To + SSD Nvme 2To en pcie4x4 + Stockage NFS (NAS)
NIC : Mellanox MCX4121A-ACAT dual-port 25 Gb/s en pcie 3.0x4
Alimentation : FSP Twinpro 900X (Double Alimentation, une connectée en direct, l'autre sur un onduleur Eaton).

Côté accès internet opérateurs, j’utilise deux abonnements FTTH fibre (pratique les maisons mitoyennes, avec des voisins sympa).

Lien FAI 1 : 8 Gb/s down / 8 Gb/s up
Lien FAI 2 : 8 Gb/s down / 1 Gb/s up

👉 Ma box opérateur reste dans son carton : j’ai connecté directement l'ONT sur le switch 25 Gb/s (en 10Gbps cuivre), afin de garder un contrôle total sur les accès et éviter toute limitation (l'ip publique et les préfixes ipv6 arrivent directement sur mon firewall).
Pour la box du voisin, elle arrive via une fibre multimode 10Gbps qui est associée à un vlan dédié, qui sera un vlan associé à l'interface WAN2 de la VM Firewall.
La box possède une configuration dmz (ipv4) et un routage des autres préfixes ipv6 disponibles à destination de ma VM Firewall.

Tout le setup est installé dans le garage, sur lequel le pto fibre a été déporté et d'autres fibres internes ont été tirées.

Le Switch est un modèle Qnap qui sait encaisser 16 Ports 25Gbps (le fond de panier tient la cadence) il présente des fonctionnalités limités mais parfaitement satisfaisantes pour mon environnement (il supporte les vlan et le protocole lacp par exemple).

QNAP QSW-M5216-1T (16 ports 25 Gb/s + 1 port 10 Gb/s cuivre)

🛡️ Routage et firewall : VM OPNsense en multi-WAN et segmentation par Vlan.

Sur l’hôte ESXi, une VM OPNsense, qui est donc un Routeur/Firewall assure :

ma segmentation réseau (vlans) + routage IPv4 et IPv6
securité (règles de filtrage, crowndsec, dns filter)
la gestion multi-WAN/SD-Wan (failover + load-balancing, ainsi que le nat/nptv6)
Mes VPN sites à sites (wireguard) et utilisateurs (tailscale).

⚠️ Mes réseaux expliqués en 2min :

Adressage et routage du homelab :

En IPv4, nous retrouvons une configuration classique :
• Un réseau /16 pour la maison, qui supportera un /24 dédié par VLAN (le deuxième octet correspond au site (ici 17) et le 3em à l'identifiant de vlan (dans le schéma est pris l'exemple du vlan10).
• Pour l'attribution des adresses ip aux machines, le serveur DHCP est géré directement par l'OPNsense, qui utilise l’adresse se terminant par .254 dans chaque sous-réseau.
• Concernant la sortie vers Internet, on retrouve donc du NAT en mode masquerade, l’IP source privée est remplacée par l’IP publique de l’interface WAN qui sera utilisée pour la session.

Côté IPv6 (plus intéressant 😏) :
• Chaque VLAN a un préfixe /64 global.
• Pour ces préfixes, j'ai choisi d'utiliser 2001:db8::/32, qui est normalement réservé à la documentation (donc non routée sur Internet, vous allez comprendre ensuite).
• OPNsense annonce sur chaque VLAN (Router Advertisement) le préfixe dérivé de 2001:db8:17::/48, où :
le 3ᵉ mot (17) identifie encore une fois le site,
le 4ᵉ mot correspond à l’ID du VLAN.
Exemple : 2001:db8:17:20::/64 → site = 17, VLAN = 20.

Grâce au SLAAC, les machines :
• S’auto-attribuent une (même plusieurs) adresses IPv6 dans ce préfixe.
• Apprennent automatiquement leur passerelle et le serveur DNS.

Pour la sortie WAN, j’utilise NPTv6 (traduction de préfixe sans état) :

Chacun des liens internet aura plusieurs préfixe globaux, routé sur internet et donc associé à ces liens. Ces préfixes sont configurés pour être routé à destination de la vm Opnsense sur la box du voisin, et obtenu dynamiquement pour l'accès porté directement par ma vm (/60 pour le WAN1, /61 pour le Wan2).

• Les préfixes internes sont remplacés dynamiquement par un des préfixes opérateurs du lien wan utilisé, avec un /60 sur l'opérateur 1, j'ai donc 2^4 =16 /64.

Donc sur l'opérateur 1, j'ai 16 préfixes disponible pour mapper mes préfixes de vlan, afin de permettre l’accès Internet.
Il y a donc un mapping entre chacun de mes vlans internes et chaque préfixe publique disponible, pour chaque lien utilisé.
• Grace à ça, les sessions sortantes sont équilibrées entre les deux liens.

Les machines peuvent donc égalements être accessibles depuis l’extérieur, depuis les deux connexions Internet, sous reserve qu'il y ait une règle de filtrage associé.

⚠️L’utilisation de préfixes globaux pour l’adressage interne, même s’ils sont remplacés en sortie Internet (d’où l’utilisation d’un préfixe réservé à la documentation) permet d’éviter le recours aux préfixes ULA.
Cela garantit donc que les machines présentes sur mes VLAN continuent à prioriser l’IPv6, comme le font par défaut tous les systèmes d’exploitation modernes.
En effet, lorsqu’une machine ne dispose pas d’une adresse IPv6 globale, elle a tendance à privilégier l’IPv4 plutôt que l’IPv6, un comportement que je souhaitais précisément éviter.

🔧 Ce qui donne à titre d'exemple

Préfixe global de mon site : 2001:db8:17::/48
VLAN 10 : 2001:db8:17:10::/64

ip -6 addr show scope global
    inet6 2001:db8:17:10:250:56ff:fea1:7f85/64 scope global dynamic 
       valid_lft 86375sec preferred_lft 14375sec

curl ifconfig.io
2001:861:3281:e921:250:56ff:fea1:7f85

curl ifconfig.io
2a01:e0a:e17:5201:250:56ff:fea1:7f85

La première commande montre l'adresse ipv6 présente sur ma vm.
La commande "curl ifconfig.io" permet à ma machine d'accèder au site ifconfig.io, ce site retourne en réponse l'adresse ipv6 source qu'il a reçu lors de cette requete.

On observe que le préfixe de sortie changent selon l’équilibrage de sessions, tout en gardant l'adresse du serveur (qui permet à nptv6 d'être stateless).

Mais pour les flux entrants ?(cf schéma)

Pour detailler comment fonctionnent les flux entrants, on peut le schématiser avec ton exemple, si tu lis ces lignes, c'est que tu as cliqué sur le lien https://blog.ubune.network, ta requête est donc passée d’abord par Internet et arrive chez le CDN Cloudflare.

Cloudflare joue ici le rôle de reverse proxy :

Il termine la connexion SSL/TLS (c’est donc lui que ton navigateur atteint en HTTPS), et Cloudflare présente du dual stack (ipv4 et ipv6 disponible).
Cloudflare sait joindre mon homelab de part mes deux accès internet, en ciblant le serveur hébergeant le blog uniquement en ipv6, et il choisit dynamiquement un de ces liens pour initier la requête.
Il répartit la charge, optimise les performances, et protège mon serveur (cache, filtrage, protection DDoS).

De mon côté, mon serveur accepte les flux venant de Cloudflare, et lui délivre le contenu du blog.

Résultat : Mes deux connexions Internet sont utilisées en parallèle grâce au load balancing, en actif/actif !

Si l'une des connexions tombent, Cloudflare arretera d'utiliser le lien sans réponse.
Nous avons ici un équilibrage de charge et une résilience parfaite, sans même utiliser de lien opérateurs avec session bgp (simple accès ftth).

Un schéma pour que ce soit plus clair !

🔧 Optimisations ESXi

Pour que la VM Opnsense puisse exploiter pleinement les 25 Gb/s, je lui ai ajouté des paramètres vmware spécifiques :

Configuration avancée de la VM :

Active le support du multi-queue / RSS (Receive Side Scaling)

ethernet0.pnicFeatures = "4"

Permet au vNIC d’avoir son propre thread dédié

ethernet0.ctxPerDev = "1"

Permet à la VM de « voir » une interface capable de 25 Gb/s

ethernet0.linkspeed = "25000"

Spécifications de la VM

CPU : 8 vCPU
RAM : 4 Go
Stockage : 40 Go

Optimisations OPNsense (FreeBSD tunables)

Par défaut, FreeBSD n’exploite pas toujours efficacement le multi-core pour le réseau.

J’ai donc activé et ajusté plusieurs tunables :

Configuration RSS et ISR

Active Receive Side Scaling

net.inet.rss.enabled=1

Définit 8 RSS buckets (idéal pour 6–16 CPUs)

net.inet.rss.bits=3

Utilise les 8 vCPUs

net.inet.rss.cpu_set=0-7

Permet que le thread de traitement soit planifié et réparti sur les CPU

net.isr.dispatch=deferred

Définit 1 thread par vCPU

net.isr.maxthreads=8

Lie les threads ISR aux cœurs CPU

net.isr.bindthreads=1

📊 Conditions de test :

Conditions de test avant la mesure à 15 Gbps

Avant de réaliser le test de débit, l’infrastructure suivante a été mise en place afin de garantir des conditions optimales :

Hyperviseur ESXi avec OPNsense
- Hôte ESXi présenté précédemment
Machine physique dédiée
- Serveur distinct, également équipé d’une carte réseau Mellanox 25 Gbps.
- VM Windows avec 16 Vcpu/12Go de ram.
- Connexion directe en 25Gbps sur le switch Qnap.

J’ai choisi d’utiliser une machine physique dédiée afin de démontrer que le routage à 15 Gbps (même 25Gbps) d’une VM OPNsense n’était pas uniquement possible depuis une autre machine virtuelle hébergée sur le même serveur, mais également réalisable dans des conditions de production.

📊 Monitoring du switch

Pour valider les débits, l'interface web du switch

QNAP QSW-M5216-1T affiche la charge réseau :

Ports 25 GbE : plus de 54 Gb/s de trafic total cumulé
ICI le P1 correspond à l'ont de l'accès internet 1, et le P17 à celui de l'accès internet 2, P15 et P16 aux deux serveurs.

Cette supervision d'équipement confirme que le trafic circule réellement à très haut débit sur l'infrastructure physique.

🏆 Résultats du test Nperf

Avec cette configuration, voici les mesures obtenues :

Download : 15 466 Mb/s
Upload : 8 698 Mb/s

Latence : 13,20 ms logique en prenant en compte la distance Alpes-Maritimes/Paris.

En réalité, je ne peux pas dépasser les 8 Gbps en mono-session. Cependant, comme les logiciels de speedtest utilisent plusieurs sessions simultanées lors des tests, le trafic est réparti sur mes deux liens. Cela permet d’atteindre un débit théorique pouvant aller jusqu’à 16 Gbps en téléchargement et 9 Gbps en envoi.

Merci de m'avoir lu et à bientôt pour un prochain post 😃

📖 Glossaire

NPTv6 (Network Prefix Translation v6)

Mécanisme de traduction d’adresses IPv6, NPTv6 est bien different qu’un NAT en ipv4 classique :

Pas de suivi de session → moins de charge CPU et de mémoire sur le firewall.
Pas de recalcul de checksum d’entête → traitement plus rapide et moins d’erreurs.
Pas de modification du port source/destination → connectivité plus transparente et débogage simplifié, pas limité à TCP/UDP uniquement.

Résultat : de meilleures performances, moins de latence et un réseau plus “propre”.

RSS (Receive Side Scaling)

Technologie réseau qui répartit le traitement des paquets entrants sur plusieurs cœurs CPU.
Permet de mieux exploiter les serveurs multi-cœurs et d’augmenter les performances réseau à haut débit.

Tunables FreeBSD

Paramètres de bas niveau (sysctl) qui contrôlent le comportement du noyau FreeBSD.
Utilisés pour ajuster les buffers, files d’attente et performances réseau sur OPNsense.

SLAAC (Stateless Address Autoconfiguration)

Mécanisme qui permet aux machines de générer automatiquement leur adresse IPv6 à partir du préfixe annoncé par le routeur, sans serveur DHCP.

ULA (Unique Local Address)

Plage d’adresses IPv6 privées (équivalent des 192.168.x.x en IPv4).
Utiliser exclusivement des ULA peut faire perdre la priorité à IPv6 dans certains OS, d’où l’intérêt de rester sur des adresses globales dans un homelab.

Reverse Proxy

Serveur intermédiaire qui reçoit les requêtes des clients et les transmet aux serveurs d’application.
Ici, Cloudflare sert de reverse proxy et termine la connexion HTTPS avant de joindre le homelab.

Load Balancing (Équilibrage de charge)

Répartition du trafic réseau sur plusieurs liens ou serveurs pour améliorer la redondance et la performance.
Dans mon homelab, NPTv6 + OPNsense équilibrent les sessions sur mes deux connexions WAN.

CDN (Content Delivery Network)

Réseau de serveurs distribués qui hébergent et servent le contenu plus près des utilisateurs.
Cloudflare agit comme CDN en mettant en cache certaines ressources du blog et en les servant rapidement depuis ses POPs mondiaux.