Vuoi collegarti da A a B via Desktop Remoto usando la porta 3390 ma la sessione non parte? Qui trovi una guida completa: verifica della porta, firewall, NAT/port‑forwarding, sintassi del client, diagnosi con PowerShell e consigli di sicurezza. Segui l’ordine indicato per risolvere in pochi minuti.
Scenario e obiettivo
L’utente dispone di tre desktop Windows (A, B, C) dietro un unico router domestico con IP pubblico.
- A → C funziona già via RDP (porta predefinita 3389) grazie a una regola di port‑forwarding sul router.
- Per A → B sono stati eseguiti tre passaggi: cambio porta RDP di B a 3390 via registro, inoltro 3390 sul router verso B, creazione regola firewall TCP 3390. La connessione però fallisce.
Obiettivo: far funzionare in modo affidabile la connessione A → B sulla porta 3390, mantenendo A → C su 3389.
Soluzione rapida in sette passaggi
Se ti serve un promemoria condensato, usa la tabella seguente. Subito dopo trovi gli approfondimenti di ogni punto, con comandi pronti all’uso.
| Passo | Cosa verificare/fare | Perché è importante |
|---|---|---|
| 1 | Conferma che la porta sia realmente cambiata. Su B in PowerShell:Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber | Il valore deve essere 3390; in caso contrario la modifica non è attiva o serve un riavvio. |
| 2 | Controlla che RDP stia ascoltando su 3390. Su B:netstat -ano | findstr :3390 | Se manca lo stato LISTENING, il servizio non usa la nuova porta. Riavvia il PC o il servizio Servizi Desktop remoto. |
| 3 | Test di connettività da A:Test-NetConnection <IP-di-B> -Port 3390(o telnet <IP-di-B> 3390) | Se TcpTestSucceeded: True la porta è raggiungibile; altrimenti c’è un blocco di firewall o NAT. |
| 4 | Regola firewall corretta. Su B verifica o crea una regola in entrata TCP 3390 (tutti i profili di rete necessari). | Il firewall locale può bloccare anche se la porta è in ascolto. |
| 5 | Port‑forwarding univoco sul router: Esterno 3389 → C:3389 (già presente) Esterno 3390 → B:3390 (da creare) | Una porta esterna può puntare a un solo host interno; non usare due volte la 3389. |
| 6 | Sintassi corretta nel client RDP: campo Computer = <IP-o-FQDN-di-B>:3390. Usa credenziali utente di B. | Se non specifichi la porta, il client tenta la 3389 e fallisce. |
| 7 | Riprova la connessione dopo i controlli. | Se ancora non funziona, passa alla sezione “Diagnostica avanzata”. |
Come funziona realmente Desktop Remoto su porte non predefinite
RDP usa TCP (sempre) e, se disponibile, anche UDP per ottimizzare le prestazioni. Per impostazione predefinita entrambi usano la porta 3389. Se cambi la porta TCP su Windows (ad esempio a 3390), le connessioni client devono includere esplicitamente :3390. L’UDP non è indispensabile: se non corrisponde o è bloccato, la sessione cade su TCP senza impedire l’accesso. Per semplificare la vita, puoi scegliere tra due strategie:
- Cambiare la porta su Windows e mappare la stessa porta sul router: Esterno 3390 → B:3390 (come da scenario).
- Lasciare 3389 su Windows e far tradurre al router: Esterno 3390 → B:3389. È spesso preferibile: meno modifiche al sistema operativo e aggiornamenti più tranquilli.
Entrambe le strade funzionano. Se hai già cambiato la porta a 3390 su B, assicurati che il servizio la stia davvero usando (vedi sezione successiva).
Verifiche dettagliate sul PC di destinazione B
Controllare e, se necessario, impostare la porta nel Registro
Apri PowerShell come amministratore su B e verifica:
# Lettura della porta configurata
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
Impostazione a 3390 (DWORD, valore decimale 3390)
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 3390
In alternativa via reg.exe
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 3390 /f Riavvio richiesto: la modifica della chiave è recepita al riavvio del servizio TermService o del sistema. Per evitare il reboot:
# Riavviare solo il servizio (interrompe eventuali sessioni)
Restart-Service -Name TermService -Force
Verificare che il servizio RDP ascolti su 3390
# Con netstat (funziona anche da Prompt cmd)
netstat -ano | findstr :3390
Con PowerShell
Get-NetTCPConnection -LocalPort 3390 -State Listen Se non vedi LISTENING su 3390:
- Conferma di aver riavviato TermService o il PC.
- Assicurati che Desktop remoto sia abilitato in Impostazioni > Sistema > Desktop remoto.
- Controlla eventuali criteri di gruppo che disabilitano RDP o impongono NLA (vedi più avanti).
Regole firewall in entrata
Per impostazione predefinita, Windows crea regole per “Desktop remoto – Modalità utente (TCP‑In/UDP‑In)” sulla porta predefinita. Se usi una porta diversa, aggiungi una regola dedicata:
# Creare regola firewall per 3390 TCP su tutti i profili
New-NetFirewallRule -DisplayName "RDP 3390 TCP-In" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow -Profile Domain,Private,Public
Verificare regole RDP esistenti
Get-NetFirewallRule | Where-Object DisplayName -like "Desktop remoto" | Get-NetFirewallPortFilter Consigli:
- Limita la regola agli indirizzi IP sorgente da cui ti connetti (se statici) con
-RemoteAddressper ridurre la superficie d’attacco. - Se lavori solo in LAN, disabilita il profilo Public.
- Se hai cambiato anche l’UDP, replica la regola per
-Protocol UDP.
Abilitazione Desktop Remoto e NLA
Controlla che Desktop Remoto sia attivo (Impostazioni > Sistema > Desktop remoto) e che l’utente abbia diritto di connessione (pulsante Utenti Desktop remoto). Per compatibilità con client datati, se necessario disattiva temporaneamente Richiedi autenticazione a livello di rete (NLA). Ricorda che NLA offre protezione aggiuntiva: riabilitala appena possibile.
Controlli nei registri eventi
Quando la porta è corretta ma la sessione non parte, i log Windows aiutano molto. Apri Visualizzatore eventi e ispeziona:
- Applicazioni e servizi > Microsoft > Windows > TerminalServices‑LocalSessionManager > Operational
- Applicazioni e servizi > Microsoft > Windows > RemoteDesktopServices‑RdpCoreTS > Operational
- Sicurezza per eventi di accesso/errore credenziali.
Cerca avvisi relativi a porte in uso, autenticazioni fallite o mancanza di diritti di accesso.
Verifiche e configurazione sul router
Port‑forwarding uno‑a‑uno
Imposta due regole distinte:
- Esterno 3389 → C:3389 (già operativa)
- Esterno 3390 → B:3390 (da creare)
Ogni porta esterna può essere inoltrata verso un solo host interno. Non puoi avere “3389 → C” e “3389 → B” contemporaneamente. Se preferisci non modificare Windows, puoi fare Esterno 3390 → B:3389 (traduzione porta a livello di NAT).
IP interni statici o DHCP riservato
Assicurati che B e C mantengano sempre lo stesso IP interno (es. prenotazione DHCP sul router). Se l’IP cambia, il port‑forwarding “punta nel vuoto”.
NAT loopback e test dall’interno
Alcuni router non supportano il NAT loopback (o lo disabilitano). Se provi a connetterti dal PC A, dentro la tua LAN, verso il tuo FQDN/IPv4 pubblico:3390, la prova potrebbe fallire pur funzionando da Internet. Esegui quindi prima un test in LAN: mstsc /v:192.168.x.x:3390. Se va, ma l’accesso da WAN fallisce, il problema è sul router o a monte (vedi CGNAT).
Attenzione al CGNAT del provider
Alcuni ISP usano Carrier‑Grade NAT, impedendo l’arrivo diretto delle connessioni. Se il tuo “IP pubblico” visto dal router non coincide con quello riportato dai servizi esterni, potresti essere dietro CGNAT. In tal caso il port‑forwarding non potrà funzionare: valuta una VPN in ingresso, un tunnel o un servizio con IP pubblico dedicato.
Verifiche sul client A
Sintassi corretta nel client RDP
Apri Connessione Desktop remoto e in Computer digita IP-o-nome-di-B:3390. In alternativa, da Esegui o Prompt:
mstsc /v:IP-o-nome-di-B:3390
Nel campo nome utente inserisci un account valido su B (locale o di dominio). Evita di usare solo il nome del dispositivo.
Test di connettività dallo strumento giusto
# Test locale dalla macchina A verso B
Test-NetConnection <IP-di-B> -Port 3390
Test end-to-end verso il tuo FQDN/IP pubblico (se il router supporta NAT loopback)
Test-NetConnection -Port 3390 Se il test restituisce TcpTestSucceeded: False, il problema è rete (firewall o NAT). Se invece è True ma la GUI RDP non si connette, sospetta un errore di credenziali, NLA o certificato.
Procedura di diagnostica passo‑passo
- In LAN, da A prova
mstsc /v:IP-interno-di-B:3390. Se fallisce, il problema è su B (porta, servizio, firewall). Torna alla sezione su B. - Da A verso l’IP pubblico, prova
Test-NetConnection IP-pubblico -Port 3390:- False → router/ISP: controlla la mappatura, eventuale CGNAT, o conflitti di regole.
- True → la porta è raggiungibile: verifica NLA, credenziali, autorizzazioni utenti e certificati.
- Event Viewer su B: cerca errori nel momento del tentativo.
- Disattiva temporaneamente l’UDP in firewall per escludere side‑effect, la sessione funzionerà comunque su TCP.
Script PowerShell “tutto in uno” per B
Questo script verifica porta, servizio, firewall e ascolto. Incollalo in PowerShell Elevato su B.
$desiredPort = 3390
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Write-Host "== Porta RDP configurata ==" -ForegroundColor Cyan
(Get-ItemProperty $regPath -Name PortNumber).PortNumber
Write-Host "== Stato servizio TermService ==" -ForegroundColor Cyan
Get-Service -Name TermService | Select-Object Name,Status,StartType
Write-Host "== Ascolto su TCP $desiredPort ==" -ForegroundColor Cyan
try { Get-NetTCPConnection -LocalPort $desiredPort -State Listen | Format-Table -AutoSize } catch { "Nessun ascolto su $desiredPort" }
Write-Host "== Regole Firewall che toccano $desiredPort ==" -ForegroundColor Cyan
Get-NetFirewallRule -Enabled True | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq "$desiredPort"} |
Select-Object InstanceID,Protocol,LocalPort
Write-Host "== Abilitazione rapida Firewall (se serve) ==" -ForegroundColor Cyan
Scommenta la riga seguente se vuoi creare la regola
New-NetFirewallRule -DisplayName "RDP $desiredPort TCP-In" -Direction Inbound -Protocol TCP -LocalPort $desiredPort -Action Allow -Profile Domain,Private,Public
Write-Host "== Suggerimento ==" -ForegroundColor Yellow
"Se l'ascolto manca, riavvia TermService: Restart-Service TermService -Force" Errori tipici e come risolverli
| Sintomo | Causa probabile | Rimedio |
|---|---|---|
| La connessione si blocca senza chiedere credenziali | Porta non raggiungibile, NAT o firewall | Test-NetConnection; correggi regola router o firewall; verifica IP interno di B. |
| Richiesta credenziali ma “impossibile connettersi” | NLA/credenziali errate o utente non autorizzato | Aggiungi l’utente a “Utenti Desktop remoto”; prova a disabilitare NLA temporaneamente; verifica account e password. |
| Funziona in LAN ma non da Internet | NAT loopback assente, CGNAT o port‑forwarding errato | Prova da rete esterna reale; rivedi mappature; verifica IP pubblico; considera VPN. |
| Connessione lenta o instabile | UDP bloccato o rete congesta | Accetta il fallback TCP o allinea/abilita l’UDP; ottimizza qualità in RDP (Dispositivo → Esperienza). |
| Porta 3390 in uso da altro servizio | Conflitto porte | netstat -ano per vedere PID e disinstalla/riconfigura il servizio in conflitto o scegli un’altra porta. |
Consigli di sicurezza essenziali
- Non esporre direttamente RDP su Internet se puoi evitarlo: usa una VPN (WireGuard/OpenVPN) e lascia RDP accessibile solo sulla LAN.
- Se devi esporre RDP: NLA abilitata, password robuste, eventuale account lockout, e limitazione per IP sorgenti nel firewall.
- Valuta Remote Desktop Gateway o tunnel SSH; cambiare porta riduce il rumore di scansione ma non è difesa.
- Aggiornamenti Windows e driver sempre applicati; disinstalla software RDP di terze parti non necessari.
Alternative di architettura
- Port‑forwarding con traduzione: lascia 3389 su B, mappa 3390 esterno → 3389 interno. Meno manutenzione sul sistema.
- VPN site‑to‑site o VPN road‑warrior: accesso a B con
192.168.x.x:3389senza esporre porte. - Reverse tunnel verso un VPS con IP pubblico (avanzato): utile se sei dietro CGNAT.
Approfondimenti su UDP e prestazioni
RDP tenta di stabilire anche un canale UDP per ottimizzare latenza e fluidità. Se cambi la porta TCP, il canale UDP potrebbe non stabilirsi automaticamente in alcune configurazioni. Non è un problema funzionale: la sessione procederà su TCP. Se vuoi semplificare la diagnosi, puoi bloccare temporaneamente l’UDP in ingresso su B (regola firewall) per evitare messaggi fuorvianti, oppure, se presente una voce dedicata per RDP‑UDP nel registro, allinearne la porta. È un perfezionamento, non un requisito.
Checklist finale prima della prova
- Su B: Desktop remoto abilitato, utente autorizzato.
- Registro:
RDP-Tcp\PortNumberimpostato a 3390, TermService riavviato. - Ascolto:
netstatmostra LISTENING su 3390. - Firewall: regola Inbound TCP 3390 attiva sui profili necessari.
- Router: Esterno 3390 → B:3390, IP interno di B fisso.
- Client:
mstsc /v:<destinazione>:3390con credenziali corrette.
Domande frequenti
Serve davvero cambiare la porta su Windows?
No. Puoi lasciare 3389 e usare il router per tradurre 3390 esterno → 3389 interno. È spesso la scelta migliore.
Posso usare un FQDN al posto dell’IP?
Sì, ma ricorda sempre :3390 dopo il nome (es. casa.dyndns.example:3390). Se usi DNS dinamico, verifica che il record punti al tuo IP pubblico attuale.
Devo aprire anche l’UDP 3390 dal router?
Non è obbligatorio per connetterti. Aprire solo TCP è sufficiente; se abiliti l’UDP potresti guadagnare performance, ma non è necessario.
Perché in azienda mi chiedono RD Gateway?
Perché aggiunge autenticazione e cifratura a livello applicativo, riducendo l’esposizione diretta del protocollo RDP verso Internet.
Ripristino rapido alla porta predefinita
Se vuoi tornare a 3389 su B:
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber -Value 3389
Restart-Service TermService -Force
Aggiorna firewall: puoi eliminare la regola "RDP 3390 TCP-In" se non serve più
Esempi di configurazione in scenari multipli
| Scenario | Regole router | Porta su Windows B | Vantaggi/Svantaggi |
|---|---|---|---|
| Due PC RDP dietro lo stesso IP | 3389 → C:3389; 3390 → B:3390 | 3390 | Coerenza tra porta esterna e interna; serve intervenire sul SO. |
| Due PC, no modifiche a Windows | 3389 → C:3389; 3390 → B:3389 | 3389 | Meno manutenzione su B; NAT traduce le porte; chiaro lato router. |
| Massima sicurezza | Nessuna porta RDP esposta | 3389 o personalizzata | Accesso via VPN/RD Gateway; esposizione minima su Internet. |
Note importanti e consigli extra
- Riavvio obbligatorio: dopo l’edit del registro, riavvia TermService o il PC.
- Test in LAN prima del NAT: prova
192.168.x.x:3390. Se funziona in LAN ma non da WAN, punta il dito sul router. - NLA e versioni Windows: Windows 10/11 hanno NLA attivo di default. Client obsoleti potrebbero non supportarlo; disattivalo solo per test.
- Esporre RDP su Internet: valuta seriamente soluzioni più sicure (VPN, RD Gateway, SSH tunnel). Cambiare porta riduce il rumore, non i rischi.
- Backup della chiave di registro prima di cambiare la porta: prudenza prima di modifiche di sistema.
Checklist compatta “pronta all’uso”
# Su B (PowerShell amministratore)
Set-ItemProperty 'HKLM:\...\RDP-Tcp' -Name PortNumber -Value 3390
Restart-Service TermService -Force
New-NetFirewallRule -DisplayName "RDP 3390 TCP-In" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow -Profile Domain,Private,Public
netstat -ano | findstr :3390
Su Router
Esterno 3390 → B:3390 (o → B:3389 se non cambi la porta in Windows)
IP interno di B statico o riservato
Su A
mstsc /v::3390
Test-NetConnection -Port 3390 Conclusione
Nel 99% dei casi, quando A → B su 3390 non funziona mentre A → C su 3389 sì, la causa ricade in una di tre categorie: la porta non è davvero in ascolto su B, il port‑forwarding non è “uno‑a‑uno” e coerente, oppure sul client non è stata specificata la porta. Applicando i sette passaggi iniziali e le verifiche estese qui descritte, la connessione RDP sulla porta 3390 diventa ripetibile, stabile e, con le giuste misure, anche sicura.
Appendice: comandi utili riassunti
Get-ItemProperty 'HKLM:\...\RDP-Tcp' -Name PortNumber→ leggi porta.Set-ItemProperty 'HKLM:\...\RDP-Tcp' -Name PortNumber -Value 3390→ imposta porta.Restart-Service TermService -Force→ applica senza riavvio completo.netstat -ano | findstr :3390→ verifica ascolto.New-NetFirewallRule ... -LocalPort 3390→ apri firewall.Test-NetConnection <dest> -Port 3390→ prova reachability.mstsc /v:<dest>:3390→ avvia connessione RDP.
Seguendo questi punti, potrai collegare il secondo PC via RDP su porta 3390 senza sorprese, mantenendo intatta la connessione già funzionante verso C su 3389.