Les clients VPN bloqués par le profil Public du pare-feu Windows

Windows classe l’adaptateur VPN en Public, si bien que vos règles LAN ne s’appliquent jamais. Vérifiez le profil, limitez une règle entrante au pool, puis validez le port.

Votre tunnel est monté, la passerelle répond au ping, et le partage de fichiers expire toujours. Cette combinaison est rarement un problème de routage : Windows a placé le sous-réseau de l’adaptateur VPN dans le profil Public, et toutes les règles d’autorisation écrites pour Privé ou Domaine ne se sont jamais appliquées. J’ai rencontré ce cas sur des portables qui atteignent le bureau sans problème et sur des serveurs RRAS qui desservent tous les autres clients, et la réparation est courte dès que l’on nomme le profil en cause. Voici l’ordre dans lequel je procède, avec le contrôle qui vous dit de vous arrêter avant l’étape suivante.

Identifier le profil sur lequel le trafic arrive réellement

Le pare-feu Windows n’a pas de mode global unique. Chaque interface connectée porte une catégorie, et les paquets entrants sont filtrés selon la catégorie de l’interface par laquelle ils arrivent ; c’est donc le profil de l’adaptateur VPN qui décide de ce qu’un client tunnelisé peut atteindre, et non l’adaptateur Wi-Fi ou Ethernet à côté. Lisez ces deux informations avant de modifier quoi que ce soit :

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Avec une installation standard d’OpenVPN ou de WireGuard, l’adaptateur VPN apparaît comme un réseau non identifié et se retrouve dans Public, la valeur par défaut de tout réseau que Windows ne sait pas classer : aucun contrôleur de domaine n’a répondu dessus et aucun profil de passerelle ne correspondait. Le nom de l’interface n’a ici aucune importance, appeler l’adaptateur « VPN » ou « Corp » ne change donc rien. DomainAuthenticated exige une machine jointe au domaine , qui puisse réellement joindre un contrôleur de domaine via cette interface ; un tunnel partiel qui ne transporte qu’un seul sous-réseau ne suffira pas.

Si la règle dont vous avez besoin est déjà limitée au pool VPN et s’applique déjà à la catégorie que vous venez de lire, arrêtez-vous ici : le filtrage n’est pas votre couche, et le prochain endroit à examiner est la configuration du service. Ce contrôle prend dix secondes et fait gagner une heure de modification de règles. Les noms des catégories et ce que chacune couvre sont documentés dans la référence de Get-NetConnectionProfile.

Confirmer le filtrage, pas le routage, avant de modifier des règles

Le ping est un test faible. ICMP peut passer alors que le port du service est bloqué, et un hôte peut répondre depuis le LAN tout en refusant la même requête par le tunnel. Testez le port dont le client a besoin, depuis le client :

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Si le test de port échoue, séparez les deux couches. Une panne de tunnel ou de route se traduit généralement par aucune réponse de l’adresse de passerelle, tandis qu’un rejet du pare-feu montre une passerelle qui répond et un port de service qui ne répond pas. Sur un serveur Windows qui publie le pool via RRAS, exécutez le même test depuis un client et lisez le profil du serveur lui-même : l’interface RAS peut se trouver dans une catégorie dont les règles entrantes ne mentionnent jamais la plage des clients, ce qui explique que la machine serve son LAN et refuse tous les clients tunnelisés.

Si le résultat reste ambigu, journalisez les rejets du profil en cause et lisez-les :

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Les entrées qui nomment l’adresse et le port du client avec DROP sont concluantes, et elles indiquent aussi quelle règle manquait. Un journal vide alors que le SYN du client n’apparaît jamais pointe en amont de l’hôte : revenez donc au tunnel, à la règle NAT ou à la route du pool avant de toucher un autre objet du pare-feu.

Limiter une règle entrante au pool de clients

La réparation tient en une règle d’autorisation entrante dont l’adresse distante est le pool, pas le monde entier. Depuis une session élevée :

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Lorsque le service est un seul binaire, préférez une règle limitée au programme avec -Program plutôt qu’une liste de ports ; cela limite l’exception au processus ainsi qu’à la plage source.

Le choix du profil est l’endroit où la même erreur se produit dans l’autre sens. -Profile Public suffit lorsque l’adaptateur est Public et le reste. -Profile Any est défendable lorsque le service doit fonctionner quoi que fasse Windows pour classer l’adaptateur, mais uniquement tant que la portée distante reste en place. Ce qui n’est jamais défendable, c’est -RemoteAddress Any sur le profil Public : cette règle suit le portable dans chaque réseau de café et d’hôtel qu’il rejoint et ouvre le port à quiconque partage ce sous-réseau.

Notez le pool à côté de la règle. -RemoteAddress 10.8.0.0/24 cesse silencieusement de correspondre le jour où le pool VPN est renuméroté, et la panne ressemble exactement au bogue d’origine, ce qui coûte un second après-midi. Nommez les règles d’après le service et la plage source, gardez-les ensemble avec -Group, et relisez-les chaque fois que la définition du pool change. Un inventaire de règles consultable sur un seul écran vaut mieux qu’une règle correcte que personne ne trouve.

Ne changer de catégorie que lorsque la catégorie est la décision

Basculer l’interface en Privé fonctionne aussi, mais c’est le mauvais choix par défaut. Le profil Privé comporte une longue liste de règles d’autorisation intégrées, couvrant le partage de fichiers et d’imprimantes, la découverte réseau, le bureau à distance et davantage selon la base de référence ; reclasser l’adaptateur VPN les active donc toutes pour chaque client du tunnel à la fois. Une règle limitée accorde un service à une plage. Sur un portable qui rejoint aussi des réseaux non fiables, cette différence n’est pas cosmétique.

Il existe des cas où la classification est réellement erronée : un tunnel permanent ou de site à site transportant un sous-réseau de bureau est une infrastructure de confiance, et marquer cet adaptateur comme Privé est un choix de conception légitime, fait une fois par politique, pas par ticket. Quand vous le faites, faites-le explicitement :

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Sur un appareil géré, vérifiez d’abord si une stratégie de groupe ou une base de référence MDM possède le paramètre. Si c’est le cas, la modification locale est annulée à la prochaine actualisation et gpresult /h nommera la stratégie qui le possède ; corrigez-la là-bas, pas sur le poste.

Vérifier aux deux extrémités et laisser une trace

Vérifiez le flux signalé par l’utilisateur, depuis le client, après la modification :

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Bouclez ensuite sur ce qui cassera la semaine prochaine. Redémarrez l’hôte et retestez, car une règle limitée au mauvais profil continue de fonctionner jusqu’à ce que l’adaptateur revienne dans une autre catégorie. Testez depuis un second client, car un client qui conserve un bail périmé peut masquer une incohérence de pool. Comptez les règles ajoutées face à celles supprimées, car les exceptions qui se chevauchent sont la façon dont un correctif de deux lignes devient une politique de filtrage que personne ne peut relire.

Avant de le déclarer terminé :

  • Le profil nommé dans la règle est celui de l’interface par laquelle le trafic arrive.
  • La portée distante est le pool VPN, et ce pool correspond à ce que le serveur distribue réellement.
  • Aucune règle que vous avez ajoutée n’utilise -RemoteAddress Any sur le profil Public.
  • Rien n’a été désactivé pour faire passer le test, et tout changement de catégorie consigne qui l’a approuvé.

Articles similaires