Windows Server 2022 : empêcher les interfaces VLAN de repasser en profil Public

Serveur Windows 2022 : comment empêcher vos interfaces VLAN agrégées de repasser en profil Public après chaque redémarrage

Après chaque reboot, vos interfaces VLAN d’un serveur de sauvegarde repassent systématiquement en profil Public, annulant les règles de pare‑feu indispensables. Découvrez pourquoi le service Network Location Awareness force ce basculement et comment le contrer de façon pérenne.

Sommaire

Contexte et symptômes

Dans de nombreux environnements SAN/NAS, un serveur de sauvegarde Windows Server 2022 dispose :

d’une agrégation NIC (teaming) pour la haute disponibilité ;
de plusieurs VLAN (production, réplication, gestion hors bande, etc.).

Au premier démarrage tout fonctionne : chaque interface affiche le profil Privé ou Domaine. Puis, après un redémarrage – installation cumulative, patch firmware ou simple maintenance – toutes les interfaces VLAN sont requalifiées Public. Conséquences :

Les règles de pare‑feu générées automatiquement par le logiciel de sauvegarde (et limitées aux profils Domaine/Privé) deviennent inopérantes.
Les travaux de sauvegarde à distance échouent ; les ports nécessaires sont bloqués.

Pourquoi le profil réseau change‑t‑il ?

Le composant clé est le service Network Location Awareness (NLA). À chaque initialisation de la pile TCP/IP il effectue :

Une probe DNS et LDAP afin de détecter un contrôleur de domaine AD.
Une inspection des politiques de sécurité locales et tierces (antivirus/EDR, VPN, client SD‑WAN).
Une comparaison avec le cache de signatures NLA.

Si l’une de ces étapes échoue ou qu’un agent externe impose sa propre catégorisation, NLA applique le profil Public, considéré comme le plus sûr par défaut.

Éléments aggravants

Cartes réseau Broadcom/Intel anciennes : pilotes NDIS obsolètes remontent des informations VLAN ambiguës ; NLA n’associe plus correctement les GUID.
Agents de sécurité : certains EDR détectent l’adresse IP du contrôleur AD comme « non fiable » lorsque la résolution DNS tarde.
Ordre de liaison : après un reboot, un VLAN peut apparaître avant l’interface de gestion classique et être traité comme premier « réseau ».

Solutions testées sur le terrain

Piste	Détails	Commentaires / points d’attention
Modifier puis verrouiller le registre	Ouvrir `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles`. Repérer chaque sous‑clé `ProfileName` correspondant à un VLAN. Passer `Category` de `0` (Public) à `1` (Privé). Verrouiller la clé : propriété = Everyone, droits = Lecture seule.	Empêche réécriture OS ou applicatif. ⚠ Risque de bloquer des mises à jour réseau ; documentez et sauvegardez la clé avant.
Neutraliser les agents tiers	Désinstallez temporairement l’antivirus/EDR ou créez une exclusion pour le composant NLA.	Solution souvent décisive ; nécessite coordination avec l’équipe sécurité.
Imposer la catégorie par GPO	Stratégie ordinateur → Paramètres Windows → Paramètres de sécurité → Network List Manager Policies. Spécifiez Location type = Privé pour chaque réseau ou pour ceux dont le nom contient `VLAN`.	Approche la plus propre en environnement AD. Ne couvre pas un VLAN fraîchement créé avant réplication de la GPO.
Script PowerShell au démarrage	Get-NetConnectionProfile ` \| Where-Object {$_.InterfaceAlias -like "VLAN"} ` \| Set-NetConnectionProfile -NetworkCategory Private Planifiez la tâche : déclencheur = At startup, utilisateur = SYSTEM*.	Solution de secours : la correction arrive quelques secondes après le boot, avant la plupart des services.
Mettre à jour pilotes et firmware	Dell, HPE et Lenovo publient régulièrement des révisions corrigées (NDIS 6.85+). Mettez aussi à jour le pilote du team (Broadcom BASP, Intel ANS, etc.).	Testez en labo ; certains firmwares modifient la numérotation des VLAN et nécessitent une maintenance planifiée.

Pas‑à‑pas détaillé pour chaque méthode

Verrouiller la clé registre Profiles

1. Identifier le bon GUID
Exécutez :
Get-NetAdapter -IncludeHidden | Select Name,InterfaceDescription,InterfaceGuid
Recoupez avec les sous‑clés du registre. Un GUID incorrect mènera à un verrouillage inefficace.

2. Automatiser la modification
Exemple de script .REG :

Windows Registry Editor Version 5.00

\[HKEY\LOCAL\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles{GUID\_VLAN}]
"Category"=dword:00000001

3. Sécuriser les ACL
Via PowerShell :

$path = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{GUID_VLAN}"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule("Everyone","ReadKey","Allow")
$acl = Get-Acl $path
$acl.SetAccessRuleProtection($true, $false)
$acl.AddAccessRule($rule)
Set-Acl $path $acl

Implémenter une GPO robuste

Créez ou éditez une GPO dédiée « NLA Fix VLAN ».
Accédez à Network List Manager Policies.
Double‑cliquez sur Unidentified Networks et réglez Location type = Privé.
Pour plus de finesse, créez une règle nommée « VLAN » ; renseignez le nom du réseau vu dans ncpa.cpl.
Liez la GPO à l’OU contenant les serveurs cibles.

Surveiller NLA et le pare‑feu

Activez deux journaux d’événements pour l’audit :

Applications and Services Logs ► Microsoft ► Windows ► NlaSvc ► Operational
Applications and Services Logs ► Microsoft ► Windows ► Firewall

Pendant un redémarrage de test, filtrez sur ID 4002 (changement de profil) puis examinez l’événement parent pour trouver la cause (timeout LDAP, échec DNS, etc.).

Approche recommandée selon la taille de l’infrastructure

Petite structure sans domaine

Verrouillage registre ou script PowerShell, car aucune GPO disponible.
Mise à jour pilote / firmware si le constructeur a publié un correctif.

Entreprise avec Active Directory

Priorité à la GPO, plus facile à maintenir et entièrement documentée.
Ajout d’un fallback PowerShell pour les VLAN éphémères (laboratoire).
Validation mensuelle par rapport aux mises à jour de pilotes via Lifecycle Controller ou iDRAC.

Environnement critique 24 × 7

Établir une matrice des flux Public minimale dans le pare‑feu Windows, pour que le serveur reste joignable même si NLA bascule.
Automatiser un test post‑reboot : script PowerShell qui ping le récepteur de sauvegarde et déclenche une alerte si le profil est Public.
Documenter la procédure de retour arrière (restore de la clé registre ou rollback de pilote).

Bonnes pratiques complémentaires

Ordonner les cartes réseau : dans ncpa.cpl ► Advanced Settings, placez l’interface de gestion et celle du domaine en premier.
Désactiver l’IPv6 sur les VLAN si non utilisé ; certains pilotes mal gérés génèrent des adresses link‑local incohérentes.
Retarder les services dépendants : si votre service de sauvegarde démarre trop tôt, set Startup type = Automatic (Delayed Start).
Contrôler la latence DNS : un DNS lent peut suffire à faire échouer la détection de domaine par NLA.

FAQ rapide

Existe‑t‑il une clé registre pour désactiver NLA ?

Non. Microsoft ne documente aucune option officielle. Arrêter le service compromet certaines fonctions (firewall, partages SMB, RPC).

Qu’en est‑il de l’utilitaire Set‑NetConnectionProfile ?

Il modifie simplement la même valeur registre Category. Sans verrouillage ou GPO, NLA peut toujours l’écraser.

Mon pilote est à jour mais le problème persiste ; idées ?

Vérifiez le firmware du switch : des incohérences LLDP ou CDP peuvent parfois induire NLA en erreur sur la topologie network.

Conclusion et plan d’action

Mettre à jour pilotes + firmware pour éliminer les bugs connus.
Implémenter une GPO Network List Manager pour catégoriser les VLAN.
Ajuster ou verrouiller la clé registre pour les cas hors domaine ou en dépannage rapide.
Surveiller NLA et le pare‑feu via l’Observateur d’événements.
Documenter chaque étape afin que l’équipe exploitation puisse reproduire la solution après tout changement matériel ou logiciel.

Suivre ce plan garantit que les interfaces VLAN restent en profil Privé/Domaine, protégeant vos sauvegardes sans bloquer des mises à jour légitimes.

Windows Server 2022 : empêcher les interfaces VLAN de repasser en profil Public