Ligar Sophos Firewall ao Azure VPN Gateway

Um Azure VPN Gateway liga uma rede local a um Azure Virtual Network via Site-to-Site IPsec. No Sophos Firewall, isto é normalmente implementado como route-based IPsec VPN. Ambientes maiores ou mais dinâmicos usam frequentemente BGP.

Este artigo explica o fluxo prático com SFOS 22 e um Azure VPN Gateway atual: que objetos Azure são necessários, como o lado Sophos é configurado, que parâmetros IPsec/IKE devem corresponder e como verificar depois de guardar se o tráfego realmente passa. Para bases gerais de IPsec, consultar primeiro configurar Sophos Firewall Site-to-Site IPsec VPN. Se um túnel existente está verde mas não transporta tráfego, usar Sophos Firewall IPsec VPN Troubleshooting.

Quando este artigo se aplica

Aplica-se quando uma rede local atrás de Sophos Firewall deve ser ligada a um Azure Virtual Network. Trata de um túnel Site-to-Site entre Azure VPN Gateway e firewall local, não de Point-to-Site VPN para utilizadores individuais nem de Sophos Firewall como appliance virtual em Azure.

Cenários típicos:

• rede local de servidores para Azure VMs
• filial ou sede para Azure Virtual Network
• cenário híbrido com AD, DNS, backup, monitoring ou management em Azure
• migração de designs policy-based para route-based IPsec
• BGP opcional para routing dinâmico entre rede local e Azure

Azure e Sophos nem sempre usam os mesmos termos. Em Azure trabalha-se com Virtual network, Gateway subnet, Virtual network gateway, Local network gateway e Connection. No Sophos Firewall, com ligação IPsec, interface XFRM, rotas, regras firewall e opcionalmente BGP.

Planear antes da configuração

Um túnel Azure não deve ser tratado como um simples assistente. A maioria dos erros vem de redes sobrepostas, gateway SKU errada, parâmetros IPsec/IKE incompatíveis, rotas em falta ou regras firewall sem logging.

Redes e espaços de endereços

As redes locais e os Azure address spaces não podem sobrepor-se. Azure encaminha os prefixos locais definidos no Local network gateway para o Sophos Firewall. O Sophos Firewall encaminha prefixos Azure pela interface XFRM ou por BGP.

Documentar antes:

• Azure Virtual Network Address Space, por exemplo 10.50.0.0/16
• subnets Azure, especialmente workload subnets
• rede local atrás do Sophos Firewall, por exemplo 172.16.10.0/24
• IP público do Sophos Firewall ou router upstream
• Azure Public IP do Virtual Network Gateway
• BGP sim ou não
• Preshared Key comum
• sistemas de teste planeados nos dois lados

Se redes locais e Azure se sobrepõem, o design deve ser corrigido primeiro. NAT over IPsec é possível, mas torna operação e troubleshooting bastante mais difíceis.

Route-based em vez de policy-based

Para Azure, route-based IPsec é a escolha correta. As SKUs VpnGw*AZ atuais são route-based; um gateway realmente policy-based só existe com a SKU Basic limitada e IKEv1. Um gateway Azure route-based pode usar Use policy based traffic selectors para uma firewall local policy-based, mas este modo exige seletores para cada combinação de prefixos. Com SFOS 22, um túnel route-based com XFRM é mais claro e necessário para BGP, active-active e Azure NAT.

No Sophos Firewall isto significa:

• planear a ligação IPsec como route-based tunnel interface;
• verificar a interface XFRM depois de guardar;
• definir rotas ou BGP para prefixos Azure;
• criar regras firewall entre zonas locais e zona VPN;
• verificar tráfego com Log Viewer e estado da Azure Connection.

Um túnel verde é apenas parte da validação. O túnel só está realmente verificado quando um cliente definido atinge um destino Azure definido e ambos os lados mostram logs ou contadores.

Não adivinhar parâmetros IPsec/IKE

Azure VPN Gateway suporta custom IPsec/IKE policies em VpnGw1–VpnGw5 e VpnGw1AZ–VpnGw5AZ, mas não em Basic. A Microsoft exige uma combinação completa por Connection. Antes de alterar o perfil, registar os valores implementados em Connection > Configuration e Profiles > IPsec profiles. A policy completa inclui cifra/integridade IKE e DH, cifra/integridade IPsec e PFS, duração da SA e limite de dados. Escolher uma combinação aceite pelos dois sistemas implementados e conservar a policy anterior para reversão.

Para operação:

• escolher conscientemente a versão IKE, normalmente IKEv2;
• documentar encryption, integrity, DH group, PFS e lifetimes;
• comparar Azure Custom Policy e Sophos IPsec Profile;
• não transferir defaults Sophos-para-Sophos para Azure sem validação;
• planear janela de manutenção e rollback para cada alteração de policy.

Sem Custom Policy, pelo menos uma proposta Sophos deve corresponder à policy Azure predefinida implementada. Os perfis IPsec do SFOS 22 suportam os grupos DH 1, 2, 5, 14 a 21 e 25 a 31, mas não o grupo DH 24. Uma Custom Policy deve usar apenas valores suportados pelos dois sistemas implementados. O perfil inicial documentado é Microsoft Azure (IKEv2): comparar as propostas reais com a policy da Connection e verificar estabelecimento e rekey. O nome do perfil não prova compatibilidade.

Azure fixa a lifetime IKE SA em 28 800 segundos; a route-based Default Policy usa 27 000 segundos e 102 400 000 KB para a Quick Mode SA. Uma Custom Policy define explicitamente estes limites, enquanto a Microsoft permite lifetimes SA locais diferentes. SFOS continua a recomendar uma Key lifetime menor no initiator e uma lifetime de fase 2 inferior à fase 1 para evitar colisões de rekey. Como Sophos inicia aqui, aplicar essa ordem sem inventar valores universais e observar pelo menos um rekey.

Preparar o lado Azure

A configuração Azure consiste em vários objetos. Os nomes devem ser claros para facilitar troubleshooting posterior.

Virtual Network e Gateway subnet

O Azure Virtual Network precisa de um GatewaySubnet dedicado. Este subnet é usado pelo Azure VPN Gateway e não deve ser usado por VMs normais.

Verificar:

1. Azure Virtual Network existe.
2. Address Space não se sobrepõe às redes locais.
3. GatewaySubnet existe e tem tamanho suficiente. Exceto Basic com mínimo /29, as SKUs atuais exigem pelo menos /27; a Microsoft recomenda maior que /27 para expansão.
4. GatewaySubnet não contém VMs nem NSG. Uma UDR 0.0.0.0/0 não é suportada e BGP route propagation deve permanecer ativa.
5. Workload subnets e Network Security Groups permitem o tráfego pretendido.

Criar Virtual Network Gateway

O Virtual network gateway é o Azure VPN Gateway propriamente dito. Importante:

• Gateway type: VPN
• VPN type: Route-based
• SKU adequada a largura de banda, SLA, Availability Zone e requisito BGP
• Public IP para o gateway
• Active-active só se o lado local puder criar dois túneis para os dois IPs públicos Azure
• BGP só se ASN, peer IP e conceito de routing estiverem definidos

Para novos gateways usam-se SKUs VpnGw*AZ: VpnGw1AZ–VpnGw3AZ existem como Generation 1 e Generation 2 vai de VpnGw2AZ a VpnGw5AZ. A Microsoft reserva VpnGw1–VpnGw5 para migrações e desaconselha Basic em produção. Em Virtual network gateways > Create, verificar as opções SKU/geração da subscrição e região; registar largura de banda, número de túneis, funções BGP/NAT, quotas e aprovação dos custos antes da criação. As famílias indicadas são limites de planeamento, não promessas de desempenho ou disponibilidade.

Em active-active, os dois túneis IPsec pertencem à mesma Azure Connection, mas cada instância Azure tem um IP público próprio. Sophos precisa assim de uma ligação route-based e interface XFRM separadas para cada IP Azure. O routing deve suportar tráfego nos dois túneis e a perda de qualquer caminho; testar estabelecimento, carga e failover de cada túnel separadamente.

Criar Local Network Gateway

O Local network gateway descreve o lado local do ponto de vista de Azure.

Inserir:

1. Nome, por exemplo lng-sophos-hq.
2. Endpoint como IP público ou FQDN do lado Sophos.
3. Local Address spaces: todos os prefixos locais sem BGP; com BGP o campo pode ficar vazio. Adicionar prefixos estáticos apenas quando não são aprendidos por BGP.
4. Em Advanced, ativar BGP e inserir ASN e BGP Peer IP da Sophos Firewall apenas se for utilizado routing dinâmico.

Azure usa normalmente um endereço privado do GatewaySubnet como peer BGP. Se Sophos usa APIPA, atribuir a Azure um endereço único de 169.254.21.0 a 169.254.22.255; o local pode estar entre 169.254.0.1 e 169.254.255.254. Não podem sobrepor-se e Sophos deve iniciar a sessão APIPA. Obter os valores finais em Virtual network gateway > Configuration, registá-los no plano de endereçamento e compará-los com Local Network Gateway e XFRM.

Se Sophos Firewall estiver atrás de NAT, verificar exatamente que IP público Azure vê e como NAT-T, port forwarding e IDs são implementados localmente. O caminho simples padrão é Sophos Firewall com IP público próprio.

Criar Connection

A Connection liga Virtual Network Gateway e Local Network Gateway.

Valores importantes:

• Connection type: Site-to-site (IPsec)
• Shared key: idêntica à Sophos Preshared Key
• IKE Protocol: compatível com a configuração Sophos
• BGP: ativar apenas se ambos os lados usam BGP
• Custom IPsec/IKE policy: definir apenas se os valores foram planeados
• Para o exemplo documentado Sophos-iniciador/Azure-responder: Virtual network gateways > [gateway] > Settings > Connections > [connection] > Configuration, ou Add > Settings durante a criação; Connection Mode: ResponderOnly, DPD timeout in seconds: manter o valor predefinido. Registar o valor DPD mostrado e verificar a policy implementada; não se afirma um timeout universal. Associar a Initiate the connection no Sophos. Na receita estática sem BGP, Use Azure private IP address e Enable BGP ficam desativados e Use policy based traffic selector: Disable. Validar outros desenhos separadamente.

Depois de criar a Connection, Azure está pronto, mas não automaticamente produtivo. O lado Sophos deve conhecer o mesmo túnel, os mesmos parâmetros e o caminho de retorno.

Configurar Sophos Firewall

No Sophos Firewall, o túnel é criado em Site-to-site VPN > IPsec.

Preparar IPsec profile

Em Profiles > IPsec profiles, usar ou criar um perfil compatível com Azure. A relação entre os campos da Sophos e a forma correta de clonar um perfil próprio são explicadas em Compreender e configurar perfis IPsec na Sophos Firewall. Os valores concretos continuam a ter de corresponder exatamente à Azure default policy ou à custom IPsec/IKE policy da Connection.

Documentar:

• IKE version
• Phase 1 encryption e authentication
• DH group
• Phase 2 encryption e authentication
• PFS
• Key lifetime

Se Azure usa Custom Policy, o nome do perfil deve refletir isso, por exemplo Azure_IKEv2_AES256_G14.

Criar ligação IPsec route-based

Caminho:

Site-to-site VPN > IPsec

Procedimento:

1. Abrir Add.
2. Escolher Route-based ou tunnel interface como tipo de ligação.
3. Definir nome, por exemplo azure-vnet-prod.
4. Definir Gateway type no lado Sophos normalmente como Initiate the connection.
5. Inserir o Azure Public IP do Virtual Network Gateway como Remote Gateway.
6. Definir Preshared Key idêntica à Azure Connection.
7. Verificar Local ID e Remote ID, sobretudo com NAT ou vários túneis.
8. Selecionar IPsec profile.
9. Guardar e ativar a ligação.

Depois de guardar, verificar a interface XFRM em Network > Interfaces. Ela permanece atribuída à zona VPN. Dependendo do design, é usada com rota estática, SD-WAN route ou BGP.

Definir ambos os traffic selectors Sophos como Any. A firewall cria automaticamente uma interface xfrm numerada. Para Any-to-Any, SFOS não cria regras firewall automáticas. NAT-T está sempre ativo; atrás de NAT upstream, os IDs dos peers também têm de coincidir.

Configurar rota ou BGP

Sem BGP, usar Download configuration na Azure Connection para obter os parâmetros genéricos e atribuir à XFRM, em Network > Interfaces, o primeiro tunnel IP, netmask e MSS indicados. Em Routing > Static routes > IPv4 unicast route, adicionar cada prefixo Azure através dessa interface. Gateway pode ficar vazio ou usar o endereço peer da rede de transferência descarregada. Com BGP, atribuir à XFRM o BGP peer IP local e netmask inseridos no Local Network Gateway; o neighbor Sophos é o Azure BGP Peer IP mostrado em Virtual network gateway > Configuration. Não inventar endereços de transferência.

Com BGP, ambos os lados devem estar bem planeados. Configurar BGP na Sophos Firewall explica a configuração base, a autorização segura e a validação; para Azure, utilizam-se depois os valores de peer definidos por Azure:

• ASN local do Sophos Firewall
• Azure ASN
• BGP peer IPs
• prefixos permitidos e anunciados
• route advertisement em Azure
• regras firewall para tráfego real

BGP não substitui regras firewall. Apenas distribui rotas. Se um servidor em Azure é alcançável continua a depender de routing, NSG, regras firewall e sistema de destino.

O design Azure BGP documentado usa IPv4. O ASN local deve diferir do ASN Azure e não pode ser um ASN Azure reservado: 8075, 8076, 12076, 65515, 65517, 65518, 65519 ou 65520. Em Administration > Device access, permitir Dynamic Routing para a zona VPN. Verificar depois na Sophos se os prefixos Azure são aprendidos e, em BGP peers no Azure, se chegaram os prefixos locais.

Para tráfego gerado pela firewall, verificar primeiro o source IP real, os prefixos anunciados e o caminho de retorno. Se a origem não pertence a um prefixo local encaminhado por Azure, pode ser necessária uma atribuição sys-traffic-nat específica para o LAN IP da firewall; não a adicionar apenas por usar BGP. Encaminhar seletivamente tráfego de sistema por IPsec descreve pre-check, sintaxe Device Console, validação e remoção exata.

NAT apenas como decisão de design

Azure NAT para redes sobrepostas limita-se a S2S route-based em VpnGw2–VpnGw5 e VpnGw2AZ–VpnGw5AZ, sem policy-based traffic selectors. Static NAT é 1:1 e bidirecional; dynamic NAT mantém estado e só permite iniciar ligações a partir do lado de Internal mapping. Com BGP, ativar BGP route translation; APIPA BGP não é compatível com Azure NAT. Registar Internal/External mappings e prefixos traduzidos antes das alterações, compará-los com rotas efetivas e prefixos anunciados dos dois lados e testar os sentidos de iniciação permitidos. São limites de desenho, não uma correção improvisada.

Criar regras firewall

O tráfego pelo túnel precisa de regras adequadas, geralmente entre zona interna e zona VPN.

Recomendações para implementação:

• usar redes ou hosts concretos como source e destination;
• escolher serviços para o primeiro teste, por exemplo ICMP, RDP, HTTPS ou DNS;
• ativar Log firewall traffic;
• não deixar regras em Any depois do primeiro teste;
• verificar a direção inversa separadamente se Azure também deve alcançar sistemas locais.

Se a regra não corresponder, usar Sophos Firewall: verificar porque uma regra não corresponde.

Verificar a ligação

A validação deve verificar sempre dois níveis: estado do túnel e tráfego real.

Verificar Azure

Em Azure:

1. Abrir a Connection do VPN Gateway.
2. Verificar estado da ligação.
3. Observar contadores de dados.
4. Verificar effective routes da Azure VM afetada.
5. Verificar Network Security Group dos subnets de destino.

O estado Azure sozinho não chega. Uma VM pode estar inacessível apesar de uma Connection ativa por causa de NSG, Windows Firewall local, rota errada ou falta de caminho de retorno.

Verificar Sophos Firewall

No Sophos Firewall:

1. Verificar estado em Site-to-site VPN > IPsec.
2. Controlar a interface XFRM em Network > Interfaces.
3. Verificar rota para prefixos Azure.
4. Filtrar Log Viewer por tráfego de teste.
5. Usar Packet Capture ou strongswan.log se necessário.

Para logs IPsec e análise CLI, usar Sophos Firewall IPsec VPN Troubleshooting.

Em Azure, usar VPN Gateway > Diagnostic settings com IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog e GatewayDiagnosticLog. Comparar timestamps do mesmo teste e considerar um reset apenas após estas verificações, pois reinicia a instância ativa e pode interromper ligações existentes.

Usar tráfego de teste realista

ICMP é um bom início, mas não um teste completo. Depois testar o serviço produtivo:

• DNS para servidor DNS ou domain controller em Azure
• RDP ou SSH para VM de teste
• HTTPS para aplicação interna
• tráfego de backup, monitoring ou management

A source é importante. Um ping diretamente do firewall não prova o mesmo que um teste a partir de um cliente atrás do firewall.

Erros típicos

O túnel fica down

Normalmente IP de gateway, versão IKE, Preshared Key, IDs ou parâmetros IPsec/IKE não correspondem. No Sophos Firewall, verificar primeiro strongswan.log e comparar Azure Connection Settings com Sophos IPsec Profile. Se várias ligações IPsec usarem os mesmos endpoints, verificar também a atribuição do PSK: IKEv2 suporta um PSK distinto para cada combinação de Local ID e Remote ID. IKEv1 suporta apenas um PSK por combinação de gateway local e remoto; SFOS aplica o PSK da ligação configurada mais recentemente. IDs únicos com IKEv2 evitam esta colisão.

O túnel está ligado, mas não passa tráfego

Frequentemente faltam rotas, regras firewall, regras Azure NSG ou caminho de retorno. No lado Sophos, verificar Log Viewer e rota. No lado Azure, Effective Routes e NSG.

Só uma direção funciona

Isto aponta frequentemente para routing assimétrico, NSG, host firewall ou regra inversa em falta. Testar ambos os sentidos separadamente e documentar a source do tráfego de teste.

BGP não aprende rotas

Verificar ASN, peer IP, ativação BGP, endereço XFRM e configuração Azure BGP. Depois controlar que prefixos são realmente anunciados e aprendidos. Um túnel IPsec estabelecido não significa automaticamente que BGP encaminha corretamente.

O túnel não volta após mudança de policy

Custom IPsec/IKE Policies devem ser completas e compatíveis. Se Azure e Sophos interpretam apenas um valor de forma diferente, a ligação pode falhar. Antes de alterações, documentar perfil atual, Azure Policy e estado funcional.

Azure é initiator e o child SA expira

Quando Azure é o initiator, só faz rekey de um child SA em expiração se existir tráfego no túnel. Sem tráfego, Azure elimina o child SA enquanto a fase 1 continua ativa. Tráfego posterior do Azure pode criar um novo child SA; tráfego iniciado apenas atrás da Sophos Firewall não leva Azure a criá-lo neste estado. Por isso, Initiate the connection em Sophos é adequado ao design. O rekey do IKE SA Azure também pode causar uma interrupção curta.

Reverter sem destruir o estado

Antes de alterar, exportar ou documentar Connection e perfil Sophos, endereço XFRM, rotas e regras, além de SKU/generation Azure, Connection, Shared Key, BGP e NAT. Não eliminar a Connection funcional: clonar o perfil Sophos e registar a policy Azure em Connection > Configuration ou PowerShell.

Se falhar, voltar a atribuir o perfil Sophos anterior e restaurar exatamente a Custom Policy Azure anterior, ou remover apenas a nova se antes se usavam defaults. Reativar a ligação e repetir testes de túnel, rotas e aplicação. Não eliminar preventivamente gateway, Local Network Gateway, XFRM, rotas ou NAT; isso destrói o estado conhecido e pode alterar IP público ou routing.

FAQ