Windows Server 2022: profilo di rete delle VLAN torna “Pubblico” dopo ogni riavvio (NIC Team) — cause, fix e best practice

Ecco come risolvere un problema ricorrente in Windows Server 2022: su server con NIC Team e più interfacce VLAN, il profilo di rete torna “Pubblico” a ogni riavvio, bloccando i backup. Qui trovi cause tipiche, verifiche pratiche e procedure affidabili per rendere stabile il profilo “Privato”.

Indice

Scenario e contesto

Ambiente tipico: Windows Server 2022 con NIC Team (LBFO/SET) e più interfacce VLAN logiche. Per ogni VLAN il profilo di rete viene impostato su Privato (o Dominio quando il DC è raggiungibile), ma dopo ogni riavvio alcune o tutte le VLAN tornano Pubblico. Il software di backup applica regole firewall soltanto per i profili Dominio/Privato, quindi il traffico di backup (SMB/RPC, agent proprietari, ecc.) viene bloccato.

Perché succede

Network Location Awareness (NLA) assegna un profilo (Pubblico, Privato o Dominio autenticato) a ciascuna rete identificandola tramite una firma di rete (gateway, DNS, dominio, ecc.) e memorizzando il risultato nel Registro in …\NetworkList\Profiles. In ambienti con VLAN su NIC Team possono verificarsi:

Rivalutazioni aggressive della rete durante il boot (ordine di inizializzazione dei driver, Team/VLAN che “appaiono” e “scompaiono”).
Nuove firme per la stessa VLAN (es. cambio MAC gateway, failover/VRRP/HSRP sul core, path diversi nel LAG/LACP), che inducono NLA a creare un nuovo profilo con categoria predefinita Pubblico.
Policy o agent di sicurezza (AV/EDR/HIPS) che forzano sempre il profilo Pubblico per massimizzare la superficie difensiva.
Impossibilità temporanea di contattare il DC all’avvio (nel caso di profilo Dominio), che porta a “declassamenti” a Pubblico e successivo mancato ripristino automatico.

Come riconoscere il problema

Subito dopo il boot, l’output di Get-NetConnectionProfile mostra alcune VLAN in Public anche se prima erano Private.
Nel Visualizzatore eventi, i log Microsoft-Windows-NlaSvc/Operational e Microsoft-Windows-NetworkProfile/Operational riportano cambi di categoria o la creazione di nuovi profili.
Il registro in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles contiene più GUID con nomi rete simili (es. “Rete”, “Rete 2”, “Rete 3”).

Soluzioni (e motivazioni)

Passo	Azione	Perché funziona
1. Impostare manualmente il profilo su “Privato” nel registro	Aprire `regedit` → `HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\[GUID]` Modificare `Category` da `0` (Pubblico) a `1` (Privato)	NLA legge questo valore a ogni avvio per classificare la rete.
2. Bloccare ulteriori modifiche	In “Autorizzazioni avanzate” del medesimo GUID: Cambiare Owner e i permessi in modo da consentire solo Lettura (vedi più sotto la procedura consigliata)	Impedisce a servizi o applicazioni di sovrascrivere nuovamente `Category`.
3. Verificare software di terze parti	Molti antivirus/EDR forzano il profilo “Pubblico”. Disinstallare o disabilitare temporaneamente per conferma.	Se il profilo rimane “Privato” senza AV, la causa è confermata; configurare eccezioni o preferire prodotti compatibili.
4. Applicare una GPO (opzionale)	Criteri di sicurezza locali → Network List Manager Policies → assegnare il profilo desiderato alla rete o alle Unidentified Networks.	Fornisce persistenza lato dominio, senza modifiche manuali su ogni server.
5. Creare regole firewall valide per “Qualsiasi” profilo (opzionale)	`New-NetFirewallRule … -Profile Any` con scoping a IP/programma/porta	Mitiga l’impatto anche se il profilo dovesse cambiare ancora.

Verifiche preliminari consigliate

Inventariare i profili correnti Get-NetConnectionProfile | Sort-Object InterfaceAlias | Format-Table Name, InterfaceAlias, NetworkCategory
Elenco dei profili nel Registro Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\*' | Select-Object PSChildName, ProfileName, Category | Format-Table -AutoSize
Controllo log NLA
Apri il Visualizzatore Eventi → Applications and Services Logs → Microsoft → Windows → NlaSvc → Operational, e NetworkProfile/Operational. Cerca eventi di “identificazione rete” e “categoria profilo”.

Procedura dettagliata

Impostare la categoria su Privato via Registro

La modifica è per-VLAN (per GUID). Individua il profilo corretto incrociando Name e InterfaceAlias con i dati in Profiles. Quindi imposta Category = 1:

# Esempio PowerShell: imposta tutte le VLAN correnti in Private
Get-NetConnectionProfile |
  Where-Object {$_.InterfaceAlias -match '^VLAN'} |
  ForEach-Object {
    $guid = (Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles' |
             Where-Object { (Get-ItemProperty $.PSPath).ProfileName -eq $.Name }).PSChildName
    if ($guid) {
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\{$guid}" /v Category /t REG_DWORD /d 1 /f | Out-Null
    }
  }

In alternativa, per singola interfaccia:

Set-NetConnectionProfile -InterfaceAlias "VLAN10" -NetworkCategory Private

Attenzione: quest’ultimo comando può essere sovrascritto al riavvio se la causa non è rimossa.

Impedire modifiche indesiderate alla chiave del profilo

La strategia più solida è ridurre in modo mirato i diritti in scrittura di chi effettua il downgrade (tipicamente il servizio NlaSvc o un agent di sicurezza), preservando la possibilità di gestione da parte degli amministratori.

Strategia consigliata (hardening mirato)

Identifica il GUID del profilo interessato (vedi sopra).
Aggiungi una regola Deny per impedire la scrittura a NT SERVICE\NlaSvc sulla sottochiave del profilo, mantenendo Administrators e SYSTEM con controllo completo.

$guid  = '{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}'   # Sostituisci
$path  = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\$guid"
$acl   = Get-Acl $path
$rule  = New-Object System.Security.AccessControl.RegistryAccessRule(
           'NT SERVICE\NlaSvc',
           'SetValue,CreateSubKey,Delete,WriteKey',
           'None',
           'None',
           'Deny'
         )
$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl

Questa impostazione impedisce a NLA di cambiare Category per quel profilo, ma non rompe la lettura del profilo stesso. Nota: una regola Deny prevale su qualsiasi Allow; applicala solo alla sottochiave del profilo interessato.

Strategia d’emergenza (blocco brutale e temporaneo)

Rendere la chiave di sola lettura a “tutti” può fermare qualunque sovrascrittura, ma peggiora la sicurezza e la gestibilità. Se la applichi per un test veloce:

Cambia proprietario della chiave in un account amministrativo e imposta permessi Read per Everyone, limitando la scrittura.
Usala solo per riprodurre il fenomeno e poi torna a una configurazione di ACL più granulare.

Buona pratica: mantieni Administrators proprietario della chiave ed evita “Everyone” come owner in ambienti di produzione.

Valutare e configurare l’agent di sicurezza

Se hai un antivirus/EDR/HIPS:

Esegui un riavvio con l’agent disabilitato temporaneamente (o in “bypass”) per verificare se la categoria rimane Privato.
Se confermato, abilita un profilo di trusted network per i segmenti VLAN interessati o crea una policy exception che non forzi il profilo di rete.
In caso di incompatibilità, valuta versioni/piattaforme che rispettino le API di NLA o la tua architettura Team/VLAN.

Forzare il profilo con Group Policy (opzione enterprise)

In dominio, puoi stabilizzare il comportamento da un punto centrale:

Apri gpedit.msc (o un GPO a livello OU) → Computer Configuration → Windows Settings → Security Settings → Network List Manager Policies.
Imposta la rete specifica o le Unidentified Networks su Private e Users cannot change location.
Valuta una GPO dedicata ai server di backup o ai server con VLAN/Team.

Vantaggi: coerenza e persistenza senza toccare il Registro macchina per macchina.

Mitigare il rischio lato firewall

Se il vendor del backup lo consente, crea regole scoped con profilo Any, ma limitate a remote address dei server di backup, a uno specifico programma e alle porte strettamente necessarie. Esempio generico:

# Esempio: consenti dal server di backup 10.10.10.50
New-NetFirewallRule -DisplayName "Backup agent in - VLAN" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 135,445 `
  -RemoteAddress 10.10.10.50 -Program "C:\Program Files\AppBackup\agent.exe" `
  -Profile Any -Enabled True

Importante: segui la matrice porte del tuo fornitore e limita sempre gli IP remoti.

Approfondimenti su VLAN, Team e NLA

Ordine di inizializzazione: il Team si porta su, poi le interfacce VLAN. Se NLA valuta prima che tutti i binding siano stabili, può assegnare Pubblico e non sempre ricalcola correttamente.
Firme che cambiano: in presenza di ridondanza L3 (HSRP/VRRP/GLBP) o equal-cost multipath, il MAC del gateway può cambiare tra un boot e l’altro, generando nuovi GUID in Signatures/Profiles.
Rinominare le schede: usa alias chiari (Rename-NetAdapter -Name "Ethernet 5" -NewName "VLAN10") per mappare rapidamente profili e ridurre errori operativi.
Dominio: quando il DC è raggiungibile, NLA assegna DomainAuthenticated. Se il problema compare solo a freddo, verifica le dipendenze di rete di Netlogon e la latenza di contatto del DC.

Automazione di recupero al boot (fallback)

Se devi uscire da un’emergenza prima di una correzione strutturale, puoi schedulare un fix automatico all’avvio che forza Privato sulle VLAN con nome coerente (es. alias che iniziano per “VLAN”).

$script = @'
Start-Sleep -Seconds 30
Get-NetConnectionProfile |
  Where-Object { $.InterfaceAlias -match '^VLAN' -and $.NetworkCategory -ne 'Private' } |
  ForEach-Object { Set-NetConnectionProfile -InterfaceAlias $_.InterfaceAlias -NetworkCategory Private }
'@

\$ps1 = 'C:\Windows\Temp\FixVlanProfile.ps1'
\$script | Out-File -FilePath \$ps1 -Encoding ASCII -Force

\$action  = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument "-NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File `"$ps1`""
\$trigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -TaskName 'FixVlanProfileAtBoot' -Action \$action -Trigger \$trigger -RunLevel Highest -User 'SYSTEM'

Nota: è un workaround, non la soluzione definitiva.

Diagnostica avanzata

Monitorare il Registro: con strumenti di auditing o Procmon filtra le scritture su \NetworkList\Profiles per scoprire chi modifica Category.
Verificare le firme: sotto …\NetworkList\Signatures\Managed/Unmanaged osserva la presenza di molte chiavi per la stessa VLAN; più firme = più probabilità di ricreazione profilo.
Eventi sequenza boot: controlla log di team driver/NIC, NlaSvc e DHCP; un ritardo del DHCP può far classificare la rete come non identificata.
Connettività verso DC: se la rete è di dominio, testa la reachability dei DC durante lo startup (DNS SRV, Kerberos) per evitare downgrade a pubblico.

Domande frequenti

È sicuro negare la scrittura a NlaSvc sul singolo profilo?

Sì, se limiti il Deny alla sola sottochiave del profilo interessato e mantieni Administrators/SYSTEM con pieno controllo. Evita blocchi “globali” che potrebbero impedire a Windows di riconoscere nuove reti.

Conviene impostare tutto via GPO e basta?

In molti casi sì: una GPO che forza Private (o definisce policy per reti non identificate) è più pulita e tracciabile. Tuttavia, se la rete cambia firma spesso, potresti comunque vedere nuovi profili; abbina la GPO a una stabilizzazione della topologia (gateway/VRRP) o a un hardening puntuale del profilo.

Perché il problema si presenta solo su alcune VLAN?

Probabilmente quelle VLAN sono soggette a cambiamento della firma (gateway ridondati, routing asimmetrico, DHCP diverso) o sono toccate da una policy di sicurezza più restrittiva.

Posso risolvere impostando “Privato” via PowerShell e basta?

È efficace per la sessione corrente, ma se la causa persiste (agent, nuova firma, timing all’avvio) al prossimo reboot tornerà Pubblico. Serve persistenza (ACL/GPO) o rimozione della causa.

Meglio “Profile Any” nel firewall?

È un’ottima cintura di sicurezza se usata con scope stretto (IP remoti, programma, porte). Non sostituisce la correzione della causa, ma evita interruzioni di backup.

Note e precauzioni

Backup del registro: prima di modificare chiavi, esportale o crea un punto di ripristino.
Least privilege: nega la scrittura solo alla sottochiave Profiles\[GUID], non all’intero ramo NetworkList, per evitare effetti collaterali.
NLA e servizi dipendenti: bloccare la scrittura può interferire con il riconoscimento di nuove reti; testa in ambiente di staging.
Alternative PowerShell: Set-NetConnectionProfile -InterfaceAlias "VLAN10" -NetworkCategory Private funziona ma non è persistente se l’origine del problema non è rimossa.

Checklist operativa

Raccogli profili correnti con Get-NetConnectionProfile.
Imposta Category = 1 (Private) nei GUID interessati.
Applica hardening mirato: nega a NT SERVICE\NlaSvc la scrittura su quelle sottochiavi.
Conferma che nessun AV/EDR forzi Public o crea eccezioni adeguate.
Valuta GPO per reti non identificate / profili stabili in dominio.
Aggiungi regole firewall con Profile Any ma con scope stretto verso i server di backup.
Monitora i log NLA e stabilizza la topologia rete (gateway ridondati, LAG/LACP).

Riepilogo rapido

Modifica la chiave Category → rendila di sola lettura (hardening mirato sul GUID) → verifica ed eventualmente rimuovi o configura il software di sicurezza che forza il profilo pubblico. In dominio, considera una Group Policy; come safety net, regole firewall valide per tutti i profili ma con scope rigoroso.

Appendice – Snippet utili

# Elenco rapido VLAN & profili
Get-NetAdapter | Where-Object {$_.Name -match '^VLAN'} |
  ForEach-Object {
    $p = Get-NetConnectionProfile -InterfaceIndex $_.ifIndex
    [PSCustomObject]@{ VLAN = $_.Name; Category = $p.NetworkCategory; ProfileName = $p.Name }
  } | Format-Table -AutoSize

Trovare il GUID di un profilo a partire dal nome

\$target = 'Rete'   # Sostituisci con il ProfileName visto in Get-NetConnectionProfile
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles' |
Where-Object { (Get-ItemProperty $\_.PSPath).ProfileName -eq \$target } |
Select-Object -ExpandProperty PSChildName

Impostare Private su tutte le interfacce che contengono "VLAN"

Get-NetConnectionProfile | Where-Object {$\_.InterfaceAlias -like 'VLAN'} |
Set-NetConnectionProfile -NetworkCategory Private

Con questo set di azioni ottieni una soluzione stabile e documentata al rimbalzo “Pubblico”↔“Privato” delle VLAN su Windows Server 2022, eliminando interruzioni ai job di backup e allineando la postura di sicurezza al principio del minimo privilegio.