Como Configurar 2 Túneis IPsec com Failover Automático em Palo Alto Networks: Guia Passo a Passo
Redes · Firewall · Palo Alto Networks · IPsec · VPN | ✎ Duarte Spínola | 7 de Maio de 2026
Uma ligação VPN site-to-site com um único túnel IPsec é um ponto de falha único — e em ambientes empresariais isso não é aceitável. Este guia mostra como configurar dois túneis IPsec redundantes em Palo Alto Networks (PAN-OS) com failover automático: quando o túnel primário cai, o tráfego comuta para o secundário em menos de 30 segundos, sem intervenção manual.
A estratégia baseia-se em três pilares: Tunnel Monitoring (detecção de falha via ICMP heartbeat), rotas estáticas com métricas diferentes (o PAN-OS prefere sempre a rota com métrica mais baixa) e dois IKE Gateways independentes. Quando o Tunnel Monitoring deteta que o túnel primário está inativo, o PAN-OS remove automaticamente a rota associada e o tráfego flui pelo secundário.
Neste artigo
- Como funciona o failover no PAN-OS
- Pré-requisitos e planeamento
- Passo 1 — Criar os IKE Gateways (Fase 1)
- Passo 2 — Criar o Perfil IPsec (Fase 2)
- Passo 3 — Configurar os Túneis IPsec com Tunnel Monitoring
- Passo 4 — Configurar as Interfaces de Túnel
- Passo 5 — Criar Rotas Estáticas com Métricas
- Passo 6 — Configurar Políticas de Segurança
- Passo 7 — Commit e Verificação
- Passo 8 — Testar o Failover
- Resolução de problemas
- Melhores práticas
1. Como Funciona o Failover no PAN-OS
O PAN-OS não tem um mecanismo de “failover de túnel” nativo no sentido estrito — o que existe é uma combinação de dois mecanismos independentes que juntos produzem o comportamento pretendido:
| Mecanismo | O que faz | Onde se configura |
|---|---|---|
| Tunnel Monitoring | Envia pings ICMP periódicos para um IP no lado remoto. Se falhar 3 vezes consecutivas, o túnel é marcado como Down e a rota associada é removida da tabela de routing. | IPsec Tunnel → separador Tunnel Monitor |
| Rotas Estáticas com Métricas | Duas rotas para o mesmo destino remoto com métricas diferentes. O PAN-OS instala na tabela de routing apenas a rota com métrica mais baixa — quando essa é removida, a seguinte entra automaticamente. | Virtual Routers → Static Routes |
ℹ Tempo de failover esperado
Com o perfil de Tunnel Monitoring padrão, o failover ocorre em aproximadamente 20 a 30 segundos após a falha (intervalo de ping 5 segundos × 3 falhas consecutivas). Para ambientes mais críticos, criar um perfil personalizado com intervalo de 2 segundos — failover em menos de 10 segundos.
| Componente | Túnel Primário | Túnel Secundário |
|---|---|---|
| IKE Gateway | IKE-Primario | IKE-Secundario |
| Túnel IPsec | Tunnel-Primario | Tunnel-Secundario |
| Interface lógica | tunnel.1 — 169.254.1.1/30 | tunnel.2 — 169.254.1.5/30 |
| Rota estática | 10.200.0.0/24 via tunnel.1 — métrica 10 | 10.200.0.0/24 via tunnel.2 — métrica 20 |
| Estado normal | ● Ativo — tráfego flui aqui | ○ Standby — aguarda falha |
2. Pré-requisitos e Planeamento
Antes de começar, reúna as seguintes informações com o lado remoto da ligação (outro Palo Alto, Cisco ASA, FortiGate, ou gateway cloud como AWS VPN ou Azure VPN Gateway):
| Parâmetro | Exemplo | Nota |
|---|---|---|
| IP público WAN local (primário) | 203.0.113.10 | IP da interface ethernet1/1 (ISP principal) |
| IP público WAN local (secundário) | 203.0.113.11 | Interface ethernet1/2 (ISP secundário) — ou mesmo ISP, peer remoto diferente |
| IP público do peer remoto (primário) | 203.0.113.50 | Fornecido pelo administrador remoto ou carrier |
| IP público do peer remoto (secundário) | 203.0.113.51 | Pode ser o mesmo gateway remoto com IP/interface diferente |
| Pre-shared Key | [definida em conjunto] | Mínimo 20 caracteres com maiúsculas, números e símbolos |
| Subnet local (LAN) | 192.168.10.0/24 | Rede local que vai aceder ao site remoto |
| Subnet remota | 10.200.0.0/24 | Rede no site remoto que queremos alcançar |
| IP para Tunnel Monitoring | 10.200.0.1 | Host remoto sempre disponível — gateway da LAN remota ou servidor de monitorização |
⚠ O IP do Tunnel Monitoring é crítico
O destino de monitorização deve ser um host que esteja sempre disponível enquanto o site remoto estiver operacional — tipicamente o gateway da LAN remota. Se este host ficar offline mesmo com o túnel ativo, o PAN-OS vai considerar o túnel em falha e acionar um failover desnecessário (falso positivo).
3. Passo 1 — Criar os IKE Gateways (Fase 1)
O IKE Gateway define os parâmetros da negociação IKE (Phase 1) — autenticação, algoritmos e identidade de ambos os peers. Vamos criar dois: um para cada túnel.
Navegue para Network → Network Profiles → IKE Gateways e clique em Add.
IKE Gateway Primário
| Campo | Valor | Explicação |
|---|---|---|
| Name | IKE-Primario | Nome descritivo sem espaços |
| Version | IKEv2 only | Usar IKEv1 apenas se o peer remoto não suportar v2 (equipamento legado) |
| Interface | ethernet1/1 | Interface WAN principal (ISP primário) |
| Local IP Address | 203.0.113.10 | IP público da interface WAN primária |
| Peer IP Address | 203.0.113.50 | IP público do firewall/gateway remoto primário |
| Authentication | Pre-Shared Key | Mais comum; certificados são alternativa mais segura em grandes organizações |
| Pre-Shared Key | [chave acordada com o peer] | Tem de ser idêntica nos dois lados do túnel |
| IKE Crypto Profile | default ou perfil personalizado | O perfil padrão usa AES-128/SHA-1/DH-2 — criar perfil com AES-256/SHA-256/DH-14 para ambientes empresariais |
| Liveness Check | 5 segundos | IKEv2 Dead Peer Detection — deteta falhas de IKE independentemente do Tunnel Monitoring |
IKE Gateway Secundário
Repita o processo com os seguintes ajustes — o resto dos parâmetros é idêntico ao primário:
| Campo | Valor |
|---|---|
| Name | IKE-Secundario |
| Interface | ethernet1/2 (ISP secundário) — ou ethernet1/1 se o mesmo ISP mas peer diferente |
| Local IP Address | 203.0.113.11 |
| Peer IP Address | 203.0.113.51 |
4. Passo 2 — Criar o Perfil IPsec (Fase 2)
O perfil IPsec Crypto define os algoritmos da Fase 2 (SA de dados). Um único perfil serve para ambos os túneis.
Navegue para Network → Network Profiles → IPsec Crypto e clique em Add.
| Campo | Valor recomendado | Alternativa |
|---|---|---|
| Name | IPsec-AES256-SHA256 | — |
| Encryption | aes-256-cbc | aes-128-cbc (mais rápido, menos seguro) |
| Authentication | sha256 | sha1 (evitar — deprecado em alguns peers) |
| DH Group | group14 (2048-bit) | group20 (384-bit ECP, mais seguro); group5 só se peer legado exigir |
| Lifetime (seconds) | 3600 (1 hora) | 28800 (8 horas) — menos re-keying, menos seguro |
| Lifetime (KB) | 0 (desativado) | Ativar apenas se o peer exigir re-keying por volume |
ℹ Compatibilidade de algoritmos com o peer remoto
Os algoritmos configurados têm de ser exatamente iguais nos dois lados do túnel. Se o peer for um gateway cloud (AWS, Azure, Claranet, MEO Empresas), consulte a documentação do fornecedor para os valores suportados. Em caso de incompatibilidade, os logs em Monitor → Logs → System com filtro IKE mostram exatamente quais os algoritmos rejeitados.
5. Passo 3 — Configurar os Túneis IPsec com Tunnel Monitoring
Os túneis IPsec associam o IKE Gateway ao perfil de criptografia. É aqui que se ativa o Tunnel Monitoring — o mecanismo central do failover.
Navegue para Network → IPsec Tunnels e clique em Add.
Separador General — Túnel Primário
| Campo | Valor |
|---|---|
| Name | Tunnel-Primario |
| Tunnel Interface | tunnel.1 |
| Type | Auto Key |
| IKE Gateway | IKE-Primario |
| IPsec Crypto Profile | IPsec-AES256-SHA256 |
Separador Tunnel Monitor — Túnel Primário
| Campo | Valor | Atenção |
|---|---|---|
| Enable | ● Ativado | Obrigatório — sem isto o failover não funciona |
| Action | fail-over | Remove a rota quando o túnel falha. wait-recover mantém a rota e espera — não usar para failover automático. |
| Destination IP | 10.200.0.1 | Host remoto sempre disponível — gateway da LAN remota |
| Monitoring Profile | default | Padrão: intervalo 5s, 3 falhas. Para failover mais rápido, criar perfil em Network Profiles → Monitor. |
Túnel Secundário — repita o processo com:
- Name: Tunnel-Secundario
- Tunnel Interface: tunnel.2
- IKE Gateway: IKE-Secundario
- Tunnel Monitor com Action: fail-over e o mesmo Destination IP
6. Passo 4 — Configurar as Interfaces de Túnel
As interfaces tunnel.1 e tunnel.2 são criadas automaticamente com o túnel IPsec. Precisa de lhes atribuir um IP e colocá-las na zona de segurança correta.
Navegue para Network → Interfaces e edite as interfaces de túnel.
| Interface | IP | Virtual Router | Security Zone |
|---|---|---|---|
| tunnel.1 | 169.254.1.1/30 | default | vpn (criar se não existir) |
| tunnel.2 | 169.254.1.5/30 | default | vpn (mesma zona que tunnel.1) |
ℹ Porquê 169.254.x.x (Link-Local)
Usar IPs link-local nas interfaces de túnel é convenção comum — não interferem com o espaço de endereços real da organização e deixam claro que são interfaces de infraestrutura. O /30 dá dois IPs utilizáveis: .1 (local) e .2 (remoto). O PAN-OS não exige IP nas interfaces de túnel para routing básico, mas é necessário para o Tunnel Monitoring funcionar corretamente.
7. Passo 5 — Criar Rotas Estáticas com Métricas
Este passo é o coração do failover. Criamos duas rotas para o mesmo destino remoto — o PAN-OS instala apenas a de menor métrica na tabela de routing ativa. Quando o Tunnel Monitoring deteta a falha e remove a rota primária, a secundária entra automaticamente.
Navegue para Network → Virtual Routers → [default] → Static Routes → Add.
| Campo | Rota Primária | Rota Secundária |
|---|---|---|
| Name | Rota-Remota-Pri | Rota-Remota-Sec |
| Destination | 10.200.0.0/24 | 10.200.0.0/24 |
| Interface | tunnel.1 | tunnel.2 |
| Next Hop | 169.254.1.2 | 169.254.1.6 |
| Metric | 10 | 20 |
| Admin Distance | 10 (padrão) | 10 (padrão) |
⚠ Metric vs. Admin Distance — não confundir
No PAN-OS, a Metric é o valor usado para desempate entre rotas do mesmo tipo e admin distance — é este o campo que controla a preferência primária/secundária. A Admin Distance define a preferência entre diferentes fontes de routing (estáticas, OSPF, BGP). Para este cenário, mantenha ambas as rotas com a mesma admin distance e use apenas a Metric como diferenciador.
8. Passo 6 — Configurar Políticas de Segurança
O tráfego que flui pelos túneis está sujeito às políticas de segurança tal como qualquer outro tráfego. Como ambos os túneis partilham a mesma zona (vpn), são necessárias apenas duas regras.
Navegue para Policies → Security → Add.
| Campo | Regra 1 — LAN → Remoto | Regra 2 — Remoto → LAN |
|---|---|---|
| Name | Allow-LAN-to-VPN | Allow-VPN-to-LAN |
| Source Zone | trust | vpn |
| Source Address | 192.168.10.0/24 | 10.200.0.0/24 |
| Destination Zone | vpn | trust |
| Destination Address | 10.200.0.0/24 | 192.168.10.0/24 |
| Application | any | any |
| Action | Allow | Allow |
9. Passo 7 — Commit e Verificação
Clique em Commit (canto superior direito), adicione um comentário descritivo e aguarde a conclusão. Após o commit, confirme o estado em vários pontos.
| Onde verificar | O que confirmar |
|---|---|
| Monitor → IPsec Tunnels | Ambos os túneis com estado Up. IKE SA e IPsec SA negociadas com sucesso. |
| Monitor → Tunnel Monitoring | Heartbeat a funcionar — destino de monitorização a responder em ambos os túneis. |
| Network → Virtual Routers → Routing Table | Rota 10.200.0.0/24 instalada via tunnel.1 (métrica 10). A rota via tunnel.2 existe na config mas não está ativa. |
| Monitor → Logs → System | Sem erros de IKE ou IPsec. Mensagens IKE phase-1 SA established e phase-2 SA established para ambos os túneis. |
10. Passo 8 — Testar o Failover
Nunca confie num failover que não foi testado. Execute este procedimento em janela de manutenção acordada com o site remoto — a interrupção é breve mas existe.
| # | Ação | Resultado esperado |
|---|---|---|
| 1 | Inicie um ping contínuo de um host local para um host remoto: ping 10.200.0.10 -t | Pings com sucesso via Tunnel-Primario |
| 2 | No lado remoto, desative o IKE Gateway primário ou a interface WAN correspondente | Pings começam a falhar |
| 3 | Aguarde 15 a 30 segundos | Tunnel Monitoring deteta a falha após 3 pings consecutivos sem resposta |
| 4 | Observe que os pings retomam automaticamente | Tráfego flui agora via Tunnel-Secundario |
| 5 | Confirme em Monitor → IPsec Tunnels | Tunnel-Primario: Down | Tunnel-Secundario: Up |
| 6 | Reative o túnel primário no lado remoto | Túnel primário renegocia automaticamente (IKE phase-1 e phase-2) |
| 7 | Aguarde 30 a 60 segundos e verifique a Routing Table | Rota primária (métrica 10) volta a ser instalada. Tráfego regressa ao Tunnel-Primario. |
✓ Critérios de sucesso do teste
O failover está a funcionar corretamente se: (1) a interrupção máxima for inferior a 30 segundos, (2) o tráfego retomar sem intervenção manual, (3) o regresso ao túnel primário ocorrer automaticamente após a recuperação, e (4) os logs em Monitor → System mostrarem as mensagens de transição esperadas sem erros.
11. Resolução de Problemas
| Sintoma | Causa mais provável | Solução |
|---|---|---|
| Túneis não estabelecem (Down) | PSK errada, algoritmos incompatíveis, UDP 500/4500 bloqueado no ISP | Filtrar Monitor → System por IKE. Confirmar PSK idêntica. Testar ping ao IP do peer WAN. |
| Túneis Up mas tráfego não passa | Política de segurança ausente, zona errada nas interfaces de túnel, rota estática em falta | Usar Monitor → Traffic para ver se o tráfego chega. Verificar se há regra de NAT a interferir com tráfego encriptado. |
| Failover não ocorre automaticamente | Tunnel Monitoring desativado, Action definida como wait-recover, IP de monitorização inacessível | Confirmar Enable ativo e Action = fail-over. Testar ping manual ao IP de monitorização a partir do firewall. |
| Failover falso (flap sem falha real) | Host de monitorização instável, latência elevada causa timeouts de ICMP | Mudar o IP de monitorização para host mais estável. Criar perfil com threshold mais tolerante (intervalo 10s, 5 falhas). |
| Tráfego não regressa ao primário após recuperação | IKE SA do primário não renegociada, Tunnel Monitor ainda reporta Down | Verificar estado em Monitor → IPsec Tunnels. Forçar renegociação clicando em Refresh no túnel ou reiniciando o IKE Gateway. |
| Problemas de MTU / fragmentação | Overhead IPsec (~50–60 bytes) reduz o MTU efetivo para 1436–1450 bytes | Reduzir MTU das interfaces de túnel para 1400. Ativar TCP MSS Clamp em Network → Interfaces → tunnel.1/tunnel.2. |
12. Melhores Práticas
| Recomendação | Porquê |
|---|---|
| Usar ISPs diferentes para cada túnel | Dois túneis pelo mesmo ISP não protegem contra falha de carrier. Redundância real exige diversidade de operador — em Portugal, combinar MEO Empresas + NOS ou Claranet. |
| Criar perfil IKE Crypto personalizado | O perfil padrão do PAN-OS usa AES-128 e SHA-1. Para ambientes empresariais, criar perfil com AES-256, SHA-256 e DH-14 como mínimo. |
| Documentar a PSK num cofre de passwords | Uma PSK perdida implica reconfigurar ambos os lados do túnel e uma janela de indisponibilidade. Guardar em KeePass, Bitwarden Business ou similar. |
| Testar o failover após cada alteração de configuração | Alterações de zonas, políticas ou rotas podem quebrar o failover silenciosamente. Validar após cada commit significativo. |
| Configurar alertas de estado de túnel | Enviar logs de IPsec para SIEM ou Zabbix com alerta quando o estado muda para Down. Falhas noturnas passam despercebidas sem alertas ativos. |
| Considerar BGP/OSPF para múltiplos sites | Com 3 ou mais sites, rotas estáticas tornam-se difíceis de gerir. OSPF sobre IPsec com redistribuição oferece failover mais inteligente e escalável. |
