Criar uma rota IPsec no Sophos Firewall

Uma ipsec_route manual pertence ao IPsec baseado em políticas. Ela associa um host ou uma rede de destino a um túnel baseado em políticas existente. No entanto, não amplia os Seletores de Tráfego nem substitui as regras de firewall e NAT, tampouco o caminho de retorno no par remoto.

Este comando não é adequado para IPsec baseado em rotas. Em um túnel Any-to-any, a interface XFRM recebe um endereço IP; as rotas estáticas, SD-WAN ou dinâmicas passam então a determinar o caminho. Em um túnel baseado em rotas com Seletores de Tráfego, o SFOS cria a rota automaticamente. Não é possível atribuir um endereço IP ou rotas personalizadas à interface XFRM associada.

⚠️ Uma rota muito ampla ou atribuída ao túnel errado pode redirecionar o tráfego de produção. Registre o estado inicial antes de fazer a alteração e mantenha o comando exato de exclusão à mão.

Quando uma rota IPsec manual é apropriada

O caso típico é o tráfego encaminhado cujo endereço é alterado por DNAT ou SNAT. O NAT altera o endereço, mas não a decisão de roteamento. Portanto, pode ser necessária uma rota adicional para a rede remota.

Verifique o seguinte antes de executar o comando:

A conexão em Site-to-site VPN > IPsec > IPsec connections é baseada em políticas.
Os Seletores de Tráfego locais e remotos incluem os endereços apresentados ao processamento IPsec após NAT.
As regras de firewall e NAT correspondem ao tráfego de teste definido. Para SNAT com IPsec baseado em políticas, Outbound interface deve estar definida como Any.
O par remoto espera o endereço de origem visível e tem uma rota de retorno através do mesmo túnel.
Nenhuma rota estática ou SD-WAN existente, nem a Route Precedence global, direciona o destino para outro caminho.

Uma rota manual não corrige uma máscara de rede incorreta, um seletor incompatível ou uma regra de bloqueio. Configurar uma VPN IPsec site-to-site no Sophos Firewall explica os tipos de túnel.

Registrar o estado inicial no Console do dispositivo

No WebAdmin, abra admin > Console e selecione 4. Device console. Para acesso via SSH, Conectar ao Sophos Firewall via SSH leva ao mesmo menu.

Primeiro, exiba as rotas IPsec manuais existentes e a ordem global:

system ipsec_route show
system route_precedence show

Salve a saída junto com o nome do túnel, os Seletores de Tráfego, o Firewall Rule ID, o NAT Rule ID e o fluxo de teste planejado. No SFOS 22, as rotas VPN baseadas em políticas geradas automaticamente e as entradas ipsec_route manuais pertencem à categoria vpn. Essas rotas não aparecem na tabela de roteamento do WebAdmin; portanto, ip route show table 220 não é uma prova confiável do contrário.

Não altere a Route Precedence como tarefa secundária. Essa configuração é global e afeta outras conexões. Se a alteração for realmente necessária, Alterar com segurança a Route Precedence do Sophos Firewall apresenta o procedimento separado, com reversão baseada nos valores originais.

Criar a rota usando um exemplo controlado de NAT

Sophos documenta este caso de uso estritamente definido:

Um túnel baseado em políticas HO_to_Branch conecta a rede local 192.168.2.0/24 à rede remota 192.168.3.0/24.
O servidor local real 172.16.16.10 está fora do seletor local.
O par remoto o acessa pelo endereço 192.168.2.1. Esse endereço substituto pertence ao seletor local e, no exemplo, é o endereço da interface LAN do firewall.

Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Substitua a rede, os endereços e o nome do túnel por seus próprios valores. O endereço substituto deve corresponder à seleção local da Fase 2; a rede de destino remota deve ser abrangida pelo túnel existente.

1. Atribuir a rede remota ao túnel

Execute este comando no Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Para net, o SFOS espera a máscara completa em notação decimal pontuada. Use o intervalo de destino mais restrito exigido pela aplicação. O comando de reversão correspondente é:

system ipsec_route del net 192.168.3.0/255.255.255.0

O comando de exclusão não inclui o nome do túnel. Antes de excluir, use system ipsec_route show para confirmar que o destino é inequívoco. Não exclua entradas ambíguas com base apenas em suposições.

Para um único host de destino, o console aceita o seguinte formato:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Uma rota de host é mais específica, mas só está correta quando exatamente esse host é o destino e os Seletores de Tráfego correspondem.

2. Configurar o DNAT e o SNAT reflexivo

Em Rules and policies > NAT rules > Add NAT rule > New NAT rule, crie uma regra DNAT. Original source é 192.168.3.0/24, Translated source permanece Original, Original destination é 192.168.2.1, e Translated destination é 172.16.16.10.
Ative Create reflexive rule.
Abra a regra gerada Reflexive_NAT#_<DNAT_rule_name>. Para Translated source, selecione um objeto host IP com 192.168.2.1. Crie o objeto em Hosts and services > IP host > Add. Sophos não pode traduzir diretamente para uma interface nesta regra reflexiva.
Verifique a ordem, o status e o registro de ambas as regras NAT e da regra de firewall associada.

Não adicione uma regra MASQ ampla ou permita adicionalmente o servidor real através do túnel com seu endereço não traduzido. Entender o NAT no Sophos Firewall explica a correspondência e a ordem das regras.

Validar o caminho dos dados

Um túnel verde e um ping não comprovam a tradução NAT nem o caminho de retorno. Para a validação, defina um fluxo de aplicação real, por exemplo, uma conexão TCP do cliente remoto para o serviço publicado do servidor.

Execute system ipsec_route show novamente. A rede de destino deve estar atribuída exatamente uma vez ao túnel pretendido.
Gere uma conexão controlada de 192.168.3.0/24 para 192.168.2.1 no serviço permitido.
Filtre o Log viewer por Source, Destination e Firewall Rule ID. Na visualização detalhada, src_trans_ip mostra o endereço de origem realmente traduzido de forma mais confiável do que a visualização resumida.
Abra Monitor & analyze > Diagnostics > Packet capture e filtre pelo cliente, pelo endereço substituto e pelo servidor real. O ID de regra e o NAT ID devem corresponder às regras documentadas; as interfaces de entrada e saída devem mostrar o caminho pretendido.
No par remoto, verifique se as respostas de 192.168.2.1 são esperadas e retornadas através do mesmo túnel.
Teste um host ou serviço próximo que não seja permitido. Esse teste negativo ainda deve falhar e confirma que a rota e as regras não são amplas demais.

Uma SA ativa ou contadores de bytes crescentes, por si sós, não são suficientes. Para uma investigação completa, consulte Resolução de problemas de VPN IPsec no Sophos Firewall; para analisar regras e capturas, consulte Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

Reverter completamente a alteração

Primeiro, encerre todas as novas sessões de teste. Restaure o DNAT e o SNAT reflexivo, separadamente, aos estados anteriores documentados; alterar posteriormente a regra DNAT não remove automaticamente a regra reflexiva.

Em seguida, exclua apenas a rota recém-criada:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Remova o novo objeto de host IP somente quando Object usage não mostrar mais nenhuma referência. Em seguida, repita o fluxo de controle original e o teste negativo. A Route Precedence registrada anteriormente deve permanecer inalterada.

Se apenas a rota tiver sido excluída por engano, o comando add salvo restaurará a entrada exata:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Isolar sistematicamente erros comuns

A rota existe, mas o tráfego vai para a WAN

Verifique system ipsec_route show, a Route Precedence e as rotas SD-WAN concorrentes. No SFOS 22, a ausência de uma entrada na tabela de roteamento do WebAdmin ou na tabela 220 não constitui evidência contra a rota IPsec. Na Route Precedence, vpn tem prioridade sobre static apenas para o tráfego destinado à zona WAN; por isso, as zonas e o caminho real até o destino também devem ser verificados.

O túnel está ativo, mas NAT não se aplica

Compare os endereços originais e traduzidos com os Seletores de Tráfego. Para SNAT baseado em políticas, Outbound interface deve ser Any. Em seguida, verifique Firewall Rule ID, NAT ID e src_trans_ip, em vez de confiar apenas no status do túnel.

Com Any, o firewall usa a Translated source da regra SNAT correspondente, mesmo quando Override source translation (SNAT) está ativado para interfaces de saída específicas. Uma regra que lista apenas determinadas portas WAN em Outbound interface, incluindo a regra SNAT padrão habitual, não corresponde a esse tráfego IPsec baseado em políticas. A explicação de NAT no artigo sobre IPsec site-to-site esclarece essa interação; ela não justifica uma alteração generalizada das opções de substituição. Após uma correção pontual da regra, gere um novo fluxo de aplicação controlado e verifique novamente NAT ID, src_trans_ip, os seletores e o caminho de retorno, conforme a validação do caminho dos dados descrita acima.

O caminho de saída funciona, mas falta a resposta

O par remoto deve conhecer o endereço traduzido e devolver o tráfego pelo mesmo túnel. Verifique o seletor, a regra de firewall e a rota de retorno do par. Um caminho de retorno diferente não pode ser corrigido com uma ipsec_route local mais ampla.

O tráfego gerado pelo sistema ou DHCP é afetado

As solicitações de autenticação, DNS e DHCP geradas pelo firewall seguem um processo separado. No SFOS 22, elas normalmente não exigem uma rota IPsec manual. Use Roteamento SD-WAN para pacotes de resposta e tráfego do sistema ou o procedimento separado de relay DHCP, em vez de aplicar este procedimento de encaminhamento.

Falta um anúncio dinâmico após a atualização para o SFOS 22

No SFOS 22, as rotas VPN baseadas em políticas não são rotas comuns do kernel. Se o OSPF ou o BGP as anunciava anteriormente por meio de redistribute kernel, Por que redistribute kernel deixou de anunciar rotas IPsec após uma atualização para o SFOS 22 explica esse problema de migração específico.