"
Failover dual-WAN automático em OPNsense (fibra + 5G)
Uma só ligação à internet é um ponto único de falha. Basta uma quebra a meio de uma
chamada, de um upload ou de um exame online e ficamos presos a reconectar à mão. Por isso
montei uma segunda ligação que assume sozinha: fibra como linha principal, 5G como recurso.
Quando a fibra cai, o tráfego passa para o 5G em segundos; quando a fibra volta, regressa a
ela.
Isto é failover puro, não load balancing — uma linha leva tudo, a outra espera. Fica
aqui a configuração completa. Parte do princípio de que as duas WAN já estão definidas como
interfaces (no meu caso: fibra na WAN, 5G na OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Dá a cada gateway um monitor IP distinto e externo. É isto que faz o failover
disparar de verdade. Eu uso:
- fibra → 1.1.1.1
- 5G → 8.8.8.8
Mantém o gateway monitoring ativo. Sem monitor IPs distintos, o OPNsense não percebe que uma
linha caiu, e o failover nunca acontece.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Nome: GW_FAILOVER
- Fibra = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" significa que só salta para o 5G quando o gateway da fibra é dado como morto —
exatamente o que se quer para uma separação limpa entre principal e recurso.
3) A regra de LAN — Firewall ▸ Rules ▸ LAN (o passo que a maioria dos guias esquece)
Edita a regra "allow LAN to any" (ou cria uma nova no topo). Em Advanced, define:
- Gateway → GW_FAILOVER
É este o passo que ativa o policy-based routing. Sem ele, o tráfego da LAN ignora o grupo
por completo e o failover não faz nada. Se houver uma coisa para reter deste post, é esta.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
O modo automático já cobre as duas interfaces. Se usares Hybrid/Manual, garante que existe
regra de outbound NAT para a fibra e para o 5G, senão o tráfego pelo recurso não é
traduzido.
5) DNS
O Unbound local resolve sem problema. Se reencaminhares para o resolver do ISP, muda-o para
1.1.1.1 / 8.8.8.8 em System ▸ Settings ▸ General, para não ficares preso ao DNS da fibra
quando a fibra é precisamente o que está em baixo.
Testar — a sério
Não confies nisto sem o partires primeiro. Desliga a fibra fisicamente e cronometra a
comutação. Com "Member down", conta com uns 5–10 segundos até o 5G assumir. Volta a ligar e
confirma que regressa à fibra.
O que sobrevive à troca (e o que não)
A comutação demora uns segundos, e as sessões TCP ativas quebram — a ligação cai e
restabelece-se no novo caminho. Tudo aquilo em que a sessão vive num token e não no IP (a
maioria das apps web em HTTPS) aguenta um recarregar de página sem perder o estado. Streams
de longa duração levam com o corte. Planeia em conformidade.
Notas
- O 5G atrás de CGNAT não é problema aqui: não são precisas ligações de entrada, isto é
failover de saída.
- Sê honesto quanto ao alcance: isto é failover por queda de link, não SD-WAN. Não
há seleção de caminho em tempo real por latência/jitter/perda nem orquestração central —
comuta quando um link é dado como morto, que é o que a maioria dos homelabs e pequenos
escritórios precisa.
Nota de hardware: corri isto num appliance de segunda mão, fanless, sem saída de vídeo
(instalação só por consola série), mas a configuração de failover acima é igual em qualquer
máquina compatível com OPNsense.
Disponível para responder a dúvidas — e se puxares mesmo o cabo para testar, diz-me o teu
tempo de comutação. :)
Uma só ligação à internet é um ponto único de falha. Basta uma quebra a meio de uma
chamada, de um upload ou de um exame online e ficamos presos a reconectar à mão. Por isso
montei uma segunda ligação que assume sozinha: fibra como linha principal, 5G como recurso.
Quando a fibra cai, o tráfego passa para o 5G em segundos; quando a fibra volta, regressa a
ela.
Isto é failover puro, não load balancing — uma linha leva tudo, a outra espera. Fica
aqui a configuração completa. Parte do princípio de que as duas WAN já estão definidas como
interfaces (no meu caso: fibra na WAN, 5G na OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Dá a cada gateway um monitor IP distinto e externo. É isto que faz o failover
disparar de verdade. Eu uso:
- fibra → 1.1.1.1
- 5G → 8.8.8.8
Mantém o gateway monitoring ativo. Sem monitor IPs distintos, o OPNsense não percebe que uma
linha caiu, e o failover nunca acontece.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Nome: GW_FAILOVER
- Fibra = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" significa que só salta para o 5G quando o gateway da fibra é dado como morto —
exatamente o que se quer para uma separação limpa entre principal e recurso.
3) A regra de LAN — Firewall ▸ Rules ▸ LAN (o passo que a maioria dos guias esquece)
Edita a regra "allow LAN to any" (ou cria uma nova no topo). Em Advanced, define:
- Gateway → GW_FAILOVER
É este o passo que ativa o policy-based routing. Sem ele, o tráfego da LAN ignora o grupo
por completo e o failover não faz nada. Se houver uma coisa para reter deste post, é esta.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
O modo automático já cobre as duas interfaces. Se usares Hybrid/Manual, garante que existe
regra de outbound NAT para a fibra e para o 5G, senão o tráfego pelo recurso não é
traduzido.
5) DNS
O Unbound local resolve sem problema. Se reencaminhares para o resolver do ISP, muda-o para
1.1.1.1 / 8.8.8.8 em System ▸ Settings ▸ General, para não ficares preso ao DNS da fibra
quando a fibra é precisamente o que está em baixo.
Testar — a sério
Não confies nisto sem o partires primeiro. Desliga a fibra fisicamente e cronometra a
comutação. Com "Member down", conta com uns 5–10 segundos até o 5G assumir. Volta a ligar e
confirma que regressa à fibra.
O que sobrevive à troca (e o que não)
A comutação demora uns segundos, e as sessões TCP ativas quebram — a ligação cai e
restabelece-se no novo caminho. Tudo aquilo em que a sessão vive num token e não no IP (a
maioria das apps web em HTTPS) aguenta um recarregar de página sem perder o estado. Streams
de longa duração levam com o corte. Planeia em conformidade.
Notas
- O 5G atrás de CGNAT não é problema aqui: não são precisas ligações de entrada, isto é
failover de saída.
- Sê honesto quanto ao alcance: isto é failover por queda de link, não SD-WAN. Não
há seleção de caminho em tempo real por latência/jitter/perda nem orquestração central —
comuta quando um link é dado como morto, que é o que a maioria dos homelabs e pequenos
escritórios precisa.
Nota de hardware: corri isto num appliance de segunda mão, fanless, sem saída de vídeo
(instalação só por consola série), mas a configuração de failover acima é igual em qualquer
máquina compatível com OPNsense.
Disponível para responder a dúvidas — e se puxares mesmo o cabo para testar, diz-me o teu
tempo de comutação. :)
