Firewalls e NAT: o que muda na comunicação

Uma VPN cria um “túnel” entre dois pontos para transportar tráfego usando encapsulamento e criptografia. No caminho, firewalls e NAT interferem no tráfego de rede, porque eles decidem o que pode passar e alteram endereços/portas.

NAT (Network Address Translation) é comum em redes domésticas e corporativas: ele converte endereços privados (ex.: 192.168.x.x) em um endereço público. Como a sessão precisa ser reconhecida depois, o NAT mantém uma tabela com mapeamentos de origem/destino e portas.

Firewalls filtram pacotes com base em regras. Mesmo quando o túnel usa criptografia, o firewall ainda enxerga metadados de rede (como IPs, portas e tipo de tráfego) e pode bloquear fluxos necessários para:

  • estabelecimento do túnel (handshake);
  • manutenção do túnel (mensagens de keep-alive);
  • tráfego encapsulado que transporta o “trânsito” da VPN.

Quando NAT e firewall têm políticas incompatíveis (ou tempo de sessão curto, ou portas não permitidas), a VPN pode conectar “parcialmente” ou falhar ao estabelecer.

Um modelo simples de funcionamento (e onde costuma quebrar)

Pense em quatro etapas: (1) resolução de destino (muitas vezes via DNS), (2) alcance de conectividade básica, (3) criação do túnel, (4) encaminhamento do tráfego encapsulado.

Erros comuns surgem em uma dessas camadas:

  1. Falha de DNS ou resolução inadequada Se o cliente resolve um nome para um IP incorreto (por cache, split DNS ou mudanças de rede), o handshake nunca começa.

  2. Bloqueio de portas/protocolos necessários Alguns tipos de VPN usam UDP, outros podem usar TCP ou exigir protocolos específicos. Se a rede bloqueia o protocolo ou a porta, o túnel não se forma.

  3. NAT “não mapeia” o tráfego de volta Se o NAT ou o firewall estiverem com regras que não permitem retorno, ou se houver assimetria (origem e destino “vindo de redes diferentes”), o fluxo do túnel pode sumir.

  4. Problemas de rotas e encaminhamento interno Mesmo que o túnel exista, o tráfego pode não alcançar redes internas esperadas. Isso pode ocorrer por regras locais, rotas ausentes ou políticas de encaminhamento.

Problemas comuns em VPN causados por NAT/firewall

A seguir, alguns sintomas frequentes e o que geralmente está por trás:

1) “Conecta, mas não navega”

O túnel pode estar criado, porém o tráfego não encontra rota para as redes desejadas, ou o encapsulamento não está conseguindo atravessar o caminho. Em muitos casos, envolve políticas do firewall no cliente/servidor e rotas de rede.

2) Handshake falha ou conexão cai logo em seguida

Quando o handshake exige tráfego em portas/protocolos específicos, bloqueios e restrições de firewall são causas comuns. Também pode haver interferência de NAT com mapeamentos que expiram rápido.

3) Latência alta, lentidão e falhas intermitentes

MTU (Maximum Transmission Unit) e fragmentação podem causar perdas silenciosas. Se o tráfego encapsulado fica maior que o permitido na rota, alguns pacotes se perdem e a conexão fica instável.

4) Funciona em uma rede, falha em outra

Mudanças de política do firewall e comportamento do NAT em redes diferentes explicam esse padrão. Uma rede “aberta” pode permitir o fluxo, enquanto outra corporativa/CGNAT pode restringir.

5) Dependência de DNS e acessos específicos

Se a VPN depende de nomes internos ou de regras de DNS (por exemplo, para resolver recursos privados), um DNS que não reflita o necessário para a VPN pode resultar em tráfego que não chega ao destino.

Diferenças e limites importantes (para não concluir errado)

Nem todo problema de VPN é “culpa do NAT” ou “culpa do firewall”. Existem limitações e exceções relevantes:

  • A VPN pode estar correta, mas o caminho não: mesmo configurações válidas podem falhar em redes com filtragem agressiva.
  • Criptografia não impede filtragem por metadados: firewalls ainda podem bloquear por porta/protocolo e pelo tipo de fluxo.
  • CGNAT e redes móveis: ambientes com NAT em cascata ou com controles adicionais tendem a tornar a comunicação menos previsível.
  • MTU é um fator frequentemente subestimado: a falha pode parecer “túnel instável”, mas o motivo real é perda por tamanho de pacote.

Como a tecnologia exata da VPN pode variar, nem todas as correções são universais. O ponto está em observar o sintoma e isolar a camada em que a falha aparece.

Verificações práticas para isolar a causa

Uma abordagem útil é seguir da base para o específico, reduzindo suposições.

  1. Verifique conectividade básica até o destino Confirme se o cliente consegue alcançar o IP do servidor (ou ao menos resolver e chegar ao gateway). Se o destino não é alcançável, o túnel nem começa.

  2. Revise DNS antes de culpar a VPN Teste resolução de nomes e consistência de IPs (especialmente quando há mudança de rede). Se o IP “correto” não for resolvido, o handshake falha.

  3. Observe logs e o momento da falha Registre em que etapa ocorre: ao iniciar, durante handshake, após alguns minutos, ou apenas para certas redes internas. Essa marcação reduz as possibilidades.

  4. Considere portas/protocolos e políticas do caminho Se a rede bloqueia o tipo de tráfego exigido, mudar a política do firewall (quando você administra) ou ajustar o modo de conexão (quando disponível) pode resolver.

  5. Suspeite de MTU quando houver lentidão e perdas Se a conexão alterna entre “ok” e “ruim”, ou perde tráfego apenas em certas rotas, teste redução de tamanho de pacotes/ajuste de MTU no lado do cliente quando aplicável.

  6. Teste em redes diferentes (com cuidado) Se funciona em uma rede doméstica e falha em corporativa, é um forte indício de filtragem no caminho. Nesse caso, alinhar regras de firewall e permitir o tráfego necessário tende a ser o caminho.

Quando aceitar que é um problema de rede (e não de configuração interna)

Se a VPN sempre falha ao atravessar uma determinada rede, a causa mais provável é uma política local no caminho (firewall/NAT), como bloqueio de tráfego, regras de sessão restritivas, CGNAT em cascata ou limitação de MTU.

Nesses cenários, as soluções costumam ser de integração: liberar portas/protocolos necessários, ajustar MTU na rota, revisar DNS para recursos internos e garantir rotas/encaminhamento coerentes.

Se você descrever o seu sintoma específico (por exemplo, “handshake falha”, “conecta e sem tráfego”, “lento com quedas”), é possível transformar essa descrição em um checklist mais direcionado para a etapa que está falhando.