Skip to main content

260823-Le réglage du parefeu Postmaster

Portmaster — la découverte réseau et le NAS maison

Poste julie (DESKTOP-B7J2KGP), Windows 10. Installation de Safing Portmaster 2.2.1 le 22/08/2026 à 10:58, réglage le 23/08/2026.

Portmaster est un pare-feu applicatif qui s'insère au niveau WFP via son pilote portmaster-kext.sys. Il double le pare-feu Windows et c'est lui qui tranche : inutile d'aller chercher du côté de Defender.

Élément Valeur Version 2.2.1 (éditeur safing) Service PortmasterCore, démarrage automatique Binaires C:\Program Files\Portmaster Données et journaux C:\ProgramData\Portmaster API locale http://127.0.0.1:817

1. Le symptôme, et ce qui n'était pas en cause

Plus aucune découverte réseau sur le poste : le NAS Synology maison (192.168.1.17, \\NASMAISON) n'apparaissait plus dans le volet Réseau de l'Explorateur.

Le premier réflexe — soupçonner le réseau ou le NAS — était faux. Tout répondait :

Contrôle Résultat Poste 192.168.1.26/24, passerelle et DNS 192.168.1.1 Ping 192.168.1.17 répond MAC du NAS 00-11-32-9C-8E-C9 — OUI Synology Ports TCP 445, 139, 22, 80 ouverts (5000/5001 fermés) Résolution du nom NASMAISON → NASMAISON.local = 192.168.1.17, par mDNS Lecteur A: → \\NASMAISON\foxy monté et lisible, 55 entrées

Leçon : l'accès n'a jamais été rompu, seule la découverte l'était. Distinguer les deux dès le départ fait gagner beaucoup de temps.

Détail annexe, non symptomatique : \\192.168.1.17\foxy échoue alors que \\NASMAISON\foxy fonctionne. L'identifiant Windows est enregistré sous la cible NASMAISON (utilisateur juxjux), pas sous l'adresse IP — comportement normal de cmdkey.

2. Le diagnostic

La preuve est dans le journal de Portmaster, C:\ProgramData\Portmaster\logs\2026-08-22_10-57-46.log :

2026-08-23 07:12:50  filter: connection AUTORITE NT\SERVICE LOCAL:
  C:\Windows\System32\svchost.exe:12184 <- 192.168.1.17
  dropped: inbound connections blocked

svchost.exe PID 12184 héberge le service SSDPSRV (Découverte SSDP) — identifié par Get-CimInstance Win32_Service -Filter "ProcessId=12184".

Cadence des rejets : 05:56, 06:11, 06:26, 06:42, 06:57, 07:12 — toutes les ~15 minutes, soit exactement le rythme des annonces SSDP périodiques du NAS.

Répartition des 1 802 blocages du même motif :

Source Occurrences Destinataire 92.184.113.225 441 syncthing.exe 192.168.1.26 (le poste lui-même) 421 — 192.168.1.1 (Livebox) 330 — 192.168.1.17 (NAS) 249 SSDPSRV 192.168.1.19 153 — IPv6 globales 2a01:cb1c:… ~80 syncthing.exe, SSDPSRV

À noter : le trafic sortant passait bien (287 requêtes SSDP acceptées vers 239.255.255.250:1900). Le poste interrogeait, mais les annonces du NAS, qui arrivent en entrant non sollicité, étaient jetées.

3. La cause

Le réglage filter/blockInbound — « Force Block Incoming Connections » — activé par défaut à l'installation.

Sa propre description est sans ambiguïté : « Is stronger than Rules ». Aucune règle entrante ne peut le contourner, ce qui explique qu'aucun réglage fin ne suffisait tant qu'il restait coché.

État des réglages liés au moment du diagnostic :

Clé Valeur Rôle filter/blockInbound True (défaut) la cause filter/defaultAction permit (défaut) action si aucune règle ne correspond filter/serviceEndpoints [] Incoming Rules, vides filter/blockLAN False (défaut) non impliqué

4. La configuration retenue

Incoming Rules, dans cet ordre impératif :

Ordre Menu Champ 1 Allow Localhost 2 Allow LAN 3 Block *

puis décocher Force Block Incoming Connections.

Localhost, LAN et Internet sont des mots-clés de portée reconnus par Portmaster, au même titre qu'une adresse ou un CIDR. Les utiliser vaut mieux que d'écrire 192.168.1.0/24 : la portée suit le réseau, la règle ne devient jamais caduque.

Variante resserrée

Si l'on veut n'ouvrir que le strict nécessaire à la découverte, plutôt que tout le LAN — cela laisse notamment les partages administratifs C$, D$, E$ et le RPC fermés y compris depuis le réseau local :

Menu Champ Rôle Allow Localhost boucle locale Allow LAN UDP/1900 SSDP — les annonces du NAS Allow LAN UDP/3702 WS-Discovery Allow LAN TCP/5357 WSDAPI, l'échange qui construit l'icône Block * tout le reste

Pour Syncthing en direct sur le LAN, ajouter avant le Block : LAN TCP/22000, LAN UDP/22000, LAN UDP/21027.

5. Les pièges — à ne pas redécouvrir

1. Incoming Rules est invisible en mode Simple. filter/serviceEndpoints est de niveau expert (ExpertiseLevel 1), tandis que filter/endpoints (Outgoing Rules) est de niveau user — d'où l'impression trompeuse que seules les règles sortantes existent. Basculer l'interface sur Advanced Interface : sélecteur en haut à droite de la fenêtre, ou Settings → User Interface → UI Mode. Les réglages masqués restent actifs.

2. Ne jamais taper le + ou le - dans le champ de la règle. Le menu Allow/Block fournit déjà le signe. Saisir + LAN produit + + LAN et déclenche :

Invalid Value: validation of filter/serviceEndpoints failed:
entry #1 did not match validation regex

La regex de validation est :

^(\+|\-) (! +)?[A-z0-9\.:\-*/]+( [A-z0-9*]+(/[A-z0-9]+(\-[A-z0-9]+)?)?)?( +#.*)?

Le + n'appartient pas à la classe de caractères qui suit le signe. La syntaxe + LAN / - * est celle du fichier de configuration, pas de l'interface graphique.

3. Block * sans Allow Localhost au-dessus casse la boucle locale. Constaté en direct :

07:43:31  firefox.exe    <- 127.0.0.1  dropped: denied by rule: matches *
07:43:18  syncthing.exe  <- 127.0.0.1  changed from accepted to dropped
07:43:18  steam.exe      <- 127.0.0.1  changed from accepted to dropped
07:43:18  dasHost.exe    <- ::1        changed from accepted to dropped

L'interface Syncthing sur 127.0.0.1:8384 est tombée en timeout. Portmaster ré-évalue les connexions déjà établies et les coupe à chaud. Sur une machine de travail, une grande part du trafic légitime passe par la boucle locale.

Piège dans le piège : l'API de Portmaster s'auto-exempte et continue de répondre — elle ne sert donc pas de témoin pour détecter la panne.

4. L'ordre des règles fait tout. Évaluation de haut en bas, la première correspondance l'emporte. Block * doit être la dernière ligne. Les flèches à gauche de chaque ligne permettent de réordonner.

5. filter/defaultAction vaut permit. Une liste de règles sans Block * final n'est pas restrictive : tout ce qui ne correspond à aucune règle est autorisé. Décocher Force Block Incoming sans poser ce garde-fou ouvre la machine — point critique compte tenu de l'IPv6 (section 6).

6. L'API locale ment par omission. GET http://127.0.0.1:817/api/v1/config/options répond à n'importe quel processus, mais ne renvoie que les définitions et les valeurs par défaut : le champ Value reste vide même pour un réglage effectivement modifié, ce qui fait croire à tort que rien n'a été enregistré. Les endpoints qui exposent l'état réel (/api/v1/sync/settings/export) répondent :

403 The requesting process is not authorized to access the Portmaster API.

Vérifier par le journal, jamais par l'API.

7. Le profil réseau Windows n'a pas eu à être modifié. Il est resté sur Public et la découverte fonctionne. L'hypothèse initiale — passer en Privé et redémarrer FDResPub et upnphost — s'est révélée inutile. Ne pas y consacrer de temps.

6. IPv6 — le point de sécurité

Ce poste possède des adresses IPv6 globales routables : 2a01:cb1c:833b:d00:4958:51b1:629a:a6b4 et 2a01:cb1c:833b:d00:28cb:cac8:3621:d7d0 (préfixe Orange, obtenu par Router Advertisement).

En IPv6 il n'y a pas de NAT. La Livebox ne fait pas écran comme en IPv4 : Portmaster est la seule barrière. Ce que le poste expose au réseau :

Port Processus 445 SMB — partages ADMIN$, C$, D$, E$, IPC$ 135 + 49664-49675 RPC (lsass, wininit, spoolsv, services) 5357 WSDAPI 22000 Syncthing 27036 Steam

La portée LAN ne couvre pas ces adresses globales — elles sont classées Global, pas LAN. Le Block * les refuse donc, ce qui est le comportement voulu.

Conséquence assumée : les liens Syncthing directs en IPv6 restent bloqués. Sans impact aujourd'hui, la synchronisation passant par le hub VPS (syncthing-vps, tcp-client vers 51.77.141.54:22000). Pour les rétablir, ajouter 2a01:cb1c:833b:d00::/64 au-dessus du Block * — en sachant que ce préfixe peut changer au redémarrage de la Livebox et rendre la règle caduque sans le moindre signal.

7. Vérification

État constaté après réglage :

Portée Verdict 127.0.0.1 / ::1 accepté — scope matches Localhost LAN (192.168.1.x, fe80::) accepté — scope matches LAN, 8 acceptations NAS, zéro rejet IPv6 globales 2a01:cb1c:… rejeté — denied by rule: matches *
    Interface Syncthing 127.0.0.1:8384 : HTTP 200 A: → \\NASMAISON\foxy : accessible, 55 entrées fdPHost, SSDPSRV, FDResPub, upnphost : les quatre Running

    Commande de contrôle, à relancer si le NAS redisparaît :

    grep "192.168.1.17" /c/ProgramData/Portmaster/logs/*.log | tail -20

    Attendu :

    svchost.exe:12184 <- 192.168.1.17  accepted: allowed by rule: scope matches LAN
dasHost.exe:3608  to nasmaison. (192.168.1.17)  accepted

    dasHost.exe est le Device Association Host : le voir dialoguer avec nasmaison., c'est littéralement l'icône du NAS en train de se construire dans l'Explorateur.

    Si l'on lit dropped: inbound connections blocked, c'est que Force Block Incoming Connections a été réactivé.

    8. Chronologie

    Horodatage Événement 22/08 10:58 Installation de Portmaster 2.2.1 22/08 → 23/08 Découverte réseau muette, ~1 800 blocages entrants silencieux 23/08 ~05:45 Diagnostic : NAS joignable, seule la découverte est cassée 23/08 ~07:30 Cause identifiée — filter/blockInbound et les annonces SSDP 23/08 07:41 Allow LAN posé, Force Block Incoming décoché → NAS visible 23/08 07:43 Block * ajouté → boucle locale coupée, Syncthing GUI en timeout 23/08 07:45 Allow Localhost ajouté en tête → état final correct 23/08 07:46 Vérification des trois niveaux, conforme

    9. Références

      CLAUDE.md — section « Portmaster (pare-feu applicatif) sur julie », insérée le 23/08/2026 Journal Portmaster : C:\ProgramData\Portmaster\logs\ Aide intégrée à Portmaster : la syntaxe complète des règles (portées, domaines, pays, AS, listes de filtrage, protocoles et ports) est dans l'infobulle des champs Outgoing Rules et Incoming Rules
      Back to top