[FREE] Port UDP fermé depuis l'extérieur malgré IP full-stack et redirection configurée

MaurtenLow

Nouveau membre
30 Mars 2026
4
2
3
Bonjour à tous,

Je viens de recevoir mon premier NAS (UGREEN DXP4800 Plus) et je me suis lancé dans une config sous Docker d'un serveur Valheim.

Mon problème : je n'arrive pas à ouvrir des ports UDP depuis l'extérieur pour mon serveur Valheim dédié.

Ma configuration :
- FAI : Free, Freebox (modèle récent)
- IP publique fixe IPv4 full-stack demandée et obtenue depuis l'espace abonné
- NAS en IP fixe via réservation DHCP dans la Freebox
- Serveur Valheim dans Docker (image lloesche/valheim-server)
- DuckDNS configuré et fonctionnel, pointe bien vers ma nouvelle IP publique

Ce que j'ai vérifié côté NAS :
- Le serveur écoute bien sur le port 2456 UDP (vérifié via ss -ulnp)
- La règle iptables DNAT est correcte : udp dpt:49456 to:[IP_DOCKER]:2456
- Connexion en local via IP LAN sur le port 49456 : OK
- Endpoint de status du serveur accessible et retourne les bonnes infos

Ce que j'ai configuré côté Freebox :
- WAN 49456 UDP -> LAN 2456 (IP NAS)
- WAN 49457 UDP -> LAN 2457 (IP NAS)
- WAN 49458 UDP -> LAN 2458 (IP NAS)
- Freebox redémarrée après obtention de l'IP full-stack

Le problème :
Depuis un réseau externe (testé en 4G via yougetsignal.com), le port 49456 apparaît comme CLOSED. Mes amis ne peuvent pas se connecter au serveur depuis l'extérieur.

J'ai écarté le problème de hairpin NAT (je sais que je ne peux pas tester ma propre IP publique depuis mon réseau local). Le test en 4G confirme bien que le port est fermé côté externe.

Ma question : est-ce que Free bloque toujours l'UDP entrant sur certaines plages de ports même avec une IP full-stack ? Quelqu'un a déjà réussi à faire fonctionner un serveur de jeux en UDP derrière une Freebox ?

Merci d'avance pour votre aide !
 
Depuis un réseau externe (testé en 4G via yougetsignal.com), le port 49456 apparaît comme CLOSED. Mes amis ne peuvent pas se connecter au serveur depuis l'extérieur.
C'est pas vraiment possible ce genre de test, UDP ne répond pas vraiment par un "confirmation" contrairement au TCP par exemple. Pour les VPN cela a un coté pratique ( + perf, + de sécu dans le sens ou tes jamais sur que ce que tu envoi est correct sauf a avoir un retour du serveur lui même et donc que la commande est correctement formée en plus d'avoir le bon port :) )

est-ce que Free bloque toujours l'UDP entrant sur certaines plages de ports même avec une IP full-stack ?
À ma connaissance Free n'a jamais bloqué l'UDP

Attention le parefeu ipv6 de la freebox filtre tout le trafic entrant, c'est du tout ou rien. Si ton nom de domaine retourne l'ipv6, c'est peut etre la le soucis.

je ne connais pas les ports par défaut pour le VPN intégré a la freebox, mais assure toi qu'il n'y a pas de conflit.
Aussi, je ne connais pas l'image /valheim-server mais assure toi que par défaut elle autorise les connexions externe
 
  • J'aime
Réactions: MaurtenLow
[RÉSOLU] J'ai trouvé le problème tout seul et ce n'était pas Free qui bloquait quoi que ce soit.

Le souci venait d'un décalage entre les redirections Freebox et les ports exposés par Docker.

Dans mon docker-compose, j'avais :

ports:
- 49456:2456/udp
- 49457:2457/udp
- 49458:2458/udp

Ce qui veut dire que le NAS écoute sur les ports 49456-49458, et Docker redirige vers 2456-2458 à l'intérieur du conteneur.

Mais côté Freebox, j'avais configuré :
WAN 49456 → LAN 2456

Donc la Freebox envoyait le trafic sur le port 2456 du NAS… où rien n'écoutait. Le NAS attend le trafic sur 49456, pas sur 2456.

La correction : j'ai modifié les redirections Freebox pour que le port LAN de destination corresponde au port exposé par Docker :
- WAN 49456 → LAN 49456
- WAN 49457 → LAN 49457
- WAN 49458 → LAN 49458

Tout fonctionne maintenant depuis l'extérieur.

Autre point utile : yougetsignal.com teste en TCP, pas en UDP. Donc même avec une config correcte, ce site affichera "closed" pour un serveur Valheim. Pour tester l'UDP, utilisez nmap -sU ou tentez simplement une connexion en jeu depuis un autre réseau.

En résumé : si vous utilisez Docker avec un mapping de ports non standard (ex: 49456:2456), pensez à aligner vos redirections box sur le port hôte Docker, pas sur le port interne du conteneur.
 
  • J'aime
Réactions: EVO
C'est pas vraiment possible ce genre de test, UDP ne répond pas vraiment par un "confirmation" contrairement au TCP par exemple. Pour les VPN cela a un coté pratique ( + perf, + de sécu dans le sens ou tes jamais sur que ce que tu envoi est correct sauf a avoir un retour du serveur lui même et donc que la commande est correctement formée en plus d'avoir le bon port :) )


À ma connaissance Free n'a jamais bloqué l'UDP

Attention le parefeu ipv6 de la freebox filtre tout le trafic entrant, c'est du tout ou rien. Si ton nom de domaine retourne l'ipv6, c'est peut etre la le soucis.

je ne connais pas les ports par défaut pour le VPN intégré a la freebox, mais assure toi qu'il n'y a pas de conflit.
Aussi, je ne connais pas l'image /valheim-server mais assure toi que par défaut elle autorise les connexions externe
Merci pour ta réponse !

Tu as raison pour yougetsignal, c'est un test TCP donc forcément ça affichait "closed" pour un serveur qui n'écoute qu'en UDP — fausse piste de ma part.

En fait le problème était plus bête que ça : c'était un décalage entre mes redirections Freebox et les ports exposés par Docker.

Dans mon docker-compose j'avais 49456:2456/udp, donc le NAS écoute sur le port 49456. Mais côté Freebox j'avais redirigé WAN 49456 → LAN 2456. La Freebox envoyait donc le trafic sur le port 2456 du NAS, où rien n'écoutait.

J'ai corrigé en alignant les redirections Freebox sur les ports hôte Docker (WAN 49456 → LAN 49456) et tout fonctionne maintenant depuis l'extérieur.

Pour le reste :
- Pas de conflit avec le VPN Freebox, il n'était pas activé
- L'image lloesche/valheim-server autorise les connexions externes par défaut (SERVER_PUBLIC=true)
- Bon point pour l'IPv6, mon DuckDNS ne retourne que l'IPv4 donc pas de souci de ce côté, mais c'est bon à savoir pour d'autres

Encore merci !
 
  • J'aime
Réactions: morgyann