|
Description de la tâche
Modèle de Freebox : Pop
Version du Firmware : 4.9.18.1
Type d’IP : IPv4 Full Stack (Ports 0 à 65535 confirmés)
Description du problème : Suite à une coupure brutale du réseau le 16 avril depuis le retour à la normal le 17 avril, toutes les redirections de ports (NAT) sont devenues inopérantes. Malgré une configuration correcte dans l’interface FreeboxOS, toute tentative de connexion entrante sur l’IP publique se solde par un ERR_CONNECTION_RESET.
Tests et Diagnostics effectués :
Routage WAN : Un tracert vers mon IP publique aboutit correctement au dernier saut sur l’équipement Free. Le trafic arrive bien à la box.
Vérification Serveur Local : Un curl -Ikv effectué en local sur le serveur cible (Unraid/Nginx) répond correctement en HTTP 200 OK. Le serveur et ses services sont parfaitement fonctionnels.
Tests de Ports Multiples : Testé sur les ports standards (80, 443) ainsi que sur des ports exotiques (ex: 52345, 58000). Le résultat est identique : TCP Reset.
Analyse de trafic (Sniffing) : Une écoute réseau via tcpdump sur l’interface du serveur cible ne montre aucun paquet entrant lors des tentatives de connexion depuis l’extérieur (4G). La Freebox ne transmet pas les paquets vers le LAN malgré les règles NAT actives.
Actions de dépannage déjà réalisées :
Redémarrages électriques multiples.
Réinitialisation aux paramètres d’usine.
Suppression et recréation manuelle de toutes les règles de redirection.
Attribution d’une nouvelle IP fixe au serveur local.
Désactivation/Réactivation de l’accès distant à la Freebox pour éviter les conflits de ports.
Comportement observé : La Freebox semble rejeter silencieusement ou envoyer un paquet RST immédiatement après la réception d’un paquet sur un port redirigé, sans consulter ou appliquer la table NAT.
Pouvez-vous vérifier s’il existe un bug de corruption de la table NAT suite à une déconnexion brutale ou un problème de “provisioning” du profil Full Stack sur le DSLAM/NRO qui ne serait pas synchronisé avec l’état affiché dans FreeboxOS.
|
