Utilizar NAT em redes IPsec sobrepostas na Sophos Firewall

Se a sede e a filial utilizarem a mesma sub-rede real, nenhuma firewall consegue decidir apenas pelo destino se um pacote deve permanecer local ou atravessar o túnel IPsec. O túnel pode estar verde sem existir um caminho inequívoco. A solução é um plano de tradução coordenado em ambos os lados: cada local aparece ao peer sob uma rede traduzida única.

O tipo de túnel determina o método. IPsec policy-based e IPsec route-based com traffic selectors específicos utilizam as definições NAT diretamente na ligação IPsec. Route-based Any-to-Any utiliza regras DNAT e SNAT e uma rota para a rede remota traduzida. Configurar uma VPN IPsec Site-to-Site explica a escolha geral do tipo de túnel.

Escolher o método correto

A Sophos suporta tradução 1:1, 1:n ou n:n para IPsec policy-based. Com n:n, as redes original e traduzida têm de ter o mesmo tamanho. Por exemplo, um /24 é associado a outro /24, não a um /25.

Três perguntas bastam para escolher:

• A ligação IPsec contém Local e Remote subnets específicas? Utilizar Network address translation (NAT) na ligação.
• Ambas as sub-redes estão em Any num túnel route-based? Utilizar DNAT com uma regra SNAT reflexive e uma rota através de XFRM.
• As redes não se sobrepõem? NAT é normalmente desnecessário e dificulta logs, regras e troubleshooting.

⚠️ Não misturar os dois métodos. Antes da alteração, guardar ambas as configurações do túnel, regras NAT e de firewall, rotas, respostas DNS e um acesso administrativo independente. Uma regra MASQ ampla ou um endereço traduzido improvisado não são workarounds seguros.

Criar um plano de endereçamento para ambos os locais

No exemplo, a sede e a filial utilizam a mesma rede real 192.0.2.0/24. Cada lado recebe a sua própria rede virtual para o túnel:

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

Um cliente na sede contacta assim um servidor da filial através do endereço em 203.0.113.0/24. Um cliente da filial utiliza o endereço correspondente em 198.51.100.0/24 para um servidor na sede. O endereço real 192.0.2.x permanece local em cada local.

As três redes pertencem aos blocos IPv4 reservados para exemplos pela RFC 5737 e devem ser substituídas em conjunto por redes livres do plano real. As redes traduzidas têm de ser únicas, não podem colidir com nenhuma LAN, VLAN, VPN, rede cloud ou doméstica e devem ser documentadas de forma espelhada nas duas firewalls. Se as aplicações utilizarem nomes, o DNS de cada local deve devolver o endereço traduzido do sistema remoto.

Configurar IPsec policy-based com NAT

Para IPsec policy-based, são necessários três objetos de rede em cada firewall, criados em Hosts and services > IP host > Add: a rede local real, a própria rede traduzida e a rede traduzida do peer. No exemplo da sede são HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 e BO_LAN_NAT_203.0.113.0.

Configurar a sede

Em Site-to-site VPN > IPsec > Add, criar a ligação como Policy-based com Gateway type Respond only. Perfil, autenticação, interface WAN e endereço do peer têm de corresponder ao lado remoto. Utilizar estas atribuições:

• Activate on save: ativado
• Create firewall rule: ativado
• Local subnet: HO_LAN_NAT_198.51.100.0
• Remote subnet: BO_LAN_NAT_203.0.113.0
• Network address translation (NAT): ativado
• Original subnet: HO_LAN_REAL_192.0.2.0

A firewall traduz a rede local real para a própria rede traduzida antes do envio. O tráfego de entrada para a rede traduzida é novamente associado à rede real.

Configurar a filial de forma espelhada

Na filial, criar a ligação Policy-based com Gateway type Initiate the connection. Espelhar totalmente a atribuição:

• Activate on save: ativado
• Create firewall rule: ativado
• Local subnet: BO_LAN_NAT_203.0.113.0
• Remote subnet: HO_LAN_NAT_198.51.100.0
• Network address translation (NAT): ativado
• Original subnet: BO_LAN_REAL_192.0.2.0

Local e Remote subnet contêm as redes traduzidas, enquanto Original subnet contém a rede local real. Se o tamanho ou a direção não coincidirem, pode formar-se Phase 2, mas o tráfego é traduzido incorretamente ou não encontra caminho de retorno.

Rever as regras de firewall automáticas

Com Create firewall rule, o SFOS cria regras VPN de entrada e saída. Revê-las em Rules and policies > Firewall rules, no grupo Automatic VPN rules. As regras têm de permitir as redes traduzidas na direção correta e apenas os serviços necessários. Uma regra VPN geral existente pode ser adaptada; não é obrigatória uma regra ampla separada por túnel.

As regras são avaliadas de cima para baixo. Colocar estas regras VPN acima de qualquer regra mais abrangente que entre em conflito e, durante um teste real, verificar Rule ID, zonas de origem e destino, redes de origem e destino, serviços e logging. Criar regras de firewall na Sophos Firewall explica a lógica geral.

Configurar route-based Any-to-Any com DNAT e SNAT

Este método requer um túnel route-based Any-to-Any funcional. A interface XFRM tem um endereço de trânsito único, existem regras LAN-to-VPN e VPN-to-LAN adequadas e uma rota estática, SD-WAN ou dinâmica aponta para a rede traduzida do peer. Só depois se adiciona NAT.

As ligações route-based com traffic selectors específicos não utilizam este procedimento. Tal como IPsec policy-based, utilizam as definições NAT da ligação IPsec. Esta é uma variante distinta, documentada pela Sophos, e não deve ser combinada com as regras DNAT/SNAT para Any-to-Any.

NAT na sede

Criar uma regra DNAT em Rules and policies > NAT rules > Add NAT rule > New NAT rule. Esta traduz pacotes de entrada destinados à rede virtual da sede para a rede local real:

• Original source: rede traduzida da filial 203.0.113.0/24
• Translated source: Original
• Original destination: rede traduzida da sede 198.51.100.0/24
• Translated destination: rede real da sede 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: ativado
• Load balancing method: One-to-one

Utilizar objetos de rede ou IP range do mesmo tamanho para a associação. Depois de guardar, abrir a regra gerada Reflexive_NAT#_<DNAT_rule_name>. Na saída, tem de traduzir a rede real da sede para 198.51.100.0/24 e utilizar a rede traduzida da filial 203.0.113.0/24 como Original destination.

NAT na filial

Aplicar o mesmo princípio de forma espelhada na filial:

• Original source: rede traduzida da sede 198.51.100.0/24
• Translated source: Original
• Original destination: rede traduzida da filial 203.0.113.0/24
• Translated destination: rede real da filial 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: ativado
• Load balancing method: One-to-one

A regra reflexive tem de traduzir a rede real da filial na saída para 203.0.113.0/24. O valor Any para ambas as interfaces é intencional neste modelo documentado; não o substituir por WAN apenas porque o peer IPsec é alcançado através da WAN. Os objetos dos endereços traduzidos e as regras de firewall fornecem a restrição necessária. Uma regra SNAT ou MASQ mais geral acima não pode capturar primeiro o tráfego.

O SFOS faz corresponder uma regra NAT pela origem, destino e serviço originais, antes de NAT, e pelas interfaces de entrada e saída. Aplica NAT apenas ao primeiro pacote de uma ligação, pelo que cada teste após uma alteração de NAT tem de utilizar uma nova ligação, com um novo quíntuplo. Demonstrar ordem e correspondência com NAT Rule ID e Packet Capture, em vez de as inferir apenas da lista. Compreender NAT na Sophos Firewall explica regras reflexive e o princípio first-match.

Associar com precisão as regras de firewall Any-to-Any

Uma regra NAT não permite tráfego. Em Rules and policies > Firewall rules > Add firewall rule > New firewall rule, criar regras restritas para cada direção necessária. Na sede, utilizar estas associações:

• saída: Source zone LAN, Source network rede real da sede, Destination zone VPN, Destination network rede traduzida da filial;
• entrada: Source zone VPN, Source network rede traduzida da filial, Destination zone LAN, Destination network rede real da sede;
• limitar Services ao serviço de negócio em teste e ativar Log firewall traffic para a validação.

Na firewall da filial, trocar sede e filial. A diferença entre os objetos de destino é intencional: no tráfego de saída, o SFOS avalia a regra de firewall antes de aplicar SNAT. No tráfego de entrada, determina primeiro o destino DNAT e depois avalia a regra de firewall com o destino traduzido e a respetiva zona. Por isso, esta ordem de processamento NAT determina os objetos das regras.

Verificar em conjunto routing, DNS e aplicações

Em cada lado, a rota para a rede remota traduzida tem de utilizar a interface XFRM correta ou o respetivo gateway monitorizado. Uma rota para a rede real idêntica seria ambígua e poderia atrair tráfego local para o túnel. Com várias rotas, verificar em conjunto Route Precedence, Administrative Distance e a seleção SD-WAN.

A aplicação também tem de utilizar o destino traduzido. Configurações estáticas, ACL, respostas DNS, monitoring e logs dos servidores não podem continuar a esperar o endereço remoto real. Um teste NAT apenas com ping não comprova que o processo de negócio funciona.

Validar o caminho em ambas as direções

Começar com um host conhecido e um serviço TCP ou UDP real em cada lado. A partir da sede, aceder ao endereço traduzido da filial e depois testar o endereço traduzido da sede a partir da filial. Verificar a ligação estabelecida em Current activities > IPsec connections e a utilização de IPsec em Reports > VPN. Em Diagnostics > Packet capture > Configure, um filtro BPF como host 203.0.113.10 limita a captura ao host de teste. Para o mesmo timestamp, verificar:

1. A ligação IPsec e a Child SA estão ativas.
2. A Firewall Rule ID esperada permite o fluxo.
3. A NAT Rule ID esperada traduz corretamente endereços originais e de destino.
4. Em Packet Capture, In interface, Out interface, NAT ID, Rule ID, Status e Reason mostram entrada, tradução, saída XFRM e retorno.
5. O servidor de destino vê o endereço de origem planeado e responde pelo mesmo caminho.

Como controlo negativo, aceder em seguida ao endereço real idêntico 192.0.2.10: este deve permanecer local e não pode surgir na captura através da interface XFRM. Só depois de os testes positivo e negativo produzirem o resultado planeado nas duas direções se adicionam mais hosts, serviços e nomes DNS. Packet Capture na Sophos Firewall ajuda a comparar antes e depois de NAT; Troubleshooting de IPsec na Sophos Firewall descreve a verificação completa do túnel.

Limitar os erros por sintoma

O túnel está verde, mas o destino responde localmente

O cliente utiliza provavelmente o endereço real, que também existe localmente, em vez da rede remota traduzida. Verificar a resposta DNS, o ficheiro hosts, a configuração da aplicação e a rota de destino. O erro ocorre então antes do túnel.

O caminho de ida funciona, mas falta o retorno

As traduções têm de ser espelhadas nas duas firewalls. Comparar Original e Translated source na regra reflexive, Remote subnet na ligação IPsec, gateway do servidor e regras no sentido inverso. Uma tradução unilateral não produz um fluxo bidirecional estável.

Corresponde a regra NAT errada

Verificar NAT Rule ID e ordem. Uma regra MASQ ampla, Default-SNAT ou DNAT anterior pode corresponder antes da regra VPN específica. Não desativar todas as regras NAT por tentativa; primeiro correlacionar o fluxo de teste pelo timestamp e corrigir apenas a regra em conflito.

Alguns hosts funcionam e outros não

Com n:n, os intervalos original e traduzido têm de ter o mesmo tamanho e posição. Verificar objetos IP range, máscaras, endereços excluídos, firewall do host e o offset realmente utilizado. O sucesso para .10 não comprova a associação de todo o intervalo.

Rollback e operação

Antes da alteração, preparar um backup da configuração, capturas ou exportações das configurações de túnel, NAT, firewall e routing e um acesso de gestão independente. Registar também os nomes, IDs, ordem e estado de ativação de todas as regras e rotas afetadas, bem como os valores anteriores de DNS e das aplicações. Durante a migração, desativar regras antigas apenas depois de documentar o seu estado anterior exato.

Se a validação falhar, repor primeiro os valores registados de DNS e das aplicações. Em Any-to-Any, desativar apenas as novas regras de firewall, o par DNAT/SNAT reflexive e a rota para a rede traduzida. Em IPsec policy-based, repor os valores guardados de Local, Remote e Original subnet. Depois, restaurar as regras e rotas anteriores na ordem e no estado de ativação originais e testar novas ligações nas duas direções. As sessões já estabelecidas mantêm a associação NAT definida no primeiro pacote e não comprovam o rollback: deixar continuar as sessões não relacionadas e, se for necessária uma prova imediata, terminar apenas as sessões de teste afetadas antes de repetir o teste. Não limpar todas as ligações. Remover endereços XFRM e objetos apenas quando Object usage não indicar dependências. Remover as redes traduzidas de DNS, monitoring e documentação apenas quando já não existirem dependências.

Em operação, gerir as redes traduzidas no plano central de endereços IP. Comparar novos locais, redes cloud, pools de Remote Access e redes domésticas com as redes originais e traduzidas. Caso contrário, a sobreposição é apenas deslocada para outro ponto.

Perguntas frequentes