Votre serveur Windows/DNS répond sur le LAN mais reste muet aux pings depuis Internet ? Suivez ce guide pas à pas pour ouvrir l’ICMP en sécurité, corriger NAT/routage et valider la publication publique sans compromettre la surface d’attaque.
Vue d’ensemble
Contexte classique : un serveur Windows (souvent Windows Server) héberge aussi le service DNS. Il fonctionne en interne, mais impossible de le « pinger » depuis un réseau externe. Le but de cet article est double : 1) rétablir, si nécessaire, la réponse aux requêtes ICMP Écho depuis Internet et 2) s’assurer que la machine est effectivement joignable publiquement pour ses services utiles (DNS, RDP, HTTP/S, etc.).
Avant d’ouvrir quoi que ce soit, rappelez-vous que répondre au ping n’est pas un prérequis pour offrir des services fiables. Beaucoup d’infrastructures filtrent l’ICMP tout en délivrant parfaitement DNS, web ou RDP. Décidez si l’ICMP est indispensable pour votre supervision ou vos diagnostics, puis appliquez la méthode ci‑dessous.
Plan d’action synthétique
- Autoriser l’ICMP dans le pare‑feu Windows. Activez la règle entrante « Echo Request – ICMPv4-In » (et ICMPv6 si dual‑stack) ou créez une règle PowerShell dédiée.
- Valider la configuration IP du serveur. Adresse statique, masque, passerelle, DNS (souvent 127.0.0.1 pour un serveur DNS), profil réseau correct.
- Vérifier NAT et routage. Publication par DMZ/1:1 NAT ou exposition contrôlée. Attention au double NAT et au CGNAT.
- Tester DNS et la connectivité interne puis externe. Ping interne,
nslookup, tests depuis une source externe (4G/5G, outils de test en ligne) pour lever tout biais local. - Analyser journaux et services. Observateur d’événements, état des services DNS et pare‑feu.
- Écarter les blocages côté FAI ou équipement. Certains opérateurs filtrent ICMP et/ou le port 53.
- Redémarrer proprement. Services réseau/DNS puis, si nécessaire, le serveur et/ou le routeur.
Vérifications côté Windows
Règles pare‑feu pour l’ICMP
Le pare‑feu Windows bloque par défaut les requêtes ICMP sur les profils publics. Pour autoriser uniquement l’écho ICMPv4 entrant :
# PowerShell (indépendant de la langue du système)
New-NetFirewallRule -DisplayName "Allow ICMPv4 Echo In" `
-Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -Profile Any
Et pour ICMPv6 (si votre environnement est dual‑stack) :
New-NetFirewallRule -DisplayName "Allow ICMPv6 Echo In" `
-Protocol ICMPv6 -IcmpType 128 -Direction Inbound -Action Allow -Profile Any
Vous pouvez aussi activer la règle intégrée :
# Activer la règle intégrée ICMPv4 (nom variable selon la langue/édition)
Get-NetFirewallRule | Where-Object DisplayName -match "Echo Request|requête d’écho" |
Where-Object Direction -eq Inbound | Enable-NetFirewallRule
Interface graphique : Pare‑feu Windows avec fonctions avancées de sécurité → Règles de trafic entrant → activer File and Printer Sharing (Echo Request – ICMPv4-In) et, si besoin, la variante ICMPv6. Vérifiez qu’aucune règle bloquante spécifique à l’ICMP n’est définie.
Profil réseau et découverte
Assurez‑vous que l’interface du serveur est sur le bon profil (Domaine ou Privé). Un profil Public applique souvent des restrictions plus strictes.
Get-NetConnectionProfile | Format-Table Name, InterfaceAlias, NetworkCategory
Le cas échéant, basculez en Private ou DomainAuthenticated selon votre contexte d’annuaire.
Configuration IP et rôle DNS
Contrôlez la pile IP :
ipconfig /all
- L’adresse IPv4 doit être statique (ou réservation DHCP).
- Passerelle par défaut présente et joignable.
- DNS : pour un serveur DNS, pointe souvent vers
127.0.0.1(et/ou une IP locale) + un relais conditionnel si nécessaire.
Confirmez que le service DNS écoute bien en local :
netstat -ano | findstr ":53"
# Ou
Get-NetTCPConnection -LocalPort 53
Get-NetUDPEndpoint -LocalPort 53
Services et journaux
Vérifiez l’état des services :
Get-Service -Name DNS, Dnscache, MpsSvc | Select-Object Status, Name, DisplayName
Dans l’Observateur d’événements :
- Journaux Windows → Système pour les événements réseau/pare‑feu.
- Applications et services → Microsoft → Windows → DNS-Server pour les erreurs DNS (par ex. événements 4000/4013/4015).
Vérifications côté routeur et NAT
Comprendre ICMP et la NAT
L’ICMP n’est pas du TCP/UDP : il n’y a pas de « port ». Sur de nombreux routeurs grand public, un ping vers l’IP publique obtient la réponse du routeur lui‑même, pas d’une machine derrière la NAT. Pour faire répondre le serveur au ping externe, vous avez généralement besoin d’un des scénarios suivants :
- DMZ/Exposed Host : tout le trafic entrant non mappé (y compris ICMP) est redirigé vers une IP interne spécifique.
- 1:1 NAT / NAT statique : association d’une IP publique dédiée à l’IP privée du serveur (idéal si vous disposez de plusieurs IP publiques).
- Bridge/Pass‑through : le routeur opère en pont et l’IP publique est portée directement par un firewall/routeur en aval qui gère l’ICMP.
Si vous ne possédez qu’une seule IP publique et que votre routeur ne permet pas de relayer l’ICMP vers un hôte interne (ou qu’il force la réponse lui‑même), le serveur ne pourra pas répondre au ping externe. Dans ce cas, appuyez‑vous sur des tests de ports (53/UDP, 53/TCP, 3389/TCP, 443/TCP, etc.) pour valider l’accessibilité.
Détecter le double NAT et le CGNAT
| Symptôme | Indicateur | Action |
|---|---|---|
| IP WAN privée sur le routeur | 10.0.0.0/8, 172.16–31/12, 192.168.0.0/16 ou 100.64.0.0/10 | Double NAT ou CGNAT. Demander un mode bridge ou une IP publique dédiée. |
| Traceroute sortant anormal | Premier saut privé puis un autre saut privé | Éliminer le routeur intermédiaire (bridge, cascade propre) ou ouvrir les mappages sur chaque NAT. |
| Port forwarding inefficace | Aucun service accessible de l’extérieur | Le FAI utilise du CGNAT : les redirections ne peuvent pas fonctionner. Solution : IP fixe publique. |
Paramètres du routeur à contrôler
- Réponse au ping sur l’interface WAN : selon que vous voulez tester le routeur ou le serveur. Désactivez la réponse du routeur si vous souhaitez que l’ICMP soit routé ou redirigé vers le serveur (si l’équipement le permet).
- DMZ/Exposed Host : pointer vers l’IP privée du serveur pour inclure l’ICMP.
- 1:1 NAT : associer IP publique ↔ IP privée du serveur. C’est la solution la plus propre en entreprise.
- Redirections : créer des mappages pour 53/UDP et 53/TCP si vous exposez DNS. Ne laissez pas la récursion ouverte vers Internet si le serveur n’est pas autoritaire public.
- Filtrage ICMP : certains routeurs possèdent un filtrage explicite « Block/Allow ICMP from WAN ».
Tests réseau fiables
Tests depuis le LAN
# Ping de l'IP privée du serveur
ping 192.168.X.Y
# Résolution DNS interne
nslookup monserveur.exemple.lan 192.168.X.Y
# Dépôt de route
tracert 8.8.8.8 Si ces tests échouent, corrigez d’abord la connectivité locale (adresse IP statique, passerelle, pare‑feu local, VLAN).
Tests depuis l’extérieur
- Depuis un téléphone en 4G/5G : effectuez un ping vers l’IP publique (ou le FQDN public qui la résout) et testez les ports ouverts.
- Depuis un outil de test externe : utilisez un service de ping/port‑check côté Internet pour lever tout biais de pare‑feu de votre poste.
# Depuis un autre Windows connecté à Internet (hors LAN)
Test-NetConnection -ComputerName <IP_publique> -InformationLevel Detailed
Test-NetConnection -ComputerName <IP_publique> -Port 53 -InformationLevel Detailed
Diagnostic par symptômes
| Symptôme observé | Cause probable | Résolution |
|---|---|---|
| Ping interne OK, ping externe KO, services accessibles | ICMP filtré en bordure | Autoriser l’ICMP ou accepter que le ping soit bloqué si les services fonctionnent |
| Aucun service exposé n’est joignable de l’extérieur | Double NAT/CGNAT, port forwarding manquant | Mode bridge, IP publique, DMZ/1:1 NAT, créer les mappages |
| Ping externe répond mais DNS ne marche pas | Règle 53/UDP/53/TCP absente | Créer les redirections/ACL spécifiques au port 53 |
| Ping externe vers IP publique répond, mais c’est le routeur | Le routeur traite l’ICMP pour lui‑même | DMZ/1:1 NAT vers le serveur ou accepter le comportement |
| Ping externe aléatoire | QoS/DoS/Rate‑limit ICMP sur le routeur ou FAI | Vérifier la protection DoS, ajuster la limite, utiliser un monitoring par port |
Spécificités DNS à l’Internet
Exposer un serveur DNS sur Internet exige des précautions :
- Récursion : désactivez la récursion publique si le serveur héberge des zones autoritatives uniquement. Autorisez la récursion uniquement aux subnets internes.
- TCP et UDP : ouvrez et mappez 53/UDP et 53/TCP (pour les réponses longues, transferts de zone, etc.).
- Anycast/Redondance : en production, préférez des serveurs DNS séparés et redondants, répartis sur des réseaux/AS différents si possible.
- Journalisation : activez des logs DNS pour détecter les abus (amplification, scans).
IPv6 : ne pas oublier l’ICMPv6
Avec IPv6, l’ICMPv6 est vital (découverte de voisins, MTU, etc.). Filtrer l’ICMPv6 de manière trop agressive casse la connectivité. Si votre serveur possède une adresse IPv6 globale, les tests externes se font sans NAT. Autorisez explicitement l’Echo Request ICMPv6 si vous voulez répondre aux pings externes :
New-NetFirewallRule -DisplayName "Allow ICMPv6 Echo In" `
-Protocol ICMPv6 -IcmpType 128 -Direction Inbound -Action Allow -Profile Any
Commandes utiles :
# Afficher les adresses IPv6
netsh interface ipv6 show addresses
# Ping IPv6 (depuis l'extérieur)
ping -6 Procédure pas à pas complète
- Vérifier la connectivité locale : ping de la passerelle, ping d’un hôte du LAN,
ipconfig /all. Corriger tout défaut local avant l’Internet. - Activer temporairement l’ICMP pour le diagnostic via PowerShell (ICMPv4, et éventuellement IPv6). Conserver une règle nominative pour la désactiver ensuite si la politique le requiert.
- Contrôler le service DNS : le rôle « DNS Server » doit être présent, le service en cours d’exécution, les zones chargées correctement (absence d’erreurs 4000/4013/4015).
- Confirmer l’écoute sur le port 53 :
netstat -anoetGet-NetUDPEndpoint/Get-NetTCPConnection. - Vérifier l’IP WAN du routeur : doit être publique. Si privée/CGNAT, demander une IP publique ou un mode bridge.
- Choisir la méthode d’exposition : DMZ/Exposed Host (si sûre et temporaire), 1:1 NAT (recommandé en pro) ou bridge.
- Créer les mappages nécessaires : 53/UDP et 53/TCP vers l’IP du serveur. Si souhaité, permettre l’ICMP vers cet hôte via DMZ/1:1 NAT.
- Tester depuis l’extérieur : ping (ICMP),
Test-NetConnectionsur le port 53, et unnslookup/digdepuis une machine non connectée au LAN. - Contrôler la sécurité : si la réponse ICMP n’est pas utile, retirez-la. Conservez uniquement les ports indispensables et des ACL source si possible.
- Industrialiser la supervision : mettez en place un monitoring par port (DNS/RDP/HTTPS). Le ping n’est qu’un signal de couche 3.
Exemples de commandes et sorties attendues
# 1) Activer ICMPv4 pour diagnostic
New-NetFirewallRule -DisplayName "Allow ICMPv4 Echo In" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -Profile Any
# 2) Vérifier l'écoute du DNS
netstat -ano | findstr ":53"
# 3) Tester la connectivité externe depuis un poste distant
Test-NetConnection -ComputerName -Port 53 -InformationLevel Detailed
# 4) Explorer la route
tracert
# 5) Désactiver la règle ICMP si non souhaitée en production
Disable-NetFirewallRule -DisplayName "Allow ICMPv4 Echo In" Pièges fréquents et solutions
- UPnP activé qui crée des redirections inattendues : désactiver en production, préférer des règles explicites.
- Hairpin NAT manquant : les clients du LAN ne peuvent pas atteindre le FQDN public. Solution : split‑DNS ou NAT loopback.
- Profils pare‑feu incohérents après jonction domaine : forcer une stratégie via GPO pour les règles ICMP et DNS.
- Antivirus/EDR avec pare‑feu intégré : vérifier les règles ICMP et port 53 au sein de la console EDR.
- QoS/DoS sur routeur qui limite l’ICMP : ajuster ou exclure l’ICMP des protections trop strictes.
Sécurité : bonnes pratiques de publication
- Principe du moindre privilège : n’ouvrez que ce qui est strictement requis (53/UDP/TCP si DNS public).
- ACL source : si possible, restreignez l’accès aux adresses qui en ont besoin (partenaires, sondes, secondary DNS).
- Récursion DNS : limitez-la aux réseaux internes. Un résolveur ouvert est une faille de sécurité et un vecteur d’amplification DDoS.
- Journaux et alertes : consignez les requêtes anormales. Surveillez les pics de trafic et les codes ICMP inhabituels.
- Durcissement Windows : appliquez les mises à jour, limitez les services installés, séparez les rôles (DNS ↔ autres services sensibles).
Cas pratiques
Petit site hébergé derrière une box
Vous avez une seule IP publique dynamique. Le routeur répond au ping et ne propose ni DMZ incluant l’ICMP ni 1:1 NAT. Vous ne pourrez pas faire répondre le serveur aux pings externes. Exposez uniquement port 53 si nécessaire, et validez l’accessibilité via tests de ports. Si vous tenez à la réponse ICMP du serveur, migrez vers un routeur/fai offrant DMZ/1:1 NAT, ou vers une offre IP fixe.
PME avec firewall dédié
Le modem du FAI est en mode bridge et le firewall possède l’IP publique. Créez une translation 1:1 (IP_publique ↔ IP_privée_serveur) incluant tous les protocoles, puis restreignez par politique les ports nécessaires. Le ping externe atteindra le serveur si la règle ICMP entrante de Windows l’autorise.
Environnement dual‑stack
Votre FAI délègue un préfixe IPv6 : l’ICMPv6 est nécessaire à la santé du réseau. Ouvrez au minimum l’Echo Request ICMPv6 sur le serveur si vous souhaitez qu’il réponde aux pings v6, et vérifiez que le pare‑feu périmétrique n’étrangle pas l’ICMPv6.
Checklist d’audit express
- Le serveur ping la passerelle et un hôte Internet (par IP) depuis le LAN.
- Règle Windows : Allow ICMPv4 Echo In active (et ICMPv6 si besoin).
- Adresse IP locale statique, passerelle correcte, DNS pointant vers lui‑même si rôle DNS.
- Service DNS Server en cours d’exécution ; netstat confirme l’écoute sur 53/UDP et 53/TCP.
- Routeur avec IP WAN publique, pas de CGNAT. Si double NAT, corriger la topologie.
- Méthode d’exposition choisie : DMZ/1:1 NAT/bridge. Règles de port 53 en place si DNS public.
- Tests externes réalisés (réseau mobile ou outil distant) pour éviter les faux positifs locaux.
- Supervision mise en place sur les ports de service, pas uniquement sur le ping.
FAQ rapide
Le ping est‑il indispensable ? Non. Il facilite le diagnostic et la supervision, mais on peut parfaitement fournir DNS/RDP/HTTP(S) sans répondre à l’ICMP.
Pourquoi mon routeur répond à la place du serveur ? Parce que l’ICMP vise l’IP publique du routeur. Sans DMZ/1:1 NAT, le routeur traite l’ICMP lui‑même.
Puis‑je « rediriger » l’ICMP comme un port ? Pas exactement. Il faut une exposition globale (DMZ) ou un mappage 1:1, ou une IP publique directement portée par le serveur/firewall en aval.
Mon FAI bloque‑t‑il l’ICMP ? Certains le limitent ou l’étranglent. Si tout est correct mais que le ping échoue encore, il est possible que l’opérateur filtre l’ICMP en amont.
Conclusion
La non‑réponse au ping depuis Internet résulte généralement de l’un de ces facteurs : pare‑feu Windows trop restrictif, routeur qui absorbe l’ICMP, double NAT/CGNAT, FAI filtrant, ou service DNS non publié correctement. En appliquant la séquence pare‑feu → IP → NAT → tests → journaux → FAI, vous isolez rapidement l’étape bloquante. Conservez des règles minimales et ciblées, et privilégiez un monitoring par port pour refléter la vraie disponibilité des services.
Récapitulatif des commandes clés
| Objectif | Commande |
|---|---|
| Autoriser ICMPv4 Echo entrant | New-NetFirewallRule -DisplayName "Allow ICMPv4 Echo In" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -Profile Any |
| Autoriser ICMPv6 Echo entrant | New-NetFirewallRule -DisplayName "Allow ICMPv6 Echo In" -Protocol ICMPv6 -IcmpType 128 -Direction Inbound -Action Allow -Profile Any |
| Vérifier l’écoute DNS | netstat -ano | findstr ":53" |
| Tester un port depuis l’extérieur | Test-NetConnection -ComputerName <IP_publique> -Port 53 -InformationLevel Detailed |
| Afficher la config IP | ipconfig /all |
| Lister les profils réseau | Get-NetConnectionProfile |
| Basculer/contrôler les règles pare‑feu | Get-NetFirewallRule, Enable/Disable-NetFirewallRule |
Notes de sécurité complémentaires
- Si vous exposez DNS au public, isolez ce rôle du reste (idéalement un serveur dédié ou un service géré), limitez la récursion, durcissez les transferts de zone (TSIG, IPs autorisées).
- Évitez d’ouvrir plus que nécessaire en DMZ ; la DMZ « exposed host » peut être pratique pour un test rapide mais n’est pas une solution pérenne.
- Conservez des sauvegardes et des instantanés avant toute modification d’infrastructure réseau, surtout si vous intervenez sur le routeur/pare‑feu.
En bref
Autorisez l’ICMP côté Windows si vous en avez besoin, assurez une IP/route correcte, utilisez DMZ ou 1:1 NAT pour que l’ICMP atteigne réellement le serveur, testez depuis l’extérieur, surveillez vos journaux et gardez la sécurité en tête. Ainsi, votre serveur Windows/DNS sera joignable et diagnostiquable depuis l’Internet, sans compromis inutile.