Pour citer, c'est en deux temps
Trois petits points à droite, des options supplémentaires s'affichent.
Puis le guillemet
Il me semblait bien qu'il n'y avait pas de pare-feu V4 mais j'avais un doute connaissant mieux les anciennes NB6 que la Box Plus (NB6vac)
Du coup je ne vois pas où ça bloque.
Vous pouvez créer une redirection NAT dans la box vers votre PC sur un port exotique (par exemple 54321)
Puis écouter ce port avec Port Listener
--> https://www.clubic.com/telecharger-fiche182914-port-listener.html
Et enfin tester ce port exotique avec CanYouSeeMe
Vous verrez ce que dit CanYouSeeMe et vous verrez l'activité (s'il y en a) sur Port Listener
Ça permettra de voir si le blocage est au niveau du NAS ou de la Box.
@Valentech a écrit :
Bonjour @Geneve999, et bienvenue sur la Communauté SFR 🙂
Merci pour le suivi précis des tests et pour les retours détaillés, ils permettent d’y voir beaucoup plus clair. Les échanges avec @TagadaTsoinTsoin et @jnq35 ont permis d’écarter plusieurs pistes importantes, ce qui fait déjà bien avancer le diagnostic.
À ce stade, plusieurs constats se dégagent.
La résolution DDNS fonctionne correctement, l’accès local au NAS via l’IP 192.168.1.x est opérationnel et la ligne n’est pas en CGNAT, ce qui confirme que les redirections de ports sont bien possibles sur votre accès. Le comportement observé depuis le réseau local correspond en revanche à une absence de prise en charge du NAT loopback par la box, ce qui explique la redirection systématique vers l’interface de gestion lorsqu’on utilise l’URL DDNS depuis le LAN.
Concernant l’accès depuis l’extérieur, le test CanYouSeeMe apporte une information intéressante. Le message « connection refused » sur le port 5000 indique que la requête atteint bien l’adresse publique, mais qu’elle est refusée côté NAS ou côté redirection. Cela oriente plutôt vers un point de configuration que vers un blocage réseau.
Dans cette configuration, les vérifications suivantes restent pertinentes :
confirmer que la redirection NAT de la box pointe bien vers l’IP locale du NAS, sur le port externe 5000 vers le port interne 5000,
vérifier dans DSM que le NAS écoute bien sur le port 5000 en HTTP et que ce port n’a pas été modifié ou restreint par un pare-feu interne,
contrôler que le pare-feu du NAS ou une règle de sécurité ne bloque pas les connexions entrantes depuis l’extérieur,
refaire un test d’accès en 4G/5G directement via http://adresseDDNS:5000
pour éliminer tout effet lié au réseau local.
À ce stade, tout indique que la box remplit correctement son rôle de routage, et que le point bloquant se situe soit dans la redirection précise, soit dans la configuration DSM elle-même. Les prochains retours sur ces vérifications permettront d’affiner encore et pourront servir de référence à d’autres membres rencontrant une situation similaire.
Merci encore pour la qualité des échanges et pour le temps consacré aux tests, c’est exactement ce qui fait la richesse de l’entraide ici.
Bonne journée à vous.🙂
Bonjour @Valentech et un grand merci pour votre message, agréable à lire et clair!
Avant de répondre à vos questions, je propose de refaire un point complet sur ma demande, tenant compte également des divers échanges:
❗Pour des raisons de confidentialité, j'ai remplacé ci-dessous:
- le nom attribué à mon NAS (visible dans la console de la box SFR dans la liste des périphériques connectés) par "nomdunas"
- le vrai nom de mon domaine par "mondomaine.com"
- la vraie adresse IP de ma box SFR par "80.xxx.xxx.xxx".
- la vraie IP interne de destination de mon NAS par "192.xxx.x.xx"
Mon objectif initial:
Changer le mode de connection à mon NAS Synology (qui est connecté à internet via ma Box Plus SFR NB6vac), de Synology "QuickConnect" à DynDNS afin de gagner en performance, comme expliqué ici: https://kb.synology.com/fr-fr/DSM/tutorial/What_are_the_differences_between_QuickConnect_and_DDNS
Création et configuration initiale du DDNS:
1. FAI Infomaniak:
Infomaniak hébergeant un de mes domaines internet, j'ai jugé judicieux de me créer un DDNS rattaché à mon nom de domaine, afin d'avoir la main, plutôt que de créer un DDNS générique chez Synology.
Instructions Infomaniak ici: https://www.infomaniak.com/fr/support/faq/2368/configurer-dyndns-avec-un-nas-synology
Voici mon DDNS chez Infomaniak:
2. NAS Synology:
J'ai rajouté dans la console de mon NAS le DDNS créé précédemment chez Infomaniak:
Comme on peut le voir, le "Statut" de ce DDNS apparaît "Normal" 😅
3. Box SFR:
J'ai rajouté la redirection de port NAS comme suit:
Tests:
A1. Lorsque je saisis l'URL https://nomdunas.mondomaine.com dans mon navigateur internet sur mon PC (connecté à internet via la Box SFR), j'obtiens l'erreur suivante:
A2. Lorsque je saisis l'URL nomdunas.mondomaine.com:5001 dans mon navigateur internet sur mon PC (connecté à internet via la Box SFR), j'obtiens l'erreur suivante:
A3. Lorsque je saisis l'URL http://nomdunas.mondomaine.com dans mon navigateur internet sur mon PC (connecté à internet via la Box SFR), j'accède à l'interface du routeur SFR.
B1. Lorsque je saisis l'URL https://nomdunas.mondomaine.com dans le navigateur de mon smartphone en 5G, j'obtiens l'erreur suivante:
B2. Lorsque je saisis l'URL nomdunas.mondomaine.com:5001 dans le navigateur de mon smartphone en 5G, j'obtiens l'erreur suivante:
B3. Enfin, Lorsque je saisis l'URL http://nomdunas.mondomaine.com dans le navigateur de mon smartphone en 5G, j'obtiens l'erreur suivante:
Réponse à vos questions:
confirmer que la redirection NAT de la box pointe bien vers l’IP locale du NAS, sur le port externe 5000 vers le port interne 5000:
--> Oui c'est bien le cas, voir capture d'écran ci-dessus.
vérifier dans DSM que le NAS écoute bien sur le port 5000 en HTTP et que ce port n’a pas été modifié ou restreint par un pare-feu interne,
--> En effet, les ports ont été changés de 5000 et 5001 à d'autres ports, je crois les avoir changés moi-même pour une meilleure sécurité !:
⚠️J'ai remplacé les "port de destination" dans la redirection NAT du routeur SFR par les ports ci-dessus, puis j'ai refait les tests de connexion décrits plus haut: je n'ai pas eu plus de succès! 😒 Pourtant il me semble que la clé est peut-être là??
contrôler que le pare-feu du NAS ou une règle de sécurité ne bloque pas les connexions entrantes depuis l’extérieur:
--> Le pare-feu n'est pas activé.
refaire un test d’accès en 4G/5G directement via http://adresseDDNS:5000
--> "Ce site est inaccessible" ... ERR_CONNECTION_FAILED
--> Même erreur avec 80.xxx.xxx.xxx:5000 ...
En espérant avoir été clair et dans l'espoir que vous trouverez une solution, ne pouvant imaginer que je suis le seul utilisateur d'une Box SFR souhaitant se connecter à un NAS interne en DDNS 😆,
Très sincèrement,
Bonjour @Geneve999 ,
Avez vous fait le test Port-Listener + CanYouSeeMe avec redirection NAT vers un PC ? (Port Listener n'est compatible qu'avec Windows)
Si ça ne passe pas, ça ressemblerait à un comportement CG-Nat sans être en CG-Nat (et il me semble bien avoir déjà vu ça)
En faisant quelques recherches, j'ai découvert que TeamViewer permettait l'accès distant à certains NAS Synology (voir centre de paquets)
https://www.teamviewer.com/fr/integrations/synology/#featurelist-fc02f2d282-item-7cb2aec457
Ce pourrait être une solution de contournement.
Pour accéder à mon Syno j'utilisais une autre approche
- prendre en main un PC par TeamViewer
- accéder au NAS au travers du PC.
Mon objectif principal était la prise à distance du PC (l'accès au Syno était la cerise sur le gâteau)
Concernant les ports http et https, faites quelques essais en remettant les ports par défaut ou ajoutez le nom d'hôte si vous ne mettez pas les ports par défaut. (je n'ai jamais utilisé cette fonction)
Quel est le résultat d'un ping vers l'adresse DDNS ?
Chez moi ça renvoie bien mon IP publique (j'utilise un DDNS chez OVH paramétré dans mon Syno)
Sur les redirections NAT avez vous donné un nom différent à chaque redirection ? (contrairement à votre copie écran)
Je vais continuer de lire vos tests pour voir si ça m'inspire.
@Valentech a écrit :
Bonjour @Geneve999, et merci pour ce récapitulatif très clair et extrêmement structuré 👍
Le temps que vous avez pris pour poser les éléments un par un permet désormais de cibler beaucoup plus précisément le point de blocage, et les échanges avec @TagadaTsoinTsoin et @jnq35 ont clairement aidé à éliminer les faux diagnostics.
À ce stade, plusieurs éléments importants se confirment et méritent d’être posés calmement.
D’abord, côté réseau SFR, rien n’indique un blocage volontaire ou une limitation spécifique.
Votre IPv4 publique en 80.x.x.x, la présence des règles NAT actives et le fait que la box accepte bien les redirections confirment que l’accès entrant est autorisé. De plus, le comportement en local correspond bien à l’absence de NAT loopback sur la box, ce qui est attendu et n’a pas d’impact sur l’accès depuis l’extérieur.
Ensuite, le point clé se situe clairement au niveau de la cohérence ports / protocoles / certificats côté NAS.
Vous indiquez un élément déterminant :
Les ports DSM ont été modifiés (HTTP et HTTPS différents de 5000 / 5001), ce qui change complètement la logique de test.
Dans cette configuration, trois points doivent impérativement être alignés ensemble, sans quoi le symptôme observé (« connection refused » ou « ERR_CONNECTION_FAILED ») est exactement celui attendu :
- Redirection NAT de la box
Port externe X → IP du NAS → port interne X
Le port externe utilisé dans l’URL doit strictement correspondre au port d’écoute DSM.
- Ports d’écoute DSM
Vérifier que le port HTTPS personnalisé est bien actif et appliqué (Panneau de configuration > Accès externe > Avancé).
Confirmer que DSM écoute bien sur ce port précis, et pas uniquement en local.
- Certificat HTTPS
Dès que l’on sort des ports 5000/5001, DSM exige un certificat correctement associé au nom de domaine.
Il est important de vérifier que le certificat est bien lié à nomdunas.mondomaine.com et affecté au service DSM (et non uniquement à un autre service).
À noter également :
Le test CanYouSeeMe n’est réellement pertinent que sur un port HTTP simple, sans TLS. Tester un port HTTPS personnalisé peut renvoyer des erreurs trompeuses, même si la redirection fonctionne.
👉Pour avancer de manière factuelle et isoler définitivement le point bloquant, la méthode la plus efficace serait :
configurer temporairement un port HTTP non sécurisé (par exemple un port DSM HTTP dédié),
créer la redirection NAT correspondante,
tester l’accès depuis la 4G/5G via http://nomdunas.mondomaine.com:port.
Si cet accès fonctionne, alors la chaîne réseau + DDNS + NAT est validée, et le blocage se situe exclusivement sur la partie HTTPS/certificat.
Ce que vous décrivez n’est en tout cas ni un cas isolé, ni incohérent, et votre raisonnement est solide. Les prochains tests permettront surtout de verrouiller la partie sécurité DSM, qui est souvent le dernier verrou dans ce type de configuration.
Merci encore pour la qualité de vos retours et pour l’esprit d’échange constructif — c’est exactement ce qui fait avancer l’entraide ici.
Bonne journée à vous.🙂
Merci @Valentech pour votre message, j'ai "bidouillé" et ai réussi à me connecter à mon NAS en DDNS, je vous explique:
J'ai modifié la config NAT en remplaçant les "Ports de destination" par les ports mentionnés dans Synology DSM --> Portail de connexion --> Services Web:
J'ai ensuite fait deux tests:
1. Test de l'URL https://nomdunas.mondomaine.com:5001 sur le réseau local:
J'ai atteint la page de connexion de mon NAS 😁 !!! MAIS le browser m'informe que ma connexion n'est pas sécurisée:
En analysant le certificat Let's Encrypt, il est indiqué que certaines informations sont manquantes, ce qui me semble faire sens, vu que j'accède à mon NAS en local (?):
2. Test de l'URL https://nomdunas.mondomaine.com:5001 depuis un réseau 4/5G:
J'ai atteint la page de connexion de mon NAS, sans message lié au certificat 😁 !!! Youpiiii!!
Il me semble que mon problème d'accès est désormais résolu, qu'en pensez-vous? Est-il temps de trinquer virtuellement avec tous ceux qui m'ont aidés à résoudre mon problème de connexion 🍾?
