Quer aceder por Remote Desktop a um segundo PC mudando a porta padrão? Este guia prático mostra, de ponta a ponta, como operar na porta 3390 (ou outra), diagnosticar falhas de ligação e endurecer a segurança — ideal para casas e pequenos escritórios em países lusófonos.
Visão geral do cenário
O utilizador possui três desktops: A, B e C. A ligação de A → C funciona na porta padrão 3389/TCP. Para aceder agora ao computador B, a porta de escuta do RDP em B foi alterada para 3390, a porta 3390 foi aberta no router/roteador e na Firewall do Windows, mas a ligação não se estabelece.
Este artigo explica o porquê e o como resolver, com passos prescritivos, comandos e boas práticas de segurança e performance.
Resumo rápido da solução
- Validar a porta no registo (dec/hex) e confirmar que o serviço RDP (TermService) reiniciou após a alteração.
- Garantir que o RDP escuta localmente em
3390/TCP(e preferencialmente3390/UDPpara melhor performance). - Provar conectividade a partir de A para o IP de B na porta 3390.
- Ajustar a Firewall do Windows (regras TCP e UDP) e NAT/Port Forward no router com coerência.
- Usar o formato correto no cliente RDP:
<IP-ou-nome>:3390oumstsc /v:<IP-ou-nome>:3390. - Verificar pré‑requisitos: edição do Windows, permissões de utilizador, NLA e endereço IP interno estático/reservado.
Pré‑requisitos essenciais (evitam horas de frustração)
- Edição do Windows no PC B: Windows Pro, Enterprise ou Server. Windows Home não aceita RDP inbound.
- RDP ativado no B: Definições → Sistema → Ambiente de trabalho remoto (ou Propriedades do sistema → Remoto) e selecionar Permitir ligações. Ative NLA (Network Level Authentication).
- Conta autorizada: o utilizador que fará login deve estar em Administradores ou em Utilizadores da Área de Trabalho Remota no PC B.
- IP interno fixo/reservado para B: defina IP estático no Windows ou reserva DHCP no router para evitar que o encaminhamento “aponte” para um IP que mudou.
- Atualizações do Windows e reinício após mudar a porta: algumas alterações só são efetivas após reiniciar o serviço TermService (ou o sistema).
Passo a passo detalhado de diagnóstico e correção
Confirmar a porta no registo
Valide se a chave foi gravada corretamente (o valor é DWORD, normalmente em decimal):
# Executar no PC B (PowerShell como Administrador)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumberEsperado: PortNumber : 3390. Se aparecer em hexadecimal (ex.: 0x00000d3e), corresponde a 3390.
Depois da alteração, reinicie o serviço para aplicar:
# Reiniciar o serviço RDP de forma segura
Restart-Service -Name TermService -Force
Confirmar que voltou a "Running"
Get-Service -Name TermServiceDica: se estiver a gerir remotamente, planeie uma janela com acesso local de contingência para não “se trancar” fora do PC.
Verificar se o serviço escuta na porta 3390
No PC B, verifique a escuta (TCP e, se possível, UDP para melhor qualidade de sessão):
# PowerShell (Windows 10/11)
Get-NetTCPConnection -LocalPort 3390 -State Listen
Get-NetUDPEndpoint | Where-Object {$_.LocalPort -eq 3390}
CMD (alternativa)
netstat -ano | findstr LISTENING | findstr :3390
Identificar qual processo/serviço mantém a porta
(Copie o PID do netstat e associe ao serviço)
tasklist /svc | findstr \Se não escutar: reveja o registo e o reinício do serviço; confirme que nenhuma política corporativa está a impedir a configuração; verifique se outra aplicação ocupou a porta.
Testar conectividade a partir do PC A
Teste primeiro dentro da rede local (LAN) usando o IP interno de B e, depois, a partir da Internet usando o IP público ou DDNS:
# PowerShell recomendado (substitui o Telnet)
Test-NetConnection -ComputerName <IP-de-B> -Port 3390 -InformationLevel Detailed
OU pelo nome
Test-NetConnection -ComputerName B-NomeDoPC -Port 3390
Cliente Telnet (se instalado)
telnet \ 3390
(janela negra indica porta aberta; erros indicam bloqueio)Nota: o Telnet não vem ativo por padrão. Se necessário, ative em Ativar/Desativar funcionalidades do Windows → Cliente Telnet.
Ajustar a Firewall do Windows (Inbound)
As regras integradas “Remote Desktop – User Mode (TCP‑In)” e “Remote Desktop – User Mode (UDP‑In)” apontam para a porta 3389. Ao mudar de porta, crie novas regras ou edite as existentes:
# Criar regras dedicadas para a nova porta
New-NetFirewallRule -DisplayName "RDP TCP 3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow
New-NetFirewallRule -DisplayName "RDP UDP 3390" -Direction Inbound -Protocol UDP -LocalPort 3390 -Action Allow
Validar regras
Get-NetFirewallRule | Where-Object {$\_.DisplayName -like "RDP 3390"}Garanta que as regras se aplicam aos perfis de rede corretos (Domínio, Privado, Público) conforme o ambiente do PC B.
Usar o formato correto no cliente RDP
No PC A, ao abrir o cliente (mstsc.exe), indique o alvo com a porta explícita:
<IP-de-B>:3390
B-NomeDoPC:3390
Linha de comandos
mstsc /v:<IP-ou-FQDN>:3390 /promptSe gravar um ficheiro .rdp, pode incluir a linha server port:i:3390 para persistir a configuração.
Encaminhamento no router (NAT/Port Forward)
Crie uma regra de encaminhamento no router/roteador que mapeie a porta externa para a porta interna do IP de B. Exemplo base:
| Campo | Valor | Observações |
|---|---|---|
| WAN Port (Externa) | 3390 (ou personalizada, ex.: 55123) | Para segurança por obscuridade adicional, pode usar uma porta externa alta e única. |
| LAN IP (Interno) | IP do PC B (ex.: 192.168.1.30) | Idealmente reservado no DHCP para não mudar. |
| LAN Port (Interna) | 3390 | Deve coincidir com a porta em que o RDP B escuta. |
| Protocolo | TCP e UDP | TCP é obrigatório; UDP melhora a performance. |
Dica: alguns routers exigem regras separadas para TCP e UDP. Outros aceitam “Both”.
Tabela prática de diagnóstico (do mais local ao mais externo)
| Etapa | O que verificar | Comando/Ação | Resultado esperado |
|---|---|---|---|
| Confirmar porta no registo | Porta PortNumber = 3390 | Get-ItemProperty ... RDP-Tcp -Name PortNumber | Valor decimal 3390 (ou hex equivalente) |
| Serviço escuta na porta | TermService a ouvir em 3390 | Get-NetTCPConnection / netstat -ano | Entrada LISTENING em 0.0.0.0:3390 |
| Conectividade local | A → B (IP interno) | Test-NetConnection <IP-interno> -Port 3390 | TcpTestSucceeded = True |
| Firewall do Windows | Regras TCP/UDP para 3390 | New-NetFirewallRule ... | Porta aberta nos perfis certos |
| Formato no cliente | Destino com :3390 | mstsc /v:<IP-ou-nome>:3390 | Cliente tenta na porta certa |
| NAT no router | WAN 3390 → LAN 3390 (IP B) | Configuração de Port Forward | Porta pública encaminha para B |
Porque este método funciona
- Porta personalizada: cliente e servidor têm de “combinar” o mesmo número de porta, caso contrário a sessão nem começa.
- “netstat/Test‑NetConnection”: valida, respetivamente, se o serviço escuta e se o tráfego chega à porta, isolando o problema por camadas (SO, firewall, rede).
- Coerência Firewall/NAT: alterar a porta exige replicar a abertura no SO e no router; um único ponto em falso quebra todo o caminho.
Automatizar a configuração no PC B (script PowerShell)
O bloco abaixo aplica a porta 3390, cria regras de firewall coerentes, reinicia o serviço e faz validações:
# Executar como Administrador no PC B
$Port = 3390
1) Definir porta no registo
\$RegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'
Set-ItemProperty -Path \$RegPath -Name PortNumber -Value \$Port -Type DWord
2) Regras de firewall (TCP/UDP)
\$tcpRule = "RDP TCP \$Port"
\$udpRule = "RDP UDP \$Port"
If (-not (Get-NetFirewallRule -DisplayName \$tcpRule -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName \$tcpRule -Direction Inbound -Protocol TCP -LocalPort \$Port -Action Allow
}
If (-not (Get-NetFirewallRule -DisplayName \$udpRule -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName \$udpRule -Direction Inbound -Protocol UDP -LocalPort \$Port -Action Allow
}
3) Reiniciar serviço
Restart-Service -Name TermService -Force
Start-Sleep -Seconds 2
4) Validações
"=== Validações ==="
(Get-ItemProperty -Path \$RegPath -Name PortNumber).PortNumber
Get-NetTCPConnection -LocalPort \$Port -State Listen
Get-NetUDPEndpoint | Where-Object {$\_.LocalPort -eq \$Port}Reversão: defina $Port = 3389 e repita o script (pode remover as regras antigas com Remove-NetFirewallRule se desejar).
Erros comuns e como resolver
| Sintoma | Causa prováveI | Resolução |
|---|---|---|
| Cliente “não consegue conectar” | Cliente tentou porta 3389, servidor escuta 3390 | Usar <destino>:3390 ou editar o ficheiro .rdp com server port:i:3390. |
| TcpTestSucceeded = False (LAN) | Firewall de B sem regra para 3390 | Criar regras TCP/UDP 3390 no Windows Defender Firewall (Inbound). |
| Funciona em LAN, falha pela Internet | NAT mal configurado; IP interno mudou; ISP com CGNAT | Rever Port Forward (WAN→LAN 3390); reservar IP; verificar se o router tem IP público (não CGNAT). |
| Conecta por IP interno, mas não por nome | DNS local sem registo; cache desatualizada | Usar IP ou arrumar DNS (registo A/hosts). Para nomes externos, usar DDNS. |
| Credenciais incorretas ou NLA falhou | Conta sem permissão; política de segurança | Adicionar o utilizador a Utilizadores da Área de Trabalho Remota e manter NLA ativo (melhor segurança). |
| Ligação fecha após autenticar | Política/RDP desativado; perfis de firewall errados | Rever Permitir ligações no sistema e aplicar regras nos perfis corretos (Domínio/Privado/Público). |
| Lento/instável | UDP bloqueado; latência alta | Abrir UDP 3390; priorizar ligações via VPN/local; considerar QoS no router. |
| Dois routers em cascata | Duplo NAT | Encaminhar no router 1 → router 2 → PC B ou colocar router 2 em bridge. |
| Teste externo falha dentro da própria LAN | Router sem NAT loopback/reflexão | Testar via rede móvel ou usar IP interno/“split DNS” quando dentro da LAN. |
Quando usar porta externa ≠ interna
Se vários PCs precisarem de RDP por um único IP público, use portas externas distintas no router, mapeadas para portas internas específicas em cada máquina:
| PC | WAN Port | IP Interno | LAN Port | Cliente RDP |
|---|---|---|---|---|
| C | 3389 | 192.168.1.20 | 3389 | IP_Publico:3389 |
| B | 55123 | 192.168.1.30 | 3390 | IP_Publico:55123 (router redireciona → 192.168.1.30:3390) |
Assim, evita expor portas “tradicionais” e mantém uma matriz clara de encaminhamentos.
Boas práticas de segurança (recomendação forte)
- Evite expor RDP diretamente à Internet: prefira aceder via VPN (WireGuard, IPsec, OpenVPN) ou Gateway RDP próprio.
- Restrinja origens na Firewall/Router (listas de IP permitidos) e ative NLA.
- Porta externa única e alta (ex.: 55123) que o router envia para a 3390 interna — reduz “ruído” de varreduras automáticas.
- Políticas de palavra‑passe, bloqueio após tentativas falhadas e contas apenas necessárias no PC B.
- Atualizações de Windows e cópias de segurança regulares; antes de editar o registo, exporte a chave ou crie ponto de restauro.
- Auditoria: monitorize eventos de logon RDP e falhas em Visualizador de Eventos → Logs do Windows → Segurança.
- Desative 3389 se não for usada, para minimizar superfícies de ataque.
Checklist rápido
- Edição do Windows de B permite RDP inbound.
- RDP ativado com NLA e utilizador autorizado.
- Registo:
PortNumber=3390emRDP-Tcp. - TermService a escutar em 3390 (TCP e, se possível, UDP).
- Firewall de B com regras TCP/UDP para 3390.
- Router com encaminhamento correto (WAN→LAN 3390) e IP interno de B estático/reservado.
- Cliente RDP a usar
<destino>:3390. - Testes com
Test-NetConnectiona passar na LAN e pela Internet.
FAQ – Perguntas frequentes
Preciso de mexer em UDP?
O RDP funciona em TCP. Contudo, versões recentes usam também UDP na mesma porta para melhorar fluidez (áudio/vídeo, latência). Abra TCP e UDP na Firewall e no router para obter a melhor experiência.
Telnet não funciona no meu Windows. O que fazer?
Prefira Test-NetConnection (PowerShell), que já vem nativo. Exemplo: Test-NetConnection -ComputerName <IP> -Port 3390.
Consigo ligar na LAN mas não pela Internet. Porquê?
Geralmente é NAT/Port Forward em falta, IP interno que mudou, ou ISP com CGNAT. Confirme se o IP WAN do router é público (não inicia por 100.64.x.x, 10.x.x.x, 172.16‑31.x, 192.168.x.x). Se estiver atrás de CGNAT, peça IP público ao ISP ou use VPN.
Mudar a porta melhora a segurança?
Reduz tentativas automatizadas (security by obscurity), mas não substitui VPN, NLA, palavras‑passe fortes, restrição por IP e atualização do sistema.
Como reverto para 3389 rapidamente?
- No B, defina
PortNumber=3389e reinicie o TermService. - Ajuste/remoção das regras de firewall para 3390 e restaure as de 3389.
- Atualize o NAT no router se necessário.
- Conecte usando
<destino>:3389.
Exemplos de comandos úteis (copiar/colar)
# Mostrar porta RDP atual (PC B)
(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber).PortNumber
Abrir Firewall para nova porta (PC B)
New-NetFirewallRule -DisplayName "RDP TCP 3390" -Direction Inbound -Protocol TCP -LocalPort 3390 -Action Allow
New-NetFirewallRule -DisplayName "RDP UDP 3390" -Direction Inbound -Protocol UDP -LocalPort 3390 -Action Allow
Confirmar escuta local (PC B)
Get-NetTCPConnection -LocalPort 3390 -State Listen
Get-NetUDPEndpoint | Where-Object {$\_.LocalPort -eq 3390}
Testar de A para B (LAN)
Test-NetConnection -ComputerName 192.168.1.30 -Port 3390 -InformationLevel Detailed
Testar de A para B (Internet, substitua pelo IP público/DDNS)
Test-NetConnection -ComputerName exemplo.ddns.net -Port 3390
Conectar com MSTSC a usar porta personalizada (PC A)
mstsc /v\:exemplo.ddns.net:3390 /promptApêndice: diferenças de ambiente
- Windows Server (RDS): as mesmas validações aplicam; se usar Gateway RDP, a porta do serviço gateway difere e a exposição direta do host pode não ser necessária.
- Ambientes corporativos: GPOs podem forçar configurações. Coordene com a equipa de TI antes de alterar portas e firewall.
- Clientes móveis (Android/iOS/macOS): a sintaxe
:3390após o host permanece válida na maioria dos clientes oficiais.
Conclusão
Ao mudar a porta do RDP, tudo precisa estar alinhado: registo → serviço → firewall → NAT → cliente. Com os testes certos (local e remoto) e as regras coerentes (TCP/UDP), a ligação de A para B via 3390 torna‑se previsível, segura e estável. Para uso regular a partir de locais externos, considere fortemente uma VPN ou um gateway RDP e restrinja as origens por IP. E, sempre que mexer no registo, faça backup e planeie uma reversão rápida.
Tabela “tudo‑em‑um” do caso descrito
| Etapa | O que verificar | Comando/ação sugerida | Notas |
|---|---|---|---|
| Confirmar porta no registo | Porta aplicada | Get-ItemProperty ... PortNumber | Valor em decimal ou hex para 3390 |
| Serviço RDP escuta | 3390/TCP (e 3390/UDP) | Get-NetTCPConnection, Get-NetUDPEndpoint | Reinicie o TermService após mudanças |
| Conectividade A → B | Teste de porta | Test-NetConnection <IP-de-B> -Port 3390 | Telnet é alternativa; preferir TNC |
| Firewall do Windows | Regras para 3390 | New-NetFirewallRule ... | Aplicar nos perfis corretos |
| Cliente RDP | Formato do destino | <IP-ou-nome>:3390 | Guardar em .rdp se desejar |
| NAT (router) | WAN→LAN coerente | 3390 externa → 3390 interna (IP de B) | Considerar porta externa alta (ex.: 55123) |