Pare-feu Windows : diagnostiquer les règles effectives et les flux bloqués

Résumé opérationnel

Le pare-feu applique les profils Domain, Private et Public selon le réseau détecté. Une règle correcte pour Domain ne résout rien si le poste utilise Public, et désactiver le pare-feu pour tester modifie trop largement le risque.

Les règles proviennent de plusieurs policy stores: local, GPO, MDM, service hardening ou règles intégrées. Get-NetFirewallRule avec PolicyStoreSourceType et ActiveStore aide à comprendre l’état effectif.

Je reproduis le flux avec source, destination, protocole et port connus, active une journalisation séparée par profil et corrèle les paquets dropped/allowed. Le rollback retire uniquement la règle pilote.

Le pare-feu applique les profils Domain, Private et Public selon le réseau détecté. Une règle correcte pour Domain ne résout rien si le poste utilise Public, et désactiver le pare-feu pour tester modifie trop largement le risque.

Symptôme, contexte et périmètre de l’incident

Get-NetConnectionProfile et Get-NetFirewallProfile établissent le profil réseau et les actions par défaut. Je vérifie aussi le domaine authentifié, le VPN et les changements de profil pendant la reproduction.

Get-NetFirewallRule -PolicyStore ActiveStore montre les règles actives, tandis que PolicyStoreSourceType aide à distinguer local, group policy et autres sources. Le nom d’une règle ne garantit pas qu’elle est applicable.

Une règle combine direction, action, enabled, profile et filtres de programme, service, adresse, port, interface et sécurité. Je récupère les filtres associés au même instance ID pour éviter une lecture partielle.

• Windows Firewall, Intune, Troubleshooting, Network
• Endpoint Lab — Network, Policy stores, Filtering, Evidence
• flux exact documenté, profil réseau reproduit, droits de lecture firewall

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting du pare-feu Windows, l’enquête suit le parcours Network → Policy stores → Filtering → Evidence. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Identifier profil et actions par défaut, Lister les règles actives et sources et Lire tous les filtres de la règle candidate. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « Règle présente, flux KO, Règle locale ignorée et Port ouvert mais service KO » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Identifier profil et actions par défaut.
• Lister les règles actives et sources.
• Lire tous les filtres de la règle candidate.

Cartographie du flux à diagnostiquer

Get-NetConnectionProfile et Get-NetFirewallProfile établissent le profil réseau et les actions par défaut. Je vérifie aussi le domaine authentifié, le VPN et les changements de profil pendant la reproduction.

Get-NetFirewallRule -PolicyStore ActiveStore montre les règles actives, tandis que PolicyStoreSourceType aide à distinguer local, group policy et autres sources. Le nom d’une règle ne garantit pas qu’elle est applicable.

Une règle combine direction, action, enabled, profile et filtres de programme, service, adresse, port, interface et sécurité. Je récupère les filtres associés au même instance ID pour éviter une lecture partielle.

État initial et prérequis de collecte

L’état initial de Troubleshooting du pare-feu Windows doit couvrir flux exact documenté, profil réseau reproduit, droits de lecture firewall, policies Intune/GPO exportées. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Network, Policy stores, Filtering, Evidence sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• flux exact documenté
• profil réseau reproduit
• droits de lecture firewall
• policies Intune/GPO exportées
• journalisation bornée
• application et service identifiés
• règle de rollback prête

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting du pare-feu Windows relie Network, Policy stores, Filtering, Evidence. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Identifier profil et actions par défaut. Lister les règles actives et sources. Lire tous les filtres de la règle candidate. Reproduire avec logs par profil. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Mauvais profil/filtre », « Merge désactivé », « Process non à l’écoute » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Identifier profil et actions par défaut.
• Lister les règles actives et sources.
• Lire tous les filtres de la règle candidate.
• Reproduire avec logs par profil.
• Vérifier process et écoute locale
• Créer une règle pilote minimale
• Tester autorisé et refusé

Investigation pas à pas

L’investigation suit l’ordre Network → Policy stores → Filtering → Evidence. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting du pare-feu Windows, les contrôles « Reproduire et horodater le symptôme », « Contrôler la première couche », « Corréler les preuves » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé de Troubleshooting du pare-feu Windows

Get-NetConnectionProfile et Get-NetFirewallProfile établissent le profil réseau et les actions par défaut. Je vérifie aussi le domaine authentifié, le VPN et les changements de profil pendant la reproduction.

Get-NetFirewallRule -PolicyStore ActiveStore montre les règles actives, tandis que PolicyStoreSourceType aide à distinguer local, group policy et autres sources. Le nom d’une règle ne garantit pas qu’elle est applicable.

Une règle combine direction, action, enabled, profile et filtres de programme, service, adresse, port, interface et sécurité. Je récupère les filtres associés au même instance ID pour éviter une lecture partielle.

• flux exact documenté
• profil réseau reproduit
• droits de lecture firewall
• policies Intune/GPO exportées

Traitement, exploitation et cas limites de Troubleshooting du pare-feu Windows

Les paramètres AllowLocalFirewallRules et le merge déterminent si une règle locale participe au résultat. Une policy MDM qui refuse le merge peut rendre invisible l’effet attendu d’une règle créée manuellement.

Les règles block explicites et les règles de service peuvent primer sur une ouverture générale selon le scénario. Je ne tente pas d’inférer la priorité uniquement par ordre d’affichage dans wf.msc.

La journalisation peut enregistrer les paquets dropped et les connexions allowed. Microsoft recommande une taille suffisante et des fichiers distincts pour Domain, Private et Public afin de garder une chronologie exploitable.

• Vérifier process et écoute locale
• Créer une règle pilote minimale
• Tester autorisé et refusé

Lire les états propres à Troubleshooting du pare-feu Windows

Test-NetConnection confirme la capacité TCP mais ne démontre pas quelle règle a décidé. pktmon, netsh trace ou une capture réseau peuvent compléter le diagnostic lorsque le paquet n’atteint pas l’application.

Les événements de Windows Filtering Platform dans le journal Security exigent une audit policy et peuvent être volumineux. Je l’active sur un pilote pour une fenêtre courte, avec stockage et protection des adresses.

La correction crée une règle étroite avec programme ou service, protocole, port, direction, profils et adresses nécessaires. Je teste les flux autorisés et interdits pour éviter une ouverture fonctionnelle mais excessive.

• Règle présente, flux KO — ActiveStore et filtres
• Règle locale ignorée — Firewall profile effective
• Port ouvert mais service KO — Get-NetTCPConnection
• Flux intermittent en VPN — Chronologie réseau

Pilote et suivi opérationnel de Troubleshooting du pare-feu Windows

Le pilote couvre le périmètre Windows Firewall, Intune, Troubleshooting, Network et contrôle Identifier profil et actions par défaut. Lister les règles actives et sources. Lire tous les filtres de la règle candidate. Les résultats sont segmentés selon les populations réellement concernées par Troubleshooting du pare-feu Windows.

Les cas d’échec « Règle présente, flux KO », « Règle locale ignorée », « Port ouvert mais service KO » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne pas désactiver tous les profils, ne pas créer Any/Any, protéger les journaux réseau, tester IPv4 et IPv6. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Identifier profil et actions par défaut. Lister les règles actives et sources. Lire tous les filtres de la règle candidate. Reproduire avec logs par profil. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting du pare-feu Windows, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity,IPv6Connectivity
  Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction,AllowLocalFirewallRules,LogFileName
  Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True |
    Select-Object DisplayName,Direction,Action,Profile,PolicyStoreSourceType,PrimaryStatus
} catch { Write-Error "Collecte pare-feu impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  Get-NetFirewallProfile |
    Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction,LogFileName
  Get-NetFirewallRule -PolicyStore ActiveStore |
    Where-Object Enabled -eq 'True' |
    Select-Object DisplayName,Direction,Action,Profile,PolicyStoreSourceType
  Test-NetConnection -ComputerName '<HOST>' -Port 443 -InformationLevel Detailed
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[14:08:10.012] Profile Active=Domain DefaultOutbound=Allow
[14:08:10.018] Rule    Name=<RULE> Direction=Outbound Action=Block Source=MDM
[14:08:11.441] Test    Remote=<HOST>:443 TcpTestSucceeded=False
[14:08:11.442] Firewall DROP TCP <SRC-IP> <DST-IP> <SRC-PORT> 443
[14:09:02.100] Check   PolicyStore=ActiveStore RuleMatch=<RULE>

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment Règle présente, flux KO, Règle locale ignorée, Port ouvert mais service KO, Flux intermittent en VPN. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Identifier profil et actions par défaut, Lister les règles actives et sources et Lire tous les filtres de la règle candidate sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Troubleshooting du pare-feu Windows est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• Identifier profil et actions par défaut.
• Lister les règles actives et sources.
• Lire tous les filtres de la règle candidate.
• Reproduire avec logs par profil.
• Vérifier process et écoute locale
• Créer une règle pilote minimale
• Tester autorisé et refusé

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting du pare-feu Windows restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Identifier profil et actions par défaut. Lister les règles actives et sources. Lire tous les filtres de la règle candidate. Reproduire avec logs par profil. ainsi que les causes déjà écartées.