Muitos administradores de rede já se depararam com o seguinte cenário:
“A VPN funciona quando conecto o PPPoE direto no equipamento, mas não funciona quando estou atrás do roteador.”
Se isso te soa familiar, esse post vai explicar exatamente por quê e como resolver (ou contornar) a situação.
Entendendo o funcionamento do L2TP/IPSec
O protocolo L2TP por si só não oferece criptografia. Por isso, ele é geralmente encapsulado com IPSec para prover segurança.
Esse conjunto (L2TP/IPSec) usa os seguintes protocolos e portas:
- UDP/500 – negociação de chave (IKE)
- UDP/4500 – para NAT-T (quando há NAT envolvido)
- ESP (protocolo IP 50) – tráfego criptografado de fato (não é TCP/UDP)
O problema: IPSec e NAT não se dão bem
Diferente de protocolos baseados em portas como TCP e UDP, o ESP é um protocolo da camada IP. Ou seja, ele não tem portas como “porta 443” ou “porta 22”. Isso dificulta o processo de NAT (Network Address Translation), que normalmente espera trabalhar com portas TCP/UDP.
Em redes roteadas (com NAT), o roteador:
- não consegue identificar o destino correto para o tráfego ESP
- pode bloquear ou descartar os pacotes ESP
- nem sempre suporta NAT-T adequadamente
O que acontece na prática?
| Situação | Funciona? | Motivo |
|---|---|---|
| PPPoE direto (sem NAT) | ✅ | O cliente tem IP público e o tráfego ESP flui diretamente. |
| Rede local com NAT simples | ⚠️ | Pode funcionar se o roteador suportar NAT-T e encaminhar UDP/500/4500. |
| NAT duplo (modem + roteador) | ❌ | Pacotes ESP geralmente são descartados ou quebram no meio do caminho. |
| Rede corporativa/CGNAT | ❌ | Firewalls e NAT múltiplo bloqueiam IKE, ESP e UDP/4500. |
Diagnóstico rápido
Se você quer confirmar que está esbarrando nesse problema, observe:
- O cliente tenta conectar, mas nunca passa da fase de autenticação.
- O log do servidor mostra negociação de IKE incompleta.
- Usando
tcpdumpno servidor:sudo tcpdump -i eth0 port 500 or port 4500 or proto 50Você verá pacotes chegando por UDP/500, mas nenhum ESP (proto 50) chegando ou saindo.
Soluções e alternativas
1. Evitar o uso de NAT
- Conecte-se via PPPoE direto, quando possível.
- Coloque o servidor VPN atrás de IP público real.
2. Usar protocolos compatíveis com NAT
| Protocolo | Usa portas normais? | Compatível com NAT? | Recomendado? |
|---|---|---|---|
| PPTP | TCP/1723 + GRE (47) | Não (GRE é problemático) | Não (inseguro) |
| L2TP/IPSec | UDP/500, UDP/4500, ESP | Parcialmente | Só com NAT-T |
| OpenVPN | UDP/TCP custom | Sim | Sim |
| SSTP | TCP/443 | Sim (SSL) | Sim |
3. Ativar e forçar NAT-T
No Mikrotik, por exemplo:
/ip ipsec settings set nat-traversal=yes
No Linux:
- Certifique-se de que o
strongSwanouLibreSwanesteja comnat_traversal=yes.
Quando tudo falhar: use OpenVPN ou SSTP
Se você precisa de confiabilidade mesmo em redes CGNAT, NAT duplo ou ambientes corporativos restritos, a melhor saída é trocar de protocolo:
- OpenVPN: customizável, pode usar qualquer porta, inclusive TCP/443.
- SSTP: funciona exatamente como HTTPS (TCP/443), passa até por proxy e DPI.
Conclusão
O L2TP/IPSec não foi projetado para funcionar bem com NAT. Embora existam extensões como o NAT-T, elas nem sempre são bem suportadas por roteadores domésticos ou operadoras.
Se você precisa de uma VPN robusta para ambientes com NAT, considere alternativas modernas e compatíveis como OpenVPN ou SSTP, e reserve o L2TP/IPSec apenas para cenários onde há IP público direto e controle completo da rede.