Windows Server 2019 DC non risponde a ping e RDP dall’host Hyper‑V: cause, diagnosi e fix

Dopo la promozione a Domain Controller di un Windows Server 2019, il PC host Windows 10 non riesce più a pingare né ad aprire l’RDP sulla VM, mentre la VM continua a navigare ed è raggiungibile dagli altri nodi. In questa guida trovi cause probabili, diagnosi e soluzioni operative.

Indice

Scenario e sintomi

Hai una VM Windows Server 2019 promossa a controller di dominio (DC1.local) su Hyper‑V. Dopo un riavvio, l’host Windows 10 Pro non riesce più a:

pingare la VM (ICMP time out);
aprire la connessione RDP (porta 3389).

Nel frattempo:

la VM raggiunge gateway e Internet senza problemi;
altre macchine della rete (es. una VM RHEL su Xen o altri client) raggiungono la VM.

Questa combinazione di sintomi suggerisce che lo stack di rete interno alla VM è sano e che il blocco si trovi tra l’host e la VM: tipicamente nel virtual switch Hyper‑V e/o nel profilo Domain del Windows Firewall della VM.

Perché il problema emerge dopo la promozione a Domain Controller

La promozione a DC modifica in modo sostanziale il comportamento del server sul piano identità, ruoli e policy:

la scheda di rete del server passa al Domain Profile del Windows Defender Firewall, che ha set di regole diversi rispetto a Private/Public;
l’abilitazione di Remote Desktop sui Domain Controller è più restrittiva (NLA, gruppi autorizzati, criteri del Default Domain Controllers Policy);
il client che non è membro del dominio può essere “fuori perimetro” rispetto alle eccezioni previste dal profilo Domain.

Se a ciò sommi un vSwitch esterno configurato senza condivisione con l’OS di gestione (Allow management OS to share this network adapter), l’host può restare isolato dal traffico che transita tra NIC fisica e vNIC della VM.

Cause principali (riassunto)

Macro‑area	Dettaglio	Indicazione pratica
Firewall	La VM usa ora il Domain Profile. Finché l’host non appartiene allo stesso dominio, ICMP e RDP risultano bloccati a livello di regole del profilo Domain (o non abilitati).	Quando il domain firewall del server è attivo, l’host non si connette; unendo la workstation al dominio o ampliando le eccezioni, la connettività torna.
Virtual Switch Hyper‑V	Lo switch esterno può mostrare “No network access” all’host. Se l’opzione Allow management OS to share this network adapter non è selezionata, l’host non condivide la NIC con la VM e resta tagliato fuori.	Abilitare la condivisione, applicare, e riavviare se richiesto. In alternativa, ricreare correttamente lo switch.

Soluzioni rapide e già verificate

Verificare e correggere il Virtual Switch esterno

Apri Hyper‑V Manager ▸ Virtual Switch Manager.
Seleziona lo switch esterno usato dalla VM.
Assicurati che sia spuntato Allow management OS to share this network adapter.
Conferma con Apply e riavvia host/VM se richiesto.

Cosa aspettarti: l’host recupera la visibilità Layer‑2/3 verso la vNIC della VM. Ping e RDP cominceranno almeno a “vedersi” a livello ARP/TCP, lasciando al firewall il giudizio finale.Alternativa PowerShell (più veloce e ripetibile)

# Elenco switch
Get-VMSwitch | Format-Table Name,SwitchType,NetAdapterInterfaceDescription,AllowManagementOS

Impostare la condivisione con l'OS di gestione

Set-VMSwitch -Name "vSwitch-Esterno" -AllowManagementOS $true

(Opzionale) Ricreare uno switch esterno corretto

Remove-VMSwitch -Name "vSwitch-Esterno-Errato" -Force
New-VMSwitch -Name "vSwitch-Esterno" -NetAdapterName "Ethernet" -AllowManagementOS $true -EnableIov $false

Aggiustare il Windows Firewall sulla VM

Hai due strade, entrambe valide:

Opzione A – Unire l’host al dominio DC1.local

Imposta sul client Windows 10 come DNS primario l’IP del DC (DC1).
Apri Impostazioni ▸ Sistema ▸ Informazioni ▸ Rinomina questo PC (avanzate), clic su Dominio e inserisci DC1.local.
Riavvia. A questo punto il traffico dall’host ricadrà nel Domain Profile atteso dalla VM.

Vantaggio: allinei sicurezza e gestione (GPO, NLA) e riduci eccezioni ad hoc.

Opzione B – Lasciare l’host in workgroup e aprire solo ciò che serve

Apri Windows Defender Firewall with Advanced Security sulla VM.
Nella sezione Inbound Rules, abilita:
- File and Printer Sharing (Echo Request – ICMPv4‑In) (profilo: Domain);
- Remote Desktop (TCP‑In) e Remote Desktop (UDP‑In) (profilo: Domain).
In alternativa, crea regole mirate che consentano solo l’IP dell’host.

PowerShell: abilitazione mirata e sicura

# Abilita RDP nel profilo Domain
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Abilita ICMP Echo Request (ping) nel profilo Domain

Get-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" |
Where-Object {$_.Profile -like "Domain"} |
Enable-NetFirewallRule

Consenti ping solo dall'IP dell'host (sostituisci 192.168.1.50)

New-NetFirewallRule -DisplayName "ICMPv4-In da Host Win10" -Direction Inbound -Protocol ICMPv4 `
-IcmpType 8 -RemoteAddress 192.168.1.50 -Profile Domain -Action Allow

Consenti RDP (TCP 3389) solo dall'IP dell'host

New-NetFirewallRule -DisplayName "RDP-In da Host Win10" -Direction Inbound -Protocol TCP `
-LocalPort 3389 -RemoteAddress 192.168.1.50 -Profile Domain -Action Allow

Verifiche rapide di rete

Dalla VM: Get-NetIPAddress per vedere IP/maschera/gateway; ping <IP_host> per misurare la risposta (attendibile solo se l’host permette ICMP in ingresso).
Dall’host: arp -a. L’assenza della voce per l’IP della VM indica che non stai risolvendo il MAC (blocco a livello 2/3) o non c’è traffico di ritorno.

Procedura diagnostica completa

Controllo della stessa subnet e del percorso Layer‑3

Confronta subnet e gateway: # VM ipconfig /all Host ipconfig /all Devono appartenere allo stesso segmento (es. 192.168.1.0/24) se il vSwitch è esterno “bridgiato”. Se sono in segmenti diversi, verifica NAT/route.
Verifica route attive sull’host: route print Se manca una rotta verso la subnet della VM o confligge una metrica, l’host potrebbe instradare in modo errato.
Prova l’RDP via IP, evitando il DNS: mstsc /v:192.168.1.10 /admin Se con l’IP funziona ma con FQDN no, la questione è di DNS (spesso il client punta a un DNS esterno e non risolve dc1.local).

Connettività porta 3389 e test attivi

Sull’host: Test-NetConnection 192.168.1.10 -Port 3389 -InformationLevel Detailed Expected: TcpTestSucceeded = True. Se False, cattura i pacchetti (vedi sotto).
Sulla VM, verifica lo stato delle regole RDP e il servizio: Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select DisplayName,Enabled,Profile Get-Service TermService Se TermService non è in Running, abilita RDP: SystemPropertiesRemote.exe (spunta “Consenti connessioni Desktop remoto” con NLA).

Packet capture mirata (quando i test non bastano)

Installa Wireshark sull’host e filtra per ICMP/RDP:

# ICMP
icmp and host 192.168.1.10
RDP (TCP 3389)
tcp.port == 3389 and host 192.168.1.10

Vedi SYN → nessun SYN‑ACK? Probabile blocco firewall sulla VM o blackhole intermedio.
Vedi ICMP Echo Request ma non Echo Reply? Regola ICMP non abilitata sul profilo Domain della VM.

Log del firewall sul server

Abilita logging: Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True -LogFileName "C:\Windows\system32\LogFiles\Firewall\pfirewall.log" -LogMaxSizeKilobytes 16384
Riesegui ping/RDP e apri pfirewall.log per confermare ALLOW/DROP sul traffico dall’IP dell’host.

Verifiche Hyper‑V aggiuntive

Controlla i binding della NIC fisica: Get-NetAdapterBinding -Name "Ethernet" | Where-Object {$_.DisplayName -match "Hyper-V"} Deve essere Enabled = True per “Extensible Virtual Switch”.
Esamina lo stato del vNIC dell’host (vEthernet (vSwitch-Esterno)): Get-NetIPConfiguration -InterfaceAlias "vEthernet (vSwitch-Esterno)"
Evita di usare il Default Switch per scenari di dominio (è NAT, cambia rete di continuo). Preferisci uno switch esterno mappato alla tua LAN.

Abilitare in sicurezza RDP e ping sul Domain Controller

Se non vuoi unire l’host al dominio, mantieni il perimetro chiuso ma consenti solo ciò che serve:

Abilita RDP con NLA e consenti solo utenti/gruppi ammessi (idealmente un gruppo amministrativo dedicato).
Apri ICMPv4 esclusivamente dall’IP (o subnet) di gestione dell’host, non da “Any”.
Valuta di limitare RDP al solo TCP 3389; l’UDP 3389 è utile per prestazioni ma non indispensabile.

Ricorda che sui Domain Controller l’impostazione “Consenti accesso Desktop remoto a…” è governata anche da GPO (Allow log on through Remote Desktop Services). Se autorizzi un utente ma la policy lo nega, il login fallirà pur avendo la porta aperta.

Diagnosi per esclusione: albero decisionale

Ping fallisce & RDP fallisce
├── Host e VM su subnet diverse?
│   ├── Sì → Correggi routing/NAT del vSwitch e DNS del client
│   └── No →
│       ├── ARP non risolve la VM?
│       │   ├── Sì → vSwitch/AllowManagementOS errato → correggi vSwitch
│       │   └── No →
│           ├── TCP SYN → nessun SYN-ACK su 3389
│           │   ├── Sì → Firewall Domain della VM blocca RDP → abilita regole
│           │   └── No → Ispeziona device intermedio / AV / IPS
└── RDP apre ma credenziali respinte → controlla NLA e GPO su DC

Tabelle operative di riferimento

Profili firewall e implicazioni

Profilo	Comportamento tipico su Server	Implicazione per host in workgroup
Domain	Regole pensate per ambienti gestiti; RDP spesso disabilitato finché non lo abiliti esplicitamente; ICMP spesso non aperto di default.	Se non unito al dominio, l’host resta “esterno” alle eccezioni; serve aprire regole mirate.
Private	Più permissivo (file sharing, discovery) su workstation; sui server dipende dal ruolo.	Non rilevante sul DC: la NIC resta in Domain.
Public	Più restrittivo; non usato in LAN di dominio.	—

Tipi di Hyper‑V Virtual Switch

Tipo	Uso	Pro/Contro
External	Bridge verso la NIC fisica della LAN	Pro: Visibilità completa in rete. Contro: Se togli “Allow management OS…”, l’host perde visibilità.
Internal	Solo host <→ VM	Pro: Lab isolati. Contro: Nessun accesso diretto alla LAN/Gateway.
Private	Solo VM <→ VM	Pro: Segmentazione forte. Contro: Host escluso per definizione.

Checklist consigliata

IP & subnet della vNIC della VM allineati a quelli dell’host (stessa VLAN/subnet).
Virtual Switch esterno con Allow management OS… attivo; in caso di dubbi, ricrealo.
Firewall allineato: unisci l’host al dominio oppure apri regole mirate (ICMPv4‑In, RDP TCP/UDP‑In nel profilo Domain).
Riavvio di host e VM dopo modifiche strutturali (switch, binding, GPO) per eliminare cache ARP e sessioni.
Packet capture con Wireshark sull’host se persiste: verifica arrivo/ritorno di ICMP/RDP sull’interfaccia fisica.

Strumenti e comandi utili (pronti all’uso)

Host Windows 10

# Stato rete e cache
ipconfig /all
arp -a
nbtstat -R

Test porta RDP

Test-NetConnection  -Port 3389 -InformationLevel Detailed

Pulizia DNS e reset stack (se sospetti naming)

ipconfig /flushdns
netsh int ip reset

VM Windows Server 2019 (DC)

# IP, gateway, DNS
Get-NetIPConfiguration

Stato regole RDP/ICMP nel profilo Domain

Get-NetFirewallRule -DisplayGroup "Remote Desktop" | ft DisplayName,Enabled,Profile
Get-NetFirewallRule | ? DisplayName -like "Echo Request - ICMPv4-In" | ft DisplayName,Enabled,Profile

Abilita log firewall Domain

Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True

Problemi correlati e come riconoscerli

Risoluzione DNS sbagliata dal client: l’RDP via IP funziona, ma via nome no. Soluzione: puntare il DNS del client al DC per la zona .local oppure aggiungere record corretti.
NLA e autorizzazioni RDP: la porta 3389 è aperta, ma ottieni errore “impossibile connettersi” o credenziali respinte. Verifica che il gruppo Administrators (o un gruppo dedicato) sia autorizzato in Allow log on through Remote Desktop Services.
Software di sicurezza sull’host (AV/IPS) che filtra ICMP o 3389 in uscita. Disabilitazione temporanea solo per test, poi crea regole di allow.
vSwitch su NIC sbagliata: se l’host ha più NIC, accertati che lo switch esterno “bridgi” quella collegata alla LAN corretta.

Best practice per evitare che si ripeta

Separare gestione e workload: dedicare una subnet/VLAN di management da cui amministrare i server (RDP, WinRM), con regole allow esplicite e logging.
Automatizzare con PowerShell: mantieni script per creare/validare il vSwitch e per abilitare le regole firewall minime necessarie.
Documentare l’IP del DC, DNS dei client, profili firewall e regole aperte: zero ambiguità quando si riavvia o si ripromuove.
Monitorare i log del firewall: pfirewall.log a rotazione e alerts su DROP ricorrenti.

FAQ

Perché altre macchine raggiungono la VM ma il mio host no?
Perché il problema non è nello stack della VM. O l’host è isolato dallo switch Hyper‑V (manca la condivisione verso l’OS di gestione), oppure il firewall Domain del server consente solo da certe origini (es. membri del dominio) e il tuo host non rientra nelle eccezioni.

Aprire il firewall “a tutto” risolve?
Può “far funzionare”, ma è sconsigliato: apri soltanto ICMP e RDP e, meglio ancora, limita RemoteAddress a IP/subnet di gestione.

Devo per forza unire il PC al dominio?
No. È la strada più “pulita” in ambienti aziendali, ma puoi anche restare in workgroup e creare regole firewall mirate.

Conclusione

La combinazione “vSwitch esterno non condiviso” + “profilo Domain più restrittivo sul DC” spiega perché, dopo la promozione e il riavvio, l’host Windows 10 non riesca più a pingare o entrare via RDP nella VM mentre gli altri nodi sì. Concentrando la diagnosi su questi due elementi e applicando le soluzioni operative descritte (correzione vSwitch, unione al dominio o regole firewall mirate, verifica porta 3389 e log), ripristini in modo sicuro e tracciabile la connettività host ↔ VM.

Appendice: playbook “copia e incolla”

Usalo quando devi risolvere in fretta, ricordando di adattare nomi e IP.

# 1) Hyper-V: assicurare la condivisione con l'OS di gestione
Set-VMSwitch -Name "vSwitch-Esterno" -AllowManagementOS $true

2) Server (DC): abilitare RDP e ICMP nel profilo Domain (mirati all'host)

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

New-NetFirewallRule -DisplayName "RDP-In da Host Win10" -Direction Inbound -Protocol TCP `
-LocalPort 3389 -RemoteAddress 192.168.1.50 -Profile Domain -Action Allow

New-NetFirewallRule -DisplayName "ICMPv4-In da Host Win10" -Direction Inbound -Protocol ICMPv4 `
-IcmpType 8 -RemoteAddress 192.168.1.50 -Profile Domain -Action Allow

3) Host: verifiche

arp -a
Test-NetConnection 192.168.1.10 -Port 3389 -InformationLevel Detailed

4) Logging firewall del DC

Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True

Nota finale

Il fatto che la VM sia raggiungibile da altre macchine è la prova che la rete interna al server funziona; il punto di rottura è fra vSwitch e firewall di dominio. Intervenendo con metodo su questi due livelli ripristinerai in modo stabile ping e RDP dall’host.