Toda empresa pequena que já perdeu meio dia de operação porque a fibra da operadora caiu sabe o valor de ter um segundo link. O pfSense resolve isso nativamente com Gateway Groups, sem precisar de appliance externo ou licença adicional — mas a configuração tem um punhado de detalhes que, se ignorados, fazem o failover “existir no papel” e nunca disparar de verdade quando o link principal cai.
Esse é o erro mais comum que encontro em auditoria de rede: cliente jura que tem redundância configurada, mas na prática o pfSense nunca troca de link porque o monitoramento de gateway está mal ajustado. Vamos direto ao que funciona.
Antes de começar: o que você precisa ter
Duas conexões de internet físicas chegando ao pfSense em interfaces separadas (duas placas de rede ou uma placa com VLAN, dependendo do hardware), e o mais importante: cada um dos dois links precisa estar configurado como uma interface WAN distinta, não como IP secundário na mesma interface. Se os dois links estiverem entrando pela mesma porta física, o failover simplesmente não existe — você só tem um ponto único de falha disfarçado.
Passo 1 — Configurar os Gateways
Acesse System > Routing > Gateways e confira se as duas WANs já aparecem com gateway associado. Normalmente o pfSense cria isso automaticamente ao configurar a interface, mas em instalações mais antigas ou migradas, às vezes um dos gateways fica sem o “IP monitorado” definido — e sem isso o pfSense não sabe dizer se o link está de pé ou não.
Aqui está o detalhe que mais derruba failover em produção: por padrão o pfSense monitora o próprio gateway (o IP do roteador da operadora). Só que muita operadora configura o equipamento de borda para não responder ping (ICMP bloqueado por política interna deles). Resultado: o pfSense acha que o link caiu mesmo com internet funcionando, ou o contrário — acha que está tudo bem quando na verdade só o roteador da borda responde, mas a internet real está fora.
A correção é simples: edite o gateway e troque o “Monitor IP” para um endereço público estável e conhecido, como 8.8.8.8 (Google) ou 1.1.1.1 (Cloudflare), em vez de deixar monitorando o gateway padrão da operadora.
Passo 2 — Criar o Gateway Group
Vá em System > Routing > Gateway Groups e clique em Add. Aqui está a parte que confunde muita gente que configura pela primeira vez: os “Tiers”.
- Se as duas WANs ficarem no mesmo Tier, o pfSense faz balanceamento de carga entre elas (as duas ativas ao mesmo tempo, dividindo tráfego).
- Se ficarem em Tiers diferentes (WAN principal em Tier 1, WAN backup em Tier 2), o comportamento vira failover puro: a WAN 2 só entra em uso quando a WAN 1 é considerada down pelo monitoramento.
Para a maioria dos clientes que só querem “se cair o link principal, o backup assume”, o certo é usar Tiers diferentes. Load balancing parece atraente no papel, mas em prática mistura latência dos dois links de forma imprevisível para aplicações sensíveis (chamadas VoIP, por exemplo), então costumo recomendar failover puro salvo pedido explícito do cliente.
Passo 3 — Aplicar o Gateway Group na regra de firewall
Esse é o passo que mais gente esquece, e é exatamente por isso que o failover “não funciona” mesmo depois de configurado corretamente nos dois passos anteriores. Vá em Firewall > Rules > LAN, abra a regra que libera saída para internet (geralmente a regra “allow LAN to any”), e no campo Gateway — que por padrão fica em “default” — troque para o Gateway Group que você acabou de criar.
Se esse campo continuar em “default”, o tráfego sempre sai pela WAN configurada como padrão do sistema, ignorando completamente o Gateway Group. É a causa número um de “configurei tudo certo mas não falha para o outro link” que vejo em suporte remoto.
Testando de verdade (sem torcer para dar certo)
Não confie só no status verde do dashboard. Desconecte fisicamente o cabo da WAN principal (ou desative a interface via CLI) e acompanhe em tempo real pelo menu Status > Gateways se o status muda para “Offline” e se o tráfego realmente passa a sair pela WAN backup — pode testar acessando um painel de monitoramento como Grafana apontando para um IP externo, ou simplesmente rodando um traceroute de uma máquina da LAN durante o teste.
Problemas comuns
1. Failover funciona mas demora demais para trocar (30 segundos ou mais de rede fora). Ajuste os parâmetros de “Probe Interval” e “Down” na configuração avançada do gateway — o padrão é conservador para evitar falso positivo, mas para links instáveis vale reduzir o intervalo de checagem.
2. Depois que a WAN principal volta, o tráfego não retorna para ela automaticamente. Comportamento esperado em alguns cenários de NAT com estado — as conexões já estabelecidas continuam pela WAN backup até serem encerradas. Novas conexões, no entanto, devem voltar à WAN principal (Tier 1) automaticamente assim que ela for considerada up de novo.
3. Sites que exigem IP fixo (banco, sistemas de nota fiscal) quebram durante o failover. Isso é esperado — o IP público muda de operadora para operadora. Para esses casos específicos, é preciso criar uma regra de firewall separada fixando aquele tráfego só na WAN que tem o IP homologado, sem passar pelo Gateway Group.
Perguntas frequentes
Preciso de duas placas de rede físicas para ter dual WAN?
O ideal é sim, uma interface por link. Tecnicamente dá para usar VLANs numa mesma placa, mas isso reduz a resiliência real em caso de falha da própria placa de rede.
O pfSense suporta mais de duas WANs no mesmo Gateway Group?
Sim, é possível adicionar quantas WANs o hardware suportar, distribuídas em Tiers conforme a prioridade desejada.
Failover e load balancing podem ser usados juntos?
Sim — é possível colocar duas WANs no mesmo Tier (balanceando entre elas) e uma terceira em Tier mais baixo, funcionando como backup geral caso as duas primeiras caiam.
Se depois de configurar o failover você quiser também monitorar a saúde da rede em tempo real, veja o guia de monitoramento de servidores com Prometheus e Grafana, e para quem ainda não tem DNS interno redundante, o passo a passo de configuração de servidor DNS com BIND9 complementa bem essa estrutura de rede.
