260823-Le réglage du pare-feu Portmaster
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éesfdPHost,SSDPSRV,FDResPub,upnphost: les quatreRunning
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) surjulie», 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
No comments to display
No comments to display