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 a IPsec policy-based. Para designs novos ou em crescimento, route-based Any-to-Any com XFRM e routing explícito é frequentemente mais flexível. 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.

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 caminho de retorno documentado e uma janela de manutenção.

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. Sem um caminho de retorno e NAT corretos, o túnel pode estar verde e as ligações à Internet não receberem resposta.

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
• 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.

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 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. Packet Capture mostra 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.

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.

No rollback, desativa-se primeiro a regra Branch_LAN_to_WAN_drop e restaura-se de forma controlada o caminho local para a Internet que estava anteriormente permitido. Depois, as regras VPN-to-WAN e MASQ só são removidas quando nenhum outro fluxo depende delas. Route Precedence e a opção de tráfego do sistema são repostas exatamente nos valores anteriores documentados; em seguida, repetem-se os testes nos dois locais.

FAQ