Configurar Site-to-Site RED entre duas Sophos Firewall

Um túnel Site-to-Site RED liga diretamente duas Sophos Firewall sem instalar uma appliance SD-RED em qualquer dos locais. Uma firewall funciona como Firewall RED server e aceita a ligação. A outra funciona como Firewall RED client e estabelece o túnel para o servidor.

Este processo atual do SFOS 22 não deve ser confundido com um modo de operação RED como Standard/Unified ou Standard/Split. Esses modos pertencem a uma SD-RED física. Um design firewall-to-firewall utiliza, em vez disso, interfaces RED, rotas estáticas e regras de firewall correspondentes em ambas as firewalls.

⚠️ Antes da alteração, é necessário um backup atualizado das duas firewalls, um acesso administrativo independente e um caminho de recuperação documentado. Sempre que possível, o endereço público do Firewall RED server não deve ser traduzido por NAT, porque a tradução pode interferir com as ligações RED de entrada.

O processo em oito passos

1. Planear as funções, os IP RED, as redes dos locais e um endereço de servidor acessível.
2. Ativar o RED provisioning service em ambas as firewalls e permitir o caminho de controlo RED.
3. Criar na central a interface Firewall RED server.
4. Transferir de forma segura o ficheiro de provisionamento gerado para o outro local.
5. Criar na filial a interface Firewall RED client e importar o ficheiro.
6. Adicionar em ambos os lados uma rota estática para a LAN remota, usando o IP RED do peer como gateway e sem selecionar uma interface.
7. Permitir o tráfego de dados em ambas as firewalls através de regras restritas com logging; não criar uma regra NAT associada.
8. Verificar separadamente o túnel, a rota, a correspondência de regras e tráfego bidirecional real.

Uma interface RED verde confirma apenas que o túnel foi estabelecido. Não prova que o routing, as regras de firewall e o caminho de retorno funcionem.

Planeamento e design

Quando Site-to-Site RED é adequado

Site-to-Site RED é uma forma simples de ligar duas Sophos Firewall. O provisionamento RED trata de parte da negociação VPN clássica, enquanto as LAN remotas continuam a utilizar routing e regras de firewall normais.

Nos novos designs, deve continuar a ser feita uma escolha consciente entre RED e Site-to-Site IPsec. O IPsec oferece mais opções de perfis, routing, interoperabilidade e redundância. Site-to-Site RED é atrativo quando os dois endpoints são Sophos Firewall e basta um túnel simples específico da Sophos.

Uma SD-RED física é configurada com Configurar e diagnosticar a Sophos SD-RED. Os modos de operação RED não se aplicam ao túnel firewall-to-firewall aqui descrito.

Planear a topologia de exemplo

O exemplo seguinte utiliza deliberadamente endereços de documentação. Todos são substituídos pelas redes e endereços reais dos dois locais:

• Central, função Firewall RED server: endereço público 198.51.100.10, LAN 10.10.0.0/16
• Filial, função Firewall RED client: endereço público 203.0.113.20, LAN 10.20.0.0/16
• IP RED da central: 10.255.100.1
• IP RED da filial: 10.255.100.2

Os dois IP RED formam o par de endereços entre as firewalls. Não podem entrar em conflito com uma LAN de local nem com outra rede de interface ou VPN. A firewall client deve conseguir alcançar de forma fiável o endereço IP público ou FQDN do servidor.

O exemplo usa 255.255.255.252 (/30) como RED netmask. Esta pequena rede de trânsito contém exatamente o par necessário. Ao escolher outra rede livre, substituem-se coerentemente ambos os IP RED e a máscara. RED não resolve LAN sobrepostas; o endereçamento ou NAT deve ser definido antes do túnel.

A Sophos descreve explicitamente as interfaces RED como túneis seguros e encriptados. Ao registar o RED provisioning service, o SFOS utiliza os dados de registo para gerar um certificado destinado à comunicação RED segura. Por isso, no processo firewall-to-firewall documentado não se escolhe manualmente um PSK ou certificado na interface: o servidor gera um Provisioning file com os dados de configuração do cliente. O ficheiro deve ser transferido apenas através de um canal protegido. Ver RED tunnels and provisioning e RED.

Configurar o túnel e o caminho de dados

Criar o Firewall RED server

Primeiro, o servidor é criado na firewall com um endereço público acessível de forma estável:

1. Em System services > RED, ativar o RED provisioning service.
2. Abrir Network > Interfaces.
3. Selecionar Add interface > Add RED.
4. Em Branch name, introduzir por exemplo RED-HQ-Branch.
5. Definir Type como Firewall RED server.
6. Manter Tunnel ID em Automatic.
7. Introduzir 10.255.100.1 como RED IP.
8. Introduzir 255.255.255.252 como RED netmask.
9. Atribuir uma zona escolhida, no exemplo RED-S2S.
10. Deixar inicialmente Tunnel compression e MTU inalterados e guardar.
11. Em Network > Interfaces, escolher Download provisioning file no menu da interface.

O ficheiro de provisionamento pertence a este túnel e deve ser tratado como um artefacto de configuração sensível. É transferido para a filial através de um canal protegido e, após a importação, não permanece numa pasta de downloads ou partilha acessível a todos.

A zona influencia mais tarde a correspondência de regras e de Device Access. É possível usar LAN, mas uma zona dedicada costuma criar um limite de segurança mais claro quando existem vários locais. Configurar zonas e interfaces na Sophos Firewall explica as relações gerais.

Automatic evita reutilizar acidentalmente uma Tunnel ID. Se for obrigatório defini-la manualmente, a Sophos exige que não esteja em uso em nenhum dos dispositivos. No processo de cliente documentado não se introduz uma segunda Tunnel ID; a associação vem do ficheiro de provisionamento do servidor. Tunnel compression pode melhorar o débito numa ligação lenta, mas consome recursos; só deve mudar após uma medição antes/depois reproduzível. Uma MTU menor só se testa perante fragmentação ou Path MTU comprovados.

Criar o Firewall RED client

No outro local, o cliente é criado com o ficheiro gerado pelo servidor:

1. Também aqui, em System services > RED, ativar o RED provisioning service.
2. Criar uma nova interface em Network > Interfaces > Add interface > Add RED.
3. Usar um Branch name como RED-Branch-HQ.
4. Definir Type como Firewall RED client.
5. Em Firewall IP/hostname, introduzir o endereço público ou FQDN do servidor.
6. Em Provisioning file, selecionar o ficheiro da firewall server.
7. Introduzir 10.255.100.2 como RED IP.
8. Introduzir também 255.255.255.252 como RED netmask.
9. Atribuir RED-S2S, manter Tunnel compression e MTU e guardar.

Se o cliente só conseguir alcançar o servidor através de um endereço traduzido ou variável, o DNS, o NAT a montante e o caminho de retorno precisam de testes especialmente rigorosos. A Sophos recomenda que o servidor fique diretamente acessível sem NAT sempre que possível.

O procedimento atual da Sophos para Site-to-Site RED confirma as funções, o ficheiro e a recomendação de não traduzir o servidor por NAT. O cliente inicia a ligação de saída, pelo que a filial não precisa de publicação de entrada equivalente.

Adicionar rotas estáticas sem interface

Depois de estabelecido, o túnel não conhece automaticamente as redes LAN atrás das firewalls. É criada uma rota unicast IPv4 em ambos os lados:

• Central: destino 10.20.0.0/16, gateway 10.255.100.2
• Filial: destino 10.10.0.0/16, gateway 10.255.100.1

A exceção RED decisiva é que não se seleciona nenhuma interface para estas duas rotas. A firewall envia pedidos ARP para determinar a interface RED acessível para o endereço do peer. Selecionar posteriormente uma interface pode interferir com este mecanismo e não constitui uma melhoria.

A rota é criada em Routing > Static routes > IPv4 unicast route > Add. Administrative Distance e Metric são escolhidos conscientemente para corresponder ao restante design de routing. Configurar e testar uma rota estática na Sophos Firewall explica a lógica geral dos campos e a validação com Route Lookup.

Limitar o serviço RED e as regras de firewall

Primeiro, o serviço RED local deve aceitar a ligação. Em Administration > Device access, ativar RED apenas para a zona real de chegada. Com endereços públicos de origem estáveis, criar antes em Local service ACL exception rule > Add uma regra Accept restrita com Source zone, Source Network / Host, interface WAN como Destination host e Services: RED. Regras normais não controlam serviços locais. Ver Sophos Device access e Device Access e Local Service ACL.

Depois, em Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, um fluxo da central exige: central origem LAN/10.10.0.0/16, destino RED-S2S/10.20.0.0/16; filial origem RED-S2S/10.10.0.0/16, destino LAN/10.20.0.0/16. Limitar Services ao necessário.

Para ligações iniciadas pela filial, adicionar o par inverso. Ativar Log firewall traffic, verificar a posição e deixar Create linked NAT rule desativado. Preservar endereços reais e rotas de retorno; não substituir uma exceção NAT intencional sem revisão. Compreender e configurar regras da Sophos Firewall detalha as regras.

Validação, troubleshooting e rollback

Validar o túnel de forma controlada

A validação começa com um único fluxo de teste cuja hora exata é registada. Primeiro, confirma-se que ambas as interfaces RED estão ativas e que Route Lookup mostra o caminho esperado para um endereço na LAN remota. Em seguida, o fluxo deve corresponder à Rule ID prevista nas duas firewalls.

Um Packet Capture na Sophos Firewall mostra se o pacote entra na interface RED do lado de origem, chega ao peer e é encaminhado para a LAN de destino. O caminho de retorno é testado separadamente. Um ping por si só não é suficiente quando a aplicação de produção utiliza TCP ou UDP noutras portas.

Por isso, o sucesso significa que todos estes pontos são cumpridos em simultâneo:

• As interfaces RED estão ativas em ambos os lados.
• Route Lookup mostra o caminho planeado nas duas direções.
• A regra de firewall esperada corresponde nas duas firewalls.
• Um fluxo de aplicação real funciona de forma bidirecional.
• Os endereços de origem e destino aparecem sem NAT não intencional.
• Após um reinício controlado, um novo fluxo funciona novamente; um cluster HA exige ainda um teste de failover separado.

Para HA, a Sophos documenta um atraso enquanto os túneis RED voltam a ligar à Auxiliary Firewall após failover. Depende do número de interfaces e de outras definições e aplica-se também a Site-to-Site RED. Não prometer recuperação imediata: registar o momento, estado e tempo de reconexão e repetir o fluxo. Ver Add a RED interface.

Delimitar erros de forma sistemática

O cliente não estabelece o túnel: Verificar RED provisioning service, endereço do servidor, DNS, acessibilidade, Device Access e o ficheiro de provisionamento pertencente ao túnel. Não combinar cegamente um novo ficheiro com uma configuração antiga do cliente.

O ficheiro de provisionamento é rejeitado: confirmar que veio da interface atual do servidor e não foi alterado. Preservar primeiro o estado anterior; depois descarregar outro ficheiro se necessário e recriar o cliente numa janela de manutenção.

O túnel está ativo, mas a LAN remota não está acessível: Verificar em ambos os lados a rede de destino e o IP RED do peer na rota estática. Não pode estar selecionada nenhuma interface nesta rota RED especial. Depois, verificar a correspondência da regra e a rota de retorno.

Só funciona uma direção: Normalmente falta uma regra ou rota adequada numa firewall, ou uma rede do local já é alcançada por um caminho mais específico ou de prioridade superior. Route Lookup, Packet Capture e o tráfego de retorno real têm de coincidir.

A ligação é instável: Correlacionar latência, perda de pacotes, acessibilidade pública do servidor, NAT à frente do servidor e alterações no caminho WAN. Guardar os logs locais do nó para a hora exata do teste. Encontrar e analisar os logs de serviço da Sophos Firewall explica os ficheiros de log e os caminhos de suporte.

Ligações pequenas funcionam, mas transferências grandes param: procurar fragmentação e mensagens ICMP Path MTU no Packet Capture. Só depois testar gradualmente a mesma MTU nas duas interfaces. Não alterar compression e MTU em simultâneo.

Nenhuma regra Any ampla, autorização WAN geral, reinício de serviço ou alteração aleatória dos IP RED e das rotas substitui esta correlação. Se o erro continuar pouco claro apesar de um design correto, são recolhidos para o Sophos Support o backup, build SFOS, timestamp, estado das interfaces, rotas, Rule IDs, Packet Capture e logs relevantes.

Reverter com segurança

Se o piloto falhar, desativar primeiro regras e remover rotas, depois a interface client e por fim a server. Repor Device Access/Local Service ACL e valores MTU ou compression; remover objetos novos apenas se não forem usados noutro local.

Um caminho de gestão existente que utilize precisamente este túnel não é removido antes de um acesso alternativo ter sido testado com sucesso. Após a reversão, verificam-se novamente o routing normal, as regras anteriores e a acessibilidade das duas firewalls.

FAQ