Collegare Sophos Firewall ad Azure VPN Gateway

Un Azure VPN Gateway collega una rete locale a un Azure Virtual Network tramite Site-to-Site IPsec. Su Sophos Firewall di solito si usa un route-based IPsec VPN. Negli ambienti più grandi o dinamici si aggiunge spesso BGP.

L’articolo spiega il flusso pratico con SFOS 22 e un Azure VPN Gateway attuale: oggetti Azure necessari, configurazione Sophos, parametri IPsec/IKE da allineare e verifica del traffico reale dopo il salvataggio. Per le basi IPsec generali vedere configurare Sophos Firewall Site-to-Site IPsec VPN. Se un tunnel è verde ma non trasporta traffico, usare Sophos Firewall IPsec VPN Troubleshooting.

Quando questo articolo è adatto

L’articolo è adatto quando una rete locale dietro Sophos Firewall deve essere collegata a un Azure Virtual Network. Si tratta di un tunnel Site-to-Site tra Azure VPN Gateway e firewall locale, non di Point-to-Site VPN per singoli utenti e non di Sophos Firewall come appliance virtuale in Azure.

Scenari tipici:

• rete server locale verso Azure VMs
• sede principale o filiale verso Azure Virtual Network
• scenario ibrido con AD, DNS, backup, monitoring o management in Azure
• migrazione da design policy-based a route-based IPsec
• BGP opzionale per routing dinamico tra rete locale e Azure

Azure e Sophos non usano sempre gli stessi termini. In Azure si lavora con Virtual network, Gateway subnet, Virtual network gateway, Local network gateway e Connection. Su Sophos Firewall con connessione IPsec, interfaccia XFRM, rotte, regole firewall ed eventualmente BGP.

Pianificare prima della configurazione

Un tunnel Azure non dovrebbe essere trattato come un semplice wizard. La maggior parte degli errori deriva da reti sovrapposte, SKU gateway errata, parametri IPsec/IKE non compatibili, rotte mancanti o regole firewall senza logging.

Reti e address spaces

Le reti locali e gli address spaces Azure non devono sovrapporsi. Azure instrada i prefissi locali inseriti nel Local network gateway verso Sophos Firewall. Sophos Firewall instrada i prefissi Azure tramite interfaccia XFRM o BGP.

Documentare prima:

• Azure Virtual Network Address Space, ad esempio 10.50.0.0/16
• subnet Azure, soprattutto workload subnets
• rete locale dietro Sophos Firewall, ad esempio 172.16.10.0/24
• IP pubblico di Sophos Firewall o router upstream
• IP pubblico Azure del Virtual Network Gateway
• BGP sì o no
• Preshared Key condiviso
• sistemi di test su entrambi i lati

Se reti locali e Azure si sovrappongono, correggere prima il design. NAT over IPsec è possibile, ma complica molto esercizio e troubleshooting.

Route-based invece di policy-based

Per Azure, route-based IPsec è la scelta corretta. Le SKU VpnGw*AZ attuali sono route-based; un vero gateway policy-based esiste solo con la SKU Basic limitata e IKEv1. Un gateway Azure route-based può usare Use policy based traffic selectors per una firewall locale policy-based, ma è una modalità di compatibilità che richiede selettori per ogni combinazione di prefissi. Con SFOS 22, un tunnel route-based con XFRM è più chiaro ed è necessario per BGP, active-active e Azure NAT.

Su Sophos Firewall significa:

• pianificare la connessione IPsec come tunnel interface route-based;
• verificare l’interfaccia XFRM dopo il salvataggio;
• impostare rotte o BGP per i prefissi Azure;
• creare regole firewall tra zone locali e zona VPN;
• verificare il traffico con Log Viewer e stato della connection Azure.

Uno stato tunnel verde è solo una parte della validazione. Il tunnel è davvero verificato solo quando un client definito raggiunge una destinazione Azure definita e su entrambi i lati si vedono log o contatori.

Non indovinare parametri IPsec/IKE

Azure VPN Gateway supporta custom IPsec/IKE policies su VpnGw1–VpnGw5 e VpnGw1AZ–VpnGw5AZ, ma non su Basic. Microsoft richiede una combinazione completa per Connection. Verificare sempre la documentazione Microsoft.

Per l’operatività:

• scegliere consapevolmente la versione IKE, di solito IKEv2;
• documentare encryption, integrity, DH group, PFS e lifetimes;
• confrontare Azure Custom Policy e Sophos IPsec Profile;
• non trasferire automaticamente default Sophos-to-Sophos su Azure;
• pianificare finestra di manutenzione e rollback per ogni cambio policy.

Senza Custom Policy, almeno una proposta Sophos deve corrispondere ai parametri Azure predefiniti. I profili IPsec di SFOS 22 supportano i gruppi DH 1, 2, 5, da 14 a 21 e da 25 a 31, ma non il gruppo DH 24. Una Custom Policy deve quindi usare solo valori presenti negli elenchi attuali di entrambi i produttori.

Azure fissa la lifetime IKE SA a 28 800 secondi; la Default Policy route-based usa 27 000 secondi e 102 400 000 KB per la Quick Mode SA. Una Custom Policy imposta esplicitamente questi limiti, mentre Microsoft consente lifetime SA locali diverse. SFOS raccomanda comunque una Key lifetime più breve sull’initiator e una lifetime di fase 2 inferiore alla fase 1 per evitare collisioni di rekey. Poiché qui Sophos avvia la connessione, rispettare questo ordine senza inventare valori universali e osservare almeno un rekey.

Preparare il lato Azure

La configurazione Azure contiene vari oggetti. I nomi devono essere chiari, perché il troubleshooting diventa rapidamente confuso.

Virtual Network e Gateway subnet

L’Azure Virtual Network richiede un GatewaySubnet dedicato. Questa subnet è usata da Azure VPN Gateway e non deve contenere normali VM.

Controllare:

1. Azure Virtual Network esiste.
2. Address Space non si sovrappone alle reti locali.
3. GatewaySubnet esiste ed è dimensionata correttamente. Tranne Basic con minimo /29, le SKU attuali richiedono almeno /27; Microsoft consiglia più di /27 per espansioni future.
4. GatewaySubnet non contiene VM né NSG. Una UDR 0.0.0.0/0 non è supportata e BGP route propagation deve restare attiva.
5. Workload subnets e Network Security Groups permettono il traffico desiderato.

Creare Virtual Network Gateway

Il Virtual network gateway è il vero Azure VPN Gateway. Punti importanti:

• Gateway type: VPN
• VPN type: Route-based
• SKU adatta a banda, SLA, Availability Zone e requisito BGP
• Public IP per il gateway
• Active-active solo se il lato locale può creare due tunnel verso i due IP pubblici Azure
• BGP solo se ASN, peer IP e concetto di routing sono definiti

Per nuovi gateway, scegliere le SKU VpnGw*AZ: VpnGw1AZ–VpnGw3AZ esistono in Generation 1, mentre Generation 2 va da VpnGw2AZ a VpnGw5AZ. Microsoft riserva VpnGw1–VpnGw5 alle migrazioni e sconsiglia Basic in produzione. Controllare la tabella SKU aggiornata.

In active-active, i due tunnel IPsec appartengono alla stessa Connection Azure, ma ogni istanza Azure ha un proprio IP pubblico. Sophos richiede quindi una connessione route-based e un’interfaccia XFRM separate per ogni IP Azure. Il routing deve tollerare entrambi i tunnel e la perdita di ciascun percorso; verificare separatamente attivazione, traffico e failover di ogni tunnel.

Creare Local Network Gateway

Il Local network gateway descrive il lato locale dal punto di vista di Azure.

Inserire:

1. Nome, ad esempio lng-sophos-hq.
2. Endpoint come IP pubblico o FQDN del lato Sophos.
3. Local Address spaces: tutti i prefissi locali senza BGP; con BGP il campo può restare vuoto. Aggiungere prefissi statici solo se non vengono appresi tramite BGP.
4. In Advanced, attivare BGP e inserire ASN e BGP Peer IP Sophos.

Azure usa normalmente un indirizzo privato del GatewaySubnet come peer BGP. Se Sophos usa APIPA, assegnare ad Azure un indirizzo univoco tra 169.254.21.0 e 169.254.22.255; quello locale può essere tra 169.254.0.1 e 169.254.255.254. Gli indirizzi non devono sovrapporsi e Sophos deve avviare la sessione APIPA. Vedere la guida BGP Azure.

Se Sophos Firewall è dietro NAT, verificare attentamente quale IP pubblico vede Azure e come sono implementati NAT-T, port forwarding e ID. Il percorso standard semplice è una Sophos Firewall con IP pubblico proprio.

Creare Connection

La Connection collega Virtual Network Gateway e Local Network Gateway.

Valori importanti:

• Connection type: Site-to-site (IPsec)
• Shared key: identico al Preshared Key Sophos
• IKE Protocol: coerente con la configurazione Sophos
• BGP: attivare solo se entrambi i lati usano BGP
• Custom IPsec/IKE policy: impostare solo se i valori sono pianificati

Dopo la creazione della Connection, Azure è pronto, ma non automaticamente produttivo. Il lato Sophos deve conoscere lo stesso tunnel, gli stessi parametri e il percorso di ritorno.

Configurare Sophos Firewall

Su Sophos Firewall il tunnel si crea in Site-to-site VPN > IPsec.

Preparare IPsec profile

In Profiles > IPsec profiles usare o creare un profilo compatibile con Azure. Comprendere e configurare in sicurezza i profili IPsec Sophos Firewall spiega come interagiscono i campi Sophos e come clonare correttamente un profilo personalizzato. I valori specifici devono comunque corrispondere esattamente alla Azure default policy o alla custom IPsec/IKE policy della Connection.

Documentare:

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

Se Azure usa una Custom Policy, il nome del profilo dovrebbe indicarlo, ad esempio Azure_IKEv2_AES256_G14.

Creare connessione IPsec route-based

Percorso:

Site-to-site VPN > IPsec

Procedura:

1. Aprire Add.
2. Scegliere Route-based o tunnel interface come tipo di connessione.
3. Impostare un nome, ad esempio azure-vnet-prod.
4. Impostare Gateway type lato Sophos normalmente su Initiate the connection.
5. Inserire l’IP pubblico Azure del Virtual Network Gateway come Remote Gateway.
6. Impostare il Preshared Key identico alla Connection Azure.
7. Verificare Local ID e Remote ID, soprattutto con NAT o più tunnel.
8. Selezionare IPsec profile.
9. Salvare e attivare la connessione.

Dopo il salvataggio, verificare l’interfaccia XFRM in Network > Interfaces. Rimane assegnata alla zona VPN. A seconda del design si usa con rotta statica, SD-WAN route o BGP.

Impostare entrambi i traffic selector Sophos su Any. La firewall crea automaticamente un’interfaccia xfrm numerata. Per Any-to-Any SFOS non crea regole firewall automatiche. NAT-T è sempre attivo; dietro NAT upstream devono corrispondere anche gli ID dei peer.

Configurare route o BGP

Senza BGP, usare Download configuration nella Connection Azure per ottenere i parametri generici, quindi assegnare all’XFRM in Network > Interfaces il primo IP tunnel, la netmask e l’MSS indicati. In Routing > Static routes > IPv4 unicast route, aggiungere ogni prefisso Azure tramite questa interfaccia. Gateway può restare vuoto o usare l’indirizzo peer della subnet di trasferimento scaricata. Con BGP, assegnare invece a XFRM il BGP peer IP locale e la netmask inseriti nel Local Network Gateway; il neighbor Sophos è l’Azure BGP Peer IP mostrato in Virtual network gateway > Configuration. Non inventare indirizzi di trasferimento.

Con BGP, entrambi i lati devono essere pianificati con attenzione. Configurare BGP su Sophos Firewall spiega la configurazione di base, l’autorizzazione sicura e la verifica; per Azure vengono quindi utilizzati i valori del peer specificati da Azure:

• ASN locale di Sophos Firewall
• Azure ASN
• BGP peer IPs
• prefissi consentiti e annunciati
• route advertisement in Azure
• regole firewall per il traffico reale

BGP non sostituisce le regole firewall. Distribuisce solo rotte. La raggiungibilità di un server in Azure dipende ancora da routing, NSG, regole firewall e sistema di destinazione.

Il design BGP Azure documentato usa IPv4. L’ASN locale deve essere diverso dall’ASN Azure e non può essere uno degli ASN riservati: 8075, 8076, 12076, 65515, 65517, 65518, 65519 o 65520. In Administration > Device access consentire Dynamic Routing per la zona VPN, poi verificare i prefissi appresi su entrambi i lati.

Per il traffico generato dalla firewall, verificare prima source IP effettivo, prefissi annunciati e percorso di ritorno. Se la sorgente non appartiene a un prefisso locale instradato da Azure, può servire una mappatura sys-traffic-nat mirata verso l’IP LAN della firewall; non aggiungerla solo perché si usa BGP. Instradare selettivamente il traffico di sistema tramite IPsec descrive pre-check, sintassi Device Console, verifica e rimozione esatta.

NAT solo come scelta progettuale

Azure NAT per reti sovrapposte è limitato a S2S route-based su VpnGw2–VpnGw5 e VpnGw2AZ–VpnGw5AZ, senza policy-based traffic selectors. Static NAT è 1:1 e bidirezionale; dynamic NAT è stateful e va iniziato dal lato Internal mapping. Con BGP attivare BGP route translation; APIPA BGP non è compatibile con Azure NAT. Vedere i limiti NAT Microsoft.

Creare regole firewall

Il traffico nel tunnel richiede regole adatte, tipicamente tra zona interna e zona VPN.

Raccomandazioni per il rollout:

• usare reti o host concreti come source e destination;
• scegliere servizi specifici per il primo test, ad esempio ICMP, RDP, HTTPS o DNS;
• attivare Log firewall traffic;
• non lasciare regole su Any dopo il primo test;
• controllare separatamente la direzione opposta se Azure deve raggiungere sistemi locali.

Se la regola non corrisponde, usare Sophos Firewall: verificare perché una regola non corrisponde.

Verificare la connessione

La validazione deve controllare sempre due livelli: stato del tunnel e traffico reale.

Verificare Azure

In Azure:

1. Aprire la Connection del VPN Gateway.
2. Verificare lo stato della connessione.
3. Osservare i contatori dati.
4. Verificare le effective routes della Azure VM interessata.
5. Controllare il Network Security Group delle subnet di destinazione.

Lo stato Azure da solo non basta. Una VM può restare irraggiungibile nonostante Connection attiva per NSG, Windows Firewall locale, rotta errata o ritorno mancante.

Verificare Sophos Firewall

Su Sophos Firewall:

1. Controllare stato in Site-to-site VPN > IPsec.
2. Verificare interfaccia XFRM in Network > Interfaces.
3. Verificare route verso prefissi Azure.
4. Filtrare Log Viewer per il traffico di test.
5. Usare Packet Capture o strongswan.log se necessario.

Per log IPsec e analisi CLI usare Sophos Firewall IPsec VPN Troubleshooting.

In Azure, VPN Gateway > Diagnostic settings con IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog e GatewayDiagnosticLog fornisce prove migliori di un reset. Confrontare i timestamp dello stesso test e resettare solo alla fine, perché il reset riavvia l’istanza attiva.

Usare traffico di test realistico

ICMP è un buon inizio, ma non è un test completo. Poi testare il servizio produttivo:

• DNS verso un server DNS o domain controller Azure
• RDP o SSH verso una VM di test
• HTTPS verso un’applicazione interna
• traffico backup, monitoring o management

La source è importante. Un ping direttamente dal firewall non prova la stessa cosa di un test da un client dietro il firewall.

Errori tipici

Il tunnel resta down

Di solito gateway IP, versione IKE, Preshared Key, ID o parametri IPsec/IKE non corrispondono. Su Sophos Firewall controllare prima strongswan.log e confrontare Azure Connection Settings con Sophos IPsec Profile. Se più connessioni IPsec usano gli stessi endpoint, verificare anche l’assegnazione del PSK: IKEv2 supporta un PSK distinto per ogni combinazione di Local ID e Remote ID. IKEv1 supporta invece un solo PSK per combinazione di gateway locale e remoto; SFOS applica quello della connessione configurata più di recente. ID univoci con IKEv2 evitano questa collisione.

Il tunnel è connesso, ma non passa traffico

Spesso mancano rotte, regole firewall, regole Azure NSG o ritorno. Lato Sophos controllare Log Viewer e route. Lato Azure controllare Effective Routes e NSG.

Funziona solo una direzione

Spesso indica routing asimmetrico, NSG, host firewall o regola inversa mancante. Testare entrambe le direzioni separatamente e documentare la source del traffico di test.

BGP non apprende rotte

Controllare ASN, peer IP, attivazione BGP, indirizzo XFRM e configurazione Azure BGP. Poi verificare quali prefissi sono realmente annunciati e appresi. Un tunnel IPsec attivo non significa automaticamente che BGP instradi correttamente.

Il tunnel non sale dopo una modifica policy

Le Custom IPsec/IKE Policies devono essere complete e compatibili. Se Azure e Sophos interpretano diversamente anche un solo valore, la connessione può fallire. Prima delle modifiche documentare profilo attuale, Azure Policy e stato funzionante.

Azure è initiator e il child SA scade

Quando Azure è l’initiator, esegue il rekey di un child SA in scadenza solo se esiste traffico nel tunnel. Senza traffico Azure lo elimina, mentre la fase 1 resta attiva. Traffico successivo da Azure può creare un nuovo child SA; il traffico avviato solo dietro Sophos Firewall non induce Azure a crearlo in questo stato. Per questo Initiate the connection su Sophos è adatto al design. Il rekey dell’IKE SA Azure può inoltre causare una breve interruzione.

Rollback senza distruggere lo stato

Prima di una modifica, esportare o documentare connessione Sophos, profilo, indirizzo XFRM, rotte e regole, oltre a SKU/generazione Azure, Connection, Shared Key, BGP e NAT. Non eliminare la Connection funzionante: clonare il profilo Sophos e annotare la policy Azure in Connection > Configuration o via PowerShell.

In caso di errore, riassegnare il vecchio profilo Sophos e ripristinare esattamente la precedente Custom Policy Azure, oppure rimuovere solo quella nuova se prima erano attivi i default. Riattivare la connessione e ripetere i test tunnel, route e applicazione. Non eliminare preventivamente gateway, Local Network Gateway, XFRM, route o NAT: si perderebbe lo stato noto e potrebbero cambiare IP pubblico o routing.

FAQ