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 é o tráfego criado pela própria Sophos Firewall. Inclui, por exemplo, consultas DNS, transferências de assinaturas e pedidos de autenticação. Em serviços como DHCP, SNMP ou Syslog, a classificação depende da função e da direção do tráfego; nem todo o tráfego destinado a um serviço da firewall corresponde a uma ligação de saída gerada pelo sistema. Por predefinição, a firewall envia o seu próprio tráfego através dos gateways WAN 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. Em Current activities > Live connections, o tráfego gerado pelo sistema apresenta, por isso, a Firewall Rule ID 0. A Local service ACL em Administration > Device access é independente: controla o acesso aos serviços locais da firewall, não a seleção do caminho SD-WAN de saída. Se for necessário um endereço IP de origem específico, uma regra SNAT normal também não é suficiente: as regras NAT traduzem tráfego encaminhado; consoante o cenário, o tráfego da firewall pode exigir 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.

Aceder a um servidor de autenticação através de IPsec route-based

Um caso especial importante é um servidor AD ou LDAP na sede central ao qual a própria firewall de uma filial deve aceder através de um túnel IPsec route-based. Uma regra normal de LAN para VPN não encaminha este pedido porque o tráfego é gerado pela firewall. Num túnel any-to-any com interfaces XFRM endereçadas, os caminhos de ida e de retorno têm, por isso, de ser planeados de forma explícita.

O exemplo seguinte utiliza 10.10.1.1 como endereço de origem visível da firewall da filial, 10.10.2.15 como servidor AD e TCP 636 para LDAPS. Estes valores não são predefinições do produto. Devem ser substituídos por um endereço da filial permitido no túnel e com rota de retorno na sede central, pelo servidor real e pelo serviço de autenticação efetivamente configurado.

1. Na firewall da filial, criar uma rota SD-WAN específica com Source networks definido como Any, o host AD como Destination networks e o serviço de autenticação necessário. TCP 636 só é adequado se o servidor utilizar realmente LDAPS. O Primary Gateway é o endereço XFRM remoto através da interface XFRM local.
2. Ativar Route only through specified gateways apenas quando o pedido deva ser deliberadamente descartado se o túnel não estiver disponível. Verificar a opção para tráfego gerado pelo sistema conforme descrito acima e ativá-la de forma controlada para este procedimento.
3. Na Device Console, utilizar primeiro show advanced-firewall para registar as entradas sys-traffic-nat existentes e a respetiva ordem. Em seguida, traduzir o endereço de origem da própria firewall para o endereço previsto da filial. Este endereço deve corresponder às regras do túnel e do caminho de retorno:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. Na firewall da sede central, criar uma rota SD-WAN de retorno do host AD para o endereço traduzido da filial através do endereço XFRM remoto. Source, Destination e Service permanecem tão específicos como no lado da filial.
5. Na sede central, criar regras com logging de VPN para a rede do servidor e da rede do servidor de volta para VPN, usando os hosts e serviços concretos. Os exemplos abrangentes com Any nas instruções do produto não são adequados como configuração permanente.
6. Ping/Ping6 em Administration > Device access para a zona VPN só é necessário se o probe target for um endereço local da firewall ou um endereço XFRM. Para um host encaminhado atrás do túnel, são necessários o túnel, a rota e, se aplicável, a Firewall Rule adequados. Após o teste, repor qualquer permissão temporária de Device Access no estado anterior.

Para a validação, executar um teste real de ligação ao servidor e um início de sessão de utilizador. Na firewall da filial, o tráfego gerado pelo sistema aparece em Current activities > Live connections com Firewall Rule ID 0; na sede central, as regras com logging esperadas devem corresponder. Packet Capture deve mostrar o pedido e a resposta nas interfaces XFRM planeadas. Um ping bem-sucedido, por si só, não confirma LDAPS, a autenticação nem o caminho de retorno.

No rollback, verificar primeiro se as duas rotas SD-WAN, as regras, os objetos de gateway e qualquer permissão temporária de Ping/Ping6 têm outras dependências. Remover a entrada NAT utilizando exatamente os mesmos seletores; se netmask ou interface também tiverem sido utilizados ao criá-la, incluí-los no comando delete:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Em seguida, utilizar show advanced-firewall para verificar se apenas a entrada pretendida desapareceu. Remover exclusivamente as rotas, regras e objetos criados para este procedimento, repor as duas opções globais de SD-WAN e a Route Precedence nos valores anteriores documentados e testar novamente o caminho de dados original.

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.

Em Routing > SD-WAN routes, também deve ficar claro como cada rota afetada reage à falha de um gateway. Com Route only through specified gateways, a firewall descarta o tráfego se os gateways especificados não estiverem disponíveis. Sem esta opção, verifica as SD-WAN Routes seguintes e depois o WAN Link Load Balancing. Se o Primary Gateway selecionado ou o SD-WAN Profile for eliminado, o SFOS elimina também a rota; se apenas o Backup Gateway for eliminado, a rota permanece com None como backup.

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 OUT/IN da rota SD-WAN.
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

Antes do teste, verifique em System services > Log settings se o registo de SD-WAN está ativo. As entradas aparecem no módulo SD-WAN do Log viewer; no caso de tráfego encaminhado, Log firewall traffic também deve estar ativo na Firewall Rule aplicável. Registe o estado anterior e restaure-o após o teste se o registo tiver sido ativado apenas temporariamente.

O tráfego gerado pelo sistema não é controlado por uma Firewall Rule. Pode ser identificado em Current activities > Live connections através da Firewall Rule ID 0 e das interfaces Inbound e Outbound. A Local service ACL continua a ser o controlo independente para o acesso aos serviços locais da firewall.

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 pedidos originados pela própria firewall, Status apresenta Generated e, quando aplicável, para respostas entregues à firewall apresenta Consumed?
• O Gateway ID, o NAT ID e as interfaces de entrada e saída correspondem ao caminho pretendido?

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

Verificar o serviço do sistema afetado

Uma correspondência de rota, por si só, não prova que o serviço funciona. Antes do teste, registe o IP de destino, a porta, o IP de origem esperado e a interface de saída esperada. Em seguida, execute exatamente a função afetada, por exemplo um pedido de autenticação ou uma consulta DNS da firewall, e verifique tanto o Packet Capture como a confirmação no sistema remoto. Utilize um destino não correspondente ou outro serviço como teste negativo; este não deve corresponder à rota específica.

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, verifique se o mesmo endereço IP de origem é mantido através dos diferentes gateways. Consulte o estado atual na Device Console com show routing reroute-connection e show routing reroute-snat-connection. O SFOS pode reencaminhar ligações após a falha de um gateway, mas as ligações SNAT têm de manter o mesmo endereço IP de origem traduzido em ambos os caminhos. MASQ ou endereços traduzidos diferentes podem interromper uma ligação ativa durante o reencaminhamento. Neste artigo, estes dois valores são apenas consultados, não alterados. 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. Reponha as rotas SD-WAN alteradas nos valores anteriores documentados; após verificar as dependências, remova as rotas criadas apenas para o teste.
4. Elimine as entradas temporárias de sys-traffic-nat utilizando exatamente os mesmos seletores e verifique o resultado com show advanced-firewall.
5. Restaure as Firewall Rules, os objetos de gateway, as permissões de Device Access e as definições de registo alteradas apenas para o teste.
6. Teste o acesso de gestão e o caminho de dados original a partir de uma rede não afetada.
7. Só depois continue a delimitar a causa efetiva.

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