MENU
  1. Início
  2. Windows
  3. Windows Server
  4. Falha de Conexão VPN RRAS/NPS: por que o PPTP cai e como migrar para L2TP/IPsec no Windows Server e firewall CentOS

Falha de Conexão VPN RRAS/NPS: por que o PPTP cai e como migrar para L2TP/IPsec no Windows Server e firewall CentOS

Windows Server

VPN conecta internamente, mas cai pela Internet? Em ambientes com RRAS + NPS, o culpado costuma ser o protocolo errado passando (ou não) pelo firewall. Entenda por que o PPTP falha, como diagnosticar rapidamente e como migrar com segurança para L2TP/IPsec, mantendo compatibilidade e criptografia forte.

Índice

Contexto e sintomas observados

Um servidor Windows com RRAS (Routing and Remote Access Service) e NPS (Network Policy Server) foi publicado na Internet para aceitar conexões PPTP. Dentro da rede local, a conexão funciona; externamente, usuários recebem a mensagem em inglês “the network connection between your computer and the VPN server was interrupted…”. Já estavam abertos no firewall de borda (Linux CentOS) os serviços do RADIUS (UDP 1812/1813 e, por legado, 1645/1646), e numa tentativa de correção liberaram também UDP 1701/500/4500. Ainda assim, o túnel PPTP continuava caindo.

Esse cenário é clássico quando se publica PPTP atrás de NAT/firewall que não está a encaminhar o GRE (protocolo IP 47). O handshake começa, o canal de controle responde, mas a sessão de dados não se estabelece — e o cliente interpreta como “conexão interrompida”.

Por que o PPTP falha fora da rede

O PPTP depende de dois elementos:

  • TCP 1723 para o canal de controle.
  • GRE (Generic Routing Encapsulation), que é o protocolo IP 47 (não é uma porta!), para transportar os dados do túnel.

Se o GRE não atravessa o firewall/NAT, o cliente até “fala” com o servidor na 1723/TCP e chega a autenticar, mas os pacotes de dados do túnel não conseguem circular. Resultado: queda imediata, geralmente com a mensagem apresentada anteriormente. Em appliances, isso aparece como ausência de pass-through para PPTP; em Linux com iptables/nftables, faltam os módulos de acompanhamento e tradução específicos para PPTP.

Além disso, muitas implementações modernas de firewall stateful deixaram de ativar automaticamente helpers de aplicação. Em kernels Linux recentes, é comum precisar carregar módulos e/ou associar explicitamente o helper PPTP à sessão da 1723/TCP para que o tráfego GRE seja acompanhado e traduzido corretamente.

Mapa de portas e protocolos por tecnologia

TecnologiaPortas/Protocolos exigidos na bordaNotas rápidas
PPTPTCP 1723 e GRE (IP 47)Forte dependência de GRE. Problemático atrás de NATs rígidos. Sem criptografia robusta.
L2TP/IPsecUDP 500 (IKE), UDP 4500 (NAT‑T), UDP 1701 (L2TP) e ESP (IP 50)Criptografia forte. Com NAT, dados trafegam encapsulados em UDP 4500 (NAT‑T).
IKEv2UDP 500 e UDP 4500; usa ESP (IP 50)Mais moderno e resiliente a mudanças de rede; ótimo em mobilidade.
SSTPTCP 443Funciona bem por trás de proxies e firewalls restritivos; encapsula em TLS.
RADIUSUDP 1812/1813 (ou 1645/1646)Somente entre RRAS e NPS (rede interna). Não publique na Internet.

Conclusão de causa

A causa principal no caso descrito é a falta de encaminhamento do GRE (IP 47). Sem ele, o PPTP inicia o controle via TCP 1723, mas o túnel de dados não se sustenta e cai. Abrir portas de RADIUS ou mesmo UDP 500/4500/1701 não resolve PPTP — são protocolos de outras VPNs.

Opções de correção

Dependendo de requisitos e prazos, há três caminhos práticos:

OpçãoAção técnicaObservações
Manter PPTPEncaminhar TCP 1723 e o protocolo GRE 47, ou posicionar o servidor em uma DMZ one‑to‑one NAT.Em firewalls com iptables/nftables, habilitar os módulos nfconntrackpptp e nfnat_pptp. Segurança fraca (MS‑CHAP v2 vulnerável). Não recomendado.
Migrar para L2TP/IPsecAbrir UDP 500 (IKE), UDP 4500 (NAT‑T), UDP 1701 (L2TP) e permitir ESP (IP 50).Evita GRE, oferece criptografia forte e alta compatibilidade em Windows, macOS, iOS e Android. Foi a solução que corrigiu o caso real relatado.
Optar por IKEv2 ou SSTPIKEv2 usa as mesmas UDP 500/4500; SSTP utiliza TCP 443.Protocolos modernos e amigáveis a NAT; desempenho e segurança superiores ao PPTP. SSTP atravessa redes muito restritivas.

Passo a passo de migração segura para L2TP/IPsec no RRAS

Se você ainda está em PPTP, a migração para L2TP/IPsec no Windows Server é direta e traz ganhos imediatos de segurança e confiabilidade.

Pré‑requisitos e checklist

  • Windows Server com a função Remote Access instalada e o serviço RRAS configurado para VPN.
  • Servidor NPS (no mesmo host do RRAS ou separado) com políticas de conexão definidas.
  • Chave pré‑compartilhada (Pre‑Shared Key, PSK) complexa ou certificados válidos para IPsec. Em ambientes corporativos, prefira certificados.
  • Acesso ao firewall de borda (CentOS com iptables/nftables ou firewalld) para publicar as portas corretas.
  • Escopo de IP para clientes VPN (pool de endereços no RRAS ou DHCP).

Configuração no RRAS

  1. No Routing and Remote Access, abra as propriedades do servidor RRAS.
  2. Na guia Security:
    • Em Authentication Methods, mantenha EAP‑MSCHAPv2 e MS‑CHAPv2. Desabilite PAP/CHAP legados.
    • Em IPsec Settings, defina a chave pré‑compartilhada (PSK) ou selecione o certificado de máquina para L2TP/IPsec.
  3. Em Ports, verifique se há L2TP habilitado com quantidade suficiente de portas virtuais.
  4. Em IPv4, configure o Static address pool ou a integração com DHCP, e informe DNS/WINS e o sufixo DNS da sua organização.

Revisão das políticas no NPS

  • Em Policies > Network Policies, edite a regra que atende os clientes VPN:
    • Em Conditions, confirme os grupos de usuários e o tipo de conexão NAS‑Port‑Type: Virtual (VPN).
    • Em Constraints > Authentication Methods, permita MS‑CHAPv2 e/ou EAP‑MSCHAPv2. Em L2TP/IPsec, a autenticação IPsec é feita por PSK/certificado; o usuário autentica em MS‑CHAPv2 por cima do L2TP.
    • Em Settings, se necessário, aplique atributos como Framed‑IP‑Address, DNS‑Server e Class.
  • Em Accounting, ative o log para auditoria (arquivo ou SQL, conforme a política da empresa).

Abertura do firewall do Windows

No servidor RRAS, as regras do Windows Defender Firewall geralmente são criadas com a função de Acesso Remoto. Ainda assim, confirme:

  • Entrada: UDP 500, UDP 4500, UDP 1701 e Protocolo 50 (ESP).
  • Saída: permitir resposta correspondente (stateful).

Publicação no firewall CentOS

A seguir, exemplos práticos para os três cenários comuns no CentOS. Ajuste <WANIF>, <LANIF> e <RRAS_IP> ao seu ambiente.

Usando firewalld

# Portas UDP e L2TP
firewall-cmd --permanent --add-port=500/udp
firewall-cmd --permanent --add-port=4500/udp
firewall-cmd --permanent --add-port=1701/udp

Permitir ESP (IP protocolo 50) via regra rica

firewall-cmd --permanent --add-rich-rule='rule protocol value="50" accept'

Encaminhar para o RRAS (se o CentOS faz NAT)

(em muitos cenários, o DNAT é feito no próprio firewall - valide sua topologia)

Exemplo de redirecionamento (ajuste zona/rede conforme seu desenho)

Para firewalld com forwarding já habilitado entre zonas, bastam as permissões acima.

firewall-cmd --reload

Usando iptables

# Encaminhar IKE, NAT-T e L2TP para o RRAS
iptables -t nat -A PREROUTING -i <WANIF> -p udp --dport 500  -j DNAT --to-destination <RRASIP>
iptables -t nat -A PREROUTING -i <WANIF> -p udp --dport 4500 -j DNAT --to-destination <RRASIP>
iptables -t nat -A PREROUTING -i <WANIF> -p udp --dport 1701 -j DNAT --to-destination <RRASIP>

Permitir encaminhamento

iptables -A FORWARD -p udp -d \ --dport 500  -j ACCEPT
iptables -A FORWARD -p udp -d \ --dport 4500 -j ACCEPT
iptables -A FORWARD -p udp -d \ --dport 1701 -j ACCEPT

Permitir ESP (IP protocolo 50)

iptables -A FORWARD -p 50 -d \ -j ACCEPT

Se usar MASQUERADE para clientes VPN saírem pela Internet via este firewall:

(substitua 10.99.0.0/24 pelo pool VPN configurado no RRAS)

iptables -t nat -A POSTROUTING -s 10.99.0.0/24 -o \ -j MASQUERADE

Usando nftables

table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
    udp dport {500,4500,1701} dnat to &lt;RRAS_IP&gt;
  }
  chain postrouting {
    type nat hook postrouting priority 100;
    # MASQUERADE opcional para tráfego de saída de clientes VPN
    ip saddr 10.99.0.0/24 oif &lt;WAN_IF&gt; masquerade
  }
}
table ip filter {
  chain forward {
    type filter hook forward priority 0;
    ip daddr &lt;RRAS_IP&gt; udp dport {500,4500,1701} accept
    ip daddr &lt;RRAS_IP&gt; meta l4proto 50 accept   # ESP (IP 50)
    ct state established,related accept
  }
}

Nota sobre o UDP 1701 e o ESP em NAT

Em cenários com NAT‑T, o tráfego L2TP e ESP ficam encapsulados em UDP 4500, reduzindo atritos com NAT. Ainda assim, recomenda‑se publicar também o UDP 1701 para clientes que eventualmente não usem NAT (ou em firewalls que esperam ver o 1701). O ESP (IP 50) deve ser permitido; na prática, quando o NAT‑T entra em ação, quase todo o fluxo de dados transita por UDP 4500.

Quando o problema é PPTP e você precisa manter temporariamente

Se não puder migrar imediatamente, assegure no CentOS:

# Carregar módulos de acompanhamento/tradução PPTP
modprobe nfconntrackpptp
modprobe nfnatpptp

Em kernels novos, pode ser preciso ativar o helper explicitamente:

(habilita atribuição automática de helpers; teste e avalie segurança)

sysctl -w net.netfilter.nf\conntrack\helper=1

Ou associe o helper na 1723/TCP (tabela raw)

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Encaminhar 1723/TCP e GRE (IP 47)

iptables -t nat -A PREROUTING -i \ -p tcp --dport 1723 -j DNAT --to \
iptables -A FORWARD -p tcp -d \ --dport 1723 -j ACCEPT
iptables -A FORWARD -p 47 -d \ -j ACCEPT   # GRE

Importante: PPTP é considerado inseguro. Planeje a migração o quanto antes.

Testes rápidos de conectividade

No cliente Windows

# Verificar resposta das portas na Internet
Test-NetConnection vpn.exemplo.com -Port 500  -InformationLevel Detailed
Test-NetConnection vpn.exemplo.com -Port 4500 -InformationLevel Detailed
Test-NetConnection vpn.exemplo.com -Port 1701 -InformationLevel Detailed

Após conectar, conferir IP, DNS e rotas

ipconfig /all
route print

No firewall CentOS

# Ver o tráfego chegando
tcpdump -ni <WAN_IF> udp port 500 or udp port 4500 or udp port 1701 or proto 50

Se estiver depurando PPTP:

tcpdump -ni \ tcp port 1723 or proto 47

Diagnóstico por códigos de erro comuns

Erro do clienteInterpretação provávelComo agir
Mensagem genérica “the network connection… was interrupted” (PPTP)Controle em 1723/TCP respondeu, mas GRE (IP 47) não passouLiberar GRE e ativar helpers PPTP; ou migrar para L2TP/IPsec
809 (L2TP/IPsec)Bloqueio em UDP 500/4500 ou problema de NAT/ESPAbrir portas, confirmar NAT‑T ativo e encaminhamento correto
789 (L2TP/IPsec)Falha na camada de segurança do L2TP/IPsec (PSK/certificado)Verificar PSK/certificado; confirmar IKE/SA no servidor
691 (qualquer)Credenciais inválidas ou política NPS negou acessoRevisar políticas no NPS, pertencer a grupos corretos
812 (qualquer)Política de rede impede a conexãoAjustar condições/constraints da Network Policy

Logs e onde olhar no Windows Server

  • Event Viewer:
    • Applications and Services Logs > Microsoft > Windows > RemoteAccess
    • … > RasMan
    • … > IKEEXT
    • … > PolicyAgent
    • System (para drivers e rede)
  • RRAS: nas propriedades do servidor, guia Logging, habilite Log additional Routing and Remote Access information temporariamente.
  • NPS: ative Accounting e verifique os arquivos em C:\Windows\System32\LogFiles; eles mostram a razão de aceitação/negação.
  • PowerShell para SAs IPsec: Get-NetIPsecMainModeSA Get-NetIPsecQuickModeSA

Roteamento, DNS e pós‑conexão

Mesmo com portas corretas, clientes podem conectar e “não abrir nada”. Valide:

  • Pool de IP: sem sobreposição com a rede do usuário (evite usar 192.168.0.0/24 se muitos clientes também usam).
  • Split‑tunneling vs forçar todo o tráfego: escolha consciente e de acordo com a política de segurança.
  • DNS interno: entregue IP dos controladores de domínio/servidores internos via RRAS ou NPS; defina o sufixo DNS.
  • Rotas estáticas no RRAS se a rede interna tem múltiplos segmentos.
  • MTU/MSS: se houver perda em sites específicos, teste MSS clamping no caminho de saída.

Boas práticas e dicas essenciais

  • Evite PPTP: vulnerável (MS‑CHAP v2). Prefira L2TP/IPsec, IKEv2 ou SSTP.
  • Não exponha o RADIUS à Internet: as portas 1812/1813 (ou 1645/1646) devem estar acessíveis somente entre o RRAS e o NPS.
  • Restrinja origem: quando possível, limite por IPs/países no firewall para IKE/SSTP.
  • Use PSK forte ou certificados; idealmente, certificados emitidos por sua CA.
  • Ative registros e monitore; problemas intermitentes ficam claros com logs.
  • Planeje IKEv2 no médio prazo: melhor suporte a mobilidade, reconexões rápidas e suites modernas.

Caso resolvido

No cenário que motivou este artigo, bastou mudar o RRAS de PPTP para L2TP/IPsec e publicar corretamente UDP 500/4500/1701 + ESP no firewall CentOS. Os usuários externos passaram a conectar normalmente, sem quedas, e com criptografia robusta.

Checklist de correção rápida

  • Se for PPTP: confirmar TCP 1723 e GRE (IP 47) a passar; ativar helpers PPTP no Linux.
  • Preferencial: migrar para L2TP/IPsec e publicar UDP 500/4500/1701 + ESP (IP 50).
  • No RRAS: definir PSK/certificado, habilitar L2TP, ajustar pool de IP, DNS e políticas do NPS.
  • No CentOS: redirecionamento/encaminhamento correto e FORWARD a permitir UDP e ESP.
  • Validar rotas e DNS dos clientes após a conexão.

Perguntas frequentes

PPTP precisa só de portas?

Não. Precisa de TCP 1723 e do protocolo GRE (IP 47). Muitos administradores liberam apenas portas, esquecendo do GRE, e a sessão cai após o início do handshake.

Preciso abrir UDP 1701 para L2TP/IPsec?

Recomenda‑se abrir. Com NAT‑T, os dados trafegam em UDP 4500, porém alguns clientes e cenários sem NAT esperam ver o 1701 aberto. Em ambientes padronizados, teste e documente o comportamento.

Qual protocolo escolher hoje?

IKEv2 e SSTP são os mais robustos contra NATs rigorosos. L2TP/IPsec é amplamente compatível e fácil de operar. PPTP deve ser evitado por motivos de segurança.

Erro 809 ao conectar L2TP/IPsec. E agora?

Geralmente é bloqueio de UDP 500/4500 ou problema de NAT/ESP. Verifique publicação no firewall, confirme que o tráfego chega (tcpdump) e que o RRAS negocia SAs (PowerShell com Get-NetIPsec*).

O RADIUS precisa estar publicado na Internet?

Não. O NPS deve atender apenas o RRAS (rede interna). Expor 1812/1813 à Internet aumenta a superfície de ataque sem necessidade.

Clientes atrás de NAT não conectam L2TP/IPsec

Confirme o NAT‑T (UDP 4500) no firewall. Em alguns casos de Windows atrás de NAT simétrico, pode ser necessário o registro AssumeUDPEncapsulationContextOnSendRule em HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent (valor 2 quando cliente e servidor estão atrás de NAT).

Roteiro de mudança com baixo risco

  1. Habilitar L2TP/IPsec no RRAS em paralelo ao PPTP.
  2. Publicar UDP 500/4500/1701 + ESP no CentOS.
  3. Testar com grupo piloto; validar desempenho, rotas e DNS.
  4. Comunicar usuários, fornecer instruções de novo perfil VPN.
  5. Desabilitar PPTP após a adoção, removendo GRE/1723 no firewall.

Resumo para ação imediata

Se a sua VPN RRAS/NPS “funciona dentro e cai fora” e você usa PPTP, o problema quase sempre é GRE bloqueado. A correção definitiva é migrar para L2TP/IPsec (ou IKEv2/SSTP), abrir as portas e protocolos adequados e ajustar NPS/DNS/rotas. Além de resolver a queda, você eleva significativamente a segurança.

Dicas adicionais

  • Evite PPTP quando possível: vulnerável (MS‑CHAP v2). Prefira L2TP/IPsec, IKEv2 ou SSTP.
  • RADIUS não precisa vir da Internet: portas 1812/1813 (ou 1645/1646) devem estar acessíveis apenas entre RRAS e o servidor NPS.
  • Valide rotas e DNS após o túnel subir; portas corretas não garantem tráfego se o roteamento falhar.
Windows Server
L2TP/IPsec NPS PPTP RRAS VPN Windows Server
Índice