SD-WAN: Reply Packets e System Traffic na Sophos Firewall

As rotas SD-WAN na Sophos Firewall não são relevantes apenas para o tráfego clássico entre clientes e a Internet. Consoante o ambiente, também podem ser afetados Reply Packets e tráfego gerado pelo sistema. É precisamente nestas situações que surgem frequentemente problemas de routing difíceis de detetar: a regra parece correta, o gateway está ativo, mas as respostas seguem pelo caminho errado ou a própria firewall não alcança um serviço através da ligação esperada.

Este guia explica as duas opções CLI reply-packet e system-generate-traffic, quando devem ser verificadas e como testar alterações em segurança. Para a configuração normal de uma rota SD-WAN, consulte primeiro Configurar e testar uma rota SD-WAN na Sophos Firewall. Para compreender a ordem geral entre rotas estáticas, SD-WAN Policy Routes e rotas VPN, consulte também Alterar a Route Precedence com segurança na Sophos Firewall.

⚠️ Estas definições podem afetar imediatamente o routing em produção. Antes de qualquer alteração, documente o estado atual, escolha uma janela de manutenção e prepare um caminho claro de retorno. São especialmente críticas as rotas SD-WAN abrangentes com Any, uma Route Precedence que coloque SD-WAN antes de Static e a ativação do routing SD-WAN para System Traffic ou Reply Packets.

Conceitos básicos e limitações

O que controlam as duas opções

Nas rotas SD-WAN, é necessário distinguir entre tráfego encaminhado normal, pacotes de resposta e tráfego gerado pela própria firewall. As duas opções não determinam se uma rota SD-WAN individual está corretamente configurada. Em vez disso, alargam os tipos de tráfego que podem ser considerados pelo SD-WAN Policy Routing.

As duas opções têm funções diferentes:

• reply-packet: Afeta os pacotes de resposta de tráfego existente. Permite influenciar o caminho de retorno através de SD-WAN em determinados cenários que não envolvem WAN.
• system-generate-traffic: Afeta o tráfego gerado pela própria firewall. Permite encaminhar ligações originadas na firewall através de rotas SD-WAN definidas.

Nenhuma das opções deve ser ativada indiscriminadamente apenas porque “o SD-WAN não funciona”. Primeiro, confirme se o problema afeta realmente Reply Packets ou tráfego gerado pelo sistema. Em ligações normais, a causa está muitas vezes na Firewall Rule, no NAT, na Route Precedence, no estado do gateway ou numa rota SD-WAN demasiado abrangente.

Reply Packets

Reply Packets são pacotes de resposta de tráfego existente. Nas interfaces WAN, a Sophos Firewall impõe geralmente routing simétrico para estas respostas: os pacotes devem regressar pela mesma interface WAN através da qual entrou a ligação original.

A opção reply-packet é sobretudo relevante quando se pretende que os pacotes de resposta sejam considerados pelo SD-WAN Policy Routing em determinados cenários. Um exemplo típico é o routing assimétrico em interfaces que não são WAN, como entre LAN e DMZ.

Existe uma limitação importante: se o tráfego original utilizar a Default Route ou WAN Link Load Balancing, as rotas SD-WAN não se aplicam a estes Reply Packets. A firewall continua a utilizar o caminho de retorno adequado através da interface da ligação original.

Perguntas úteis para a análise:

• Trata-se realmente de tráfego de resposta e não de uma nova ligação?
• O tráfego passa por WAN, LAN, DMZ, XFRM ou outra zona?
• Existe uma rota SD-WAN destinada a influenciar deliberadamente o caminho de retorno?
• A rota é demasiado abrangente, por exemplo com Destination Any?
• A Route Precedence faz com que a rota seja avaliada antes de uma rota estática ou VPN?

Tráfego gerado pelo sistema

O tráfego gerado pelo sistema tem origem na própria Sophos Firewall. Consoante o ambiente, pode incluir consultas DNS, transferências de assinaturas, pedidos de autenticação, DHCP, NTP, Syslog ou ligações ao Sophos Central. Por predefinição, este tráfego utiliza os gateways WAN ativos em Network > WAN link manager.

Neste tipo de tráfego, Incoming interface e Source networks não são conhecidos e, por isso, não são seletores adequados. Numa rota SD-WAN destinada ao tráfego da firewall, apenas Destination networks e Services devem ser limitados de forma específica; os restantes critérios permanecem abrangentes. Caso contrário, uma rota com Destination Any pode encaminhar inesperadamente tráfego do sistema e de gestão por um caminho incorreto.

Não é necessária uma Firewall Rule normal para este tráfego. Por esse motivo, em Current activities > Live connections, o tráfego gerado pelo sistema apresenta a Firewall Rule ID 0. Se for necessária uma Source IP específica, uma regra SNAT normal também não é suficiente: as regras NAT traduzem tráfego encaminhado e, consoante o cenário, o tráfego da firewall requer sys-traffic-nat na Device Console.

Aplicam-se ainda duas limitações práticas:

• Se todos os gateways configurados em Network > WAN link manager estiverem marcados apenas como Backup, a firewall não encaminha tráfego gerado pelo sistema através deles. Pelo menos um gateway deve estar Active.
• O tráfego RED gerado pelo sistema na porta UDP 3410 é tráfego de Layer 2. As rotas SD-WAN não se aplicam a esse tráfego.

Preparação

Quando verificar estas definições

As duas opções são especialmente relevantes em arquiteturas de routing mais complexas. Em ambientes simples com uma única WAN, raramente são o primeiro ponto a alterar.

Situações que justificam a verificação:

• O tráfego originado na firewall não utiliza o caminho WAN ou VPN esperado.
• Syslog, Central, DNS, NTP ou monitorização deve utilizar uma ligação específica.
• Uma route-based IPsec VPN com interfaces XFRM é utilizada em conjunto com rotas SD-WAN.
• VoIP ou outro tráfego sensível funciona apenas num sentido através de SD-WAN/VPN.
• O Packet Capture mostra respostas numa interface diferente da esperada.
• Após uma atualização, SD-WAN, IPsec ou NAT comportam-se de forma diferente.
• Uma rota SD-WAN abrangente começa subitamente a afetar redes internas ou o acesso de gestão.

Em cenários IPsec, consulte também Resolver problemas de IPsec VPN na Sophos Firewall. Para analisar ligações individuais, Testar uma regra da Sophos Firewall com Log Viewer e Packet Capture é frequentemente o melhor ponto de partida.

Apresentar o estado atual

Os comandos são executados na Device Console, não na Advanced Shell. Se o acesso à consola ainda não estiver configurado, consulte Ligar à Sophos Firewall através de SSH.

Verificar o estado de Reply Packets:

show routing sd-wan-policy-route reply-packet

Verificar o estado do tráfego gerado pelo sistema:

show routing sd-wan-policy-route system-generate-traffic

Além disso, em Routing > SD-WAN routes, o WebAdmin indica no tooltip das informações de routing se o routing SD-WAN está ativo para tráfego gerado pelo sistema e Reply Packets.

A Route Precedence atual também deve ser documentada:

system route_precedence show

Documente o resultado atual antes de qualquer alteração. Um rollback só pode ser efetuado de forma controlada se o estado anterior for conhecido.

Alterar a configuração

Ativar ou desativar as opções

Ativar o routing SD-WAN para Reply Packets:

set routing sd-wan-policy-route reply-packet enable

Ativar o routing SD-WAN para tráfego gerado pelo sistema:

set routing sd-wan-policy-route system-generate-traffic enable

Em seguida, execute novamente os comandos de estado e documente o resultado.

Para desativar especificamente as opções, utilize os comandos inversos:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Não efetue várias alterações de routing em simultâneo. Se a Route Precedence, a rota SD-WAN, a regra NAT e estas opções CLI forem alteradas ao mesmo tempo, torna-se muito difícil identificar posteriormente a causa de um problema.

Procedimento seguro para alterações

Um procedimento pragmático reduz o risco:

1. Defina concretamente o tráfego afetado: Source, Destination, Service, Zone e gateway esperado.
2. Documente as rotas SD-WAN, os gateways e a Route Precedence existentes.
3. Confirme se Destination Any é realmente necessário.
4. Documente o estado atual de reply-packet e system-generate-traffic.
5. Altere apenas uma opção.
6. Realize um teste com um exemplo de tráfego claramente definido.
7. Verifique o Log Viewer, o Packet Capture e os contadores do gateway.
8. Documente o resultado e só depois efetue outras alterações.

Se o acesso de gestão puder ser afetado, deve existir uma segunda forma de acesso: consola local, outro caminho interno ou acesso através de uma rede de gestão não afetada.

Validação após a alteração

Após a ativação, um estado verde do gateway não é suficiente. É necessário confirmar se o tráfego pretendido utiliza realmente o caminho esperado.

Live Connections, Log Viewer e contadores SD-WAN

Para tráfego encaminhado, verifique no Log viewer os eventos relacionados com Firewall Rules e SD-WAN. Nas Firewall Rules relevantes, Log firewall traffic deve estar ativo. O tráfego gerado pelo sistema, por outro lado, não é controlado por uma Firewall Rule. Pode ser identificado em Current activities > Live connections pela Firewall Rule ID 0 e pelas interfaces Inbound e Outbound.

Pontos a verificar:

• Trata-se de tráfego encaminhado com uma Firewall Rule ID ou de tráfego do sistema com ID 0?
• Que NAT Rule ID é utilizada no tráfego encaminhado?
• Que gateway ou interface aparece no registo?
• Existem drops, violações de política ou decisões inesperadas de Security Features?
• A rota SD-WAN apresenta apenas OUT para requests ou também IN para replies? Os contadores só aparecem quando os critérios de Source e Destination correspondem à direção respetiva.

Packet Capture

Em Diagnostics > Packet capture, é possível verificar o fluxo real de pacotes. Para problemas de routing, limite o filtro a Source IP, Destination IP, Port e Protocol.

Compare os seguintes pontos:

• O pacote chega à interface esperada?
• Sai da firewall pela interface esperada?
• A resposta regressa?
• É aplicado NAT?
• O caminho de retorno dos Reply Packets é plausível?

Para utilizar e interpretar esta função, consulte Utilizar o Packet Capture no WebAdmin da Sophos Firewall.

Verificar serviços do sistema

No caso de tráfego gerado pelo sistema, teste especificamente o serviço afetado:

• DNS: Efetue uma consulta DNS na firewall e verifique o caminho até ao destino.
• NTP: Verifique o estado da hora e a acessibilidade do servidor NTP.
• Syslog: Confirme uma mensagem de teste ou um registo recente no coletor.
• Sophos Central: Verifique a ligação ao Central e o reporting.
• Monitorização: Verifique SNMP, sFlow ou testes externos no coletor.

Se o tráfego gerado pelo sistema não for visível, confirme se a rota exige desnecessariamente critérios de Source networks, Incoming interface, utilizador ou aplicação. No tráfego originado pela firewall, a decisão deve basear-se sobretudo em Destination networks e Services. Se o sistema remoto exigir um endereço de origem específico, verifique também a Source IP e uma eventual configuração sys-traffic-nat.

Erros e dependências

Erros frequentes

• Rota SD-WAN com Destination Any para caminhos internos: O tráfego interno ou o acesso de gestão pode ser encaminhado através da WAN. Prefira grupos de destinos da Internet ou redes de destino específicas.
• Route Precedence coloca SD-WAN antes de Static: Redes diretamente ligadas ou estáticas podem corresponder inesperadamente a uma rota SD-WAN. Verifique a Route Precedence e, se necessário, coloque Static antes de SD-WAN.
• system-generate-traffic ativo sem limitação do destino: Serviços originados na firewall podem utilizar o caminho errado. Restrinja as redes de destino e os Services.
• Reply Packets confundidos com novas ligações normais: Nesse caso, está a ser investigada a causa errada. Verifique o Packet Capture e a direção do fluxo.
• Procura de uma Firewall Rule para tráfego gerado pelo sistema: Este tráfego tem a Firewall Rule ID 0; as Firewall Rules normais não o controlam. Verifique a rota, o serviço, a Live Connection e, se necessário, sys-traffic-nat.
• Direct Web Proxy tratado como tráfego HTTP/HTTPS normal: Com o proxy direto, a rota SD-WAN deve incluir a porta configurada em Web > General settings > Web proxy listening port. Em alternativa, Services pode estar definido como Any. Source Network e Incoming Interface não correspondem aos Reply Packets do tráfego de proxy; o caminho de retorno requer pelo menos um gateway WAN ou uma rota estática adequada.
• Várias alterações de routing em simultâneo: A causa do problema permanece incerta. Altere um elemento de cada vez e documente cada teste.
• Ausência de acesso de gestão alternativo: O acesso ao WebAdmin ou por SSH pode perder-se na rede afetada. Prepare uma janela de manutenção e um caminho de acesso alternativo.

Existe um risco particularmente elevado quando se verificam várias condições em simultâneo: a Route Precedence coloca SD-WAN antes de Static, uma rota SD-WAN abrangente utiliza Any e o routing SD-WAN para tráfego gerado pelo sistema ou Reply Packets está ativo. Neste caso, pode perder-se o acesso ao WebAdmin ou por SSH a partir de determinadas sub-redes internas.

Interação com NAT, IPsec e VoIP

O SD-WAN raramente é o único componente envolvido. Em muitos problemas, NAT, IPsec ou tráfego específico de aplicações também desempenham um papel.

No caso de SNAT, é importante saber se o mesmo Source IP é mantido através dos diferentes gateways. Se forem utilizados MASQ ou diferentes endereços Source traduzidos, um failover ou novo routing pode causar problemas de comunicação. Para os conceitos básicos, consulte Compreender o NAT na Sophos Firewall.

Nas route-based IPsec VPNs, as interfaces XFRM podem ser utilizadas em rotas SD-WAN ou SD-WAN Profiles. Nesse caso, verifique em conjunto o estado de IPsec, a rota SD-WAN, a Route Precedence e as Firewall Rules. Os conceitos fundamentais encontram-se em Rota IPsec na Sophos Firewall.

Em problemas de VoIP, verifique também SIP, RTP, NAT e SD-WAN. As release notes do SFOS 22.0 MR1 documentam a correção de um problema no qual, após uma atualização para SFOS 22.0 GA, o áudio VoIP funcionava apenas num sentido através de uma route-based VPN com routing SD-WAN. O procedimento prático encontra-se em Resolver problemas de VoIP com SIP e RTP na Sophos Firewall.

Rollback e conclusão

Rollback

O estado anterior deve ser documentado antes de qualquer alteração. Se o acesso de gestão, os serviços do sistema ou o tráfego de produção forem afetados, não continue a improvisar. Primeiro, restaure o estado anterior.

Na prática:

1. Reponha os valores anteriores documentados de reply-packet e system-generate-traffic com os comandos enable ou disable adequados.
2. Reponha a Route Precedence na ordem anterior, caso tenha sido alterada.
3. Desative temporariamente rotas SD-WAN demasiado abrangentes ou limite-as a destinos específicos.
4. Teste o acesso de gestão a partir de uma rede não afetada.
5. Só depois continue a investigar a causa real.

Se o acesso ao WebAdmin e por SSH se perder numa sub-rede interna, mas continuar disponível noutra, verifique primeiro a rota SD-WAN abrangente, a Route Precedence e as duas opções CLI.

Lista de verificação

• Estado atual das duas opções CLI documentado.
• Route Precedence documentada com system route_precedence show.
• Tráfego afetado definido concretamente.
• Para tráfego do sistema, utilizados apenas Destination e Service como critérios decisivos de correspondência.
• Rota SD-WAN não configurada de forma desnecessariamente abrangente com Any.
• Route Precedence verificada.
• Pelo menos um gateway WAN para System Traffic definido como Active.
• Ligação de gestão alternativa preparada.
• Apenas uma alteração efetuada por teste.
• Log Viewer e Packet Capture utilizados para validação.
• NAT, IPsec e Firewall Rules também verificados.
• Resultado e rollback documentados no diário de operações.

FAQ