Quel port utilise WireGuard ? Port par défaut, le changer & l'ouvrir (2026)

Le réseau de WireGuard est d'une simplicité agréable — mais le nombre qui fait trébucher tout le monde, c'est le port. Par défaut WireGuard écoute sur l'UDP 51820, et presque tous les « mon VPN auto-hébergé ne se connecte pas » se résument à ce port non ouvert, non redirigé, ou ne correspondant pas à la config client. Ce guide couvre le défaut, comment le changer, et comment l'ouvrir et le rediriger correctement.

Le défaut : UDP 51820

WireGuard écoute sur le port UDP 51820 par convention, défini par la ligne ListenPort dans la section [Interface] du serveur. Deux choses comptent :

• C'est de l'UDP, pas du TCP. WireGuard n'a aucun mode TCP. Les pare-feu ou réseaux qui bloquent l'UDP l'arrêtent net.
• 51820 n'est que le défaut, pas une règle — tu peux utiliser n'importe quel port UDP libre de 1 à 65535.

Les clients joignent le serveur via la ligne Endpoint = <ip-publique>:51820 de leur config. Ce port doit correspondre exactement au ListenPort du serveur.

Choisir un port : le 443/UDP en vaut-il la peine ?

N'importe quel port UDP libre de 1 à 65535 marche, mais certains choix sont plus malins :

• Gardez 51820 par simplicité si votre réseau ne filtre pas l'UDP — c'est le défaut documenté, le plus facile à maintenir.
• Utilisez l'UDP 443 sur un réseau restrictif. Le port 443 est celui du HTTPS, et le trafic web moderne (HTTP/3 / QUIC) passe déjà en UDP 443 : un tunnel WireGuard là-dessus se fond dans du trafic chiffré d'apparence normale et passe beaucoup de blocages par port. C'est le changement de port le plus utile. À noter : c'est un camouflage au niveau du port seulement — l'inspection profonde de paquets peut toujours reconnaître la poignée de main (voir la section furtivité plus bas).
• Évitez les ports sous 1024 sans raison ; ils sont « privilégiés » et exigent root, sans avantage ici.

Ouvrir le port dans le pare-feu

Sur le serveur, le port doit être autorisé en UDP. Avec UFW :

sudo ufw allow 51820/udp
sudo ufw reload

Avec iptables c'est -A INPUT -p udp --dport 51820 -j ACCEPT. C'est la cause la plus fréquente d'un serveur qui « tourne » mais n'accepte jamais de connexions : le service WireGuard est actif, mais le pare-feu jette silencieusement les paquets.

Rediriger le port via un routeur

L'endroit où vit ton serveur décide si tu as aussi besoin de redirection de port :

• Sur un VPS (serveur loué à IP publique) : pas de redirection — la règle pare-feu suffit, car l'IP publique pointe directement la machine.
• Sur un serveur maison derrière un routeur : ajoute une règle de redirection dans l'admin du routeur — rediriger l'UDP 51820 (externe) vers l'IP locale du serveur en UDP 51820 (interne). Sans ça, les paquets venus d'internet n'atteignent jamais le serveur.

Teste depuis l'extérieur de ton réseau (par ex. un téléphone en données mobiles, Wi-Fi coupé) : un client doit joindre ip-publique-serveur:51820. Si ça marche sur ton LAN mais pas de l'extérieur, la redirection est la pièce manquante.

Changer le port

Pour utiliser un autre port, définis-le dans le [Interface] du serveur :

[Interface]
ListenPort = 51821

Puis redémarre le tunnel (systemctl restart wg-quick@wg0) et mets à jour tout ce qui référençait l'ancien port :

1. la règle pare-feu (autoriser le nouveau port UDP),
2. la redirection routeur (le cas échéant),
3. la ligne Endpoint dans chaque config client.

Oublie-en un seul et les clients ne se connecteront pas. Un VPS auto-hébergé simplifie tout ça car tu contrôles le pare-feu et l'IP publique directement.

Vérifier que le port écoute vraiment

Avant d'accuser le client, confirmez que le serveur écoute bien sur le port que vous croyez :

sudo wg show              # affiche l'interface et son port d'écoute
sudo ss -lunp | grep 51820   # quelque chose est-il lié à l'UDP 51820 ?

wg show liste le listening port actif ; ss -lunp (le u = UDP) prouve qu'un processus y est lié. Si wg show affiche un port différent de votre config, le service n'a pas rechargé après l'édition — redémarrez-le. Depuis une autre machine, vous pouvez sonder avec nc -uvz ip-serveur 51820, mais les sondes UDP sont peu fiables : une vraie poignée de main client reste le test définitif.

Faire tourner plusieurs tunnels

Chaque interface WireGuard a besoin de son propre ListenPort. Si vous lancez par ex. wg0 pour le trafic général et wg1 pour un autre groupe de pairs, donnez-leur des ports distincts (ex. 51820 et 51821), ouvrez et redirigez les deux, et pointez chaque client sur le bon. Deux interfaces partageant un port échouent silencieusement au démarrage.

Changer le port cache-t-il ton VPN ?

Un port non-standard réduit le bruit des bots qui scannent 51820, mais ce n'est pas de la furtivité. L'inspection profonde de paquets identifie la poignée de main UDP caractéristique de WireGuard quel que soit le port. Si tu dois passer un pare-feu qui bloque ou détecte activement les VPN, il te faut de l'obfuscation (envelopper le tunnel), pas juste un autre port — vois WireGuard avec port knocking / furtivité. Pour router un trafic précis ou rediriger des services dans le tunnel, vois la redirection de port.

En résumé

WireGuard utilise l'UDP 51820 par défaut — UDP uniquement, pas de TCP. Pour rendre un serveur auto-hébergé joignable : ouvre le port en UDP dans le pare-feu, redirige-le sur le routeur si le serveur est derrière un (un VPS à IP publique évite ça), et assure-toi que le Endpoint de chaque client correspond. Change le port si tu veux pour moins de bruit de scan, mais traite ça comme un durcissement léger, pas une vraie furtivité.