Configurar e testar rotas SD-WAN na Sophos Firewall

As rotas SD-WAN no Sophos Firewall controlam o caminho que determinado tráfego deve seguir. Isto é útil com várias ligações WAN, MPLS, VPNs IPsec route-based, VoIP, serviços cloud ou aplicações que têm de passar por um fornecedor específico.

Na prática, os problemas de SD-WAN raramente surgem por causa do botão em si. Normalmente os critérios são demasiado abrangentes, os gateways são avaliados de forma incorreta, as regras NAT não encaixam, a route precedence é inesperada ou os testes são pouco precisos. Por isso, este artigo não explica apenas o caminho de configuração, mas também o planeamento, a validação e o troubleshooting típico.

Vídeo explicativo

Resposta curta

Uma rota SD-WAN é criada em Routing > SD-WAN routes. Antes disso, deve estar claro:

• que tráfego deve ser encaminhado
• que source, destination, services e utilizadores são afetados
• se DSCP, aplicação ou utilizador são critérios de correspondência realmente estáveis
• que gateway ou SD-WAN profile será usado
• se o tráfego só pode passar pelos gateways especificados
• se existem rotas estáticas, rotas VPN ou route precedence a concorrer
• se o NAT corresponde à rota
• se as ligações existentes podem realmente continuar durante failover
• como o caminho será verificado no Log viewer e no Packet capture

Uma boa rota SD-WAN é suficientemente restrita para controlar apenas o tráfego pretendido. Uma rota ampla com Any pode afetar inesperadamente redes internas, acesso de gestão ou tráfego VPN.

Quando as rotas SD-WAN fazem sentido

As rotas SD-WAN são policy routing. São usadas quando a tabela de routing normal não consegue expressar sozinha que tráfego deve usar que caminho.

Casos típicos:

• Duas ou mais ligações à Internet: enviar determinadas aplicações por uma ligação preferencial ou por failover.
• VoIP ou Teams: priorizar uma ligação com baixa latência ou pouco jitter.
• Serviços cloud: encaminhar Microsoft 365, ERP ou tráfego de backup de forma direcionada.
• VPN IPsec route-based: encaminhar tráfego por uma interface XFRM ou por um perfil de gateway.
• MPLS ou ligação entre sites: alcançar redes internas por um caminho dedicado.
• Fornecedor com vinculação por IP de origem: enviar tráfego exatamente pela interface WAN que corresponde ao public IP permitido.

Se apenas uma rede de destino estática tiver de ser alcançada por um next hop claro, uma rota estática pode ser mais simples e robusta. SD-WAN compensa quando são necessários critérios, seleção de gateway, failover ou avaliação de desempenho.

Como o Sophos avalia rotas SD-WAN

O Sophos Firewall processa rotas SD-WAN segundo uma lógica clara, não como uma coleção solta de regras:

1. Verificar a ordem em Routing > SD-WAN routes. As regras são verificadas de cima para baixo. A primeira rota correspondente vence.
2. Verificar os critérios de correspondência. Incoming interface, DSCP, source, destination, service, utilizador ou aplicação decidem se a rota corresponde.
3. Verificar a seleção de gateway. A rota usa gateways primary/backup fixos ou um SD-WAN profile.
4. Considerar estado de gateway e SLA. Em SD-WAN profiles, latência, jitter, packet loss e destinos de health check podem influenciar a escolha.
5. Verificar route precedence. Static, SD-WAN e VPN são avaliados de acordo com a ordem global.
6. Compreender o comportamento de fallback. Se não houver caminho SD-WAN correspondente disponível, pode ser usada outra rota SD-WAN ou a default route, conforme o desenho.

Por isso, não chega abrir apenas a rota individual. Ordem, estado do gateway, SLA, NAT, regra de firewall e route precedence têm de ser verificados em conjunto.

Planeamento e requisitos

Antes de criar a rota, o fluxo de dados pretendido deve ser descrito de forma concreta. Uma frase como “Teams deve ir pela WAN2” é demasiado vaga. Uma pequena matriz é melhor:

• Source zone: LAN
• Source network: Client_Net_10.20.0.0_24
• Destination: grupo de destino Microsoft 365, Internet IPv4 group, grupo FQDN ou rede concreta
• Services: HTTPS, UDP 3478-3481 ou serviços definidos
• DSCP ou aplicação: usar apenas se a marcação ou deteção de aplicação puder ser verificada de forma fiável
• Utilizador/grupo: opcional, apenas se user matching funcionar de forma estável
• Gateway primário: WAN2
• Fallback: WAN1
• Regra de fallback: permitir Default Route ou impor Route only through specified gateways
• NAT: MASQ ou SNAT-IP fixo correspondente ao gateway
• Teste: IP do cliente, destino, gateway esperado, entrada de log esperada

Quanto mais clara for esta matriz, menos será necessário adivinhar mais tarde. Especialmente em VoIP, VPN, serviços cloud e vários sites, não se deve começar com Any só porque é mais rápido clicar.

Requisitos

• Sophos Firewall em modo gateway.
• Pelo menos um gateway configurado em Network > WAN link manager ou um caminho VPN/XFRM adequado.
• Redes source e destination conhecidas.
• Regras de firewall adequadas para o tráfego.
• Regras NAT adequadas, caso o tráfego tenha de ser traduzido.
• Logging nas regras de firewall relevantes.
• Acesso a Log viewer e Diagnostics > Packet capture.

Para zonas, interfaces e gateways, consultar Configurar zonas e interfaces no Sophos Firewall. Se a rota SD-WAN envolver uma VPN IPsec route-based, consultar também Criar rota IPsec no Sophos Firewall.

Configuração e dependências

Criar rota SD-WAN

Caminho do menu:

Routing > SD-WAN routes

Procedimento:

1. Abrir Add.
2. Selecionar IPv4 ou IPv6.
3. Atribuir um nome claro, por exemplo Clients_M365_WAN2.
4. Selecionar Incoming interface ou o contexto source de acordo com o desenho. Em IPsec route-based, isto também pode ser uma interface XFRM.
5. Opcionalmente, selecionar DSCP se os pacotes de entrada estiverem marcados de forma fiável.
6. Definir source networks ou utilizadores apenas tão amplamente quanto necessário.
7. Escolher conscientemente destination networks, FQDN Hosts, Internet Services ou Internet IPv4 group.
8. Limitar services aos protocolos necessários.
9. Usar application objects apenas se a deteção de aplicação e a primeira ligação puderem ser testadas.
10. Selecionar gateway ou SD-WAN profile.
11. Decidir se Route only through specified gateways deve estar ativo.
12. Guardar a regra e colocá-la na posição correta na ordem.
13. Testar com um cliente definido.

A interface exata pode variar ligeiramente conforme a versão do SFOS. O essencial é que a rota corresponda ao flow pretendido e não capture acidentalmente mais tráfego do que o planeado.

Para destinos de Internet, Destination networks não deve ficar em Any por conveniência. A Sophos recomenda o grupo padrão Internet IPv4 group ou os intervalos padrão individuais, como Internet IPv4 (1-9), para destinos IPv4 públicos. Isto reduz o risco de redes internas seguirem subitamente para um WAN gateway devido a uma rota SD-WAN demasiado ampla.

Application objects são úteis, mas menos determinísticos do que uma rede de destino e um service. O Sophos Firewall usa detalhes da primeira sessão para associar sessões posteriores de uma aplicação a uma rota SD-WAN. Esta informação de sessão de aplicação tem uma TTL de 3600 segundos desde o início da sessão. Para caminhos críticos, deve testar-se com tráfego real da aplicação e não apenas com um ping ou policy test.

Escolher gateway e SD-WAN profile

As rotas SD-WAN podem apontar diretamente para gateways ou usar SD-WAN profiles. A abordagem correta depende do objetivo.

• Gateway fixo: útil quando o tráfego deve passar deliberadamente por uma ligação.
• Gateway com backup: útil quando uma ligação é preferida, mas o failover deve ser possível.
• SD-WAN profile com First available gateway: útil quando os gateways devem ser verificados numa ordem definida.
• SD-WAN profile com Load balancing: útil quando várias ligações devem ser usadas ao mesmo tempo e session persistence ou ponderação se adequam ao serviço.
• SD-WAN profile com SLA: útil quando latência, jitter ou packet loss devem decidir a seleção de gateway.
• Interface XFRM ou caminho VPN: útil quando IPsec route-based faz parte do desenho de routing.

Com várias ligações WAN, também se deve verificar se a monitorização do gateway, os critérios de failover e o routing do fornecedor são realistas. Um gateway pode estar tecnicamente “up” mesmo que uma aplicação de destino específica não funcione corretamente por esse fornecedor.

Em SD-WAN profiles, o destino do health check deve corresponder à aplicação. Um ping genérico para a Internet não prova que Microsoft 365, VoIP, um ERP cloud ou um gateway remoto funcionem corretamente por esse fornecedor. Para aplicações críticas, uma pequena baseline ajuda: latência normal, jitter, packet loss, gateway esperado e comportamento durante falha do fornecedor.

Com First available gateway, a firewall verifica os gateways na ordem definida e usa o primeiro caminho disponível. Com Load balancing, distribui o tráfego por vários gateways adequados; Session Persistence e Gateway Weights decidem então quão estável uma sessão permanece no mesmo gateway e com que peso cada ligação é usada.

Com Best quality, a firewall avalia apenas o critério selecionado, por exemplo latência ou packet loss. Com Custom SLA, os limites definidos para latência, jitter e packet loss têm de corresponder. Se nenhum gateway cumprir o SLA, a decisão regressa à estratégia de routing escolhida. Isto deve ser provocado conscientemente no teste; caso contrário, o comportamento em falha é apenas uma suposição.

Se Route only through specified gateways estiver ativo, o tráfego é descartado quando os gateways indicados ou o profile não estão disponíveis. Se a opção não estiver ativa, a firewall pode usar outras rotas SD-WAN correspondentes ou, por fim, a Default Route. Ambas as opções podem estar corretas: para compliance ou provider IP binding, o descarte rígido é muitas vezes melhor; para failover normal de Internet, normalmente deseja-se outro fallback.

Outro caso operacional é facilmente esquecido: se um backup gateway for eliminado, o Sophos Firewall define o valor de backup como None. Se o primary gateway falhar, a firewall usa o backup gateway. Quando o primary voltar a estar disponível, novas ligações voltam a usar o primary, mas ligações existentes podem permanecer no backup. Se, pelo contrário, um primary gateway ou um SD-WAN profile for eliminado, a rota associada pode desaparecer e o tráfego pode cair na Default Route.

A Sophos descreve a comutação dinâmica como zero-impact failover. Na prática, isto não deve ser lido como garantia para todas as aplicações. Para ligações normais, reroute-connection pode manter ligações durante uma mudança de gateway. Com SNAT, a limitação é mais clara: se for usado MASQ ou Override Source Translation com source IPs traduzidos diferentes, a firewall não rerouteia deliberadamente essas ligações SNAT, porque a alteração do source IP levaria a falhas de comunicação. Para provider IP bindings, SIP/RTP, portais bancários, cloud APIs e allowlists fixas, o failover deve por isso ser testado com tráfego real da aplicação.

Verificar ordem e route precedence

As rotas SD-WAN não existem isoladamente. Dependendo do desenho, competem com redes directly connected, rotas estáticas, rotas VPN e a route precedence global.

Perguntas importantes:

• Existe uma rota estática mais específica para o destino?
• Uma rota SD-WAN mais ampla acima corresponde ao tráfego?
• SD-WAN deve ser avaliado antes ou depois de Static?
• Está envolvida uma VPN IPsec policy-based ou route-based?
• Está envolvido tráfego SSL VPN que, do ponto de vista de routing, pertence à categoria static?
• A rota afeta apenas tráfego de clientes encaminhado ou também reply packets e system-generated traffic?

A ordem global é explicada em Alterar route precedence no Sophos Firewall com segurança. Para os casos especiais Reply Packets e System Traffic, consultar Verificar SD-WAN routing para reply packets e system traffic no Sophos Firewall.

Ativar e usar logs SD-WAN

Para testes simples de caminho, os logs de firewall muitas vezes não chegam. O Sophos Firewall também pode escrever logs específicos de SD-WAN, tornando mais visíveis o estado de health check, decisões SLA, eventos de perfil e alterações de rota.

Verificar:

1. Abrir System services > Log settings.
2. Ativar logging para SD-WAN.
3. Ativar SD-WAN profile, SD-WAN SLA e SD-WAN route conforme necessário.
4. No Log viewer, verificar o módulo SD-WAN.
5. Nos logs de firewall, abrir as opções avançadas de log e mostrar informações SD-WAN.

Isto é especialmente útil quando um gateway aparece disponível no WAN Link Manager, mas a rota SD-WAN muda para outro caminho por causa de SLA, health check ou decisão do perfil.

Não esquecer o NAT

Routing decide para onde vai um pacote. NAT decide se o endereço source ou destination é alterado. Ambos têm de encaixar.

Exemplos típicos:

• Tráfego de Internet por WAN2 pode precisar de MASQ ou de um SNAT-IP fixo em WAN2.
• Fornecedores ou serviços cloud podem permitir apenas um public IP específico.
• Em redes internas ou VPNs, NAT está muitas vezes errado porque o source-IP real deve ser preservado.
• Após failover, o public source-IP pode mudar e sistemas remotos podem terminar sessões.

Se uma rota SD-WAN parecer correta mas a aplicação continuar a falhar, NAT deve ser verificado cedo. Os fundamentos estão em Compreender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Validação e troubleshooting

Teste e validação

Um estado verde do gateway não prova que a rota SD-WAN atinja o tráfego esperado. O teste tem de verificar um flow real.

Procedimento útil:

1. Usar um cliente de teste com IP conhecido.
2. Definir exatamente destino e service.
3. Ativar logging da regra de firewall.
4. Iniciar a ligação.
5. No Log viewer, verificar source, destination, service, rule ID, NAT ID e gateway.
6. Controlar o contador de utilização da rota SD-WAN.
7. Em SD-WAN profiles, verificar também logs SD-WAN para decisões SLA ou health check.
8. Em caso de dúvida, usar Diagnostics > Packet capture com filtro restrito.
9. Simular a falha do gateway primário, se o failover tiver de ser validado.
10. Após o failback, verificar se sessões e novas ligações funcionam como esperado.

Para análise do fluxo de pacotes, consultar Testar regras Sophos Firewall com Log Viewer, Policy Test e Packet Capture. Importante: O Policy Tester não substitui um teste real de fluxo de pacotes em SD-WAN.

Erros frequentes

• Destination Any por conveniência: demasiado tráfego é capturado pelo SD-WAN. É melhor escolher redes de destino, FQDN Hosts ou Internet Services de forma mais restrita.
• Tráfego de Internet com Any em vez de Internet IPv4 group: destinos internos podem corresponder também, especialmente se a route precedence avaliar SD-WAN antes de Static.
• Rota SD-WAN demasiado acima: uma aplicação ou rota mais específica é sobreposta. É melhor verificar ordem e contadores de hits.
• NAT não corresponde ao gateway: a aplicação vê o source-IP errado ou o caminho de retorno falha. É melhor verificar regra NAT e MASQ/SNAT.
• Monitorização de gateway demasiado genérica: o gateway parece ativo, embora a aplicação de destino não esteja alcançável. É melhor escolher destinos SLA/monitorização adequados ao serviço.
• Application objects mal compreendidos: rotas baseadas em aplicações precisam de tráfego real da aplicação e podem depender da primeira sessão. É melhor validar com destino, service, Log Viewer e testes repetidos.
• Direct Web Proxy testado de forma incorreta: tráfego de Direct Web Proxy não corresponde ao SD-WAN como tráfego HTTP/HTTPS normal de clientes. Se os clientes usarem o proxy direto, um match apenas por HTTP/HTTPS muitas vezes não chega. Nesse caso, deve usar-se como service a porta de proxy direto de Web > General settings > Web proxy listening port, ou testar conscientemente o caso especial com Any. Para reply packets, source network e Incoming interface também nem sempre correspondem ao esperado.
• Logs SD-WAN desativados: alterações de caminho ficam difíceis de compreender. É melhor ativar SD-WAN profile, SLA e route logging.
• Route precedence ignorada: uma rota estática ou VPN tem efeito diferente do esperado. É melhor documentar e testar a route precedence.
• Reply traffic classificado incorretamente: respostas não usam o caminho esperado. É melhor verificar Packet Capture e a opção reply packet.
• Usage Counter mal interpretado: o contador mostra apenas tráfego que corresponde a source e destination da rota. Reply traffic pode usar o mesmo caminho e, ainda assim, não aparecer no contador esperado.
• Gateway ou profile eliminado: uma rota SD-WAN pode ser alterada ou removida quando gateways ou profiles dependentes são eliminados. Depois disso, o tráfego pode cair na Default Route.
• Várias alterações ao mesmo tempo: a causa fica pouco clara. É melhor fazer uma alteração, testar e só depois continuar.

Troubleshooting

Se a rota SD-WAN não funcionar como esperado, não se deve “resolver” o problema imediatamente com regras mais amplas. Uma análise limpa é melhor.

Verificar:

1. O pacote chega sequer à firewall?
2. Atinge a regra de firewall esperada?
3. A rota SD-WAN corresponde segundo o contador?
4. Existe outra rota SD-WAN acima que seja mais específica ou mais ampla?
5. O service corresponde realmente, por exemplo TCP/UDP e porta?
6. NAT é aplicado e isso é pretendido?
7. O pacote sai da firewall pelo gateway esperado?
8. A resposta regressa?
9. Existe uma rota estática, rota VPN ou route precedence a influenciar o caminho?
10. Os logs SD-WAN mostram uma alteração de SLA, health check ou perfil?
11. Route only through specified gateways está ativo e o tráfego está por isso a ser descartado deliberadamente?
12. Foi eliminado um gateway, SD-WAN profile ou uma regra de firewall associada migrada?
13. Em Direct Web Proxy: está a ser verificada a porta de proxy direto em vez de apenas HTTP/HTTPS?
14. Em SNAT/MASQ: o source-IP traduzido muda durante failover?

Se o Packet Capture não mostrar qualquer pacote, o problema está antes da firewall: gateway do cliente, VLAN, switch, routing local ou teste incorreto. Se o pacote chega mas usa o caminho errado, os próximos pontos são critérios SD-WAN, ordem, NAT e route precedence.

Verificação operacional

As rotas SD-WAN devem ser documentadas e verificadas regularmente após a introdução. Isto é especialmente importante em mudanças de fornecedor, novas VPNs, ligações WAN adicionais ou alterações em serviços cloud.

Documentar:

• objetivo da rota
• critérios source e destination
• DSCP, user ou application matching, caso usado
• services
• gateway ou SD-WAN profile
• definição de Route only through specified gateways
• expectativa de NAT
• comportamento de failover
• cliente e destino de teste
• owner e data de revisão

Em aplicações críticas para o negócio, também deve estar claro quem reage a falhas de fornecedor, problemas de failover ou alterações de public IPs.

Checklist

• Objetivo do tráfego e intenção da rota claramente descritos.
• Source, destination e services não definidos de forma desnecessariamente ampla.
• Destinos de Internet não modelados desnecessariamente com Any, mas com grupos de Internet ou destinos concretos.
• DSCP, user e application matching usados apenas se o tráfego real foi testado com esses critérios.
• Gateway ou SD-WAN profile escolhido conscientemente.
• Route only through specified gateways ativado ou desativado conscientemente.
• Regra de firewall e regra NAT correspondem à rota.
• Route precedence verificada.
• Logs SD-WAN ativados para validação ou troubleshooting.
• Reply packets e system-generated traffic incluídos apenas quando necessário.
• Log Viewer e Packet Capture usados para validação.
• Failover e failback testados, se fizerem parte do desenho.
• Rota documentada e com owner definido.

Perguntas frequentes