Port WireGuard : le défaut, le changer, l'ouvrir

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.

Les ports WireGuard en un coup d'œil

Réponse courte : WireGuard utilise le port UDP 51820 par défaut - c'est son port standard, défini par la ligne ListenPort. Il n'existe aucun mode TCP. Les ports qui comptent :

Le Endpoint = <public-ip>:<port> du client doit utiliser exactement le même port que le ListenPort du serveur - ce décalage est la raison numéro un pour laquelle un tunnel WireGuard auto-hébergé ne se connecte pas.

Votre VPN masque votre IP. Pas votre navigateur.

Un tunnel WireGuard bien configuré remplace l'adresse que voit un site. Il ne change rien à ce que votre navigateur annonce de lui-même : polices, écran, fuseau, pile graphique. Cette combinaison suffit souvent à vous suivre d'une session à l'autre, tunnel ou pas.

Mesurez votre empreinte de navigateur, mesure passive, aucune question, aucun compte, aucune adresse e-mail. Elle vous dit combien de navigateurs sur N ressemblent au vôtre, et quel attribut vous singularise.

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.

Attention à la suite, qui piège beaucoup de configurations : cette règle autorise les paquets à entrer sur le serveur, pas à le traverser pour ressortir vers Internet. Si le handshake réussit mais qu'aucun trafic ne sort, le port n'est plus en cause, voir UFW et WireGuard : le tunnel monte, rien ne passe.

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. Si tu édites la config depuis zéro, nos templates de configuration WireGuard prêts à l'emploi te donnent un squelette [Interface]/[Peer] correct avec les lignes ListenPort et Endpoint déjà au bon endroit.

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é.

Une fois le port choisi, notre générateur de configuration WireGuard gratuit construit une config serveur et client cohérente dans votre navigateur, avec le ListenPort et l'Endpoint déjà alignés.

Quand aucun reglage de port n y changera rien

Ouvrir l UDP 51820 ne sert que si quelque chose peut reellement atteindre votre serveur. Derriere un CGNAT, ou sur une box que vous ne controlez pas, il n y a aucun port a rediriger et aucune regle de pare-feu qui repare cela. Un VPS avec sa propre IPv4 publique supprime la question : le port que vous ouvrez est celui que voit Internet. Un VPS Cloud 10 de Contabo a 5,50 EUR/mois vous donne un acces root complet et une IP publique, et le guide pas a pas Contabo + WireGuard couvre la suite.

Pour aller plus loin

• MikroTik CVE-2026-14227 : votre clé privée WireGuard peut être lue, et désactiver l'API n'annule rien

Changer de port ne sert que si l'hébergeur ne le filtre pas lui-même. Notre comparatif des VPS les moins chers pour WireGuard indique lesquels laissent l'UDP tranquille.

Si le tunnel ne monte pas du tout alors que le port est correctement ouvert, la cause est souvent ailleurs que dans le port : pourquoi un VPN ne se connecte pas, et les deux pannes opposées que cette phrase recouvre sépare le cas du tunnel qui n'arrive pas à s'établir de celui du tunnel monté où plus rien ne circule.

Sur un téléphone, les mêmes vérifications de port et de pare-feu s'appliquent, mais les pannes se présentent autrement et les outils sont plus rares : voir WireGuard sur iPhone pour les trois qui expliquent presque tous les tunnels iOS cassés.