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

Esta atribuição de funções é especialmente útil quando a filial tem um endereço IP dinâmico e a sede não dispõe de um endereço fiável do peer para iniciar a ligação: nesse caso, a filial inicia a ligação para o ponto de terminação da sede, acessível de forma estável. Um endereço dinâmico não é, contudo, um impedimento absoluto se o endereço do peer puder ser resolvido de forma fiável e o desenho permitir iniciar a ligação a partir da sede. À medida que se acrescentam filiais, o estabelecimento das ligações escala melhor se cada filial repetir as suas próprias tentativas de ligação, em vez de a sede ter de repetir todas as ligações às filiais.

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.

Estabelecer a ligação quando necessário

Verificar o estado do túnel apenas depois de configurar os dois locais e rever as regras de firewall. Activate on save ativa a entrada de configuração, mas não comprova que o túnel esteja estabelecido. Se o túnel ainda não estiver estabelecido e for necessário estabelecê-lo manualmente, abrir Site-to-site VPN > IPsec no lado iniciador – a filial neste exemplo – e clicar no botão de estado na coluna Connection da ligação em causa.

Não desligar nem restabelecer uma SA de produção já estabelecida para este passo; não é necessário clicar nesse botão na sede que responde. Um indicador de ligação verde confirma o estabelecimento do túnel, não o funcionamento do caminho de dados: efetuar depois, em ambas as direções, as verificações de serviço, Child SA e captura descritas abaixo.

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 route-based Any-to-Any, uma rota estática, SD-WAN ou dinâmica configurada manualmente em cada lado tem de apontar para a rede remota traduzida através da interface XFRM correta ou do respetivo gateway monitorizado. Com várias rotas, verificar em conjunto Route Precedence, Administrative Distance e a seleção SD-WAN. Em route-based com traffic selectors específicos, é criada automaticamente uma rota estática quando o túnel é estabelecido; neste caso, verificar essa rota e os selectors correspondentes. Em IPsec policy-based, o SFOS cria uma rota VPN no backend quando o túnel é estabelecido e faz corresponder o tráfego à política VPN ou às sub-redes definidas em Local subnet e Remote subnet; uma rota XFRM própria não faz parte deste método. Em todas as três variantes, a rede real idêntica tem de permanecer local e não pode ser encaminhada para o túnel por uma rota para a rede remota.

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. Em Any-to-Any, as Rule IDs esperadas das regras DNAT e SNAT reflexive comprovam a tradução planeada da origem e do destino. Em IPsec policy-based e route-based com traffic selectors específicos, comparar, em vez disso, os valores guardados de Original subnet, Local subnet e Remote subnet em ambos os lados, os selectors negociados e os endereços originais e traduzidos efetivamente observados no fluxo de teste. Este NAT interno à ligação não exige uma NAT Rule ID separada.
4. Packet Capture mostra a entrada, o encaminhamento e o retorno através de In interface, Out interface, Rule ID, Status e Reason. Comparar os endereços de origem e destino antes e depois da tradução com o plano de endereçamento; o filtro tem de abranger os endereços originais ou traduzidos que estão a ser verificados. Em route-based, verificar a interface XFRM correspondente; em policy-based, verificar o caminho IPsec através da interface IPsec partilhada, não de uma interface XFRM própria. Em Any-to-Any, NAT ID permite também identificar a regra NAT separada e não é uma prova obrigatória para NAT interno à ligação.
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 tem de permanecer local e não pode atravessar a VPN em nenhuma das três variantes. 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. Em Any-to-Any, comparar Original source e Translated source, bem como o endereço de destino remoto que permanece inalterado, na regra SNAT reflexive; em IPsec policy-based e route-based com traffic selectors específicos, comparar as associações de Original subnet, Local subnet e Remote subnet, bem como os selectors negociados da ligação. Verificar também o gateway do servidor e as regras de firewall no sentido inverso. Uma tradução unilateral não consegue produzir um fluxo bidirecional estável.

Corresponde a regra NAT errada

Em Any-to-Any, verificar NAT Rule ID e a ordem das regras DNAT/SNAT separadas. 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 temporalmente o fluxo de teste individual e depois corrigir apenas a regra em conflito. Em IPsec policy-based e route-based com traffic selectors específicos, localizar uma tradução incorreta através dos campos NAT da ligação IPsec, dos selectors negociados e dos endereços efetivamente observados antes e depois de NAT; a ausência de uma NAT Rule ID separada não é um erro neste caso.

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