Encaminhar a Internet da filial pela sede através de IPsec

Quando o tráfego Internet de uma filial deve ser inspecionado centralmente e sair pela ligação WAN da sede, a Sophos Firewall pode usar um túnel IPsec site-to-site policy-based. Os clientes da filial deixam de comunicar diretamente pela WAN local e enviam o tráfego pelo túnel até à sede. Aí são aplicadas as regras centrais de firewall, NAT e segurança.

LAN da filial → Firewall da filial → IPsec policy-based → Sede → MASQ → Internet

Esta configuração exige mais do que um túnel VPN verde. Route Precedence, Traffic Selectors, ordem das regras e caminho de retorno têm de ser coerentes. Se o túnel ou a sede falhar, normalmente a filial não dispõe de um breakout local automático para a Internet neste design.

⚠️ Este procedimento aplica-se apenas a IPsec policy-based. O peer não pode ser route-based. Para designs novos ou em crescimento, recomenda-se route-based Any-to-Any: ambos os peers usam seletores Any, cada um recebe uma interface XFRM e são necessárias rotas Static, SD-WAN ou dinâmicas explícitas. Não misture esses passos com o procedimento policy-based seguinte. A decisão entre os tipos é explicada em Configurar uma VPN IPsec site-to-site.

Exemplo e requisitos

O exemplo utiliza a rede da filial 10.20.0.0/24. A sede dispõe de uma ligação WAN funcional e de um túnel policy-based já planeado. 10.20.0.0/24 é um valor de documentação e deve ser substituído pela rede real da filial.

Para este design, a Route Precedence global tem de ser VPN, Static, SD-WAN. Antes de a alterar, deve-se guardar o valor atual e identificar todos os outros caminhos static, VPN e SD-WAN que possam ser afetados. O procedimento controlado encontra-se em Alterar a Route Precedence com segurança.

O valor predefinido do SFOS 22 é Static, SD-WAN, VPN. Este design difere porque Remote subnet: Any cria na filial uma rota VPN policy-based automática para todos os destinos. Não se elimina a default route Static 0.0.0.0/0 para a WAN local: ela continua disponível para tráfego gerado pela firewall quando a utilização da VPN está desativada e para um rollback controlado. O valor atual é consultado na Device Console com system route_precedence show; o artigo dedicado contém o comando de alteração, a análise de impacto e o caminho de recuperação.

Antes da alteração também devem estar assegurados:

• um túnel IPsec policy-based funcional entre as duas firewalls;
• acesso administrativo testado aos dois locais;
• capacidade suficiente de Internet e da firewall na sede;
• DNS, Web Policies, IPS, Application Control e as exceções pretendidas;
• um backup atual da configuração e um registo da alteração com os seletores originais, Route Precedence, a opção de tráfego do sistema e os IDs de firewall e NAT;
• um caminho de retorno documentado e uma janela de manutenção.

Em HA, antes da alteração registam-se em cada local o nó ativo, o estado correto do cluster e o acesso administrativo ao peer. HA não substitui uma segunda WAN na sede nem um segundo local. O failover é um teste separado e não se deduz de um túnel verde.

Definir os seletores IPsec

Na sede, Local subnet é definido como Any e Remote subnet como a LAN da filial. Na filial aplica-se o inverso: rede local da filial e Any como rede remota.

Em seguida, testa-se o túnel com um destino interno na sede. O caminho para a Internet só é ativado depois de o tráfego entre os locais funcionar nos dois sentidos. Assim, um problema de IPsec continua distinguível de um problema de NAT ou de regras.

Criar regras de firewall e NAT

As regras são criadas em Rules and policies > Firewall rules. As regras VPN geradas automaticamente não constituem por si só um design completo para este caminho para a Internet.

Sede: VPN para WAN

Uma regra Branch_VPN_to_WAN permite o tráfego da filial para a Internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: apenas os serviços realmente necessários
• Log firewall traffic: ativado
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control e TLS Inspection são selecionados de forma consciente. A regra MASQ associada traduz os clientes da filial para o endereço público da sede. Para tráfego de saída, o SFOS avalia primeiro a regra de firewall e depois SNAT; também se verifica a ordem NAT, pois uma regra NAT anterior correspondente prevalece. Além disso, NAT não cria uma rota e alterações NAT só abrangem novas ligações.

O caminho de retorno tem duas partes: MASQ devolve as respostas da Internet ao endereço WAN da sede; depois, a sede usa a rota VPN policy-based automática para o destino novamente traduzido 10.20.0.0/24. Se a LAN da filial estiver atrás de outro router, os caminhos de ida e volta desse router também são documentados e testados.

Filial: permitir LAN para VPN

A regra Branch_LAN_to_VPN fica acima de qualquer regra local que permita LAN para WAN:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: apenas os serviços realmente necessários
• Log firewall traffic: ativado

Depois adiciona-se uma regra específica Branch_LAN_to_WAN_drop para a mesma rede da filial, de LAN para WAN. Esta impede que uma regra local de Internet demasiado ampla contorne o caminho planeado pelo túnel. Outras redes ou serviços locais expressamente necessários não devem ser incluídos por engano.

A ordem faz parte da segurança: exceções específicas, Branch_LAN_to_VPN, depois Branch_LAN_to_WAN_drop e finalmente regras mais amplas. Depois das alterações, validam-se novas ligações de clientes, não apenas sessões existentes.

Criar regras de firewall com segurança explica como verificar em conjunto a posição da regra, a Rule ID e a regra NAT associada.

Decidir separadamente sobre o tráfego gerado pelo sistema

As regras anteriores controlam o tráfego encaminhado dos clientes. DNS, NTP, atualizações, Central e outras ligações geradas pela própria firewall da filial são tráfego gerado pelo sistema.

O DNS também é separado pela origem. Um cliente com um resolver público segue o caminho do cliente pelo túnel. Um resolver interno na sede requer seletor, regra de firewall e caminho de retorno adequados. Apenas os pedidos DNS gerados pela própria firewall seguem a opção de tráfego do sistema. Por isso testam-se separadamente um IP público e um FQDN.

O valor predefinido é enable. Como um sistema existente pode ter outro valor, deve-se começar por consultar o estado atual com este comando apenas de leitura na Device Console:

show routing policy-based-ipsec-vpn system-generate-traffic

Se apenas o tráfego dos clientes deve passar pela sede, o tráfego gerado pela firewall pode sair localmente pela WAN da filial:

set routing policy-based-ipsec-vpn system-generate-traffic disable

⚠️ Esta alteração reinicia todos os túneis IPsec da firewall. Antes da execução, deve-se documentar o estado e o caminho de recuperação e reservar uma janela de manutenção. O comando não deve ser executado apenas para testar ou por tentativa.

Para o rollback, restaura-se o estado anterior documentado. Se a opção estava ativa, o comando inverso é:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Depois de cada alteração, todas as ligações IPsec e os serviços necessários da firewall são novamente verificados.

Validar o caminho dos dados

Um cliente de 10.20.0.0/24 abre primeiro um endereço IP público e depois um FQDN por HTTPS. A validação comprova várias camadas:

1. Na filial, a regra Branch_LAN_to_VPN corresponde; a regra local de drop LAN-to-WAN não corresponde a este fluxo bem-sucedido.
2. Na sede, correspondem Branch_VPN_to_WAN e a regra MASQ associada.
3. O endereço de origem visível publicamente pertence à sede.
4. DNS, HTTPS e um destino bloqueado de propósito comportam-se de acordo com a policy central.
5. Em Diagnostics > Packet capture, In interface, Out interface, Rule ID, NAT ID, Status e Reason mostram os pacotes de ida e volta pelo túnel e pela WAN da sede.
6. O tráfego gerado pelo sistema utiliza o caminho local ou central anteriormente definido.
7. Current activities > IPsec connections permanece estabelecido durante o teste e o Log viewer não apresenta drops inesperados.
8. Em HA, executa-se separadamente um failover de nó aprovado e repete-se o teste completo. Sem este teste não se afirma redundância HA.

Um speed test, isoladamente, não constitui uma validação completa. Também devem ser testadas aplicações reais, DNS, Security Logs e um download mais prolongado. Para problemas de desempenho existem procedimentos separados para testes de velocidade da Internet e para MTU e MSS em VPN.

Erros típicos e rollback

• O cliente da filial continua a usar a WAN local: verificar a ordem das regras, Source Network, a regra LAN-to-VPN e a regra de drop. Não adicionar uma exceção ampla como correção rápida.
• O túnel está verde, mas não há Internet: verificar na sede a regra VPN-to-WAN, Rule ID, MASQ, gateway WAN, DNS e caminho de retorno.
• Apenas a própria firewall utiliza o caminho errado: verificar policy-based-ipsec-vpn system-generate-traffic. Não confundir tráfego de clientes com tráfego gerado pelo sistema.
• Outros túneis falham depois da alteração CLI: o reinício de todos os túneis IPsec é um comportamento documentado. Restaurar o estado anterior e validar cada túnel individualmente.
• O túnel ou a sede falha: o design padrão não oferece breakout local para a Internet. Esse fallback requer um caminho de segurança e routing separado e planeado de forma consciente.
• Um IP público funciona, mas um FQDN não: verificar o endereço DNS do cliente, a regra DNS, o caminho do resolver central e as respostas. A opção de tráfego do sistema só importa quando a firewall gera o pedido.

Para o rollback, prepara-se primeiro, acima de Branch_LAN_to_WAN_drop, uma regra LAN-to-WAN temporária limitada a um único cliente de teste. Em seguida, repõe-se a Route Precedence no valor registado e verifica-se o caminho WAN local com uma nova sessão desse cliente. Se o teste falhar, repõem-se imediatamente a precedência e o estado das regras do full tunnel através de um acesso administrativo independente. Só depois de um teste bem-sucedido se ativa a regra LAN-to-WAN normal anterior, se desativa Branch_LAN_to_WAN_drop e se remove a regra temporária.

Depois, repõe-se a opção de tráfego do sistema no valor anterior e, como esta alteração reinicia os túneis, verificam-se todas as ligações IPsec. Branch_LAN_to_VPN, VPN-to-WAN e MASQ só são desativadas ou removidas quando Rule ID, NAT ID e utilização confirmam que nenhum outro fluxo depende delas. Por fim, repõem-se os seletores IPsec originais ou remove-se o túnel criado exclusivamente para este caminho. O backup da configuração e o acesso administrativo independente permanecem disponíveis até novas sessões DNS, HTTPS e de aplicações funcionarem nos dois locais.

FAQ