Criar Rota IPsec no Sophos Firewall

Uma rota IPsec manual não é o padrão para todos os túneis. Ela é indicada principalmente para IPsec baseado em políticas quando o tráfego encaminhado e traduzido precisa ser associado a um túnel específico.

IPsec baseado em rotas: Não crie uma ipsec_route. O tráfego passa por interfaces XFRM e por rotas estáticas, SD-WAN ou dinâmicas. IPsec baseado em políticas sem um caso especial de NAT: Primeiro verifique o túnel, as regras de firewall, o NAT e o caminho de retorno. IPsec baseado em políticas com tráfego DNAT ou SNAT encaminhado: As etapas a seguir ajudam na verificação e na configuração.

⚠️ Uma rota IPsec incorreta pode direcionar tráfego de produção para o túnel errado. Antes de qualquer alteração, registre o estado inicial e prepare um procedimento de reversão exato.

Verificar, criar e remover uma rota IPsec

Os comandos para exibir, criar e remover rotas são executados no Device Console. Se o acesso ainda não estiver configurado, consulte Conectar ao Sophos Firewall por SSH para chegar ao Device Console.

Registrar o estado inicial

Antes de executar um comando Add, o caminho concreto precisa estar definido:

• Trata-se de um túnel baseado em políticas ativo, e não de IPsec baseado em rotas.
• O host ou a rede de destino corresponde aos seletores do túnel e à tradução planejada.
• As regras de firewall e NAT correspondem ao tráfego de teste definido; para SNAT, Outbound interface está definido como Any.
• Route Precedence e rotas concorrentes foram verificadas.
• O peer espera o endereço de origem visível e possui uma rota de retorno.

Primeiro, documente todas as rotas IPsec manuais:

system ipsec_route show

Em caso de problemas de roteamento ou NAT, registre também Route Precedence e o NAT do tráfego do sistema:

system route_precedence show
show advanced-firewall

Na Advanced Shell, esta visualização mais antiga para solução de problemas também pode ser útil:

ip route show table 220

Segundo a Sophos, no SFOS 22 as rotas IPsec baseadas em políticas e as entradas ipsec_route não são visíveis nessa tabela. Portanto, a ausência de uma entrada não comprova que não exista uma rota IPsec. O que vale é system ipsec_route show, a configuração e um teste de tráfego.

Criar uma rota para um host

Sintaxe:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Exemplo para o host 10.33.46.69 através do túnel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Criar uma rota para uma rede

Sintaxe:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Exemplo para a rede 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

A máscara de rede deve corresponder exatamente ao destino pretendido. Uma rota ampla demais pode direcionar tráfego adicional para o túnel sem que isso seja desejado.

Remover uma rota com segurança

⚠️ Os comandos de remoção não incluem o nome do túnel. Antes de remover, use system ipsec_route show para confirmar que o host ou a rede é inequívoco e mantenha o comando Add completo disponível para a reversão. Se houver entradas ambíguas, não remova nada por tentativa.

Remover uma rota de host:

system ipsec_route del host <host-ip>

Remover uma rota de rede:

system ipsec_route del net <network>/<netmask>

Em seguida, verifique novamente a lista:

system ipsec_route show

Se o resultado do teste piorar, restaure a rota com o comando Add registrado anteriormente.

Quando usar ipsec_route

IPsec baseado em políticas e baseado em rotas

No IPsec baseado em políticas, as redes locais e remotas definem os seletores do túnel. Uma ipsec_route manual pode associar hosts ou redes adicionais a um túnel existente, mas não substitui um seletor adequado, regras de firewall nem a rota de retorno.

No IPsec baseado em rotas, o tráfego é roteado para a interface XFRM. Dependendo do projeto, usa-se uma rota estática, uma rota SD-WAN ou roteamento dinâmico. Uma ipsec_route é a ferramenta errada nesse caso. Os fundamentos das duas variantes estão em Configurar VPN IPsec Site-to-Site no Sophos Firewall e Configurar zonas e interfaces no Sophos Firewall.

Diferença entre SFOS 21.5 e 22

A classificação em Route Precedence mudou:

• No SFOS 21.5, as rotas IPsec baseadas em políticas geradas automaticamente pertencem à categoria vpn, enquanto as entradas ipsec_route manuais pertencem à categoria static.
• No SFOS 22, as rotas IPsec baseadas em políticas automáticas e manuais pertencem à categoria vpn. Elas não aparecem como rotas comuns do kernel e são processadas internamente com base em marcações, zonas e flags.

Após uma atualização do SFOS 21.5, teste novamente Route Precedence e os casos especiais existentes. A verificação de atualização para o SFOS 22 reúne as verificações gerais. A ordem global é explicada em Alterar Route Precedence com segurança no Sophos Firewall.

Uma rota manual só faz sentido quando o túnel, o seletor de tráfego, a regra de firewall, a regra NAT e o caminho de retorno estão corretos. Ela não corrige máscara de rede incorreta, rota ausente no peer nem regra bloqueadora.

NAT para tráfego encaminhado

O NAT altera os endereços, mas não muda automaticamente a decisão de roteamento. Se um túnel baseado em políticas transportar tráfego adicional traduzido por DNAT ou SNAT, poderá ser necessária uma rota IPsec correspondente para o host ou a rede remota.

Para SNAT em IPsec baseado em políticas, a regra NAT correspondente deve usar Outbound interface Any. Se ela estiver limitada a uma interface WAN específica, não corresponderá ao tráfego IPsec. Entender NAT no Sophos Firewall explica em mais detalhes a ordem, a correspondência e o caminho de retorno.

A alteração deve ser feita em uma janela de manutenção ou com um caso de teste controlado. Antes disso, estes valores precisam estar definidos:

• endereços de origem e destino originais e traduzidos,
• redes local e remota da conexão IPsec,
• nome do túnel e regra de firewall esperada,
• rota de retorno e endereços permitidos no peer.

Tratar separadamente o tráfego gerado pelo sistema

As consultas DNS, de autenticação ou de outros serviços originadas pelo próprio firewall não seguem automaticamente a mesma lógica do tráfego de cliente encaminhado. No SFOS 22, normalmente não é necessária uma ipsec_route para esse tráfego. Somente o guia específico da Sophos para solicitações de autenticação a menciona como alternativa condicional quando, de forma comprovada, a solicitação não chega ao túnel baseado em políticas por causa da Route Precedence configurada.

Se necessário, o endereço de origem desse tráfego pode ser definido com sys-traffic-nat. Exemplo: o firewall deve acessar o servidor 10.10.2.15 usando o endereço SNAT/de interface definido 10.10.1.1. Esse endereço precisa corresponder às sub-redes IPsec e ter uma rota de retorno no peer.

Os comandos a seguir são executados no Device Console:

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

Reversão:

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

Se interface ou netmask também tiver sido usado ao adicionar a entrada, os mesmos seletores deverão ser informados ao removê-la. Há outros exemplos em Roteamento SD-WAN para Reply Packets e System Traffic.

O DHCP exige uma avaliação própria:

• No IPsec baseado em políticas, o relay precisa da opção Relay through IPsec, de sub-redes IPsec locais e remotas adequadas, de sys-traffic-nat e das regras e rotas de retorno necessárias no peer. Se as solicitações ainda não entrarem no túnel por causa da configuração de roteamento concreta, uma ipsec_route poderá ser necessária como fallback verificado.
• No IPsec baseado em rotas, Relay through IPsec não é ativado. O que tem suporte é um relay para o lado do servidor DHCP através de uma interface XFRM com sub-redes Any-to-any, rotas estáticas, SD-WAN ou dinâmicas e regras adequadas nos dois firewalls. Uma ipsec_route não faz parte desse caminho.
• Se, em uma topologia de IPsec baseado em políticas, o firewall da sede atuar como servidor DHCP para redes remotas, Lease over IPsec deverá estar ativado. Segundo a Sophos, não há suporte para interfaces do firewall como servidor DHCP nessa topologia baseada em rotas.

Este comando também é executado no Device Console:

system dhcp lease-over-IPSec enable

Procedimentos mais antigos do SFOS 21.5 citavam ipsec_route com mais frequência para autenticação e DHCP. Essas configurações devem ser verificadas durante uma atualização e não recriadas sem validação.

Testar e validar a alteração

Um túnel verde ou um ping bem-sucedido não é prova suficiente. Um teste ICMP pode funcionar mesmo que TCP, NAT ou o caminho de retorno ainda estejam incorretos.

1. Defina Source, Destination, Service, direção e túnel esperado.
2. Ative o logging da regra de firewall afetada.
3. Registre system ipsec_route show antes do teste.
4. Gere uma vez e de forma controlada o tráfego real da aplicação.
5. No Log Viewer, filtre por Source, Destination e regra.
6. Execute o Packet Capture com um filtro restrito nos dois lados do caminho.
7. No peer, verifique o endereço de origem, a rota de retorno e o firewall local.
8. Documente o resultado, a alteração e o comando de reversão.

Na Advanced Shell, estes comandos mostram SAs negociadas, contadores de bytes e políticas XFRM:

ipsec statusall
ip xfrm policy

Sozinhos, porém, eles não comprovam que o NAT, a regra de firewall e o caminho de retorno estejam corretos. Para uma análise sistemática, consulte Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture. Se apenas transferências maiores ficarem paradas, verifique também MTU e MSS em problemas de VPN.

Isolar erros e reverter

O túnel está ativo, mas nenhum tráfego passa

Verifique a regra de firewall, o NAT, o seletor de tráfego e a rota de retorno. Em seguida, compare Log Viewer, Packet Capture e os contadores de ipsec statusall. O procedimento completo está em Solução de problemas de VPN IPsec no Sophos Firewall.

O tráfego segue em direção à WAN

Verifique Route Precedence, as rotas SD-WAN e system ipsec_route show. No SFOS 22, uma entrada ausente na tabela 220 não deve ser usada como prova de que não existe uma rota IPsec.

O SNAT não corresponde

No IPsec baseado em políticas, verifique se Outbound interface está definido como Any e se os endereços originais e traduzidos correspondem ao túnel e ao peer.

Um host funciona, mas uma rede não

Compare a máscara de rede, o objeto de host/rede e o seletor de tráfego nos dois lados. Não crie uma rota mais ampla antes de entender a divergência.

O caminho muda após a atualização para o SFOS 22

Verifique novamente Route Precedence e todos os casos especiais baseados em políticas com NAT, SD-WAN ou MPLS. Não remova nem recrie rotas antigas automaticamente.

O tráfego do próprio firewall não chega ao destino

Primeiro, determine se o caso envolve autenticação, DNS, DHCP ou outro serviço. Depois, verifique Route Precedence, SD-WAN, sys-traffic-nat e o procedimento correspondente do SFOS 22.

Se um erro começar imediatamente após a alteração, remova a nova rota, verifique com system ipsec_route show e repita o teste anterior. Se o problema persistir, restaure completamente o estado inicial documentado.

FAQ