Conectou à VPN do Windows Server 2019 (RRAS), recebeu IP, consegue pingar hosts internos, mas os drives mapeados ficam “Offline” e a Internet some? Este guia mostra, passo a passo, como corrigir com foco em DNS, rotas e NAT — e ainda traz um checklist final para você validar tudo.
Visão geral e sintomas
Ambiente típico: Windows Server 2019 rodando RRAS (servidor de Acesso Remoto), que também é Controlador de Domínio (DC) e DNS. Há port‑forwarding no firewall e no Windows Defender, o servidor possui apenas uma NIC, o pool de endereços da VPN é estático e o DNS do DC é fornecido ao cliente.
- Cliente VPN conecta, recebe IP do pool e consegue
pingem máquinas internas. - Drives mapeados aparecem Offline ou inacessíveis.
- Sem Internet enquanto a VPN está ativa (não abre sites nem responde
pingexterno). - Aplicativos externos (ex.: Sage, e‑mail) não funcionam durante a VPN.
Causa mais comum: combinação de roteamento/NAT e DNS no RRAS. Antes de mexer, defina o modelo de túnel que você quer:
Diagnóstico rápido: escolha do modo de túnel
| Opção | Quando usar | Como funciona | Internet do usuário | Complexidade | Segurança |
|---|---|---|---|---|---|
| Split tunneling | Home office, SaaS, banda limitada, simplicidade | Somente redes internas passam pela VPN; o restante sai pelo provedor local | Continua funcionando via gateway local | Baixa | Média (exige políticas no endpoint) |
| Túnel total | Ambientes regulados, inspeção/filtragem centralizada | Todo o tráfego do cliente vai pela VPN | Pela empresa (NAT/saída central) | Média/Alta (NAT + rotas de retorno) | Alta (controle central) |
Implementação — Split tunneling (Internet pelo provedor do usuário)
O que fazer
- No cliente Windows: em Propriedades da conexão VPN → IPv4 → Avançado, desmarque “Usar gateway padrão na rede remota”.
Automatize em perfis gerenciados:PowerShell Set-VpnConnection -Name "CorpVPN" -SplitTunneling $true -AllUserConnection - Rotas para redes internas: publique rotas específicas das sub‑redes da empresa via RRAS ou injete no cliente:
PowerShell Exemplo: rede interna 10.10.0.0/16 e DMZ 172.16.50.0/24 Add-VpnConnectionRoute -ConnectionName "CorpVPN" -DestinationPrefix "10.10.0.0/16" Add-VpnConnectionRoute -ConnectionName "CorpVPN" -DestinationPrefix "172.16.50.0/24"Essas rotas garantem que somente o tráfego destinado a essas redes siga para a VPN. - DNS interno apenas para o que for do domínio:
- Defina o sufixo DNS do domínio (ex.:
corp.local) no perfil da VPN. - Prefira FQDNs em acessos de arquivo e serviços, como
\\fileserver.corp.local\share. - No DNS do DC, configure Encaminhadores (Forwarders) para DNS público (ex.: do ISP,
1.1.1.1,8.8.8.8), permitindo que o cliente resolva nomes externos mesmo perguntando ao DC.
- Defina o sufixo DNS do domínio (ex.:
Por que funciona
O tráfego de Internet não passa pela VPN. Assim, você evita depender de NAT/saída centralizada no RRAS e elimina a causa dos “sem Internet” durante o túnel. O cliente acessa somente redes internas via rotas específicas, mantendo a usabilidade.
Observações de segurança
- Split tunneling pode conflitar com políticas mais rígidas (ex.: exigência de inspeção TLS, DLP). Use EDR, firewall de endpoint e regras de restrição de aplicativos para compensar.
- Se a empresa usa ZTNA/MDM, avalie per-app VPN para limitar aplicativos que usam o túnel.
Implementação — Túnel total (Internet pela empresa via RRAS)
Se a política exige que todo o tráfego passe pela rede corporativa, o RRAS precisa prover NAT e você deve criar rotas de retorno para o pool VPN.
Passo a passo essencial
- Ativar NAT no RRAS:
- Abra o console RRAS → IPv4 → NAT → Add Interface…
- Selecione a NIC “voltada à Internet” → marque Public interface e Enable NAT on this interface.
- Adicione a interface Internal do RRAS como Private interface.
- Rota de retorno no firewall/roteador da empresa: Adicione uma rota estática da sub‑rede do pool VPN apontando para o IP do RRAS na rede interna. Sem isso, os servidores internos responderão via gateway padrão (firewall), que não saberá voltar ao pool da VPN — quebrando SMB, RPC e afins.
# Exemplo (conceitual) no firewall perimetral ip route add 10.99.50.0/24 via 10.10.0.20 # 10.10.0.20 = IP do RRAS na LAN - DNS/Forwarders no DC:
- No serviço DNS do domínio, configure Forwarders para resolução externa (Internet).
- Entregue sufixo DNS da empresa aos clientes e use FQDN em todos os acessos.
- Firewall (Windows e perimetral): Garanta liberação do pool VPN → servidores internos para protocolos de autenticação e arquivos, e saída HTTP/HTTPS à Internet:
- SMB: TCP
445 - RPC: TCP
135+ portas dinâmicas (defina faixa estável, se possível) - Kerberos: TCP/UDP
88,464 - LDAP/LDAPS:
389/636 - DNS:
53 - HTTP/HTTPS (saída):
80/443
- SMB: TCP
- Confirmações no RRAS:
- Em Propriedades do servidor RRAS → IPv4, confira o Static address pool correto.
- (Opcional) Habilite broadcast name resolution para ajudar com nomes NetBIOS; o ideal, porém, é usar FQDN.
Nota importante:Port‑forwarding não substitui NAT. Regras de encaminhamento abrem portas de fora para dentro; para a saída à Internet dos clientes VPN, quem traduz é o NAT do RRAS (ou do firewall perimetral).
DNS que realmente funciona
Grande parte dos “consigo pingar IP, mas não acesso \\servidor\share” é DNS. Regras práticas:
- Entregue o DNS do DC aos clientes da VPN (e não DNS público).
- Configure Forwarders no DNS do DC para resolver nomes externos.
- Defina sufixo de DNS (ex.:
corp.local) e utilize FQDN (\\fileserver.corp.local\financeiro), evitando nomes curtos. - Após mudanças, peça ao usuário:
cmd ipconfig /flushdns ipconfig /registerdns
Acesso a compartilhamentos e drives mapeados
- Use FQDN em vez de nome curto:
\\fileserver.corp.local\share - Credenciais de domínio: verifique se o logon do usuário e as credenciais dos mapeamentos são de domínio (não locais).
- Offline Files / link lento (GPO):
- Se os drives ficam “Offline” assim que a VPN conecta, revise as políticas.
- Desabilite “Sempre offline” para SMB ou aumente o limiar de link lento para que a VPN não acione modo offline.
- Diretivas úteis (GPO):
- Configurações do Usuário → Políticas → Modelos Administrativos → Rede → Pastas Offline
- Configurar detecção de link lento (defina um valor coerente com a sua VPN)
- Não permitir que usuários trabalhem desconectados (se não usa CSC)
- Escopos de firewall nos servidores de arquivos: inclua explicitamente o pool VPN nas regras de SMB e RPC.
- (Opcional) DFS Namespaces: nomes estáveis (
\\dominio.local\dfs\departamento) tornam mapeamentos mais resilientes a mudanças de servidor.
Testes de linha de comando e como interpretar
Peça ao usuário os seguintes comandos e compare com os resultados esperados:
Endereçamento, DNS e gateway
cmd
ipconfig /all
- VPN Split: gateway padrão deve continuar sendo o do provedor local; DNS deve apontar para o DC.
- VPN Túnel total: rota
0.0.0.0/0deve apontar para a interface da VPN.
Tabela de rotas
cmd
route print
Verifique se:
- Split: existem rotas específicas para as sub‑redes internas via interface da VPN.
- Túnel total: a rota
0.0.0.0aponta para a interface da VPN e o next‑hop é o RRAS.
Trajeto para a Internet
cmd
tracert 8.8.8.8
- Se para no RRAS, falta NAT (túnel total) ou as rotas estão erradas.
- Se sai pela rede local do usuário (split), está correto.
Resolução de nomes externos
cmd
nslookup www.google.com
Se falhar enquanto aponta para o DNS do DC, ajuste Forwarders no DNS.
Diagnóstico rápido por sintomas
| Sintoma | Indício | Provável causa | Correção |
|---|---|---|---|
| Sem Internet no túnel total | tracert para no RRAS | NAT não habilitado no RRAS | Habilitar NAT e revisar rotas de retorno |
| Drives mapeados “Offline” | FQDN falha, IP responde | DNS e/ou GPO de link lento | Configurar Forwarders, sufixos e GPO |
| Apps internos ok, externos não | Somente sites não abrem | Sem saída HTTP/HTTPS | Liberar 80/443 e NAT (túnel total) |
| Ping interno ok, SMB falha | Hostname resolve, porta 445 não abre | Firewall/escopo sem pool da VPN | Incluir range VPN nas regras de SMB/RPC |
Firewall: portas mínimas e escopos recomendados
| Serviço | Porta/Protocolo | Direção | Observação |
|---|---|---|---|
| DNS | 53/TCP, 53/UDP | Cliente → DC | Resolução interna e encaminhamento externo |
| Kerberos | 88/TCP,UDP e 464/TCP,UDP | Cliente ↔ DC | Autenticação de domínio |
| LDAP/LDAPS | 389/TCP,UDP; 636/TCP | Cliente ↔ DC | Consulta de diretório |
| SMB | 445/TCP | Cliente → Servidor de arquivos | Acesso a compartilhamentos |
| RPC Endpoint Mapper | 135/TCP | Cliente → Servidores | Necessário para vários serviços AD/FS/Backup |
| RPC Dinâmico | Faixa dinâmica configurada | Cliente ↔ Servidores | Estabilize a faixa conforme política |
| HTTP/HTTPS | 80/TCP, 443/TCP | Cliente → Internet | Requer NAT (túnel total) |
Dica: Crie grupos/objetos de rede com o pool VPN e reutilize em todas as regras; evite “Any” por segurança.
Erros comuns e como evitar
- Confiar só em port‑forwarding e esquecer NAT: clientes saem sem tradução e perdem Internet no túnel total.
- Pool VPN sem rota de retorno: servidores internos respondem via gateway padrão, “perdendo” pacotes do cliente.
- DNS público no cliente: nomes internos não resolvem; use o DNS do DC com Forwarders.
- Escopos de firewall errados: regra válida apenas para “sub‑rede local”, exclui o pool VPN.
- Uma NIC para tudo no DC/RRAS: funciona, mas aumenta a complexidade e a superfície de ataque.
Boas práticas de arquitetura
- RRAS no DC com 1 NIC não é o ideal. Prefira servidor dedicado (de preferência com 2 NICs) ou um appliance de firewall/VPN.
- Separe funções: AD/DNS numa VM/host; RRAS/NPS em outra; firewall faz o NAT/inspeção.
- Defina tabela de redes oficial (CIDR, propósito, quem anuncia, quem recebe).
- Documente faixas RPC dinâmicas e padronize nos servidores/estações para evitar surpresas.
- Monitore com NetFlow/logs de firewall e eventos do RRAS (conexão, autenticação, queda).
Procedimentos “mão na massa”
RRAS: conferindo o pool e a interface
- Console RRAS → clique com o botão direito no servidor → Properties → guia IPv4.
- Em Static address pool, confira a sub‑rede reservada aos clientes VPN (ex.:
10.99.50.0/24). - Em IPv4 → NAT, verifique:
- NIC “Internet” como Public interface com Enable NAT.
- Interface Internal marcada como Private.
Cliente: habilitando split e rotas
PowerShell
Habilitar split tunneling no perfil "CorpVPN"
Set-VpnConnection -Name "CorpVPN" -SplitTunneling $true -AllUserConnection
Rotas específicas para redes internas
Add-VpnConnectionRoute -ConnectionName "CorpVPN" -DestinationPrefix "10.10.0.0/16"
Add-VpnConnectionRoute -ConnectionName "CorpVPN" -DestinationPrefix "172.16.50.0/24"
(Opcional) Sufixo de pesquisa DNS
Set-DnsClientGlobalSetting -SuffixSearchList @("corp.local","ad.corp.local") Validando conectividade SMB
cmd
ping fileserver.corp.local
nltest /dsgetdc:corp.local
net use * /delete /y
net use Z: \\fileserver.corp.local\financeiro /user:CORP\usuario
Checklist final (objetivo)
| # | Item | O que verificar | Status |
|---|---|---|---|
| 1 | Escolha do modo | Definiu Split ou Túnel total conforme a política? | ☐ |
| 2 | Split | Desmarcou “Usar gateway padrão” e publicou rotas específicas? | ☐ |
| 3 | Túnel total | Habilitou NAT no RRAS e a rota de retorno do pool VPN no firewall/roteador? | ☐ |
| 4 | DNS do DC | Clientes usam o DNS do domínio e o DC tem Forwarders para Internet? | ☐ |
| 5 | Firewalls | Portas SMB/RPC/Kerberos/LDAP/DNS liberadas e escopos incluem o pool VPN? | ☐ |
| 6 | Drives | Uso de FQDN, credenciais de domínio, GPO de Offline Files ajustada? | ☐ |
| 7 | Testes | route print, tracert, nslookup, ipconfig /all batendo com o modo escolhido? | ☐ |
FAQ rápida
“Tenho só uma NIC no RRAS. É obrigatório ter duas?”
Não é obrigatório, mas duas NICs simplificam NAT/roteamento e melhoram a segmentação de segurança. Com uma NIC funciona, mas requer mais cuidado com regras e rotas.
“Preciso de port‑forwarding para a Internet do cliente VPN?”
Não. Para a saída à Internet, você precisa de NAT (no RRAS ou no firewall). Port‑forwarding serve principalmente para expor serviços internos para fora.
“No split tunneling, por que meus drives somem?”
Geralmente por resolução de nomes: o cliente continua com Internet local e usa o DNS do DC para nomes internos. Se o DC não encaminha nomes externos ou o cliente não tem rotas para as sub‑redes corretas, mapeamentos falham.
“Consigo pingar o IP do servidor de arquivos, mas o caminho \\nome\share não abre.”
É DNS. Ajuste sufixo e use FQDN; valide nslookup e verifique os Forwarders no DC.
“Quais portas mínimas liberar para Active Directory e arquivos?”
DNS 53, Kerberos 88/464, LDAP 389/636, RPC 135 + dinâmicas e SMB 445. Inclua o range do pool VPN nos escopos.
Conclusão
Os sintomas “VPN conecta, mas sem Internet e sem compartilhamentos” no RRAS de 2019 quase sempre apontam para uma decisão não aplicada entre split tunneling e túnel total, com ajustes de NAT, rotas de retorno e DNS. Ao seguir o roteiro acima — definindo o modo, configurando rotas, habilitando NAT quando necessário, refinando o DNS e garantindo portas/escopos no firewall — tanto a navegação na Internet quanto o acesso a pastas e serviços internos tendem a voltar ao normal. Mantenha o foco em FQDN, valide com as ferramentas de linha de comando e use o checklist para evitar regressões.