Configurar VPN IPsec Site-to-Site Sophos Firewall

Uma VPN IPsec Site-to-Site liga duas localizações, ou uma Sophos Firewall a uma firewall de terceiros, através de um túnel cifrado. Na prática, um túnel deste tipo raramente falha por causa de uma única opção na interface. Com mais frequência, as causas são redes pouco claras, perfis IPsec diferentes, regras de firewall em falta, casos especiais de NAT ou um caminho de retorno esquecido num dos lados.

Este artigo explica como criar corretamente um túnel IPsec Site-to-Site na Sophos Firewall. O foco está no planeamento, implementação e teste de aceitação. Se um túnel existente já está verde mas não passa tráfego, Sophos Firewall IPsec VPN Troubleshooting é o artigo complementar mais adequado.

Quando este artigo se aplica

Este artigo aplica-se a ligações clássicas entre localizações, por exemplo:

• Sede para filial
• Sophos Firewall para Sophos Firewall
• Sophos Firewall para firewall de terceiros
• Sophos Firewall para cloud gateway quando não é usado um assistente cloud específico
• Migração de túneis policy-based antigos e simples para uma configuração atual documentada

Não se trata de Remote Access para utilizadores individuais. Para isso, são adequados os artigos Configurar Sophos Connect na Sophos Firewall, Sophos Connect ou SSL VPN: que solução Remote Access se adequa? e Migrar legacy Remote Access IPsec antes do SFOS 22 MR1.

IPsec policy-based ou route-based

Antes da configuração, é necessário decidir se o túnel será criado como policy-based ou route-based. Nas versões SFOS atuais, estes termos estão separados de forma mais clara do que em instruções antigas, que por vezes ainda falam de Site-to-Site ou Tunnel Interface.

Para ligações pequenas e estáveis, policy-based IPsec é muitas vezes o mais rápido de compreender. Para redes de localizações maiores ou dinâmicas, route-based IPsec é normalmente mais limpo, porque separa melhor routing e negociação VPN. Se estiverem envolvidas várias redes, SD-WAN, BGP, OSPF ou redes cloud, deve ser avaliado primeiro route-based IPsec.

Requisitos

Antes da configuração, estas informações devem estar documentadas:

⚠️ VPN Site-to-Site não deve ser implementada sem um caminho de retorno documentado. Se a firewall local envia tráfego para o túnel, mas a contraparte não conhece a rota de retorno ou espera NAT de outra forma, o túnel muitas vezes parece saudável embora as aplicações não funcionem.

Planear antes da configuração

Manter as redes inequívocas

As redes locais e remotas não podem sobrepor-se involuntariamente. Redes padrão frequentes como 192.168.0.0/24, 192.168.1.0/24 ou redes de filiais reutilizadas são particularmente problemáticas. Se as redes se sobrepõem, é necessário um design NAT consciente. Usar simplesmente o mesmo intervalo de endereços dos dois lados e traduzi-lo depois “de alguma forma” cria túneis difíceis de manter.

Para novas localizações, vale por isso a pena ter um conceito limpo de endereçamento IP. Se VLANs ou zones ainda não estiverem bem modeladas, ajuda configurar zones e interfaces na Sophos Firewall.

Alinhar o perfil IPsec

Ambos os lados têm de usar parâmetros compatíveis na Phase 1 e Phase 2. Isto inclui cifragem, autenticação, DH group, PFS e lifetime. Em ligações a firewalls de terceiros, é muitas vezes mais simples registar primeiro por escrito um perfil comum e depois configurar os dois lados.

Se um túnel não sobe, NO_PROPOSAL_CHOSEN, erros de ID ou erros de autenticação são indicações típicas. A análise estruturada está em Sophos Firewall IPsec VPN Troubleshooting.

Não esquecer as regras de firewall

Um túnel IPsec ainda não permite acesso produtivo. O tráfego através do túnel continua a precisar de regras de firewall adequadas. Em ligações policy-based são normalmente regras entre LAN e VPN ou entre zones próprias. Em designs route-based depende da zone à qual a interface XFRM, ou o caminho relevante, está atribuída.

Durante a introdução, Log firewall traffic deve estar ativado nas regras afetadas. Caso contrário falta mais tarde exatamente a informação sobre que regra permitiu ou bloqueou um teste. O fluxo geral de verificação está em testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

Verificar conscientemente as regras criadas automaticamente

Ao criar uma ligação IPsec Site-to-Site, a opção Create firewall rule pode ajudar a criar um primeiro conjunto de regras. Mas não substitui uma revisão de segurança. A Sophos Firewall cria estas regras no topo da lista de regras de firewall. Nas versões SFOS atuais, são criadas regras separadas para tráfego de entrada e saída com os prefixos Incoming e Outgoing.

Para a operação, é importante:

⚠️ Regras de firewall criadas automaticamente são um ponto de partida, não um design de segurança terminado. Especialmente em túneis entre localizações para redes de servidores, devem reduzir-se serviços, origens e destinos depois do primeiro teste.

Em IPsec route-based com sub-redes Any-to-Any, é necessário trabalhar com especial cuidado. Para estes designs route-based não podem ser criadas regras de firewall automáticas. Em versões dual IP, as regras IPv4 e IPv6 devem ser planeadas separadamente. Nestes cenários, regras de firewall, interface XFRM, rotas e testes devem ser construídos manualmente e de forma deliberada.

Configurar IPsec policy-based

Policy-based IPsec é a variante clássica para ligações Site-to-Site simples. As redes locais e remotas são definidas diretamente na ligação IPsec.

1. Verificar ou criar o perfil IPsec

Menu path:

Profiles > IPsec profiles

Primeiro verificar se um perfil existente corresponde à contraparte. Se for necessário um perfil próprio, deve receber um nome claro, por exemplo IPsec_IKEv2_AES256_G14. O nome tem de continuar compreensível mais tarde, quando existirem vários túneis e contrapartes.

Documentar pelo menos:

• Versão IKE
• Phase 1 Encryption e Authentication
• DH Group
• Phase 2 Encryption e Authentication
• PFS
• Key lifetime

Em firewalls de terceiros, a contraparte deve confirmar os mesmos valores por escrito. Uma captura de ecrã, por si só, muitas vezes não basta, porque campos individuais podem ter nomes diferentes conforme o fabricante.

2. Adicionar a ligação IPsec

Menu path:

Site-to-site VPN > IPsec

Criar uma nova ligação IPsec e escolher Policy-based como Connection type. Depois definir os dados base:

• Nome do túnel, por exemplo branch-zurich
• Local gateway ou Listening interface
• Remote Gateway como endereço IP ou FQDN
• Authentication type: Preshared Key ou certificado
• Local ID e Remote ID, se necessário
• IPsec profile
• Local subnet
• Remote subnet

Para Preshared Keys, deve ser usada uma chave forte e única, documentada de forma segura. Uma chave padrão antiga partilhada por várias localizações é um risco operacional desnecessário.

3. Ativar o túnel

Ao guardar, pode ser definido Activate on save. Em ambientes produtivos, isto deve acontecer numa janela de manutenção definida, quando a contraparte estiver acessível e os dois lados puderem verificar logs.

Depois de guardar, a lista mostra dois estados relevantes:

• se a ligação está ativa
• se o túnel está realmente established

Uma entrada ativa não é automaticamente um túnel estabelecido. Com várias redes locais ou remotas, também podem existir várias Security Associations.

Configurar IPsec route-based

Route-based IPsec separa de forma mais clara negociação VPN e routing. A Sophos Firewall cria uma interface XFRM. Depois, rotas estáticas, SD-WAN Routes ou routing dinâmico decidem que tráfego passa pelo túnel.

1. Criar a ligação como route-based

Menu path:

Site-to-site VPN > IPsec

Na ligação, escolher Route-based (Tunnel interface). Os parâmetros de gateway, autenticação, IDs e perfil IPsec continuam a ter de corresponder à contraparte. Além disso, é necessário compreender que interface XFRM será criada e como será encaminhada.

A Sophos mostra a interface XFRM gerada sob a interface física usada em:

Network > Interfaces

Conforme o design, a interface XFRM precisa de um endereço IP. Especialmente em designs Any-to-Any, versão dual IP ou cenários de routing mais complexos, o endereçamento da interface deve ser planeado cuidadosamente.

Quando se usa Any-to-Any, o Tunnel Selector já não decide sozinho que tráfego passa pelo túnel. Rotas e regras de firewall passam então a ser o controlo central. Isto é flexível, mas também propenso a erros: uma regra demasiado ampla pode permitir mais tráfego do que o pretendido, e uma rota em falta pode deixar o túnel verde sem que o tráfego de utilizador circule.

2. Definir routing

Em VPN route-based, a ligação IPsec por si só não basta. É necessária uma rota para a rede remota:

• rota estática para a interface XFRM
• SD-WAN Route com gateway ou perfil adequado
• rota dinâmica via BGP ou OSPF, se o design estiver construído para isso

Para setups simples, uma rota estática é muitas vezes suficiente. Se forem usadas várias ligações WAN, verificações SLA ou caminhos de failover, uma SD-WAN Route é mais adequada. O contexto geral sobre SD-WAN, Reply Packets e tráfego gerado pelo sistema está em verificar routing SD-WAN na Sophos Firewall para Reply Packets e System Traffic.

3. Considerar XFRM e MTU

VPNs route-based são mais suscetíveis a mal-entendidos sobre routing, MTU e MSS. Se testes pequenos funcionam, mas transferências maiores ficam bloqueadas, não se deve alterar imediatamente o perfil IPsec. Primeiro verificar MTU, MSS, fragmentação e o caminho real. O procedimento adequado está em verificar MTU e MSS na Sophos Firewall em problemas VPN.

Criar regras de firewall

Depois da configuração IPsec, são necessárias regras para o tráfego produtivo. Sem regras adequadas, o túnel pode ficar verde, mas as aplicações não funcionam.

Menu path:

Rules and policies > Firewall rules

Regras típicas:

Boa prática:

• Nome da regra com túnel ou localização, por exemplo LAN_to_Branch_Zurich.
• Definir Source e Destination tão restritos quanto possível.
• Definir Services concretamente.
• Ativar logging durante introdução e troubleshooting.
• Verificar posição da regra.
• Definir funções de proteção conscientemente em vez de as herdar por acaso.

Se o tráfego Internet de uma filial deve passar pela sede, é necessário também um conceito NAT e de segurança consciente. Isso é outro design, diferente de uma ligação simples entre localizações para redes internas.

Planear NAT conscientemente

NAT não é proibido com IPsec, mas tem de estar claramente justificado. Casos típicos são redes sobrepostas, requisitos cloud ou terceiros que aceitam apenas determinados endereços de origem.

Menu path:

Rules and policies > NAT rules

Antes de uma regra NAT, devem ser respondidas estas perguntas:

• A contraparte espera endereços IP originais ou endereços traduzidos?
• Existem redes sobrepostas?
• NAT é resolvido na ligação IPsec ou através de regras NAT separadas?
• A direção de retorno está documentada?
• Log Viewer mostra depois de NAT a Source e Destination esperadas?

Para casos especiais policy-based com NAT, uma IPsec Route na Sophos Firewall manual pode tornar-se relevante. Mas não é um passo padrão para todos os túneis.

Device Access e acesso WAN

Para pedidos IPsec de entrada, a firewall tem de poder aceitar tráfego IPsec na zone WAN adequada. Isto não se resolve com uma regra LAN-to-WAN normal, mas através dos serviços locais da firewall.

Menu path:

Administration > Device access

Aí, IPsec tem de ser permitido para a zone necessária. Ao mesmo tempo, deve verificar-se se outros serviços locais como WebAdmin, SSH, User Portal ou VPN Portal estão acessíveis de forma demasiado ampla. Para endurecer estes serviços locais, proteger o acesso à Sophos Firewall: configurar Device Access corretamente é o artigo central.

Testar o túnel

Um bom teste de aceitação não verifica apenas o estado verde. Verifica o fluxo real de dados.

1. Verificar o estado

Na interface WebAdmin:

Site-to-site VPN > IPsec

Verificar:

• A ligação está ativa.
• O estado do túnel é established.
• Com várias redes, todas as Child SAs esperadas estão estabelecidas.
• Não há reconnects ou erros recorrentes visíveis.

2. Verificar Log Viewer

Menu path:

Log viewer

Gerar tráfego de teste com Source, Destination e Service claros. Depois verificar no Log Viewer que regra de firewall corresponde e se NAT, Webfilter, IPS ou outros módulos influenciam o tráfego.

3. Usar Packet Capture

Se Log Viewer não for suficiente, deve ser usado Packet Capture com um filtro estreito:

Diagnostics > Tools > Packet capture

Exemplo de filtro:

host 172.16.10.25 and host 10.20.30.15

Em VPN troubleshooting, é importante verificar as duas direções. Pacotes apenas de saída sem resposta indicam normalmente um problema de caminho de retorno, NAT ou contraparte.

4. Usar CLI apenas de forma direcionada

Para uma análise mais profunda, pode ser usada a Advanced Shell via SSH:

ipsec statusall

São relevantes, entre outros:

• IKE SA established
• Child SA installed
• redes locais e remotas
• contadores de bytes nas duas direções
• mensagens recorrentes de rekey ou disconnect

Se SSH ainda não estiver preparado, ajuda ligar à Sophos Firewall por SSH.

Erros típicos

Checklist

Antes da alteração:

• As redes locais e remotas são inequívocas.
• Policy-based ou route-based foi decidido conscientemente.
• O perfil IPsec está alinhado com a contraparte.
• Preshared Key ou certificados estão documentados de forma segura.
• As regras de firewall estão planeadas, incluindo direção, posição, logging e serviços.
• Com Create firewall rule, é claro que regras criadas automaticamente têm de ser ajustadas.
• Em route-based Any-to-Any, regras de firewall e rotas manuais estão planeadas.
• NAT está excluído ou documentado conscientemente.
• Device Access para IPsec foi verificado.
• Janela de manutenção, contraparte e caminho de fallback são conhecidos.

Depois da alteração:

• O estado do túnel é established.
• Log Viewer mostra a regra de firewall esperada.
• Packet Capture mostra direção de ida e retorno.
• Foram testados acessos internos DNS e aplicações.
• Os contadores de bytes aumentam nas duas direções.
• NAT e caminho de retorno estão alinhados com a contraparte.
• A alteração foi atualizada na documentação de rede.

Perguntas frequentes