Le NAS répondait. Quatre paquets envoyés, quatre réponses reçues. Depuis mon portable connecté au VPN de l’Internet-Box Swisscom, je pouvais même ouvrir l’interface Web du NAS par son adresse IP. J’ai donc tapé \\192.168.1.50\Documents dans l’Explorateur en m’attendant à retrouver mes fichiers. Quelques secondes plus tard : chemin réseau introuvable. J’ai repingué le NAS. Toujours quatre réponses. C’est précisément ce qui m’a fait perdre du temps : j’avais interprété « le NAS répond au ping » comme « le VPN donne accès au NAS ». En réalité, je n’avais testé que l’accès à une machine, pas l’accès au service que je voulais utiliser.
Le voyant vert et le ping m’avaient donné deux bonnes nouvelles — mais pas la troisième
La configuration semblait pourtant difficile à accuser.
Swisscom permet de faire fonctionner un serveur VPN directement sur certaines Internet-Box et propose notamment WireGuard pour se reconnecter à distance au réseau domestique.
Mon ordinateur recevait bien son adresse VPN. La route jusqu’au réseau de la maison existait. Le NAS répondait sur son adresse privée. Son interface d’administration s’ouvrait.
Dans ma tête, toute la chaîne était validée : VPN : bon. Routage : bon. NAS : bon.
Il ne restait plus, pensais-je, qu’un problème Windows un peu obscur. Puis j’ai regardé ce que le ping testait réellement. ICMP. Et ce que mon partage de fichiers utilisait réellement.
SMB. Ce n’était pas la même conversation.
À partir de là, mon voyant vert et mes quatre réponses au ping ont cessé d’être un diagnostic. Ils étaient seulement le début du diagnostic.
Résumé de l’article et adéquation au besoin
Pourquoi un NAS répond-il au ping via le VPN Swisscom alors que le partage SMB ne s’ouvre pas ?
Le ping confirme seulement qu’un échange ICMP atteint le NAS. SMB doit encore établir une connexion distincte, généralement sur TCP 445, qui peut être bloquée par le routage ou le pare-feu entre le sous-réseau VPN et le LAN.
Points clés
- À retenir : Tester TCP 445 directement vers l’adresse IP du NAS permet de séparer un problème SMB d’un problème général de connectivité ou de DNS.
- À qui cela convient : Aux utilisateurs d’un VPN domestique Swisscom qui atteignent leur NAS par ping ou interface Web mais pas par un partage Windows.
- Quand OnlydogVPN a du sens : Pas pour remplacer le tunnel vers le NAS : dans le récit, il sert seulement à la navigation Internet courante après avoir séparé cet usage de l’accès privé au domicile.
- Limite importante : Ne pas exposer TCP 445 sur Internet pour contourner le symptôme ; il faut réparer le trajet privé et les autorisations du sous-réseau VPN.
Sources déjà citées dans l’article : Swisscom et Microsoft Learn.
SMB ne passe pas parce que le ping passe
Sur les versions modernes de SMB, le partage de fichiers passe principalement par TCP 445.
Le ping ne teste pas ce port.
Il demande simplement, en substance :
« est-ce que cette adresse IP me répond ? »
C’est comme appeler la réception d’un hôtel et conclure, parce que quelqu’un décroche, que la porte de la chambre 445 est forcément ouverte.
Ce n’est pas ce qu’on vient de vérifier.
J’ai donc remplacé mon énième ping par un test beaucoup plus utile sous Windows :
Test-NetConnection 192.168.1.50 -Port 445
C’est là que le problème devenait enfin précis.
Si le ping réussit mais que TCP 445 échoue, je sais déjà que le NAS n’est pas simplement « hors ligne ».
Le chemin jusqu’à la machine existe.
Mais le service SMB n’est pas accessible par ce chemin.
Et cette seule distinction explique parfaitement un NAS qui répond, affiche même son interface Web, tout en refusant obstinément d’ouvrir ses partages.
Un utilisateur Swisscom avait décrit presque exactement ce scénario
En juillet 2025, une discussion de la communauté Swisscom est partie d’un cas remarquablement proche.
Un utilisateur d’Internet-Box expliquait que son VPN WireGuard fonctionnait, que son NAS répondait au ping et que plusieurs services restaient accessibles. Pourtant, SMB sur le port 445 ne passait plus entre le réseau VPN et le LAN.
C’était le détail qui m’intéressait. Le problème n’était pas : « le VPN ne fonctionne pas ». Ni même :
« le NAS est inaccessible ». C’était :
« plusieurs chemins vers ce NAS fonctionnent, mais celui dont SMB a besoin ne fonctionne pas ».
La discussion faisait aussi apparaître un autre élément important : le client WireGuard pouvait utiliser un sous-réseau différent de celui du LAN domestique.
Par exemple :
VPN : 10.x.x.x
LAN : 192.168.x.x
Les deux réseaux pouvaient donc se joindre sans que chaque service soit automatiquement autorisé entre eux.
C’est exactement ce que mon ping ne me disait pas.
Il prouvait que les deux côtés savaient se trouver.
Il ne prouvait pas que TCP 445 avait le droit de franchir la porte.
J’ai éliminé le DNS en arrêtant d’utiliser le nom du NAS
Il restait encore un piège facile à confondre avec le précédent.
Habituellement, j’ouvrais mon partage avec quelque chose comme :
\\MONNAS\Documents
Or Windows peut traiter différemment la résolution de noms lorsqu’un VPN est actif, selon les interfaces, les DNS et les suffixes utilisés.
Je ne voulais pas diagnostiquer deux problèmes en même temps. J’ai donc remplacé le nom par l’adresse IP : \\192.168.1.50\Documents Même échec.
Et, pour une fois, l’échec était une bonne nouvelle. Je pouvais mettre la résolution de noms de côté.
La discussion Swisscom faisait d’ailleurs la même distinction : l’accès direct par adresse IP avait été testé sans rétablir SMB.
Mon problème tenait désormais en trois lignes : ping : oui ; interface Web : oui ; TCP 445 : non.
À partir de là, le mystère devenait beaucoup moins impressionnant. Quelque chose autorisait l’accès au NAS, mais pas le service de fichiers.
Le NAS peut parfaitement accepter le VPN… et refuser SMB depuis son sous-réseau
C’est là que j’ai regardé le pare-feu du NAS.
Un client connecté au VPN n’arrive pas forcément avec une adresse du même sous-réseau que les appareils physiques de la maison.
Le NAS peut donc voir :
un ordinateur local en 192.168.1.x ;
et le même utilisateur distant en 10.x.x.x.
Si une règle autorise SMB uniquement depuis le LAN local, le résultat devient parfaitement cohérent.
Le ping peut répondre.
L’administration Web peut fonctionner grâce à une autre règle.
Mais TCP 445 reste fermé pour le sous-réseau VPN.
Les discussions publiques autour de Synology montrent précisément ce genre de cas : accès partiel au NAS, puis blocage lié au sous-réseau, au routage ou aux règles appliquées au trafic VPN.
À ce stade, mon ordre de vérification est devenu beaucoup plus simple :
adresse IP ; TCP 445 ; autorisation du sous-réseau VPN dans le pare-feu du NAS ; route entre le VPN et le LAN.
Et seulement si 445 répond mais que le partage refuse encore de s’ouvrir, je passe aux identifiants SMB et aux politiques Windows.
C’était la première fois que le diagnostic suivait réellement le trajet du fichier au lieu de tourner autour du ping.
La solution la plus tentante était aussi celle que je ne voulais surtout pas garder
Pendant les essais, une idée est apparue :
rediriger le port 445 vers le NAS.
Et dans la discussion Swisscom, une redirection de 445 avait effectivement permis de retrouver l’accès au partage.
Comme test, c’était instructif.
Comme solution permanente, beaucoup moins.
Microsoft recommande au contraire de bloquer SMB 445 à la frontière Internet, sauf architecture explicitement prévue pour ce type d’usage.
Et c’est précisément pour ne pas exposer directement SMB au réseau public que j’utilisais un VPN domestique.
Ouvrir publiquement 445 parce que le tunnel ne l’acheminait pas correctement aurait consisté à enlever la porte parce que la clé coinçait.
Je ne voulais pas exposer le NAS.
Je voulais réparer le chemin privé jusqu’à lui.
Le correctif était plus petit : autoriser le bon trajet
Une fois cette distinction faite, le correctif n’avait plus rien de mystérieux.
Le client VPN devait disposer d’une route vers le LAN.
Le VPN devait autoriser l’accès au réseau interne.
Et le NAS devait accepter TCP 445 depuis le sous-réseau utilisé par les clients VPN.
Dans les échanges Swisscom, l’option d’accès à l’Intranet lors de la configuration WireGuard joue justement ce rôle : permettre au réseau VPN d’atteindre le réseau principal de l’Internet-Box.
Après avoir corrigé l’accès du sous-réseau VPN plutôt que d’exposer le port 445 sur Internet, le test a enfin changé :
Test-NetConnection ... -Port 445 Succès. Puis : \\192.168.1.50\Documents
La fenêtre s’est ouverte. Les dossiers sont apparus. J’ai copié le fichier que j’étais venu chercher. C’était la première réponse véritablement utile de toute la soirée.
Pas quatre réponses ICMP. Le fichier.
C’est après ça que j’ai séparé deux usages que je mélangeais depuis le début
Cette panne m’a montré autre chose.
J’utilisais le VPN Swisscom pour deux tâches qui n’avaient pas vraiment besoin d’être réunies.
La première était très précise : entrer chez moi. Atteindre le NAS. Administrer une machine.
Récupérer un fichier privé. Pour ça, le tunnel domestique reste exactement l’outil qu’il me faut.
Mais je le laissais aussi actif lorsque je voulais simplement naviguer depuis un Wi-Fi extérieur. Dans ce cas, tout mon trafic repartait vers la maison avant de ressortir sur Internet, même lorsque je n’avais aucune ressource privée à consulter.
C’est là que OnlydogVPN a trouvé une place beaucoup plus naturelle dans ma configuration.
Pour le NAS, je garde le VPN Swisscom.
Pour la navigation courante, je lance le mode adapté dans la petite application.
Je ne demande plus à l’Internet-Box d’être à la fois ma porte privée vers la maison et mon VPN général pour tout le reste.
Et cette séparation a eu un effet assez immédiat : chaque tunnel a recommencé à avoir un rôle que je pouvais expliquer en une phrase.
Je n’ai plus besoin d’affaiblir mon réseau domestique pour simplifier ma navigation
Quand le VPN Swisscom est actif, je sais pourquoi :
je veux quelque chose chez moi.
Quand l’autre service est actif, je n’attends pas de lui qu’il atteigne une adresse 192.168.x.x.
Il s’occupe simplement de ma connexion Internet.
Je ne touche plus au pare-feu du NAS pour résoudre un problème de navigation.
Je ne crée pas de redirection de port pour rendre un partage plus facile à atteindre depuis l’extérieur.
Et je ne confonds plus une panne SMB avec une panne générale de VPN.
Le petit service possède moins de régions et moins d’historique public qu’un fournisseur installé depuis longtemps.
Mais pour ce rôle précis, sa simplicité devient plutôt un avantage : il n’a pas besoin de connaître mon NAS, mes routes internes ou mes règles SMB pour faire ce que je lui demande.
Mon tunnel domestique peut rester spécialisé et fermé.
L’autre peut rester simple.
Alors pourquoi le NAS répond-il au ping mais SMB ne s’ouvre-t-il pas ?
Parce que le ping prouve seulement qu’un échange ICMP atteint le NAS et revient.
SMB doit encore établir sa propre connexion, généralement sur TCP 445.
Si le ping fonctionne mais que :
Test-NetConnection <IP-du-NAS> -Port 445
échoue, je regarde le filtrage et la route de TCP 445 entre le sous-réseau VPN et le LAN.
Si 445 fonctionne par adresse IP mais que :
\\nom-du-nas\partage
échoue, je regarde ensuite la résolution de noms.
Si 445 répond mais que le partage refuse toujours l’accès, je remonte vers les identifiants et les politiques SMB.
Ce que je ne fais plus, c’est ouvrir le port 445 sur Internet simplement pour faire disparaître le symptôme.
Je croyais que le ping me disait :
« ton NAS est accessible ».
Il me disait seulement que j’étais arrivé devant la maison ; TCP 445 était encore la clé de la pièce où se trouvaient mes fichiers.
Questions fréquentes
Que prouve réellement un ping réussi vers le NAS ?
Il prouve que l’adresse IP du NAS répond à un échange ICMP. Il ne prouve pas que le service SMB ou son port TCP 445 est accessible par le même trajet.
Quel test est plus utile que le ping pour diagnostiquer SMB sous Windows ?
Tester directement TCP 445 vers l’adresse IP du NAS, par exemple avec Test-NetConnection. Si ce test échoue alors que le ping réussit, le diagnostic se concentre sur le filtrage et le routage du service SMB.
Le nom du NAS peut-il être la cause du problème ?
Oui, la résolution de noms peut se comporter différemment avec un VPN. Tester le partage par adresse IP permet de mettre le DNS de côté ; si l’échec reste identique, il faut chercher ailleurs.
Faut-il rediriger le port 445 sur Internet pour retrouver le partage ?
Non comme solution permanente. L’article recommande au contraire de garder SMB derrière le VPN et de corriger la route et les règles qui autorisent le sous-réseau VPN à atteindre TCP 445 sur le NAS.