• Guide, Sistemi Operativi
• 12 Febbraio 2026

Quando lavorate con Hyper-V in ambienti di laboratorio, una delle esigenze più comuni è quella di avere una rete interna completamente isolata, ma allo stesso tempo capace di raggiungere l’esterno. Con Windows Server 2016 e Windows 10 è stato introdotto un nuovo comportamento per lo switch interno, che può funzionare come uno switch con NAT e forwarding.

In questa modalità, lo switch continua a comportarsi come un normale internal switch, permettendo la comunicazione tra le VM e l’host. La differenza è che le macchine virtuali possono accedere anche alle reti esterne utilizzando il NAT del sistema. Inoltre, è possibile configurare delle regole di port forwarding sull’indirizzo dell’host, in modo da pubblicare servizi specifici verso una VM collegata allo switch interno.

Si tratta di una soluzione estremamente pratica nei laboratori, dove serve una rete semplice da ricreare e indipendente dall’infrastruttura fisica. È lo stesso approccio che utilizziamo quando lavoriamo con la nested virtualization, dove il controllo del NAT e delle regole di forwarding diventa fondamentale per evitare conflitti di indirizzamento e garantire la connettività delle macchine virtuali interne.

Prerequisiti

Prima di procedere con la creazione dello switch con NAT, è necessario verificare alcuni prerequisiti lato host. La funzionalità di NAT per gli internal switch è disponibile, come ho già scritto prima, a partire da Windows Server 2016 e Windows 10, quindi è fondamentale che il sistema operativo supporti questo tipo di configurazione.

Sul sistema deve essere installato il ruolo Hyper-V, perché lo switch verrà creato all’interno dell’hypervisor. È inoltre necessario disporre dei privilegi amministrativi, in quanto i comandi PowerShell utilizzati per la configurazione modificano le impostazioni di rete dell’host.

Dal punto di vista della rete, è consigliabile scegliere una subnet interna che non entri in conflitto con quelle già presenti nell’infrastruttura fisica o in eventuali VPN. Questo evita problemi di instradamento e garantisce il corretto funzionamento del NAT.

Se prevedete di utilizzare questa configurazione in scenari di laboratorio o di nested virtualization, verificate anche che la virtualizzazione annidata sia supportata dall’hardware e abilitata sull’host, in modo da evitare limitazioni quando andrete a creare ulteriori livelli di macchine virtuali.

Creazione del NAT Switch

Per creare uno switch interno con funzionalità di NAT, iniziamo dal lato Hyper-V creando un nuovo virtual switch di tipo Internal. Questo tipo di switch permette la comunicazione tra host e macchine virtuali, senza esporle direttamente alla rete fisica.

La creazione dello switch può essere anche eseguita da PowerShell con il seguente comando:

Una volta creato lo switch, sul sistema host verrà generata automaticamente una nuova interfaccia di rete virtuale. A questa interfaccia assegniamo un indirizzo IP che fungerà da gateway per le macchine virtuali collegate allo switch:

NOTA: Potete scegliere qualsiasi indirizzo IP

Figura 1: Creazione dello switch interno in Hyper-V e assegnazione manuale dell’indirizzo IP all’interfaccia vEthernet (NATSwitch) che fungerà da gateway per la rete NAT

A questo punto possiamo attivare la funzionalità di NAT vera e propria, specificando la rete interna che dovrà essere tradotta verso l’esterno:

Con questi passaggi lo switch NAT è operativo: le VM collegate alla rete interna potranno comunicare tra loro, con l’host e raggiungere le reti esterne attraverso la traduzione degli indirizzi.

Figura 2: Creazione della rete NAT con il comando New-NetNat, specificando il prefisso IP interno che verrà tradotto verso la rete esterna

A questo punto possiamo collegare una macchina virtuale allo switch NAT appena creato e configurare manualmente i parametri di rete. Alla scheda di rete della VM assegniamo un indirizzo IP appartenente alla stessa subnet configurata sullo switch, impostando come gateway l’indirizzo dell’interfaccia vEthernet dell’host, cioè 192.168.1.1. Ovviamente se disponete di un server DHCP, collegatelo allo switch NAT e configuratelo opportunamente con i parametri della rete.

Una volta completata la configurazione, è possibile verificare la connettività verso l’esterno eseguendo un semplice ping verso un indirizzo pubblico, ad esempio 8.8.8.8. Se la risposta arriva correttamente, significa che il NAT sta funzionando e che la VM è in grado di uscire sulla rete esterna attraverso l’host.

Figura 3: Configurazione dell’indirizzo IP sulla scheda di rete della VM collegata allo switch NAT e verifica della connettività Internet tramite ping verso un host esterno

Configurazione del port forwarding verso la macchina virtuale

Se avete la necessità di pubblicare un servizio ospitato su una macchina virtuale, potete creare una regola di port forwarding sul NAT dell’host. In questo modo il traffico diretto a una specifica porta dell’host viene inoltrato automaticamente verso la VM collegata allo switch interno.

Nell’esempio seguente, il traffico diretto alla porta 80 dell’host viene inoltrato verso la stessa porta della VM con indirizzo 192.168.1.2:

Con questa configurazione, qualsiasi connessione HTTP diretta all’host verrà inoltrata alla macchina virtuale, permettendovi di pubblicare facilmente servizi web all’interno dei vostri laboratori o negli scenari di nested virtualization.

Verifica di funzionamento

Per verificare il funzionamento della regola di forwarding, sulla VM di test con indirizzo 192.168.1.2 è stato installato un semplice web server. A questo punto è sufficiente aprire un browser sull’host Hyper-V e collegarsi a localhost per controllare che la pubblicazione del servizio funzioni correttamente.

Se la pagina viene visualizzata senza problemi, significa che la regola di NAT sta inoltrando correttamente il traffico dalla porta 80 dell’host verso la VM interna, confermando il corretto funzionamento dello switch con NAT e forwarding.

Figura 4: Creazione della regola di port forwarding sulla porta 80 e verifica dell’accesso al web server installato sulla VM con indirizzo 192.168.1.2 direttamente dall’host Hyper-V

Anche se lo switch è di tipo Internal, è comunque possibile raggiungere un servizio esposto da una macchina virtuale partendo da un altro computer della rete fisica. In questo caso, però, non ci si collega direttamente all’indirizzo della VM, ma all’indirizzo IP dell’host Hyper-V.

Quando un client della rete si collega, ad esempio, a 172.16.0.4, la richiesta arriva prima all’host. A questo punto entra in gioco la regola di port forwarding configurata con NetNatStaticMapping: l’host intercetta il traffico sulla porta 80 e lo inoltra verso la VM interna con indirizzo 192.168.1.2.

Dal punto di vista del client esterno, la connessione sembra terminare sull’host, ma in realtà il traffico viene tradotto e instradato verso la rete interna dello switch, dove risponde il web server della macchina virtuale. In questo modo è possibile pubblicare servizi delle VM anche quando sono collegate a uno switch interno, mantenendo l’isolamento della rete virtuale ma consentendo accessi mirati dall’esterno.

Figura 5: Accesso al web server della VM da un altro computer della rete, collegandosi all’indirizzo IP dell’host, con il traffico inoltrato tramite la regola di NAT forwarding

Verificare e rimuovere le regole di NAT

Una volta create le regole di port forwarding, può essere utile visualizzare la configurazione attiva o rimuoverla quando non è più necessaria. Tutte queste operazioni possono essere eseguite tramite PowerShell.

Per visualizzare le regole di forwarding configurate sul NAT, potete utilizzare il comando:

Questo comando mostra tutte le mappature statiche presenti, con le relative porte, gli indirizzi interni e il nome del NAT a cui appartengono.

Se invece volete rimuovere una specifica regola di forwarding, potete utilizzare il comando:

In questo modo viene eliminata la regola che inoltra il traffico dalla porta 80 dell’host verso la VM.

Se avete la necessità di rimuovere completamente la configurazione del NAT, potete usare il comando:

Dopo la rimozione del NAT, le macchine virtuali collegate allo switch interno non avranno più accesso alla rete esterna finché non verrà creata una nuova configurazione di traduzione.

Figura 6: Visualizzazione della static mapping, rimozione della regola tramite StaticMappingID e successiva eliminazione completa della configurazione NAT

Figura 7: Dopo la rimozione della configurazione NAT, la macchina virtuale perde la connettività verso l’esterno e non riesce più a risolvere i nomi DNS o raggiungere siti Internet

Che cos’è il Default Switch in Hyper-V

A partire da Windows 10 versione 1709, Hyper-V introduce automaticamente un nuovo switch virtuale chiamato Default Switch. Si tratta di uno switch già pronto all’uso, pensato per fornire connettività immediata alle macchine virtuali senza alcuna configurazione manuale.

Dal punto di vista tecnico, il Default Switch è uno switch interno gestito completamente dal sistema operativo, con un NAT integrato e un servizio DHCP automatico. Quando collegate una VM a questo switch, riceve automaticamente un indirizzo IP e può uscire su Internet attraverso l’host, senza che dobbiate creare subnet, gateway o regole di traduzione.

Questa soluzione è comoda per scenari veloci di test o sviluppo, dove serve solo connettività immediata. Tuttavia, trattandosi di uno switch gestito automaticamente, non avete il controllo completo sulla subnet, sugli indirizzi IP o sulle eventuali regole di forwarding.

Un aspetto particolarmente interessante del Default Switch è che utilizza in modo automatico qualsiasi connessione di rete attiva sull’host in quel momento. Non è necessario specificare se la VM deve uscire tramite Ethernet, Wi-Fi o altre interfacce: lo switch si adatta dinamicamente alla connettività disponibile sul sistema.

Questo comportamento lo rende molto pratico sui sistemi Windows Client, soprattutto sui portatili o sulle macchine che cambiano spesso rete. Se passate dalla connessione wireless a quella cablata, le macchine virtuali continuano a funzionare senza dover modificare la configurazione dello switch o delle schede di rete delle VM.

Aggiungere il Default Switch in Windows Server 2025

Il Default Switch è disponibile automaticamente nelle versioni client di Windows, come Windows 10 e Windows 11, ma non è presente di default nelle edizioni Windows Server. In Windows Server 2025, però, è possibile aggiungerlo manualmente utilizzando le funzionalità di HNS (Host Networking Service).

Questa soluzione è particolarmente utile nei laboratori, soprattutto quando la rete non dispone di un DHCP e non volete assegnare manualmente gli indirizzi IP alle macchine virtuali.

Di seguito i comandi necessari, con una breve spiegazione:

Dopo l’esecuzione dei comandi, anche su Windows Server 2025 sarà disponibile uno switch virtuale con NAT e DHCP automatico, analogo al Default Switch presente nelle versioni client di Windows.

Figura 8: Creazione del Default Switch in Windows Server 2025

Test di funzionamento

Per verificare il funzionamento del Default Switch, è sufficiente collegare la macchina virtuale allo switch e lasciare la scheda di rete configurata in DHCP. In questo modo sarà il servizio interno dello switch ad assegnare automaticamente tutti i parametri di rete.

Come si può vedere, la VM riceve un indirizzo IP, la subnet mask, il gateway e i DNS senza alcuna configurazione manuale. Tutto il traffico viene poi tradotto tramite il NAT del Default Switch e instradato verso la rete esterna utilizzando la connessione attiva sull’host.

Figura 9: La VM collegata al Default Switch riceve automaticamente un indirizzo IP tramite DHCP e la configurazione di gateway e DNS senza alcun intervento manuale

Come si può notare dalla figura sotto, ogni virtual switch creato in Hyper-V genera automaticamente una corrispondente interfaccia vEthernet nel sistema operativo host. In questo caso sono presenti sia il NATSwitch creato manualmente, sia il Default Switch, ognuno con la propria scheda di rete virtuale.

Figura 10: Elenco degli switch virtuali configurati sull’host Hyper-V e delle relative interfacce vEthernet create automaticamente nel sistema operativo

Port forwarding e HNS (Host Networking Service)

Il Default Switch non è gestito con i normali cmdlet di Hyper-V, perché dietro le quinte utilizza HNS, acronimo di Host Networking Service. Si tratta del servizio di Windows che gestisce le reti virtuali, il NAT e le policy di rete utilizzate soprattutto dagli scenari con container e dalle funzionalità automatiche del sistema, come appunto il Default Switch.

In teoria, con HNS è possibile configurare anche regole di port forwarding, applicando delle policy NAT direttamente alla rete virtuale. Tuttavia, si tratta di un livello di configurazione più basso, pensato principalmente per i container e per scenari di automazione, non per la gestione tradizionale delle macchine virtuali in Hyper-V.

Inoltre, le reti gestite da HNS, come il Default Switch, possono cambiare configurazione tra un riavvio e l’altro, rendendo più difficile creare ambienti di laboratorio stabili e replicabili. Per questo motivo, quando vi serve il controllo delle porte, degli indirizzi e delle regole di forwarding, è preferibile utilizzare uno switch interno con NAT configurato manualmente.

Conclusioni

Con uno switch interno configurato con NAT e forwarding potete creare rapidamente una rete isolata per le vostre macchine virtuali, senza dipendere dall’infrastruttura fisica e mantenendo il pieno controllo degli indirizzi e delle regole di accesso. È una soluzione semplice, ma estremamente efficace quando lavorate in ambienti di laboratorio o con scenari di nested virtualization.

Il Default Switch rimane invece una scelta comoda quando vi serve connettività immediata e senza configurazioni, soprattutto sui sistemi client. Quando però vi serve una rete stabile, prevedibile e replicabile, uno switch NAT creato manualmente resta la soluzione più flessibile e controllabile.

Spero che queste indicazioni vi siano utili per i vostri laboratori e per costruire ambienti di test più semplici da gestire e replicare.