Atenção (impacto operacional): VPN debug e, principalmente, kernel debug podem gerar alto volume de logs e degradar performance. Use janela controlada, preferencialmente com acesso via console, e sempre com filtros.
1) Mentalidade correta: o que você precisa provar (e em qual camada)
Antes de “ligar debug”, defina a hipótese e a evidência esperada:
Camada 0 — Conectividade IKE/NAT-T
- O peer responde em UDP/500 (IKE) e, se houver NAT, em UDP/4500 (NAT-T)?
- Há bloqueio upstream? Roteamento assimétrico? ISP fazendo ALG?
Camada 1 — Negociação IKE (Phase 1 / IKE SA)
- Proposals compatíveis (encryption/integrity/DH)?
- Autenticação bate (PSK/cert/ID)?
- Cert chain/CRL/tempo (clock skew) OK?
Camada 2 — Child SA / Phase 2 (Traffic Selectors)
- Encryption Domain/TS batem nos dois lados?
- NAT Exemption correto?
- O tráfego “casa” em policy e entra na VPN?
Camada 3 — Data Plane
- ESP (proto 50) sai/entra? Há drops no kernel?
- A aceleração (SecureXL) está interferindo? Precisa reproduzir em path não acelerado?
2) Preparação (antes do debug)
2.1 Checklist mínimo (evita debug desnecessário)
- Confirme hora/NTP (muito comum quebrar cert/ike).
- Confirme policy instalada e regras permitindo IKE/NAT-T (UDP/500, UDP/4500) e ESP (proto 50) entre os peers.
- Confirme rota para o peer e retorno (especialmente multi-ISP).
- Confirme NAT Exemption (site-to-site) e se não há NAT “surpresa” no caminho.
2.2 Tenha o “alvo” do debug definido
Use IPs reais do caso; abaixo um exemplo seguro (IPs de documentação):
- Peer remoto (public): 203.0.113.10
- Local (public): 198.51.100.5
- Rede local: 10.10.10.0/24
- Rede remota: 10.20.20.0/24
3) Coleta padrão (CheckMates-ready): 3 sessões e logs consistentes
Sessão A — VPN debug (user space)
- Entre em Expert.
- Zere/controle o volume antes de iniciar:
vpn debug trunc ALL=5
Esse comando ajusta o nível/truncamento de debug e é o baseline recomendado para iniciar com granularidade sem explodir volume.
- Ative VPN debug:
vpn debug on
- (Opcional, mas muito útil) Habilite timestamps no debug:
vpn debug timeon
O objetivo é correlacionar com tcpdump / fw monitor / eventos de rota.
- Acompanhe os logs em tempo real (em outra aba, se quiser):
tail -f $FWDIR/log/vpnd.elg
tail -f $FWDIR/log/ike.elg
O VPN debug grava evidências nos arquivos vpnd.elg e ike.elg em $FWDIR/log/.
Quando usar “ikefail”
Se o problema é intermitente e você quer capturar “somente falhas”:
vpn debug ikefail
Esse modo foca em eventos de falha para reduzir ruído.
Sessão B — Captura de rede (tcpdump) para IKE/NAT-T/ESP
A ideia aqui é responder, com prova: “o peer respondeu?”, “houve migração para NAT-T?”, “ESP está fluindo?”.
tcpdump -ni <iface_wan> -vvv "(udp port 500 or udp port 4500 or proto 50)"
Interpretação prática:
- Só vê UDP/500 e nada volta → bloqueio/rota/ACL upstream.
- Vê UDP/500 e depois UDP/4500 → NAT-T em ação (normal quando há NAT).
- Vê ESP (proto 50) saindo mas não voltando → retorno/ACL/ISP/roteamento assimétrico ou drop remoto.
- Vê ESP indo e voltando, mas app não passa → provável Phase 2 / selectors / NAT exemption / policy.
Sessão C — (Opcional) IKE monitor (snoop) quando você precisa “ver a conversa”
Se precisar de visibilidade adicional, use o monitor do VPN debug:
vpn debug mon
Isso gera um arquivo do tipo snoop (por exemplo, ikemonitor.snoop) para análise. Atenção: pode registrar informações sensíveis em cenários de XAUTH (ex.: senha). Use apenas quando necessário e com governança.
Para parar:
vpn debug moff
4) Quando (e como) entrar em Kernel Debug sem derrubar o ambiente
Regra de ouro: não rode kernel debug “no escuro”. Primeiro filtre por IP/5-tuple/VPN peer, depois capture.
A documentação do GAiA descreve filtros de kernel debug para reduzir o output apenas ao tráfego relevante e evitar ruído/perda de performance.
4.1 Filtrar por VPN peer (mais direto para incidentes VPN)
Antes de iniciar o kernel debug, aplique filtro:
fw ctl set int simple_debug_filter_off 1
fw ctl set str simple_debug_filter_vpn_1 "203.0.113.10"
O parâmetro simple_debug_filter_vpn_<N> filtra mensagens por peer VPN.
4.2 Filtrar por 5-tuple (quando o problema é um fluxo específico)
Exemplo (HTTP de teste entre duas redes):
fw ctl set int simple_debug_filter_off 1
fw ctl set str simple_debug_filter_saddr_1 "10.10.10.50"
fw ctl set str simple_debug_filter_daddr_1 "10.20.20.80"
fw ctl set int simple_debug_filter_dport_1 443
fw ctl set int simple_debug_filter_proto_1 6
A doc detalha a lógica AND (mesmo índice) e OR (índices diferentes), inclusive quando você precisa cobrir os dois sentidos do fluxo.
4.3 Desabilitar filtros ao final (higiene obrigatória)
fw ctl set int simple_debug_filter_off 1
5) Sequência prática “end-to-end” (copiar/colar)
Início (Sessão A)
vpn debug trunc ALL=5
vpn debug timeon
vpn debug on
Captura rede (Sessão B)
tcpdump -ni <iface_wan> -vvv "(udp port 500 or udp port 4500 or proto 50)"
(Opcional) IKE monitor (Sessão C)
vpn debug mon
Reproduza o problema
- Suba o túnel / gere tráfego do domínio criptografado
- Marque horário exato do teste (para correlacionar logs)
Encerramento (Sessão A)
vpn debug off
vpn debug timeoff
Encerramento do monitor (se usado)
vpn debug moff
Se você ativou kernel debug filters
fw ctl set int simple_debug_filter_off 1
6) O que procurar nos logs (padrão “diagnóstico por evidência”)
6.1 Falha em IKE (Phase 1 / IKE SA)
Padrões comuns:
- “no proposal chosen” → mismatch de proposal (enc/integrity/DH) entre peers.
- “invalid ID / ID mismatch” → Peer ID/config de identidade divergente (DN/FQDN/IP).
- “peer not responding” → rede/ACL/rota/NAT-T/ISP (prove com tcpdump).
Como fechar diagnóstico com prova
- Se tcpdump não mostra resposta do peer em UDP/500/4500 → não é “config VPN”, é conectividade.
- Se há resposta e a troca para em um ponto fixo → volte ao ike.elg/vpnd.elg com timestamps para achar o motivo.
6.2 Falha em Phase 2 / Selectors
Sinais típicos:
- IKE sobe, mas tráfego não passa.
- ESP não aparece ou aparece só em um sentido.
- Sessões “casa em rule errada” por NAT/route.
Prova
- tcpdump com proto 50 confirma ESP.
- vpnd.elg normalmente denuncia TS/encryption domain divergente.
7) VSX (quando aplicável)
Antes de qualquer coleta, entre no VS correto:
vsenv <VSID>
E só então execute as etapas acima (cada VS tem seus próprios contextos e logs).
