Bonjour,

Je solicite votre aide à propos d'un problème que je rencontre lorsque je tente de "proxifier" l'accès à mon serveur WireGuard (hébergé à mon domicile) via un VPS hébergé à Nice.

TLDR : le débit entre mon domicile (Orange ; en France) et mon VPS (en France) est d'environ 300 à 400 Mbits/s symétrique ; lorsque proxifie mon serveur WireGuard via le VPS (redirection 51820/udp vers Livebox 51820/udp) le débit est divisé par 10 et je ne trouve pas d'explication à ce phénomène.

En détails :
J'héberge à mon domicile quelques services (ex : Nextcloud) et je souhaite y accéder depuis l'extérieur. Je pourrai me contenter d'une redirection de port depuis ma Livebox Orange car j'ai un IPv4 full stack, mais pour diverses raisons je souhaiterai plutôt que le point d'entrée se situe sur un VPS. Du coup, je souhaite utiliser un VPS disposant d'une IPv4 comme point d'entrée pour me connecter à mon serveur WireGuard.

La configuration est la suivante : sur le VPS, j'utilise l'utilitaire "socat" pour rediriger le port 51820 (du VPS) vers l'IP publique de ma Livebox (port 51820), qui elle-même est configurée pour rediriger le trafic vers mon serveur WireGuard (VM WG sur le schéma ci-dessous). Problème : dans cette configuration, le débit est d'environ 30Mbits/s, alors que j'ai une connexion fibre 2Gb/600M, et que le serveur dispose d'une connexion 500 Mbits/s symétrique.

Voici ci-dessous une schéma de mon installation réseau :



- Ma Livebox Orange est le point d'entrée depuis Internet (IP publique 86.X.X.X)
- Le réseau local (LAN) de ma Livebox est le 192.168.10.0/24, sur lequel est connecté mon MacBook (192.168.10.140)
- Sur le LAN, il y a un routeur Mikrotik (CCR2004) derrière lequel se trouve un serveur Proxmox, et plusieurs VMs hébergées dessus (sur le réseau 10.41.0.0/24)
- Le VPS sur l'Internet (IP publique 89.X.X.X)

Afin de tenter d'élucider ce problème, j'ai réalisé quelques tests :

1/ Le premier test consiste à évaluer le débit entre mon LAN et le VPS :

• MacBook --> VPS : débit mesuré d'environ 500 Mbits/s
• Détails du test :
  
  • VPS : iperf -s
  • MacBook : iperf3 -c 89.X.X.X

• VPS --> MacBook : débit mesuré d'environ 200 à 400 Mbits/s
• Détails du test :
  
  • VPS : iperf -s
  • MacBook : iperf3 -c 89.X.X.X -R

Schéma du test 1 :


2/ Le second test consiste à évaluer le débit entre la "VM iPerf" et le MacBook en profixiant la VM iPerf via le VPS :

• MacBook --> VPS --> VM iPerf : débit mesuré d'environ 400 à 500 Mbits/s
• Détails du test :
  
  • VPS : socat TCP4-LISTEN:5201,fork TCP:86.X.X.X:5201 (VPS forwards TCP-5201 to Livebox ; Livebox forwards TCP-5201 to Mikrotik ; Mikrotik forwards TCP-5201 to iPerf VM)
  • MacBook : iperf3 -c 89.X.X.X
  • VM iPerf : iperf3 -s

• VM iPerf —> VPS —> MacBook : débit mesuré de 300 à 480 Mbits/s
• Détails du test :
  
  • VPS : socat TCP4-LISTEN:5201,fork TCP:86.X.X.X:5201 (VPS forwards TCP-5201 to Livebox ; Livebox forwards TCP-5201 to Mikrotik ; Mikrotik forwards TCP-5201 to iPerf VM)
  • MacBook : iperf3 -c 89.X.X.X -R
  • VM iPerf : iperf3 -s

Schéma du test 2 :


3/ Le troisième test consiste à évaluer le débit entre "VM iPerf" et le MacBook lorsque celui-ci est connecté via WireGuard à WG VM (PAS de profixication via VPS) :

• MacBook via WireGuard Tunnel —> VM iPerf : débit mesuré de 300 à 400 Mbits/s
• Détails du test :
  
  • VM iPerf : iperf3 -s (Livebox forwards UDP-51820 to Mikrotik ; Mikrotik forwards UDP-51820 to WG VM)
  • MacBook : iperf3 -c 10.41.0.3 (WG Endpoint : 86.X.X.X:51820)

• VM iPerf —> MacBook via WireGuard Tunnel : débit mesuré de 300 à 400 Mbits/s
• Détails du test :
  
  • VM iPerf : iperf3 -s  (Livebox forwards UDP-51820 to Mikrotik ; Mikrotik forwards UDP-51820 to WG VM)
  • MacBook : iperf3 -c 10.41.0.3 -R (WG Endpoint : 86.X.X.X:51820)

Schéma du test 3 (en bleu le tunnel WireGuard, en rouge le trafic iPerf) :


4/ Ce dernier test consiste à évaluer le débit du tunnel WireGuard entre la "VM iPerf" et le MacBook AVEC proxification de "WG VM" via VPS :

• MacBook via WireGuard Tunnel --> VPS —> VM iPerf : 30 à 45 Mbits/s
• Détails du test :
  
  • VPS : socat UDP4-LISTEN:51820,fork UDP:86.X.X.X:51820 (port forwarding 89.X.X.X:51820 to 86.X.X.X:51820)
  • MacBook : iperf3 -c 10.41.0.3 (WG Endpoint : 89.X.X.X:51820)
  • VM iPerf : iperf3 -s

• VM iPerf —> MacBook via WireGuard Tunnel --> VPS  : 30 à 50 Mbits/s
• Détails du test :
  
  • VPS : socat UDP4-LISTEN:51820,fork UDP:86.X.X.X:51820 (port forwarding 89.X.X.X:51820 to 86.X.X.X:51820)
  • MacBook : iperf3 -c 10.41.0.3 -R (WG Endpoint : 89.X.X.X:51820)
  • VM iPerf : iperf3 -s

Schéma du test 4 (en bleu le tunnel WireGuard, en rouge le trafic iPerf) :


Le problème si situe donc au niveau du test n°4. Si quelqu'un a une ou plusieurs hypothèses sur la manière de régler ce problème que je n'arrive pas à expliquer, je suis à l'écoute de toutes propositions...

J'ai déjà essayé de réduire le MTU du tunnel WireGuard à 1280, et ça n'a rien changé au problème. J'ai aussi essayé d'activer le mode BBR sur le VPS comme indiqué dans ce post, idem. J'ai aussi vérifié que chacune des machines (VPS, Routeurs, VM) ne saturent pas au niveau CPU.

Si quelqu'un ici a une idée, merci !

Il faut aussi réduire le MTU sur la machine VM iperf ou clamper le MSS.

Merci pour cette indication.

Est-il possible d'ajouter une règle générique sur le routeur Mikrotik pour automatiquement clamper le MSS pour toutes les connexions venant du tunnel WG ?

Merci.

Du coup j'ai concentré mes tests sur une éventuelle fragmentation des packets. Voici les quelques tests réalisés :

1/ Vérifier que le MTU est bien de 1500 octets entre mon MacBook (sur Home Network) et le VPS :
ping -s 1472 -D 89.X.X.X
1480 bytes from 89.X.X.X: icmp_seq=0 ttl=51 time=33.391ms

Du coup, on est bon = 1472 + 8 (header ICMP) + 20 (header IP) = 1500. Une valeur supérieure à 1472 renvoie bien un "Message too long".

2/ Vérifier que le MTU est bien de 1420 octets une fois connecté au tunnel WireGuard entre le MacBook et le VPS :
ping -s 1392 -D 89.X.X.X
1400 bytes from 89.X.X.X: icmp_seq=0 ttl=56 time=118.195ms

Du coup, on est bon = 1392 + 8 (header ICMP) + 20 (header IP) = 1420. Une valeur supérieure à 1392 renvoie bien un "Message too long".

3/ Réaliser le test iPerf depuis MacBook connecté au tunnel WG vers VM iPerf proxifié par VPS (c'est le scénario du test n°4 dans mon post initial) sans la règle MSS sur Mikrotik :
Extrait Wireshark capturé sur MacBook :
10.79.34.4 --> 10.41.0.3 | TCP [SYN] | MSS = 1380
10.41.0.3 --> 10.79.34.4 | TCP [SYN, ACK] | MSS = 8960

Le client WireGuard (MacBook ; 10.79.34.4) envoie donc un MSS = 1380, ce qui est logique (1380 + 20 header TCP + 20 header IP = 1420).

Pour ce qui est de la VM iPerf, elle est configurée avec un MTU = 9000 (le réseau Home Lab supporte les jumbo frames sur un réseau 10G). Du coup, par défaut iPerf renvoie un MSS = 8960, ce qui est logique (8960 + 20 + 20 = 9000).

Dans le capture complète Wireshark, on peut constater que le client envoie bien uniquement des packets de 1420 octets. Donc il ne semble pas y avoir de problème de MTU / Fragmentation à ce niveau.

Le résultat du test iPerf montre un débit de 30Mbits/s.

4/ Réaliser le test iPerf depuis MacBook connecté au tunnel WG vers VM iPerf proxifié par VPS (c'est le scénario du test n°4 dans mon post initial) avec la règle MSS sur Mikrotik :
Extrait Wireshark capturé sur MacBook :
10.79.34.4 --> 10.41.0.3 | TCP [SYN] | MSS = 1380
10.41.0.3 --> 10.79.34.4 | TCP [SYN, ACK] | MSS = 1380

La règle ajoutée sur le Mikrotik :
/ip firewall mangle
add action=change-mss chain=forward dst-address=10.79.34.0/24 new-mss=1380 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1381-65535

Le client WireGuard (MacBook ; 10.79.34.4) envoie toujours un MSS = 1380 ; et le serveur iPerf voit bien son MSS être modifié par le Mikrotik à MSS = 1380.

Le résultat du test iPerf montre toujours un débit de 30Mbits/s. Il ne semble, là encore, ne pas y avoir de problème côté MTU / Fragmentation.

J'ai aussi réalisé deux autres tests similaires aux deux précédents, à la différence près que le processus iPerf (iperf3 -s) était démarré dans le conteneur WireGuard, et non sur le machine hôte. Les captures Wireshark montrent que le MSS renvoyé est cette fois-ci de 1380 (ce qui est logique car le conteneur WG est configuré avec un MTU de 1420). Le débit reste bridé à 30 Mbits/s.

Lien vers les captures complètes Wireshark :
- le dossier "iperf-on-host" contient les 2 tests avec et sans la règle MSS (iperf -s sur la machine VM iPerf)
- le dossier "iperf-in-wg-easy-container" contient les 2 tests avec et sans la règle MSS (iperf -s dans le conteneur docker WG)

Si quelqu'un voit quelque chose d'anormal dans ces captures, je suis à l'écoute...