RDP fuori rete aziendale: perché non trovi il PC e come risolvere con VPN e Azure

Da fuori rete aziendale il PC non è “visibile” su Internet, quindi il client RDP non sa come raggiungerlo o viene bloccato dal firewall. La soluzione più robusta è creare una VPN verso la rete aziendale (anche con Azure) e continuare a usare Remote Desktop come in ufficio, senza nuove VM per utente.

Indice

Sintomi e contesto del problema

In sede funziona: client e PC di destinazione si trovano nella stessa LAN, quindi RDP completa correttamente la connessione.
Fuori sede non funziona: il client riceve errore del tipo “<nome‑PC> non appartiene alla rete specificata” o “impossibile risolvere il nome host”.
Domanda tipica: “Devo passare ad Azure, usare un’app di terze parti (AnyDesk/TeamViewer) o RVNC/VNC?”

Cosa succede tecnicamente

In LAN il PC di destinazione ha un indirizzo IP privato (ad esempio 10.x/172.16–31.x/192.168.x). Fuori dall’azienda, quel prefisso non è instradabile sulla rete pubblica e non esiste nessuna rotta Internet verso quell’IP. Inoltre:

Risoluzione nomi: il nome “PC‑Ufficio” o “pc‑utente.dominio.lan” si risolve solo attraverso il DNS aziendale. Fuori sede, il client usa DNS pubblici che non conoscono quei nomi interni.
Firewall/NAT: anche conoscendo l’IP privato, il perimetro blocca il traffico in ingresso su RDP (porta 3389/TCP). Esporre la 3389 su Internet è sconsigliato per rischio brute‑force e vulnerabilità note.

Risultato: senza un tunnel privato o un proxy sicuro, il percorso rete e la risoluzione nomi falliscono. Da qui il messaggio che il PC non “appartiene” alla rete specificata.

Perché la VPN risolve

Una VPN istituisce un tunnel cifrato tra il dispositivo dell’utente e la rete aziendale. All’interno del tunnel:

Il client ottiene rotte verso i prefissi interni (es. 10.10.0.0/16), quindi il next hop corretto per raggiungere il PC.
La sessione usa il DNS aziendale, così pc‑utente.dominio.lan torna a risolversi.
La porta 3389 resta non esposta a Internet; è aperta solo tra client VPN e host interno, seguendo le policy IT.

In pratica, una volta stabilito il tunnel, l’utente inserisce lo stesso nome/indirizzo del PC che usa in ufficio e RDP ricomincia a funzionare.

Scenari possibili

Endpoint VPN on‑prem: un firewall aziendale (o appliance) pubblica l’endpoint. Il client si connette direttamente lì.
Endpoint VPN in Azure: si crea un Azure VPN Gateway in una VNet; il client fa point‑to‑site (P2S) verso Azure. Se i PC sono on‑prem, si aggiunge anche una site‑to‑site (S2S) tra Azure e la LAN per instradare il traffico fino alla rete locale.

Implementazione pratica con Azure

Se usi già servizi Microsoft, Azure offre un percorso veloce senza spostare i PC fisici. La logica è: VNet in Azure → Gateway VPN P2S per gli utenti → (opzionale) S2S verso on‑prem. Ecco i passi tipici:

Preparazione della rete

Crea la VNet (es. 10.50.0.0/16) e la subnet speciale GatewaySubnet (es. 10.50.255.0/27). Evita sovrapposizioni con gli spazi IP della LAN on‑prem.
Provisiona Azure VPN Gateway (SKU adeguato, es. VpnGw1) con protocollo OpenVPN e/o IKEv2.
Configura la Point‑to‑Site:
- Definisci il Client Address Pool (es. 172.20.100.0/24).
- Scegli l’autenticazione: Azure AD (per MFA/Conditional Access), RADIUS o certificati.
- Imposta i DNS interni (controller di dominio o resolver aziendali).
Se i PC sono on‑prem, crea una connessione S2S tra il gateway Azure e il firewall aziendale, con o senza BGP. Annuncia verso Azure le reti interne (es. 10.10.0.0/16); dal lato on‑prem assicurati che il ritorno verso il pool P2S passi attraverso il tunnel.

Permessi e sicurezza

NSG/Firewall: consenti il traffico RDP dalla subnet P2S o dai prefissi S2S verso gli host di destinazione, senza aprire 3389 su Internet.
Accesso applicativo: gli utenti che si connettono in RDP devono essere nel gruppo Remote Desktop Users sul PC (o avere diritti amministrativi se previsto dalle policy).
MFA: abilita MFA sull’accesso VPN (Azure AD o RADIUS con OTP) per ridurre il rischio di furto credenziali.

Distribuzione lato utente

Esporta il profilo P2S dal portale Azure.
Installa il client VPN: su Windows è disponibile Azure VPN Client o il client nativo IKEv2. Su macOS e Linux usa i client compatibili con OpenVPN/IKEv2.
Importa il profilo e verifica la connessione. Una volta connesso, prova: nslookup pc-utente.dominio.lan ping pc-utente.dominio.lan mstsc /v:pc-utente.dominio.lan

Non serve creare una VM per ogni utente

La VPN è solo il mezzo di trasporto. Non devi generare una VM per persona. Le VM servono solo se vuoi un desktop virtuale (es. Azure Virtual Desktop) invece di accedere al PC fisico in ufficio.

Alternative utili e quando usarle

Opzione	Pro	Contro
Azure VPN Gateway / firewall aziendale	Sicurezza sotto controllo IT; integrazione con AD/Azure AD; nessun software extra oltre al client VPN nativo.	Richiede configurazione di rete, costi del gateway o del firewall, gestione certificati e manutenzione.
Azure Bastion	Accesso RDP/SSH via browser, senza esporre 3389; niente client VPN sul dispositivo dell’utente.	Costo orario aggiuntivo; adatto soprattutto a VM in Azure; limitazioni su stampa locale e redirezione avanzata.
Azure Virtual Desktop (AVD)	Sessioni scalabili, isolamento, MFA, esperienza uniforme da qualsiasi dispositivo.	Richiede deploy di VM, licenze e profili FSLogix; non risolve l’accesso al PC fisico.
App di controllo remoto di terze parti (TeamViewer, AnyDesk, RustDesk, ecc.)	Avvio rapido, NAT traversal automatico, modalità assistenza remota.	Dipendenza da cloud di terzi, possibili restrizioni di policy, costi di licenza in ambito business.
Port‑forwarding/router + DDNS	Nessun costo cloud; semplice per una‑due macchine in contesti non critici.	Espone direttamente 3389 su Internet: rischio elevato, non consigliato in azienda.

Nota: se preferisci non distribuire client VPN, una valida alternativa on‑prem è Remote Desktop Gateway (ruolo Windows Server) che incapsula RDP su HTTPS con MFA. In Azure il ruolo equivalente gestito è Azure Bastion.

Passaggi consigliati e best practice

Allinea i requisiti di sicurezza: molte policy vietano l’esposizione diretta di RDP o di strumenti non gestiti.
Implementa una VPN (Azure o on‑prem) come primo strato di protezione; abilita MFA.
Configura DNS interno (o FQDN statici) in modo che i nomi dei PC siano risolvibili anche tramite VPN; imposta i DNS suffix sul profilo.
Indurisci RDP: NLA attiva, TLS aggiornato, patch di sicurezza, policy di lockout e gruppi di accesso minimali.
Valuta Bastion o AVD se serve scalabilità, se i PC fisici non devono restare accesi 24/7, o se vuoi separare completamente l’ambiente.
App di terze parti solo se approvate dall’organizzazione; in quel caso, abilita MFA e limita gli IP di management.

Diagnostica rapida

Quando “da fuori” non trovi il PC, verifica in quest’ordine:

Verifica della VPN

ipconfig /all
route print

Controlla le rotte: deve esistere una rotta verso la subnet del PC (es. 10.10.0.0/16) con next hop il tunnel VPN.
Controlla i DNS: i server DNS devono essere quelli aziendali.

Risoluzione nomi e connettività

nslookup pc-utente.dominio.lan
ping pc-utente.dominio.lan
tracert pc-utente.dominio.lan

Se nslookup fallisce, il problema è il DNS (aggiungi suffissi, usa FQDN, verifica la zona interna).
Se il ping è bloccato ma la rotta esiste, prova direttamente la porta RDP:

Test-NetConnection pc-utente.dominio.lan -Port 3389
oppure
tnc pc-utente.dominio.lan -port 3389

Controllo lato host di destinazione

RDP abilitato: su Windows, Impostazioni > Sistema > Desktop remoto (o via Criteri di gruppo).
Firewall locale: regole “Remote Desktop (TCP‑In)” abilitate su profilo Dominio/Privato; valuta di limitarle alla subnet VPN.
Gruppi di accesso: l’utente appartiene a Remote Desktop Users o ha permessi RDP attraverso criteri/gruppi di sicurezza.

Policy di dominio e sicurezza

gpresult /r
rsop.msc

Verifica GPO su NLA, requisiti cifratura, lockout e restrizioni firewall distribuite via dominio.

Indurimento di Remote Desktop

NLA e TLS 1.2+: rifiuta connessioni senza autenticazione a livello di rete.
Aggiornamenti: applica tempestivamente le patch critiche (client e host).
Gruppi minimi: limita gli utenti autorizzati a connettersi in RDP; disabilita account locali inutili.
Firewall: consenti 3389 solo dalle subnet VPN/S2S; non dalla WAN.
Account lockout: imposta soglie di blocco per tentativi falliti e avvisa il SOC/IT.
Audit: attiva log su eventi RDP (ID 4624/4625/4776/1149) e monitora anomalie.
Certificati: usa certificati attendibili per il listener RDP, evitando avvisi di identità non verificata.

Quando valutare Bastion, RD Gateway o AVD

Azure Bastion è ideale per accedere a VM in Azure via browser senza installare client. RD Gateway (on‑prem) svolge un ruolo simile per host interni, incapsulando RDP su HTTPS e consentendo MFA con NPS/Radius. AVD è la scelta per fornire un ambiente desktop centralizzato, completamente gestito e scalabile.

Domande frequenti

Serve spostare i PC in Azure? No. Se vuoi solo connetterti ai PC fisici, pubblica un endpoint VPN (Azure o on‑prem) e instrada il traffico verso la LAN.

Mi serve una VM per ogni persona? No per la VPN. Sì solo se adotti desktop virtuali (AVD) o se hai casi d’uso specifici in cloud.

TeamViewer/AnyDesk sono più semplici? Possono essere rapidi in emergenza, ma dipendono da servizi di terzi, possono confliggere con policy aziendali e introducono costi/licenze. In ambito enterprise, VPN o Bastion/RD Gateway restano standard gestibili dall’IT.

Il port‑forwarding con DDNS è un’alternativa? Dal punto di vista tecnico sì, ma espone la 3389 su Internet e aumenta drasticamente il rischio. Sconsigliato per ambienti aziendali.

Checklist immediata

Definito endpoint VPN (Azure o firewall on‑prem) e MFA abilitata.
Rotte dal client verso la subnet del PC presenti; ritorno dal PC verso il pool P2S garantito.
DNS interni nel profilo VPN; FQDN dei PC risolvibili.
RDP attivo con NLA, patch aggiornate, gruppi di accesso corretti.
Regole firewall: 3389 ammesso solo da subnet VPN/S2S; auditing attivo.
Valutate alternative come Bastion o AVD se servono accessi via browser o desktop in cloud.

Conclusione

Il motivo per cui “fuori città” non trovi il PC via Remote Desktop è strutturale: i client Internet non vedono le reti private aziendali e i nomi interni non si risolvono. La soluzione solida, sicura e sostenibile è creare un tunnel VPN (ad esempio con Azure VPN Gateway o con un firewall on‑prem) e continuare a usare RDP esattamente come in ufficio. Non è necessario generare una VM per ogni utente: le VM diventano interessanti solo se vuoi un desktop virtuale o se preferisci non tenere i PC fisici sempre accesi. Per esigenze particolari, Azure Bastion, RD Gateway o strumenti di terze parti possono integrare la strategia, ma la VPN resta il punto di partenza più robusto in ambito enterprise.

Appendice operativa

Esempi di Criteri di gruppo

Abilitare RDP: Configurazione computer → Modelli amministrativi → Componenti di Windows → Servizi Desktop remoto → Host sessione Desktop remoto → Connessioni → Consenti agli utenti di connettersi in Desktop remoto.
Richiedere NLA: Protezione → Richiedi autenticazione a livello di rete.
Limitare gruppi: Configurazione computer → Impostazioni di sicurezza → Gruppi con restrizioni per mantenere snello Remote Desktop Users.

Regola firewall d’esempio (host)

New-NetFirewallRule -DisplayName "RDP da VPN"
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3389
  -RemoteAddress 172.20.100.0/24 -Profile Domain,Private

Verifica fine‑a‑fine

# Sul client VPN
Resolve-DnsName pc-utente.dominio.lan
Test-NetConnection pc-utente.dominio.lan -Port 3389 -InformationLevel Detailed

Sul PC di destinazione (in sessione locale o remota)

Get-NetTCPConnection -LocalPort 3389 | Select-Object LocalAddress,RemoteAddress,State

Se i comandi mostrano rotta e risoluzione corrette ma la porta risulta filtrata, la causa è quasi sempre una regola firewall a perimetro o sull’host che non include il pool P2S tra le origini consentite.

In sintesi: il problema dipende dal fatto che i PC non sono visibili da Internet; la soluzione più robusta è creare un tunnel VPN (ad esempio con Azure VPN Gateway o un firewall on‑prem) e continuare a usare Remote Desktop come in ufficio, senza dover per forza creare una VM per ogni utente.

Con questa architettura ottieni sicurezza, semplicità operativa e aderenza alle policy, lasciando la porta aperta a evoluzioni come Bastion o AVD quando servono nuovi modelli di lavoro.