VPN no Windows Server 2019 sem Internet e sem acesso a recursos internos: diagnóstico e correção (RRAS, NAT, DNS e split tunneling)

Conectou-se à VPN do Windows Server 2019, consegue abrir RDP, mas Internet, e‑mail, unidades mapeadas e bases de dados não funcionam? Este guia prático mostra como diagnosticar e corrigir RRAS, NAT, DNS e rotas para recuperar o acesso completo com segurança.

Índice

Visão geral do cenário e sintomas

É comum configurar um controlador de domínio (Windows Server 2019) que também atua como Servidor de Acesso Remoto (RRAS) e, após uma conexão VPN bem‑sucedida, perceber que:

as unidades mapeadas aparecem “desligadas” (ícone vermelho);
SQL Server e aplicações como Sage não respondem;
não há navegação na Internet nem envio/receção de e‑mail enquanto a VPN está ativa;
parece estar “dentro da LAN”, mas sem passagem para a Internet.

Na prática, isso indica problemas de DNS, roteamento e/ou NAT, possivelmente combinados com políticas de firewall.

Por que isso acontece

Ao ligar à VPN, o cliente recebe um endereço IP de uma pool do RRAS e, dependendo da política, pode enviar:

Túnel total (sem split tunneling): todo o tráfego sai pelo servidor RRAS. Este cenário exige que o servidor faça NAT para a Internet.
Split tunneling: apenas o tráfego destinado a redes internas passa pela VPN; o restante usa o gateway local do utilizador. Exige rotas e DNS bem definidos para os recursos internos.

Se o NAT faltar no primeiro caso, ou se as rotas/DNS estiverem incorretos no segundo, surgem exatamente os sintomas descritos.

Diagnóstico rápido (fluxo sugerido)

Confirmar a arquitetura desejada: túnel total ou split tunneling.
Rever RRAS: endereço pool, NAT, encaminhamento IPv4 e interface pública interna/externa corretas.
Validar DNS: clientes VPN usam DNS interno e o DNS interno tem forwarders para resolver nomes públicos.
Testar rotas: ver se o cliente tem rota para a LAN e rota padrão coerente com a decisão do passo 1.
Verificar firewall: portas SMB, RDP, SQL e da aplicação (Sage) liberadas para a pool da VPN.
Executar testes de conectividade: ping, tracert, nslookup e Test-NetConnection.
Analisar registos: Event Viewer (RRAS, NPS, DNS) e logs do cliente VPN.

Decidindo entre túnel total e split tunneling

Modelo	Vantagens	Riscos/Pontos de atenção	Quando usar
Túnel total	Gestão centralizada de segurança; políticas uniformes; inspeção de tráfego na borda.	Consome banda do servidor; exige NAT no RRAS; latência maior para sites públicos.	Ambientes pequenos/médios ou que exigem inspeção e registo do tráfego.
Split tunneling	Menos carga no RRAS; melhor experiência para tráfego público.	Exige rotas e DNS bem configurados; risco de dual‑homing se o dispositivo não for gerido.	Quando a ligação de Internet do servidor é limitada ou os utilizadores precisam de tráfego público local.

Configuração essencial no servidor RRAS

Endereçamento e encaminhamento

No Routing and Remote Access, abra as Propriedades do servidor.
Em IPv4:
- Ative Encaminhamento IPv4 (se ainda não estiver ativo).
- Defina a atribuição de endereços para a VPN:
  - Pool estático (ex.: 10.10.10.10–10.10.10.200) ou DHCP.
  - Certifique‑se de que esta pool não colide com a LAN.
- Especifique DNS interno para os clientes (normalmente o próprio DC).

Ativar NAT quando usar túnel total

No RRAS, expanda IPv4 > NAT.
Clique com o botão direito em NAT > Nova interface e selecione a interface conectada à Internet.
Marque Interface pública conectada à Internet e ative Traduzir endereços de rede (NAT).
Na interface interna (LAN), defina como Interface privada conectada à rede interna.
Opcional: em Serviços e Portas do NAT, publique serviços internos se necessário.

Sem essa configuração, clientes em túnel total não terão saída para a Internet.

Configurar DNS interno com saída para a Internet

No servidor DNS (o DC), abra o DNS Manager.
Em Propriedades do servidor > Encaminhadores, defina forwarders para servidores DNS públicos confiáveis.
Confirme que a resolução externa funciona no próprio servidor: nslookup microsoft.com nslookup www.gov.pt

Com isso, os clientes VPN que usam o DNS interno conseguirão resolver nomes externos.

Verificações de acesso a partilhas e bases de dados

Permissões e firewall para SMB

Confirme que as regras File and Printer Sharing (SMB‑In) estão ativas no servidor de ficheiros e permitem a origem da pool da VPN.
Valide permissões NTFS/SMB do utilizador/grupos de domínio.

SQL Server

Confirme que o SQL escuta em TCP (porta padrão 1433) e que a firewall permite acesso a partir da pool da VPN.
Teste do cliente VPN: sqlcmd -S SERVIDORSQL,1433 -E -Q "SELECT 1"

Sage e outros ERPs

As portas variam por versão/produto. Se não tiver a documentação, identifique dinamicamente as portas em uso no servidor de aplicação:

netstat -abno | findstr /i "sage"
Get-NetTCPConnection | Where-Object {$_.State -eq "Listen"} | Sort-Object LocalPort

Abra as portas identificadas apenas para o intervalo IP da VPN.

Rever firewall e rotas

Serviço	Portas mais comuns	Origem/Destino	Observações
Navegação Web	80 (HTTP), 443 (HTTPS)	Cliente VPN → Internet	Exige NAT no RRAS se túnel total.
E‑mail cliente	25, 465, 587 (envio); 993, 995 (IMAP/POP TLS)	Cliente VPN → Internet/Servidor de e‑mail	Depende do seu serviço de e‑mail.
SMB	445/TCP	Cliente VPN ↔ Servidor de ficheiros	Permitir a pool da VPN.
SQL Server	1433/TCP (padrão)	Cliente VPN ↔ SQL	Confirmar porta real e Browser (se usado).
RDP	3389/TCP	Cliente VPN ↔ Servidor	Evite expor na Internet; use só via VPN.

Quanto às rotas, assegure que existe caminho bidirecional entre a pool da VPN e as sub‑redes da LAN. Se a LAN usa routers de terceiros, adicione rotas estáticas apontando a next‑hop para o IP interno do RRAS.

Configuração no cliente Windows

Ativar ou desativar gateway da rede remota

Se optar por split tunneling:

Abrir Propriedades da ligação VPN > Rede > TCP/IPv4 > Avançadas.
Desmarcar Usar gateway predefinido na rede remota.

Em PowerShell (admin):

Set-VpnConnection -Name "MinhaVPN" -SplitTunneling $true

Se for túnel total, mantenha o gateway remoto ativo e garanta que o RRAS está a fazer NAT.

Rotas e DNS em split tunneling

Adicione rotas para as sub‑redes internas (ex.: 192.168.1.0/24): route add 192.168.1.0 mask 255.255.255.0 <IPdaVPN> metric 1
Defina o Sufixo DNS desta ligação (ex.: empresa.local) e a lista de pesquisa de sufixos, garantindo resolução por nome curto.

Testes de conectividade que economizam horas

DNS

nslookup fileserver
nslookup fileserver.empresa.local
nslookup www.bing.com

Se o primeiro falhar e o segundo funcionar, falta sufixo. Se ambos falharem, o cliente não está a usar o DNS interno. Se apenas o terceiro falhar, o DNS interno não tem forwarders a funcionar.

Roteamento

ipconfig /all
route print
tracert 8.8.8.8
Test-NetConnection -ComputerName 8.8.8.8 -InformationLevel Detailed

No túnel total, a rota padrão (0.0.0.0/0) deve apontar para a VPN; no split, deve permanecer no gateway local.

Serviços internos

ping fileserver
Test-NetConnection fileserver -Port 445
Test-NetConnection servidoresql -Port 1433

Se o ping não responde, verifique firewall ICMP (opcional). O que importa é o teste de porta (SMB/SQL).

Logs que realmente ajudam

Event Viewer > Custom Views > Server Roles > Remote Access: erros de autenticação, DHCP, IPv4 forwarding.
RRAS > Logging: aumente a verbosidade temporariamente para capturar falhas.
DNS Server: erros de encaminhadores, tempo‑limite em consultas recursivas.
Cliente VPN: rasphone / RasMan no Event Viewer, além do relatório da ligação VPN.

Correção guiada passo a passo

Escolha e fixe a política de túnel

Decida entre túnel total e split tunneling com base na tabela anterior.
Documente a decisão e aplique de forma uniforme em todos os clientes (GPO, script PowerShell, MDM).

Se for túnel total

Certifique‑se de que a rota padrão dos clientes vai para a VPN (ver route print).
No RRAS, ative NAT na interface pública conforme descrito.
Teste Internet a partir do cliente VPN: tracert 1.1.1.1 deve sair pelo RRAS.
Confirme DNS interno com forwarders para navegação por nomes.

Se for split tunneling

Desative “Usar gateway predefinido na rede remota” ou aplique Set-VpnConnection -SplitTunneling $true.
Garanta rotas para todas as sub‑redes internas necessárias (via VPN).
Configure o DNS para resolver apenas domínios internos pela VPN e use DNS público/local para resto (política de DNS por sufixo).

Ajuste de DNS

Clientes VPN devem apontar para o DNS interno (o DC) para recursos internos.
O DNS interno deve ter forwarders para a Internet, ou usar root hints.
Considere definir o sufixo DNS da ligação VPN para resolver nomes curtos (ex.: fileserver).

Permissões e políticas

Verifique ACLs nas partilhas (NTFS/SMB) e grupos de segurança do AD.
Garanta que regras de firewall no SQL e servidores de aplicação permitem origem da pool da VPN.

Checklist de sintomas vs. causas prováveis

Sintoma	Causas prováveis	Como confirmar	Correção típica
Sem Internet quando a VPN está ativa (túnel total)	NAT ausente no RRAS; interface pública errada; DNS sem encaminhadores	`tracert 8.8.8.8` para ver o caminho; `nslookup` falha externo	Ativar NAT na interface Internet; configurar forwarders no DNS
Unidades mapeadas com ícone vermelho	DNS interno não usado; firewall SMB; rota para a LAN faltando	`Test-NetConnection fileserver -Port 445`	Ajustar DNS da VPN; abrir SMB para a pool da VPN; adicionar rotas
SQL/Sage não conecta	Portas não liberadas; endereço de escuta incorreto; bloqueio por IP	`Test-NetConnection servidoresql -Port 1433`; `netstat -abno`	Abrir portas; fixar IP/porta do serviço; permitir pool da VPN
Sem e‑mail/navegação em split tunneling	Gateway remoto ainda ativo; rota padrão desviada para a VPN	`route print`; opção “gateway remoto” marcada	Desativar “Usar gateway predefinido…”; garantir rotas específicas

Modelos práticos de configuração

Ambiente compacto (recomendado para começar)

Usar túnel total.
No RRAS:
- Definir pool de IP para a VPN (ex.: 10.10.10.0/24).
- Ativar NAT na interface “Internet”.
- Marcar a interface LAN como privada.
No DNS:
- Definir forwarders para a Internet.
Nos clientes: nenhuma mudança especial; a rota padrão irá pela VPN.

Ambiente com banda limitada no servidor

Ativar split tunneling no perfil VPN do cliente.
Empurrar rotas apenas para as sub‑redes internas necessárias.
Configurar política de DNS (GPO/MDM) para resolver apenas domínios internos via DNS corporativo.

Exemplos de comandos úteis

No servidor

:: testar DNS para fora
nslookup www.contoso.com

\:: listar rotas do servidor
route print

\:: verificar portas a escutar (inclui SQL/Sage)
netstat -abno | more

No cliente

:: ver detalhes de IP e DNS
ipconfig /all

\:: rotas
route print

\:: testes de porta
Test-NetConnection fileserver -Port 445
Test-NetConnection servidoresql -Port 1433

\:: split tunneling (requer nome exato da ligação)
Set-VpnConnection -Name "MinhaVPN" -SplitTunneling \$true

Erros comuns e como evitá‑los

Esquecer o NAT no RRAS quando se usa túnel total. Resultado: sem Internet na VPN.
Pool de endereços da VPN dentro da mesma sub‑rede da LAN. Causa conflitos e rotas ambíguas.
DNS público no cliente VPN para resolver hosts internos. Evite; use o DNS do domínio.
Regras de firewall limitadas por faixa IP que não incluem a pool da VPN.
Gateway remoto ativo em split tunneling. O tráfego público continua a tentar sair pelo RRAS.

Segurança: o que considerar

Túnel total simplifica o controlo, facilita inspeção e registo central, e reduz a superfície de ataque no dispositivo remoto.
Split tunneling pode ser seguro se combinado com:
- dispositivos geridos (EDR/antivírus, hardening);
- políticas de firewall local bloqueando tráfego lateral não solicitado;
- rotas estritas apenas para o necessário.

Perguntas rápidas

As unidades mapeadas aparecem com X vermelho, mas abrem ao clicar. É problema?
É tipicamente um timing de autenticação ou resolução de nome. Garanta que o DNS interno é usado pela VPN e reconfigure os mapeamentos via GPO com a opção “Conectar novamente” e “Executar no contexto do utilizador”.

Preciso de WINS?
Normalmente não. DNS interno com sufixos corretos é suficiente. WINS só se tiver aplicações muito antigas que dependem de NetBIOS.

Posso usar DHCP para a pool de VPN?
Sim, mas certifique‑se de que o escopo está separado da LAN e que o RRAS consegue alcançar o DHCP.

Resumo acionável

Decida a política de túnel e aplique de forma consistente.
Garanta DNS interno nos clientes VPN e forwarders no DNS corporativo.
Se for túnel total: ative NAT no RRAS e verifique a rota padrão dos clientes.
Se for split tunneling: desative o gateway remoto, adicione rotas para as redes internas e ajuste sufixos DNS.
Abra apenas as portas necessárias para a pool da VPN e confirme com Test-NetConnection.
Use Event Viewer e logs do RRAS para fechar o diagnóstico.

Exemplo de configuração completa em ambiente pequeno

RRAS: pool 10.10.10.50–10.10.10.200; interface Internet com NAT ativo; interface LAN privada; encaminhamento IPv4 ativo.
DNS (no DC/RRAS): forwarders definidos; zona interna empresa.local saudável.
Firewall:
- SMB (445/TCP) liberado para 10.10.10.0/24 nos servidores de ficheiros;
- SQL (1433/TCP) liberado para 10.10.10.0/24 no servidor SQL.
Clientes: túnel total; nenhuma alteração local; validar com tracert e nslookup.

Conclusão

Quase todos os casos de VPN “sem Internet e sem recursos internos” no Windows Server 2019 convergem para três pilares: DNS correto, rotas coerentes e NAT (ou split tunneling bem aplicado). Seguindo o roteiro acima — verificar RRAS, ativar NAT quando apropriado, ajustar DNS/forwarders, abrir portas e confirmar rotas — o acesso às unidades mapeadas, às bases de dados SQL/Sage e à navegação na Internet volta a funcionar de forma previsível e segura.