FortiGate: túnel IPsec está up mas o tráfego não passa

Problema

Um túnel IPsec aparece up/established, mas os hosts não conseguem chegar à subnet remota ou aplicação esperada através dele.

É uma situação comum porque uma IKE/IPsec security association estabelecida prova que a negociação do túnel foi concluída; não prova que routing, Phase 2 selectors, firewall policy, NAT, return routing ou o endpoint remoto estejam corretos para um fluxo específico.

Objetivo

Identificar a fase exata onde o tráfego pára.

A ordem de troubleshooting deve responder a estas perguntas:

1. A Phase 2 security association esperada está up?
2. O FortiGate tem a rota correta para a rede remota?
3. O tráfego chega efetivamente ao FortiGate?
4. O tráfego corresponde à firewall policy correta?
5. NAT está desativado ou configurado intencionalmente para o fluxo VPN?
6. Os Phase 2 selectors incluem a origem e o destino testados?
7. O pacote sai através do túnel IPsec?
8. Existe return traffic?
9. O host/serviço de destino está acessível?

Cenário de exemplo

Site A LAN: 10.1.10.0/24
Site B LAN: 10.2.20.0/24
Test source: 10.1.10.20
Test destination: 10.2.20.10
VPN interface: IPSEC-SITE-B

Substitui todos os valores pelos do ambiente real antes de executar comandos.

Step 1 - Confirmar o estado do túnel e da Phase 2

Começa por:

diagnose vpn tunnel list

Em sistemas com muitos túneis, filtra pelo nome quando suportado:

diagnose vpn tunnel list name IPSEC-SITE-B

Procura:

• O nome de túnel esperado
• Uma security association instalada
• A informação de proxy ID / selector esperada
• Contadores de pacotes (rx / tx) quando disponíveis

O output do túnel da Fortinet inclui contadores e informação de selector/security association que ajudam a perceber se os pacotes estão a ser encriptados ou desencriptados.

Interpretação

O túnel não está established

Isto não é um problema de "up but no traffic". Passa para troubleshooting de negociação de Phase 1 / Phase 2.

O túnel está up, mas os contadores permanecem a zero

Gera tráfego de teste controlado e volta a verificar.

Se os contadores não se alterarem, o tráfego pode nem estar a chegar ao túnel. Continua com routing, packet capture e verificação de policies.

TX aumenta mas RX não

O FortiGate local está a enviar tráfego encriptado, mas não observa return traffic correspondente.

Investiga:

• Remote firewall policy
• Remote route de retorno para a rede de origem
• Remote selectors
• Host/serviço de destino
• Upstream filtering

Step 2 - Confirmar a rota

Executa:

get router info routing-table all

Encontra a rota que deve corresponder ao destino remoto.

Para o destino de exemplo 10.2.20.10, confirma que a rota mais específica aponta para a interface/túnel IPsec pretendido.

Verificação crítica: rotas sobrepostas

Não procures apenas a rota /24 esperada.

Uma rota mais específica, como:

10.2.20.0/26

terá precedência para destinos entre 10.2.20.0 e 10.2.20.63, mesmo que uma rota /24 mais ampla aponte para a VPN.

Isto pode originar sintomas em que alguns endereços da rede remota funcionam e outros não.

Step 3 - Confirmar que o tráfego chega ao FortiGate

Utiliza um packet capture restrito:

diagnose sniffer packet any 'host 10.1.10.20 and host 10.2.20.10' 4 0 l

Gera o tráfego que está a falhar.

Interpretação

Não aparece nada

O tráfego não está a chegar a este FortiGate, ou o filtro/teste está incorreto.

Investiga o source endpoint, VLAN, default gateway, switching local ou outro equipamento a montante.

O tráfego entra na interface LAN mas não aparece no túnel

Continua com debug flow. As áreas mais prováveis são routing, firewall policy, policy routing, selectors ou lógica de NAT/configuração.

O tráfego entra e é visto a sair pelo túnel

O FortiGate está a encaminhar o tráfego para a VPN. Procura agora o sentido de retorno.

O tráfego regressa pelo túnel mas não chega ao host de origem

Investiga reverse firewall policy, routing, session state, caminho do endpoint ou rede local.

Step 4 - Utilizar debug flow para a decisão de policy/routing

Limpa o estado existente:

diagnose debug reset

Aplica filtros precisos:

diagnose debug flow filter saddr 10.1.10.20
diagnose debug flow filter daddr 10.2.20.10

Opcionalmente adiciona filtros de protocolo/porta.

Ativa function names e limita o trace:

diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

Gera o tráfego de teste.

Depois pára:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

O que procurar

• Interface de entrada correta
• Route / tunnel selection correto
• Firewall policy ID
• Resultado accept ou deny
• NAT inesperado
• Session handling
• Motivo explícito de drop

Step 5 - Validar firewall policies

Numa VPN site-to-site baseada em interface, confirma que existe uma policy apropriada para a direção necessária.

Fluxo típico de Site A para Site B:

Source interface: LAN / VLAN
Destination interface: IPSEC-SITE-B
Source: required local subnet/object
Destination: required remote subnet/object
Service: required service(s)
Action: ACCEPT
NAT: normally disabled for traditional site-to-site private-network traffic

O desenho exato pode variar. NAT pode ser intencional em algumas arquiteturas VPN, por isso trata "NAT disabled" como uma expectativa comum de desenho e não como regra universal.

Se for necessária iniciação bidirecional, valida também a policy para o sentido inverso.

Step 6 - Validar Phase 2 selectors

A Fortinet documenta os Phase 2 quick mode selectors como os address ranges permitidos para negociação/security associations IPsec.

Confirma que os endereços testados estão incluídos nos local e remote selectors configurados em ambos os peers.

Por exemplo:

Local:  10.1.10.0/24
Remote: 10.2.20.0/24

Se o peer remoto for uma firewall de terceiros, os requisitos dos selectors podem ser mais restritos e têm de corresponder à configuração desse peer.

Um túnel pode aparecer established enquanto o tráfego específico testado está fora do selector pair utilizável.

Step 7 - Verificar NAT

SNAT inesperado é uma causa frequente de mismatch numa VPN.

Utiliza debug flow para confirmar se a origem está a ser traduzida.

Numa policy site-to-site convencional entre subnets privadas, NAT está normalmente desativado para que o peer remoto receba o endereço de origem original.

Se NAT for intencional, confirma que:

• A origem traduzida está incluída no desenho da VPN.
• O lado remoto tem routes/selectors/policies para a rede traduzida.

Step 8 - Confirmar a return route no lado remoto

Um caminho de pacotes num só sentido não é suficiente.

O equipamento remoto e a rede de destino têm de saber como devolver tráfego para a subnet de origem original.

Se o Site A enviar:

10.1.10.20 -> 10.2.20.10

o Site B precisa de um caminho válido de regresso para:

10.1.10.0/24

através da VPN.

Uma return route em falta produz frequentemente uma configuração local do FortiGate aparentemente saudável, mas sem resposta da aplicação.

Step 9 - Testar a partir do FortiGate com cuidado

Podes executar um ping controlado com um endereço de origem que represente a rede protegida local:

execute ping-options source 10.1.10.1
execute ping 10.2.20.10

Tem cuidado na interpretação: tráfego originado pelo FortiGate é local-out traffic e não prova que tráfego de cliente encaminhado utilize o mesmo caminho de policy.

Utiliza packet capture e testes gerados por clientes para a validação final.

Step 10 - Validar o serviço de destino

Se os pacotes atravessarem a VPN nos dois sentidos, sai do âmbito da VPN.

Verifica:

• O host de destino está online?
• A firewall local permite o tráfego?
• A aplicação está em listening no IP e porta esperados?
• O default gateway do servidor está correto?
• A aplicação tem o seu próprio access control?

Um túnel IPsec funcional não resolve uma aplicação que não está em listening.

Decision tree

IPsec shown as up
        |
        v
Phase 2 / SA installed?
   |            |
  No           Yes
   |            |
VPN negotiation | 
troubleshooting v
          Correct route?
           |       |
          No      Yes
           |       |
      Fix route    v
             Traffic reaches FGT?
                |        |
               No       Yes
                |        |
         Source/L2 path  v
                   Correct policy/decision?
                     |          |
                    No         Yes
                     |          |
                Fix policy      v
                         Seen on IPsec tunnel?
                           |          |
                          No         Yes
                           |          |
                  Selectors/NAT/      v
                  route/debug     Return traffic?
                                  |         |
                                 No        Yes
                                  |         |
                           Remote side      v
                           / return path  Host/application

Evidência a recolher antes de alterar configuração

Regista o seguinte antes de fazer alterações:

Source IP:
Destination IP:
Protocol/port:
Tunnel name:
Phase 1 status:
Phase 2 status:
TX/RX counters before test:
TX/RX counters after test:
Selected route:
Firewall policy ID:
NAT observed:
Packet sniffer result:
Debug-flow result:
Remote-side result:

Isto torna o troubleshooting reproduzível e reduz alterações de configuração baseadas em suposições.

Root causes comuns

• Route em falta ou incorreta
• Rota sobreposta mais específica
• Firewall policy em falta
• Policy order incorreta
• NAT inesperado
• Phase 2 selector mismatch
• Source/destination object incorreto
• Remote firewall policy
• Remote return route em falta
• Host firewall
• Serviço sem listening
• Teste com endereço de origem incorreto
• Sessão com hardware offload a ocultar output esperado do debug flow

Riscos e rollback

A maioria dos comandos deste runbook são diagnósticos read-only.

diagnose debug flow pode gerar muito output e deve ser sempre filtrado e parado após o teste.

Não faças reset, flush, bring down ou delete de VPN security associations apenas porque o túnel não está a passar tráfego. Essas ações afetam conectividade ativa e só devem ser utilizadas quando a evidência o justificar especificamente.

Artigos relacionados

• FortiGate diagnose vpn tunnel
• FortiGate debug flow
• FortiGate packet sniffer
• FortiGate routing table
• FortiGate execute ping

Fontes

Consulta as referências oficiais da Fortinet indicadas nos metadados do artigo.