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

Variante: clientes remotos acessam um endereço virtual

Um endereço de destino virtual pode ocultar os endereços dos servidores internos do par remoto. Este cenário não deve ser confundido com o exemplo de NAT baseado em políticas acima: a variante documentada usa IPsec baseado em rotas com sub-redes Any-to-any, interfaces XFRM com endereços atribuídos e rotas comuns. Não é criada uma ipsec_route manual para isso.

No exemplo, a rede 192.168.2.0/24 está atrás do Firewall 1; os clientes remotos atrás do Firewall 2 pertencem à rede 192.168.3.0/24. Eles acessam os servidores 172.16.16.2 e 172.16.16.3 pelo endereço virtual 10.10.10.1. Esse endereço é um endereço de destino DNAT, não o endereço do gateway XFRM. Todos os valores devem ser substituídos por objetos adequados ao seu ambiente.

Nas conexões IPsec de ambos os firewalls, defina Connection type como Route-based (Tunnel interface) e Local subnet e Remote subnets como Any. No exemplo, o Firewall 1 usa Respond only, e o Firewall 2, Initiate the connection. Em Network > Interfaces, abra a barra azul na respectiva Listening interface, selecione a interface XFRM, insira o endereço IP planejado para ela e salve. O procedimento de IPsec site-to-site explica a configuração básica do túnel.
Restrinja as regras de firewall ao serviço de aplicação efetivamente utilizado: no Firewall 2, de LAN para VPN, com origem 192.168.3.0/24 e os destinos necessários 192.168.2.0/24 ou 10.10.10.1, conforme o caso; no Firewall 1, de VPN para a zona real dos servidores, com a mesma origem remota e os objetos de destino necessários 192.168.2.0/24 ou 10.10.10.1, conforme o caso. A zona de destino Any usada no exemplo não é uma recomendação para uma permissão permanente.
Em Routing > SD-WAN routes > IPv4 > Add, no Firewall 2, encaminhe o tráfego com origem 192.168.3.0/24 e os destinos necessários 192.168.2.0/24 ou 10.10.10.1, conforme o caso, por um gateway na interface XFRM local. Em Link selection settings > Primary and backup gateways, selecione ou crie o Primary gateway adequado. No Firewall 1, adicione o caminho de retorno com as origens 192.168.2.0/24 ou 10.10.10.1, conforme o caso, e o destino 192.168.3.0/24, por seu gateway XFRM. Também é possível usar rotas estáticas ou dinâmicas.
Route only through specified gateways impede o uso de um caminho alternativo, descartando o tráfego quando o túnel não está disponível. O exemplo ativa essa opção no Firewall 2 e a apresenta como opcional no Firewall 1; o comportamento desejado em caso de falha deve ser definido conscientemente em ambos os lados. Administration > Device access > Ping/Ping6 > VPN diz respeito ao ping para serviços locais do firewall, não à permissão de um serviço de servidor encaminhado.
No Firewall 1, em Rules and policies > NAT rules > Add NAT rule > New NAT rule, crie a regra DNAT: Original source 192.168.3.0/24, Translated source Original, Original destination 10.10.10.1, Translated destination um objeto de lista de servidores com 172.16.16.2 e 172.16.16.3, Load balancing method Round-robin. Permita apenas o serviço necessário; a lista se destina a vários servidores de backend adequados, não a hosts arbitrários.

Para validar, gere várias novas conexões de aplicação para o endereço virtual e verifique, no Packet Capture e com base em Rule ID e NAT ID, os backends selecionados, o caminho XFRM e as respostas. Um ping isolado não confirma o DNAT, a aplicação nem a distribuição. Antes, faça backup das rotas, regras e objetos; ao reverter a configuração, remova apenas os elementos criados para esta variante, após verificar as dependências, ou restaure os valores anteriores. Não há nenhuma ipsec_route a excluir neste caso. Por isso, as verificações de falhas a seguir continuam distinguindo os dois tipos de túnel.

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 próprio. No entanto, seria incorreto afirmar de forma generalizada que o tráfego do sistema não precisa de uma rota IPsec manual: para IPsec baseado em políticas, o guia de autenticação para SFOS 22.0 e 23.0 prevê expressamente uma rota IPsec quando a solicitação não entra no túnel devido à Route Precedence selecionada. Primeiro, o endereço de origem, sys-traffic-nat, os Seletores de Tráfego e o caminho de retorno devem estar corretos; só então o destino necessário deve ser associado ao túnel baseado em políticas existente. A validação é feita com uma solicitação de autenticação real e Packet Capture; a reversão é realizada separadamente com o comando system ipsec_route del host ou del net adequado, após verificar a entrada.

O procedimento completo para autenticação baseada em políticas e baseada em rotas está em Roteamento SD-WAN para pacotes de resposta e tráfego do sistema. O artigo também contextualiza as contradições entre as funções dos endereços NAT descritas e os exemplos de comandos. Se o endereço de origem não estiver esclarecido, não faça alterações em produção e, em particular, não use o endereço do servidor AD como origem traduzida. Para IPsec baseado em rotas, aplicam-se rotas XFRM, não ipsec_route; o relay DHCP continua sendo um procedimento separado. Isso não implica uma alteração generalizada da Route Precedence global nem uma garantia de funcionamento.

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.