• Cloud, Guide, Sistemi Operativi
• 16 Gennaio 2026

La migrazione di un server DHCP da un’infrastruttura on-premises a Microsoft Azure rappresenta un passaggio strategico nel percorso di modernizzazione dei servizi di rete aziendali. In contesti tradizionali, il servizio DHCP è spesso strettamente legato all’infrastruttura locale e alla disponibilità fisica dei data center. Tuttavia, l’evoluzione verso modelli cloud e ibridi rende necessario ripensare il posizionamento di questo servizio, garantendo continuità operativa, scalabilità e maggiore resilienza.

Spostare il DHCP in Azure non significa semplicemente “ricreare” un server nel cloud, ma integrare il servizio di assegnazione degli indirizzi IP in un’architettura più flessibile, allineata alle best practice moderne di networking e gestione centralizzata. Questa guida ha l’obiettivo di illustrare il contesto della migrazione, le sue motivazioni principali e di fornire le basi concettuali per affrontare il processo in modo consapevole e strutturato.

Motivazioni per la migrazione da on-premises a Azure

Le motivazioni che possono portare alla migrazione di un server DHCP da on-premises ad Azure sono diverse e spesso rientrano in un percorso di modernizzazione dell’infrastruttura IT. Spostare il servizio DHCP nel cloud consente di ridurre la dipendenza dall’hardware fisico e di centralizzare la gestione della rete, semplificando l’architettura complessiva.

Un aspetto particolarmente rilevante è la maggiore resilienza e disponibilità del servizio. Un server DHCP locale può facilmente diventare un single point of failure, mentre in Azure è possibile progettare soluzioni più affidabili, supportate da alta disponibilità, backup e disaster recovery.

La migrazione offre inoltre scalabilità e flessibilità operativa. In presenza di un numero crescente di dispositivi, sedi remote o workload dinamici, Azure permette di adattare rapidamente le risorse alle esigenze aziendali, senza interventi hardware.

In scenari ibridi e multi-sede, un DHCP ospitato in Azure può fungere da punto di controllo centralizzato per reti on-premises e cloud, semplificando la gestione degli indirizzi IP e riducendo la complessità amministrativa.

C’è anche da considerare che Azure mette a disposizione strumenti avanzati di sicurezza, monitoraggio e controllo degli accessi, che facilitano il rispetto dei requisiti di compliance e migliorano la governance complessiva del servizio DHCP, contribuendo anche a una riduzione dei costi operativi nel medio-lungo periodo.

Architettura e principio di funzionamento

Il servizio DHCP non è più ospitato nella rete on-premises, ma viene eseguito su una macchina virtuale in Microsoft Azure. I client locali continuano a richiedere un indirizzo IP tramite DHCP, ma l’assegnazione viene gestita da un server centralizzato nel cloud.

Poiché i pacchetti DHCP broadcast non possono essere instradati verso Azure, il server DHCP non comunica direttamente con i client. Le richieste vengono invece intercettate da un DHCP Relay Agent presente nella rete on-premises, che le inoltra in unicast al server DHCP in Azure. Le risposte seguono il percorso inverso e vengono recapitate correttamente ai client locali.

Questa architettura consente di mantenere l’allocazione dinamica degli indirizzi IP per i client on-premises, centralizzando al contempo il servizio DHCP in Azure.

Ruolo del DHCP Server in Azure

Il server DHCP in Azure ha il compito di:

• gestire gli scope DHCP e le relative opzioni,
• assegnare dinamicamente indirizzi IP ai client on-premises,
• rispondere alle richieste DHCP che gli vengono inoltrate in modalità unicast.

Questo server non riceve direttamente pacchetti DHCP broadcast dai client, poiché i broadcast non attraversano né i confini di subnet né i tunnel VPN verso una Virtual Network di Azure.

Ruolo del DHCP Relay Agent on-premises

L’agente di inoltro DHCP è configurato su un dispositivo di livello 3 (router, firewall, switch L3 o server Windows con RRAS) all’interno della rete locale. Il suo ruolo è fondamentale e consiste in:

• intercettare le richieste DHCP broadcast (DHCPDISCOVER) generate dai client locali;
• inoltrare tali richieste come pacchetti unicast verso l’indirizzo IP del server DHCP in Azure;
• ricevere le risposte dal server DHCP e recapitarle correttamente ai client nella subnet di origine.

In questo modo, l’allocazione dinamica degli indirizzi IP continua a funzionare per i client on-premises, pur avendo il server DHCP fisicamente collocato nel cloud.

Perché è necessario l’agente di inoltro DHCP

Per impostazione predefinita, i pacchetti DHCP inviati direttamente dai client a un server DHCP in Azure non funzionano per i seguenti motivi:

• il protocollo DHCP utilizza messaggi broadcast (livello 2 / UDP) nella fase iniziale;
• i broadcast non vengono instradati attraverso tunnel Site-to-Site VPN o ExpressRoute;
• le Virtual Network di Azure non supportano la ricezione di broadcast provenienti da reti esterne.

Di conseguenza, senza un DHCP Relay Agent:

• il server DHCP in Azure non riceverebbe mai le richieste dei client on-premises;
• l’assegnazione degli indirizzi IP fallirebbe.

L’agente di inoltro risolve questa limitazione trasformando i broadcast locali in comunicazioni unicast instradabili, compatibili con l’architettura di rete di Azure.

Quindi, riassumendo, il flusso operativo è:

1. Il client on-premises invia una richiesta DHCP in broadcast nella propria subnet.
2. Il DHCP Relay Agent intercetta la richiesta.
3. Il relay inoltra la richiesta in unicast al server DHCP in Azure tramite la connessione Site-to-Site VPN.
4. Il server DHCP in Azure elabora la richiesta e risponde.
5. Il relay riceve la risposta e la inoltra al client locale.
6. Il client ottiene correttamente la configurazione IP.

Figura 1: Architettura e principio di funzionamento

La macchina virtuale Azure che ospiterà il servizio DHCP può esseresia di una VM creata direttamente in Azure, sia una macchina on-premises precedentemente migrata nel cloud.

Nel mio caso ho creato una nuova macchina virtuale in Azure e procedo quindi all’installazione del ruolo DHCP nella Azure VM utilizzando il comando PowerShell Install-WindowsFeature -Name DHCP -IncludeManagementTools. Ovviamente si può fare anche l’installazione grafica da Add Roles and features 🙂

Figura 2: Installazione del ruolo DHCP nella Azure VM

Il ruolo DHCP Server su Windows richiede che il sistema operativo disponga di almeno un’interfaccia di rete configurata con indirizzo IP statico. In ambienti Azure, tuttavia, le schede di rete delle macchine virtuali utilizzano indirizzi IP assegnati e gestiti dalla piattaforma, che dal punto di vista del sistema operativo risultano dinamici.

Per questo motivo, dopo l’installazione del ruolo DHCP, il servizio DHCP non viene avviato se la macchina virtuale dispone esclusivamente dell’interfaccia di rete Azure con indirizzo IP dinamico.

Per aggirare questa limitazione è possibile installare una Microsoft Loopback Interface sulla macchina virtuale e configurarla con un indirizzo IP statico. Tale interfaccia non viene utilizzata per il traffico di rete, ma esclusivamente per soddisfare il requisito del ruolo DHCP.

Una volta configurata l’interfaccia loopback con un indirizzo IP statico, il servizio DHCP può essere avviato correttamente e operare come destinazione per le richieste inoltrate dal DHCP Relay Agent on-premises.

Installazione del Microsoft Loopback Adapter

Per installare il Microsoft Loopback Adapter sulla macchina virtuale Windows in Azure è necessario utilizzare la procedura di aggiunta legacy
hardware tramite Device Manager.

Accedete alla macchina virtuale Azure e aprite Device Manager. Una volta aperto, selezionate il nome del computer visualizzato nella parte superiore dell’elenco dei dispositivi. Dal menu principale, scegliete Action e quindi Add legacy hardware per avviare l’Add Hardware Wizard.

Figura 3: Aggiunta del legacy hardware alla Azure VM

Nella schermata iniziale della procedura guidata, selezionate Next, quindi scegliete l’opzione Install the hardware that I manually select from a list (Advanced) e proseguite nuovamente con Next.

Figura 4: Aggiunta manuale dell’hardware

Nella lista dei tipi di hardware comuni, selezionare Network adapters e continuate.

Figura 5: Scelta del network adapter

A questo punto, nella lista dei produttori, selezionate Microsoft; nella lista degli adattatori di rete disponibili, scegliete Microsoft KM-TEST Loopback Adapter e proseguite con Next. Confermate l’avvio dell’installazione dei driver selezionando nuovamente Next e completate la procedura facendo clic su Finish.

Figura 6: Scelta del Microsoft KM-TEST Loopback Adapter

Al termine dell’installazione, tornate a Device Manager, espandete la sezione Network adapters e verificate che Microsoft Loopback Adapter sia correttamente presente nell’elenco.

Figura 7: Installazione del Microsoft KM-TEST Loopback Adapter completata

Configurazione dell’indirizzo IP statico sul Microsoft Loopback Adapter

Una volta installato il Microsoft Loopback Adapter, è necessario configurare su di esso un indirizzo IP statico. Questo passaggio è fondamentale per consentire l’avvio e il corretto funzionamento del servizio DHCP sulla macchina virtuale in Azure.

Accedete alle Network Connections del sistema operativo e individuate l’interfaccia di rete corrispondente al Microsoft Loopback Adapter. Aprite le proprietà dell’adattatore, selezionate Internet Protocol Version 4 (TCP/IPv4) e accedete alle relative impostazioni.

Configurate manualmente un indirizzo IP statico dedicato, assicurandovi che l’indirizzo appartenga allo spazio di indirizzamento della Virtual Network. Ad esempio, io ho utilizzato l’indirizzo 172.16.1.100.

Non è necessario configurare un gateway predefinito sull’interfaccia loopback. Anche i server DNS possono essere omessi o impostati in modo coerente con le policy aziendali, poiché questa interfaccia viene utilizzata esclusivamente come requisito tecnico per il ruolo DHCP.

Figura 8: Assegnazione dell’indirizzo statico al Microsoft Loopback Adaprter

Dopo aver applicato la configurazione, verificate che l’indirizzo IP sia correttamente assegnato all’interfaccia loopback. A questo punto potete avviare il servizio DHCP Server, che risulterà operativo grazie alla presenza di un’interfaccia con indirizzo IP statico, pur continuando a gestire le richieste inoltrate dal DHCP Relay Agent tramite la connettività VPN verso Azure.

Aggiunta dell’indirizzo IP di loopback come configurazione IP secondaria in Azure

Dopo aver configurato l’indirizzo IP statico sul Microsoft Loopback Adapter all’interno del sistema operativo, è necessario aggiungere lo stesso indirizzo IP anche come configurazione IP secondaria sull’interfaccia di rete della macchina virtuale in Microsoft Azure.

Questo passaggio è richiesto affinché la piattaforma Azure riconosca l’indirizzo IP utilizzato dal servizio DHCP e consenta il corretto instradamento e la gestione del traffico associato alla macchina virtuale. Un indirizzo IP configurato esclusivamente a livello di sistema operativo, ma non dichiarato nella configurazione della scheda di rete Azure, non è considerato valido dalla piattaforma.

Accedete quindi al Network Interface associato alla macchina virtuale dal portale Azure, aprite la sezione IP configurations e aggiungete una nuova configurazione IP. Impostate come indirizzo IP statico lo stesso valore assegnato all’interfaccia loopback, assicurandovi che l’indirizzo appartenga allo spazio di indirizzamento della Virtual Network.

Una volta salvata la configurazione, l’indirizzo IP risulterà associato alla scheda di rete della macchina virtuale come IP secondario. Questo garantisce coerenza tra la configurazione del sistema operativo e quella della piattaforma Azure e permette al servizio DHCP di operare correttamente come destinazione delle richieste inoltrate dal DHCP Relay Agent on-premises.

Figura 9: Aggiunta dell’indirizzo IP di loopback come configurazione IP secondaria in Azure

Figura 10: Aggiunta dell’indirizzo IP di loopback come configurazione IP secondaria in Azure

Abilitazione del routing tra l’interfaccia loopback e la scheda di rete

Dopo aver configurato l’indirizzo IP sulla Microsoft Loopback Adapter e averlo aggiunto come indirizzo IP secondario alla scheda di rete della macchina virtuale in Microsoft Azure, è necessario abilitare il routing tra l’interfaccia loopback e l’adattatore di rete principale.

Per impostazione predefinita, Windows non inoltra il traffico tra interfacce se il sistema non è configurato come router. Senza questa configurazione, le risposte DHCP generate dal servizio in ascolto sull’indirizzo IP della loopback non verrebbero correttamente instradate verso la rete e quindi verso il DHCP Relay Agent on-premises.

Per abilitare il routing IP, dovete configurare la macchina virtuale affinché consenta l’inoltro dei pacchetti tra le interfacce di rete. Questo può essere ottenuto abilitando il routing IP a livello di sistema operativo (ad esempio tramite le funzionalità di Routing and Remote Access o tramite configurazione del registro di sistema).

Iniziate aprendo un Prompt dei comandi con privilegi amministrativi sulla macchina virtuale. Una volta aperto, eseguite il comando seguente per visualizzare l’elenco delle interfacce di rete e i relativi identificativi: netsh int ipv4 show int

Individuate l’interfaccia di rete collegata alla Azure Virtual Network (in genere denominata Ethernet) e l’interfaccia corrispondente alla Microsoft Loopback Adapter installata in precedenza (nell’esempio Ethernet 3). Prendete nota dei valori Idx associati a entrambe le interfacce, poiché saranno necessari nei passaggi successivi. Nell’esempio riportato:

• l’interfaccia di rete primaria ha indice 6;
• l’interfaccia loopback ha indice 11.

Attenzione: Non confondete la Loopback Pseudo-Interface 1 con la Microsoft Loopback Adapter. La Loopback Pseudo-Interface 1 è un’interfaccia logica di sistema e non viene utilizzata in questo scenario.

Una volta identificati gli indici corretti, abilitate weakhostreceive e weakhostsend sull’interfaccia di rete primaria eseguendo il comando seguente, sostituendo il valore dell’indice se diverso dal vostro ambiente: netsh int ipv4 set int 6 weakhostreceive=enabled weakhostsend=enabled

Successivamente, abilitate le stesse opzioni sull’interfaccia della Microsoft Loopback Adapter: netsh int ipv4 set int 11 weakhostreceive=enabled weakhostsend=enabled

Figura 11: Abilitazione del routing tra l’interfaccia loopback e la scheda di rete

Completamento della configurazione del ruolo DHCP

Una volta installato il ruolo DHCP Server, è necessario completare la configurazione iniziale tramite la procedura di post-installazione. Questa fase serve a rendere operativo il servizio e a predisporre i gruppi di sicurezza necessari per la gestione del DHCP. Ovviamente se avete migrato un vostro server DHCP questa operazione non è necessaria. 🙂

Dal Server Manager, accedete alla sezione relativa al ruolo DHCP e avviate il DHCP Post-Install configuration wizard. Nella schermata di descrizione, il sistema indica che verranno creati automaticamente i gruppi di sicurezza locali:

• DHCP Administrators
• DHCP Users

Questi gruppi consentono di delegare in modo controllato le attività di amministrazione e consultazione del servizio DHCP, in linea con le best practice di sicurezza.

Proseguite con la procedura guidata e confermate le impostazioni proposte fino al completamento della configurazione selezionando Commit. Al termine del processo, il ruolo DHCP risulterà correttamente configurato a livello di sistema operativo.

Figura 12: Completamento della configurazione del ruolo DHCP

Verifica del binding del server DHCP

Dopo aver completato l’intera configurazione, è necessario verificare che il server DHCP sia correttamente in ascolto sull’indirizzo IP della Microsoft Loopback Adapter. Questa verifica conferma che il servizio DHCP utilizza l’indirizzo IP logico previsto e che la configurazione con loopback è stata applicata correttamente.

Collegatevi alla macchina virtuale in Azure e aprite una sessione PowerShell con privilegi amministrativi. Una volta aperta la console, eseguite il comando seguente per verificare su quali indirizzi IP il servizio DHCP sta ascoltando: netstat -an | Select-String “67”

Il comando restituisce le porte UDP aperte sul sistema. Dovreste visualizzare un output che indica che la porta UDP 67 (porta standard del servizio DHCP server) è associata all’indirizzo IP configurato sulla loopback, ad esempio: UDP 172.16.1.100:67 *:*

Questo risultato conferma che il servizio DHCP è correttamente in ascolto sull’indirizzo IP della Microsoft Loopback Adapter.

In alternativa, o come ulteriore controllo, potete effettuare la verifica direttamente dalla console di gestione DHCP. Aprite DHCP Management, fate clic con il tasto destro sul nome del server e selezionate Bindings. Nella finestra di configurazione verificate che la Microsoft Loopback Adapter sia elencata e che risulti associata all’indirizzo IP 172.16.1.100 (o all’indirizzo configurato nel vostro ambiente).

Una volta completati questi controlli, il server DHCP può essere considerato correttamente configurato e pronto per l’uso in produzione.

Figura 13: Verifica del binding del server DHCP

Installazione e configurazione del DHCP Relay Agent

Abbiamo già detto che la funzionalità DHCP Relay Agent consente ai client DHCP presenti in una subnet locale di comunicare con un server DHCP situato in un’altra subnet (nel nostro caso, una Virtual Network in Azure). Poiché i pacchetti broadcast DHCP non vengono instradati tra subnet né attraverso tunnel VPN, il relay funge da intermediario: riceve i messaggi broadcast dai client e li inoltra in unicast verso l’indirizzo del server DHCP remoto.

Nello scenario che stiamo trattando, il DHCP Relay Agent deve essere installato sulla rete on-premises, in corrispondenza del router o dell’interfaccia di livello 3 che collega la subnet dei client locali verso il resto della rete e verso il tunnel VPN verso Azure.

Prerequisiti

• Un dispositivo di rete con connettività alla subnet dei client.
• Connettività di livello 3 verso Azure (Site-to-Site VPN o ExpressRoute).
• Raggiungibilità dell’indirizzo IP del server DHCP in Azure (quello configurato sulla loopback).

Io ho deciso di installare il DHCP Relay Agent in una macchina Windows Server on-premises

Installazione su Windows Server del DHCP Relay Agent

1. Accedete alla macchina destinata a fare da Relay Agent con un account con privilegi di amministratore.
2. Aprite il Server Manager e avviate la procedura Add Roles and Features.
3. Selezionate il ruolo Remote Access e, all’interno, la funzionalità Routing (Routing and Remote Access).
4. Proseguite con l’installazione e completate la procedura.

Figura 14: Installazione del ruolo di Routing In Windows Server

Configurazione del DHCP Relay Agent

Una volta completata l’installazione della funzionalità di routing, potete procedere con la configurazione del DHCP Relay Agent.

Aprite la console Routing and Remote Access, fate clic con il tasto destro sul nome del server e selezionate Configure and Enable Routing and Remote Access per avviare la procedura guidata.

Figura 15: Avvio della procedura guidata di configurazione del Relay Agent

Durante la configurazione, scegliete l’opzione Custom Configuration e abilitate LAN Routing, quindi completate la procedura e avviate il servizio.

Figura 16: Scelta della Custom configuration

Figura 17: Scelta dell’abilitazione del LAN Routing

Figura 18: Completamento della configurazione

Dopo l’avvio del servizio, espandete il nodo IP Routing e selezionate General. Da qui, aprite il pannello New Routing Protocol e aggiungete il protocollo DHCP Relay Agent all’elenco dei protocolli di routing disponibili.

Figura 19: Installazione di un nuovo protocollo di routing

Figura 20: Aggiunta del DHCP Relay Agent

Una volta aggiunto il protocollo di routing DHCP Relay Agent, fate clic con il tasto destro su di esso e selezionate New Interface. Nella finestra di configurazione, scegliete la scheda di rete collegata alla subnet dei client locali, ovvero l’interfaccia attraverso la quale i client inviano le richieste DHCP.

Figura 21: Aggiunta dell’interfaccia di rete attraverso la quale i client inviano le richieste DHCP

Figura 22: Scelta dell’interfaccia di rete attraverso la quale i client inviano le richieste DHCP

Nell proprietà dell’interfaccia definite come e a quali condizioni l’interfaccia inoltra le richieste DHCP provenienti dai client verso il server DHCP remoto (in Azure).

L’opzione Relay DHCP packets abilita l’inoltro dei pacchetti DHCP ricevuti su questa interfaccia.

• Quando è selezionata, l’interfaccia:
  • riceve i messaggi DHCP Discover in broadcast dai client locali;
  • li inoltra in unicast verso il server DHCP configurato nel Relay Agent.
• Se non è selezionata, l’interfaccia ignora completamente il traffico DHCP.

Questa opzione deve essere abilitata sull’interfaccia collegata alla subnet dei client.

Il parametro Hop-count threshold definisce il numero massimo di relay attraversabili da una richiesta DHCP prima che venga scartata. Il parametro Boot threshold (seconds) imposta un tempo di attesa massimo per l’inoltro delle richieste DHCP durante la fase di boot del client.

Figura 23: Configurazione dell’interfaccia di rete attraverso la quale i client inviano le richieste DHCP

Configurazione degli indirizzi del server DHCP nel DHCP Relay Agent

Dopo aver aggiunto e abilitato il DHCP Relay Agent, è necessario configurare l’elenco degli indirizzi IP dei server DHCP di destinazione. Questa configurazione indica al relay a quali server inoltrare le richieste DHCP ricevute dai client locali.

Selezionate DHCP Relay Agent e fate clic con il tasto destro su DHCP Relay Agent e scegliete Properties.

All’interno della sezione Server address, dovete inserire uno o più indirizzi IP dei server DHCP verso cui il relay deve inoltrare le richieste. In questo campo inserite l’indirizzo IP del server DHCP in esecuzione in Azure, ad esempio 172.16.1.100, e selezionate Add per aggiungerlo all’elenco.

Una volta inseriti gli indirizzi corretti, confermate la configurazione selezionando OK.

Figura 24: Configurazione dell’indirizzo a cui verranno inoltrate le richieste DHCP

Test di funzionamento con client on-premises

Per verificare il corretto funzionamento dell’intera configurazione, ho utilizzato una macchina on-premises come client DHCP. Dalla macchina client on-premises ho inizialmente verificato lo stato della configurazione di rete eseguendo il comando ipconfig. In questa fase il client risultava privo di una configurazione IP valida, con un indirizzo APIPA (169.254.x.x), condizione tipica quando non è disponibile alcun server DHCP raggiungibile.

Dopo aver collegato la macchina alla rete, ho forzato il rinnovo della configurazione DHCP eseguendo il comando: ipconfig /renew

A seguito del rinnovo, il client ha ricevuto correttamente un indirizzo IPv4 appartenente allo scope configurato sul server DHCP in Azure.

Figura 25: Il client on-premise ha ricevuto correttamente l’indirizzo IP dal server DHCP ospitato in Azure

La schermata sotto mostra la console di gestione del server DHCP in esecuzione nella macchina virtuale Azure e rappresenta la conferma finale del corretto funzionamento del servizio dal punto di vista del server. Nel caso specifico, il server DHCP ha assegnato correttamente l’indirizzo IP 192.168.11.151 al client on-premises WIN11-24H2.

Figura 26: Il server DHCP ospitato in Azure ha rilasciato correttamente l’indirizzo IP al client on-premises

Conclusioni

La migrazione del servizio DHCP da on-premises ad Azure, realizzata tramite l’utilizzo di un DHCP Relay Agent, consente di centralizzare la gestione degli indirizzi IP mantenendo la piena operatività dei client locali. L’architettura descritta supera i limiti intrinseci dei broadcast DHCP in ambienti cloud e ibridi, garantendo un’integrazione corretta tra rete on-premises e Virtual Network di Azure.

Per una panoramica più ampia sulle opzioni di gestione DHCP in ambiente Azure e sulle novità relative al supporto personalizzato per DHCP in Virtual Networks, vi consiglio la lettura dell’articolo ufficiale sul blog di Azure Networking: https://techcommunity.microsoft.com/blog/azurenetworkingblog/custom-dhcp-support-in-azure/4089674