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

Para Microsoft Azure ou AWS há também artigos próprios com as particularidades específicas de cada fornecedor: Ligar a Sophos Firewall ao Azure VPN Gateway e Ligar a Sophos Firewall ao AWS Site-to-Site VPN.

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.

• IPsec policy-based: adequado para ligações simples entre localizações com redes locais e remotas claras. Controlado principalmente através de sub-redes locais e remotas na ligação IPsec e através de regras de firewall. O Sophos cria túneis Phase 2 individuais para as combinações de sub-redes locais e remotas.
• IPsec route-based com traffic selectors: também utiliza sub-redes locais e remotas, mas cria a sua própria interface XFRM para a ligação. Isto facilita a depuração e separa melhor o túnel de outras ligações IPsec.
• IPsec route-based Any-to-Any: a variante mais flexível para redes em crescimento, SD-WAN, routing dinâmico e designs dual-stack. As rotas e as regras de firewall decidem então quais pacotes entram no túnel, já não as sub-redes da ligação IPsec.

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:

• Local gateway: IP WAN ou FQDN da Sophos Firewall local.
• Remote gateway: IP público ou FQDN da contraparte.
• Redes locais: 172.16.10.0/24, 172.16.20.0/24.
• Redes remotas: 10.20.30.0/24.
• Tipo de VPN: policy-based ou route-based. O connection type Host-to-host também existe, mas não é o foco deste guia de localização.
• Listening interface: interface WAN da firewall local. Uma bridge interface não pode ser usada para isto.
• Versão IKE: IKEv2, se a contraparte o suportar.
• Autenticação: Preshared Key ou certificado.
• Perfil IPsec: Encryption, authentication, DH group, PFS, key lifetime.
• Regras de firewall: origens, destinos e serviços permitidos.
• NAT: sem NAT, SNAT/DNAT devido a redes sobrepostas ou requisito do provider.
• Operação: owner, janela de manutenção, plano de testes, monitoring, caminho de fallback.
• Gateway type: initiate connection ou respond only, dependendo do lado que abre o túnel.
• IP version: IPv4, IPv6 ou Dual se ambos os lados o suportarem explicitamente.
• Local ID e Remote ID: necessários se a autenticação não deve depender apenas do endereço IP público.

⚠️ 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, a interface XFRM pertence à zona VPN; depois, rotas e regras de firewall decidem que tráfego pode realmente passar pelo túnel.

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

Não. Create firewall rule pode criar um primeiro conjunto de regras ao criar a ligação. A verificação exata de direção, posição, origens, destinos, serviços, logging e Security Features continua a ser necessária. Em IPsec route-based com sub-redes Any-to-Any, as regras devem ser planeadas manualmente.

Para a operação, é importante:

• Posição da regra: Mover as regras criadas automaticamente para o local correto depois de guardar.
• Direção: Verificar regra de entrada e de saída separadamente, não apenas o nome do túnel.
• Origens e destinos: Restringir redes locais e remotas se o assistente as criar demasiado amplas.
• Serviços: Usar Any só para o primeiro teste e depois reduzir aos serviços necessários.
• Logging: Ativar durante introdução e análise de erros.
• Security Features: Definir IPS, Web, Application Control ou NDR conscientemente, sem os herdar por acaso.

⚠️ 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

NAT Traversal está sempre ativo no Sophos Firewall. Se um dos lados estiver atrás de um router ou NAT do fornecedor, Local ID e Remote ID tornam-se ainda mais importantes, porque o endereço público do gateway por si só já não basta para uma identificação limpa do peer. IDs DNS, IP ou e-mail não precisam de resolver publicamente; só têm de coincidir em ambos os lados e usar um formato válido.

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.

As definições avançadas de User authentication mode pertencem apenas a perfis IKEv1 com lógica XAuth, por exemplo designs client-server muito antigos. Para ligações site-to-site normais com IKEv2, isto não deve ser interpretado como um passo adicional de autenticação. Definições idle connection obsoletas também não devem ser planeadas como design operacional moderno.

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
• IP version, normalmente IPv4.
• Gateway type, normalmente initiate connection no lado com gateway remoto definido.

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. A interface XFRM permanece atribuída à zona VPN; esta atribuição de zona não é um campo de design livre como nas interfaces físicas normais.

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
• Se ambas as sub-redes estiverem definidas como Any, o routing decide que tráfego entra no túnel.
• Se forem usados traffic selectors específicos, estes têm de corresponder exatamente ao peer.

1. A interface XFRM existe e está na zona correta.
2. A route para a rede remota aponta para a interface XFRM.
3. As regras firewall permitem o tráfego necessário entre as zonas corretas.

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:

• Rede local para rede remota: LAN para VPN ou zone de destino.
• Rede remota para rede local de servidores: VPN ou XFRM zone para Server.
• Management ou Monitoring: apenas sistemas admin ou de monitoring definidos.
• DNS, AD, RDP, HTTPS: apenas serviços necessários, não Any de forma genérica.

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.

• Em redes sobrepostas, NAT muitas vezes não é opcional, mas parte do desenho do túnel.
• Em route-based Any-to-Any, o routing e as regras firewall decidem com mais peso que tráfego entra no túnel.
• Em IPsec policy-based e VPN route-based com traffic selectors, NAT altera os endereços antes de serem comparados com os selectors.

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.

Definir matriz de aceitação

Antes do primeiro teste, deve estar definida uma pequena matriz de aceitação. Assim fica claro que ligação deve funcionar e que ligação deve ser deliberadamente bloqueada.

Casos de teste úteis:

• Rede local de clientes para rede remota de servidores: teste típico de aplicação, por exemplo HTTPS, RDP, SMB, SQL ou ICMP apenas como teste básico.
• Rede remota de clientes para rede local de servidores: verificar o sentido oposto se a ligação for usada de forma bidirecional.
• DNS ou AD através do túnel: testar apenas se estes serviços devem realmente passar pelo túnel. Definir concretamente origem, servidor de destino e porta.
• Monitorização ou backup: verificar se os sistemas previstos acedem a partir da direção correta e não precisam acidentalmente de regras Any.
• Teste não permitido: uma porta ou rede deliberadamente não autorizada deve ser bloqueada. Caso contrário, a base de regras está demasiado ampla.
• Transferência grande: em transferências de ficheiros, RDP, VoIP ou problemas de aplicação, observar também MTU/MSS e fragmentação.

Para cada caso de teste, registar source IP, destination IP, serviço, regra de firewall esperada, regra NAT esperada e direção esperada. Após cada teste, comparar Log Viewer, Packet Capture e contadores de bytes. Se só for testado ping, o túnel ainda não foi aceite.

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

• O túnel não sobe: versão IKE, perfil, PSK, certificado, Local ID ou Remote ID não corresponde. strongswan.log, perfil IPsec, contraparte.
• Phase 1 está ativa, Phase 2 não: redes locais/remotas ou Phase 2 proposal não correspondem. Traffic Selectors, sub-redes, PFS.
• Túnel verde, mas sem acesso: regra de firewall, NAT, routing ou caminho de retorno em falta. Log Viewer, Packet Capture, routing.
• Só uma direção funciona: contraparte não conhece a rota de retorno ou NAT está errado. contraparte, regras NAT, contadores de bytes.
• Pings pequenos funcionam, aplicações ficam presas: MTU/MSS, fragmentação ou Security Feature. verificar MTU/MSS, Packet Capture.
• Túnel route-based pouco claro: interface XFRM, rota ou SD-WAN Route não corresponde. Network > Interfaces, routing, SD-WAN.
• Vários túneis influenciam-se: redes sobrepostas ou configuração Selector semelhante. objetos de túnel, failover group, rotas.

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.
• Matriz de aceitação com pelo menos um teste por direção necessária definida.

Perguntas frequentes