Sophos Firewall SD-WAN Verifique o roteamento para Reply Packets e System Traffic

SD-WAN As rotas em Sophos Firewall não são relevantes apenas para o tráfego clássico de cliente para Internet. Dependendo do ambiente, Reply Packets e tráfego gerado pelo sistema também podem ser afetados. É exatamente aqui que surgem frequentemente problemas de roteamento difíceis de detectar: ​​a regra parece correta, o Gateway está ativo, mas as respostas vão pelo caminho errado ou o próprio firewall não alcança um serviço pela linha esperada.

Este guia explica as duas opções CLI reply-packet e system-generate-traffic, quando verificá-las e como testar as alterações com segurança. Para a configuração normal da rota SD-WAN, Configurar e testar a rota Sophos Firewall SD-WAN e testar se ajusta primeiro. Para a ordem geral entre rotas estáticas, rotas de política SD-WAN e rotas VPN, Sophos Firewall altera com segurança Route Precedence também se encaixa.

⚠️ Essas configurações podem afetar imediatamente o roteamento produtivo. Antes de fazer uma alteração, você deve documentar o status atual, escolher uma janela de manutenção e saber o caminho de volta. Particularmente críticas são as rotas SD-WAN amplas com Any, Route Precedence na frente de rotas estáticas e roteamento SD-WAN ativado para System Traffic ou Reply Packets.

Sobre o que são as duas opções

Com as rotas SD-WAN você deve diferenciar entre o tráfego encaminhado normal, os pacotes de resposta e o tráfego gerado pelo próprio firewall. As duas opções não determinam se uma única rota SD-WAN foi construída corretamente. Em vez disso, eles expandem qual tipo de tráfego pode ser levado em consideração pelo SD-WAN Policy Routing.

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

• reply-packet: Afeta pacotes de resposta ao tráfego existente. Isso permite que o caminho de retorno seja influenciado por meio de SD-WAN em determinados cenários não WAN.
• system-generate-traffic: Afeta o tráfego gerado pelo próprio firewall. Isso permite que conexões específicas do firewall sejam roteadas por meio de rotas SD-WAN definidas.

Ambas as opções não devem ser ativadas cegamente só porque “SD-WAN não funciona”. Primeiro, deve ficar claro se o tráfego Reply Packets ou gerado pelo sistema é realmente afetado. Para conexões normais, a causa real geralmente é a regra de firewall, o status NAT, Route Precedence, Gateway ou uma rota SD-WAN que é muito ampla.

Reply Packets

Reply Packets são pacotes de resposta ao tráfego existente. Sophos Firewall geralmente impõe roteamento simétrico para tais respostas em interfaces WAN: os pacotes de resposta devem retornar pela mesma interface WAN por meio da qual a conexão original entrou. A opção reply-packet é particularmente relevante se os pacotes de resposta forem levados em consideração em determinados cenários de roteamento de política SD-WAN. Um exemplo típico é o roteamento assimétrico em interfaces não WAN, como entre LAN e DMZ.

A restrição importante é: se o tráfego original for executado pela rota padrão ou pelo balanceamento de carga do link WAN, as rotas SD-WAN não se aplicam a este Reply Packets. O firewall continua a usar o caminho de retorno apropriado através da interface da conexão original.

Perguntas típicas de teste:

• É realmente tráfego de resposta e não uma nova conexão?
• O tráfego passa por WAN, LAN, DMZ, XFRM ou outra zona?
• Existe uma rota SD-WAN que se destina a influenciar intencionalmente a rota de retorno?
• A rota é muito larga, por exemplo destino Any?
• Route Precedence entra em vigor antes de uma rota estática ou rota VPN?

Tráfego gerado pelo sistema

O tráfego gerado pelo sistema é o tráfego gerado pelo próprio Sophos Firewall. Dependendo do ambiente, isso pode incluir DNS, NTP, Sophos Central, Syslog, atualizações, monitoramento, serviços de autenticação ou conexões de diagnóstico.

Com esse tráfego, o firewall não reconhece uma interface de entrada normal e uma rede de origem normal como acontece com o tráfego de cliente encaminhado. É por isso que você deve planejar rotas SD-WAN particularmente de perto para o tráfego gerado pelo sistema: as redes alvo e Services devem ser escolhidas de forma sensata. Caso contrário, uma rota muito ampla pode levar inesperadamente o gerenciamento ou o tráfego do sistema para um caminho errado.

Além disso, aplicam-se dois limites práticos:

• Se todos os gateways configurados em Network > WAN link manager estiverem marcados como Somente Backup, o firewall não encaminhará o tráfego gerado pelo sistema através deles. Pelo menos um Gateway deve estar Ativo.
• O tráfego RED gerado pelo sistema em UDP 3410 é tráfego de Camada 2. As rotas SD-WAN não se aplicam a isso.

Quando verificar essas configurações

As duas opções são particularmente relevantes para projetos de roteamento mais complexos. Em ambientes WAN simples e únicos, eles raramente são a primeira alavanca.

Gatilhos úteis:

• O tráfego nativo do firewall não usa o caminho WAN ou VPN esperado.
• Syslog, Central, DNS, NTP ou monitoramento devem ser executados em uma linha específica.
• IPsec VPN baseado em rota com interfaces XFRM é usado junto com rotas SD-WAN.
• VoIP ou outro tráfego sensível funciona apenas em uma direção via SD-WAN/VPN.
• Packet Capture mostra respostas em uma interface diferente da esperada.
• Após uma atualização, SD-WAN, IPsec ou NAT se comporta de maneira diferente de antes.
• Uma ampla rota SD-WAN afeta repentinamente as redes internas ou o acesso de gerenciamento. Para cenários IPsec, você também deve incluir Sophos Firewall IPsec VPN Solução de problemas. Para conexões individuais, teste de regra Sophos Firewall com Log Viewer e Packet Capture geralmente é um ponto de partida melhor.

Ver o status atual

Os comandos são executados em Device Console, não em Advanced Shell. Se o acesso ao console ainda não estiver claro, Conectar Sophos Firewall via SSH ajudará.

Verifique o status de Reply Packets:

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

Verifique o status do tráfego gerado pelo sistema:

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

Além disso, WebAdmin em Routing > SD-WAN routes mostra na dica de ferramenta de informações de roteamento se o roteamento SD-WAN está ativo para tráfego gerado pelo sistema e Reply Packets.

Antes de fazer qualquer alteração, a edição atual deve ser documentada. Isto é importante porque uma reversão posterior só é possível de forma limpa se o estado anterior for conhecido.

Habilitar opções

SD-WAN Ativar roteamento para Reply Packets:

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

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

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

Em seguida, execute os comandos de status novamente e documente a saída.

⚠️ Não faça várias alterações de rota ao mesmo tempo. Se Route Precedence, rota SD-WAN, regra NAT e essas opções CLI forem alteradas ao mesmo tempo, será difícil atribuir claramente um erro posteriormente.

Fluxo seguro para mudanças

Um processo pragmático reduz o risco:

1. Defina especificamente o tráfego afetado: Origem, Destino, Serviço, Zona, Gateway esperado.
2. Documente rotas SD-WAN, gateways e Route Precedence existentes.
3. Verifique se o Destino Any é realmente necessário.
4. Documente o status atual de reply-packet e system-generate-traffic.
5. Altere apenas uma opção.
6. Execute o teste com um exemplo claro de tráfego.
7. Verifique os contadores Log Viewer, Packet Capture e Gateway.
8. Documente o resultado e só então faça novos ajustes. Se o acesso de gerenciamento puder ser afetado, um meio secundário de acesso deverá estar disponível: console local, outro caminho de acesso interno ou acesso a partir de uma rede de gerenciamento não afetada.

Validação após alteração

Após a ativação, um status Gateway verde não é suficiente. Você tem que verificar se o tráfego desejado realmente segue o caminho esperado.

Registros Log Viewer e SD-WAN

Os eventos relacionados ao firewall e ao SD-WAN devem ser verificados no Visualizador de log. Para regras de firewall relevantes, Log firewall traffic deve estar ativo. Sem registrar, muitas vezes você vê apenas parte da decisão.

Para verificar:

• Qual Firewall Rule ID foi atingido?
• Qual NAT Rule ID é usado?
• Qual Gateway ou qual interface aparece no log?
• Houve alguma queda, violação de política ou decisões inesperadas sobre recursos de segurança?

Packet Capture

O fluxo real de pacotes pode ser verificado com Diagnostics > Captura de pacotes. Para questões de roteamento, o filtro deve ser estreito: Origem IP, Destino IP, Porta e Protocolo.

A comparação é importante:

• O pacote chega na interface esperada?
• Sai do firewall na interface esperada?
• A resposta voltará?
• NAT é usado?
• A rota de retorno é plausível para Reply Packets?

Use Sophos Firewall Packet Capture em WebAdmin é adequado para operação e interpretação.

Verifique os serviços do sistema

No caso de tráfego gerado pelo sistema, você deve testar especificamente o serviço afetado:

• DNS: Execute a pesquisa de DNS no firewall e verifique o caminho de destino.
• NTP: Verifique o status da hora e a disponibilidade do servidor NTP.
• Syslog: Verifique a mensagem de teste ou o log atual no coletor.
• Sophos Central: Verifique a conexão central e os relatórios.
• Monitoramento: Verifique SNMP, sFlow ou verificações externas no coletor.

Se o tráfego gerado pelo sistema não estiver visível, você também deverá verificar se a rota SD-WAN deve corresponder apenas às redes de origem ou às interfaces de entrada. Esses critérios não estão disponíveis para o tráfego de propriedade do firewall, assim como para o tráfego do cliente.

Erros típicos

• Rota SD-WAN com destino Any para caminhos internos: O tráfego interno ou acesso de gerenciamento pode ser roteado via WAN. Grupos-alvo da Internet ou redes-alvo específicas são melhores.
• Route Precedence define SD-WAN antes de Estático: Redes diretamente conectadas ou estáticas podem ser inesperadamente correspondidas por SD-WAN. Verifique Route Precedence e defina Static na frente de SD-WAN, se necessário.
• system-generate-traffic ativo sem limitação de destino: Serviços específicos de firewall podem usar o caminho errado. Portanto, defina as redes de destino e Services de perto.
• Reply Packets confundido com novas conexões normais: Então a causa errada é processada. Packet Capture e verifique a direção do fluxo.
• Várias alterações de roteamento ao mesmo tempo: A causa do erro permanece obscura. Mude gradualmente e documente cada teste.
• Sem acesso de gerenciamento alternativo: WebAdmin ou SSH podem ser perdidos na rede afetada. Preparar janela de manutenção e caminho de acesso.

Um risco particularmente crítico surge quando várias condições se reúnem: Route Precedence está em SD-WAN antes da estática, uma rota SD-WAN ampla usa Any e o roteamento SD-WAN para tráfego gerado pelo sistema ou Reply Packets está ativo. Neste caso, o acesso a WebAdmin ou SSH de determinadas sub-redes internas pode ser perdido.

Interação com NAT, IPsec e VoIP

SD-WAN raramente está envolvido sozinho. NAT, IPsec ou tráfego específico de aplicativo desempenham um papel em muitas interrupções. O que é importante para SNAT é se a mesma fonte IP é mantida em diferentes gateways. Se MASQ ou endereços de origem traduzidos diferentes forem usados, o failover ou o novo roteamento poderão causar problemas de comunicação. Para o básico, Entenda que NAT se encaixa em Sophos Firewall.

Para VPNs IPsec baseadas em rota, as interfaces XFRM podem ser usadas em rotas SD-WAN ou perfis SD-WAN. Em seguida, o status IPsec, a rota SD-WAN, Route Precedence e as regras de firewall devem ser verificados juntos. Os princípios básicos do VPN baseado em rota são categorizados em Rota IPsec em Sophos Firewall. Se você tiver problemas de VoIP, também vale a pena dar uma olhada em SIP, RTP, NAT e SD-WAN. As notas de versão SFOS-22.0-MR1 documentam um problema corrigido em que o áudio VoIP só funcionava unidirecionalmente por meio de VPN baseado em rota com roteamento SD-WAN após a atualização para SFOS 22.0 GA. O processo prático pode ser encontrado em Sophos Firewall Corrigir problemas de VoIP com SIP e RTP.

Reversão

Antes de fazer alterações, o status antigo deve ser documentado. Se o acesso à gestão, os serviços do sistema ou o tráfego produtivo forem afetados, a improvisação não será mais necessária. Primeiro restaure o estado anterior.

Praticamente isso significa:

1. Redefina os valores anteriores documentados para reply-packet e system-generate-traffic.
2. Retorne Route Precedence ao pedido anterior, se alterado.
3. Desative temporariamente as rotas SD-WAN que sejam muito largas ou limite-as a destinos específicos.
4. Teste o acesso de gerenciamento de uma rede não afetada.
5. Em seguida, restrinja ainda mais a causa real.

Se o acesso a WebAdmin e SSH for perdido em uma sub-rede interna, mas ainda for possível em outra sub-rede, a rota ampla SD-WAN, Route Precedence e as duas opções CLI deverão ser verificadas primeiro.

Lista de verificação

• Status atual das duas opções CLI documentadas.
• Tráfego afetado especificamente definido.
• Rota SD-WAN não construída desnecessariamente ampla com Any.
• Route Precedence verificado.
• Pelo menos um WAN-Gateway para System Traffic disponível como Ativo.
• Conexão de gerenciamento alternativa preparada.
• Fiz apenas uma alteração por teste.
• Log Viewer e Packet Capture utilizados para validação.
• NAT, IPsec e regras de firewall verificadas.
• Resultado e reversão documentados no diário de operações.

PERGUNTAS FREQUENTES