Anslut Sophos Firewall till Azure VPN Gateway

En Azure VPN Gateway ansluter ett lokalt nätverk till ett Azure Virtual Network via Site-to-Site IPsec. I Sophos Firewall byggs detta normalt som route-based IPsec VPN. Större eller mer dynamiska miljöer använder ofta även BGP.

Artikeln beskriver det praktiska flödet med SFOS 22 och en aktuell Azure VPN Gateway: vilka Azure-objekt som behövs, hur Sophos-sidan byggs, vilka IPsec/IKE-parametrar som måste matchas och hur man verifierar att trafik verkligen går efter sparande. För IPsec-grunder, börja med konfigurera Sophos Firewall Site-to-Site IPsec VPN. Om en befintlig tunnel är grön men inte transporterar trafik, använd Sophos Firewall IPsec VPN Troubleshooting.

När artikeln passar

Artikeln passar när ett lokalt nätverk bakom Sophos Firewall ska anslutas till ett Azure Virtual Network. Den gäller Site-to-Site-tunnel mellan Azure VPN Gateway och lokal brandvägg, inte Point-to-Site VPN för enskilda användare och inte Sophos Firewall som virtuell appliance i Azure.

Typiska scenarier:

• lokalt servernät till Azure VMs
• filial eller huvudkontor till Azure Virtual Network
• hybridscenario med AD, DNS, backup, monitoring eller management i Azure
• migrering från policy-based design till route-based IPsec
• valfritt BGP för dynamisk routing mellan lokalt nät och Azure

Azure och Sophos använder inte alltid samma termer. I Azure används Virtual network, Gateway subnet, Virtual network gateway, Local network gateway och Connection. I Sophos Firewall används IPsec-anslutning, XFRM-interface, routes, firewallregler och eventuellt BGP.

Planera före konfiguration

En Azure-tunnel bör inte behandlas som en ren klickguide. De flesta fel beror på överlappande nät, fel gateway-SKU, IPsec/IKE-parametrar som inte matchar, saknade routes eller firewallregler utan logging.

Nät och adressrymder

Lokala nät och Azure address spaces får inte överlappa. Azure routar lokala prefix i Local network gateway till Sophos Firewall. Sophos Firewall routar Azure-prefix via XFRM-interfacet eller via BGP.

Dokumentera i förväg:

• Azure Virtual Network Address Space, till exempel 10.50.0.0/16
• Azure subnets, särskilt workload subnets
• lokalt nät bakom Sophos Firewall, till exempel 172.16.10.0/24
• publik IP för Sophos Firewall eller upstream-router
• Azure Public IP för Virtual Network Gateway
• BGP ja eller nej
• gemensam Preshared Key
• planerade testsystem på båda sidor

Om lokala nät och Azure-nät överlappar ska designen först korrigeras. NAT over IPsec är möjligt, men gör drift och felsökning mycket svårare.

Route-based istället för policy-based

För Azure är route-based IPsec rätt val. Aktuella VpnGw*AZ-SKU:er är route-based; en äkta policy-based gateway finns bara med den begränsade Basic-SKU:n och IKEv1. En route-based Azure-gateway kan använda Use policy based traffic selectors för en lokal policy-based firewall, men detta är ett kompatibilitetsläge med selectors för varje prefixkombination. Med SFOS 22 är en route-based tunnel med XFRM tydligare och krävs för BGP, active-active och Azure NAT.

I Sophos Firewall innebär det:

• planera IPsec-anslutningen som route-based tunnel interface;
• kontrollera XFRM-interfacet efter sparande;
• sätt routes eller BGP för Azure-prefix;
• skapa firewallregler mellan lokala zoner och VPN-zonen;
• verifiera trafik med Log Viewer och Azure connection status.

Grön tunnelstatus är bara en del av acceptansen. Tunneln är verkligen verifierad först när en definierad klient når en definierad Azure-destination och båda sidor visar loggar eller räknare.

Gissa inte IPsec/IKE-parametrar

Azure VPN Gateway stöder custom IPsec/IKE policies på VpnGw1–VpnGw5 och VpnGw1AZ–VpnGw5AZ, men inte Basic. Microsoft kräver en fullständig kombination per Connection. Dokumentera före profiländring de använda värdena under Connection > Configuration och Profiles > IPsec profiles. En fullständig policy omfattar IKE-kryptering/integritet och DH, IPsec-kryptering/integritet och PFS, SA-livslängd och datagräns. Välj en kombination som båda driftsatta systemen accepterar och spara tidigare policy för återställning.

För drift betyder det:

• välj IKE-version medvetet, oftast IKEv2;
• dokumentera encryption, integrity, DH group, PFS och lifetimes;
• jämför Azure Custom Policy och Sophos IPsec Profile;
• överför inte Sophos-till-Sophos-defaults till Azure utan kontroll;
• planera underhållsfönster och rollback för varje policyändring.

Utan Custom Policy måste minst ett Sophos-förslag matcha den använda Azure-standardpolicyn. SFOS 22 stöder DH-grupperna 1, 2, 5, 14 till 21 och 25 till 31 i IPsec-profiler, men inte DH-grupp 24. En Custom Policy får därför bara använda värden som båda driftsatta systemen stöder. Den dokumenterade startprofilen är Microsoft Azure (IKEv2): jämför dess faktiska förslag med Connection-policyn och verifiera etablering och rekey. Profilnamnet ensamt bevisar inte kompatibilitet.

Azure låser IKE SA lifetime till 28 800 sekunder; route-based Default Policy använder 27 000 sekunder och 102 400 000 KB för Quick Mode SA. En Custom Policy anger dessa gränser uttryckligen, medan Microsoft tillåter avvikande lokala SA lifetimes. SFOS rekommenderar ändå en kortare Key lifetime på initiatorn och en fas 2 lifetime under fas 1 för att undvika rekey-kollisioner. Eftersom Sophos initierar här ska den ordningen följas utan påhittade universalvärden och minst en rekey observeras.

Förbered Azure-sidan

Azure-konfigurationen består av flera objekt. Namnen bör vara tydliga eftersom felsökning annars snabbt blir rörig.

Virtual Network och Gateway subnet

Azure Virtual Network behöver ett dedikerat GatewaySubnet. Detta subnet används av Azure VPN Gateway och får inte användas för vanliga VMs.

Kontrollera:

1. Azure Virtual Network finns.
2. Address Space överlappar inte lokala nät.
3. GatewaySubnet finns och är tillräckligt stort. Utom Basic med minst /29 kräver aktuella SKU:er minst /27; Microsoft rekommenderar större än /27 för utbyggnad.
4. GatewaySubnet innehåller inga VMs eller NSG. En 0.0.0.0/0 UDR stöds inte och BGP route propagation måste vara aktiv.
5. Workload subnets och Network Security Groups tillåter önskad trafik.

Skapa Virtual Network Gateway

Virtual network gateway är själva Azure VPN Gateway. Viktigt:

• Gateway type: VPN
• VPN type: Route-based
• SKU som passar bandbredd, SLA, Availability Zone och BGP-krav
• Public IP för gateway
• Active-active bara om lokal sida kan skapa två tunnlar till Azures två publika IP-adresser
• BGP bara om ASN, peer IP och routingkoncept är definierade

För nya gateways används VpnGw*AZ: VpnGw1AZ–VpnGw3AZ finns som Generation 1 och Generation 2 går från VpnGw2AZ till VpnGw5AZ. Microsoft reserverar VpnGw1–VpnGw5 för migrering och avråder från Basic i produktion. Kontrollera under Virtual network gateways > Create SKU-/generationsalternativen för abonnemang och region; dokumentera bandbredd, tunnelantal, BGP/NAT-funktioner, kvoter och kostnadsgodkännande före skapandet. De angivna familjerna är planeringsgränser, inte prestanda- eller tillgänglighetslöften.

I active-active tillhör båda IPsec-tunnlarna samma Azure Connection, men varje Azure-instans har en egen publik IP-adress. Sophos behöver därför en separat route-based anslutning och ett XFRM-interface per Azure-IP. Routingdesignen måste klara trafik över båda tunnlarna och bortfall av vardera vägen; testa etablering, belastning och failover separat för varje tunnel.

Skapa Local Network Gateway

Local network gateway beskriver lokal sida ur Azure-perspektiv.

Ange:

1. Namn, till exempel lng-sophos-hq.
2. Endpoint som publik IP eller FQDN för Sophos-sidan.
3. Local Address spaces: alla lokala prefix utan BGP; med BGP kan fältet vara tomt. Lägg bara till statiska prefix om de inte lärs via BGP.
4. Om dynamisk routing används aktiverar du BGP under Advanced och anger Sophos ASN och BGP Peer IP.

Azure använder normalt en privat adress från GatewaySubnet som BGP-peer. Om Sophos använder APIPA ska Azure få en unik adress från 169.254.21.0 till 169.254.22.255; lokal adress kan vara 169.254.0.1 till 169.254.255.254. Adresser får inte överlappa och Sophos måste initiera APIPA-sessionen. Hämta slutvärdena under Virtual network gateway > Configuration, dokumentera dem i adressplanen och jämför med Local Network Gateway och XFRM.

Om Sophos Firewall står bakom NAT måste man noggrant kontrollera vilken publik IP Azure ser och hur NAT-T, port forwarding och IDs implementeras lokalt. Det enkla standardfallet är Sophos Firewall med egen publik IP.

Skapa Connection

Connection kopplar Virtual Network Gateway och Local Network Gateway.

Viktiga värden:

• Connection type: Site-to-site (IPsec)
• Shared key: identisk med Sophos Preshared Key
• IKE Protocol: matchar Sophos-konfigurationen
• BGP: aktivera bara om båda sidor använder BGP
• Custom IPsec/IKE policy: sätt bara om värdena är planerade
• För det dokumenterade exemplet med Sophos som initiator och Azure som responder: Virtual network gateways > [gateway] > Settings > Connections > [connection] > Configuration, eller Add > Settings vid skapandet; Connection Mode: ResponderOnly, DPD timeout in seconds: behåll standardvärdet. Dokumentera visat DPD-värde och granska den driftsatta policyn; ingen universell timeout anges. Kombinera med Initiate the connection på Sophos. I det statiska receptet utan BGP förblir Use Azure private IP address och Enable BGP avstängda och Use policy based traffic selector: Disable. Validera andra designer separat.

Efter skapandet är Azure-sidan redo, men inte automatiskt produktiv. Sophos-sidan måste känna samma tunnel, samma parametrar och returvägen.

Konfigurera Sophos Firewall

I Sophos Firewall skapas tunneln under Site-to-site VPN > IPsec.

Förbered IPsec profile

Under Profiles > IPsec profiles används eller skapas en profil som passar Azure. Hur Sophos-fälten hänger ihop och hur en egen profil klonas på rätt sätt förklaras i Förstå och konfigurera IPsec-profiler säkert i Sophos Firewall. De konkreta värdena måste fortfarande matcha Azure default policy eller Connectionens custom IPsec/IKE policy exakt.

Dokumentera:

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

Om Azure använder Custom Policy bör profilnamnet visa det, till exempel Azure_IKEv2_AES256_G14.

Skapa route-based IPsec-anslutning

Menyväg:

Site-to-site VPN > IPsec

Gör så här:

1. Öppna Add.
2. Välj Route-based eller tunnel interface som anslutningstyp.
3. Ange namn, till exempel azure-vnet-prod.
4. Sätt Gateway type på Sophos-sidan normalt till Initiate the connection.
5. Ange Azure Public IP för Virtual Network Gateway som Remote Gateway.
6. Ange Preshared Key identisk med Azure Connection.
7. Kontrollera Local ID och Remote ID, särskilt vid NAT eller flera tunnlar.
8. Välj IPsec profile.
9. Spara och aktivera anslutningen.

Efter sparande, kontrollera XFRM-interfacet under Network > Interfaces. Det är fortsatt tilldelat VPN-zonen. Beroende på design används det med statisk route, SD-WAN route eller BGP.

Sätt båda Sophos traffic selectors till Any. Brandväggen skapar då automatiskt ett numrerat xfrm-interface. För Any-to-Any skapar SFOS inga automatiska firewallregler. NAT-T är alltid aktivt; bakom upstream NAT måste peer-ID:n också matcha exakt.

Konfigurera route eller BGP

Utan BGP används Download configuration på Azure Connection för de generiska parametrarna. Tilldela sedan angiven första tunnel-IP, netmask och MSS till XFRM under Network > Interfaces. Lägg till varje Azure-prefix via interfacet under Routing > Static routes > IPv4 unicast route. Gateway kan lämnas tom eller använda peer-adressen i det hämtade transfernätet. Med BGP tilldelas i stället lokal BGP peer IP och netmask från Local Network Gateway till XFRM; Sophos-neighbor är Azure BGP Peer IP under Virtual network gateway > Configuration. Hitta inte på transferadresser.

Med BGP måste båda sidor planeras noggrant. Konfigurera BGP i Sophos Firewall förklarar grundkonfiguration, säker åtkomst och verifiering; för Azure används därefter de peer-värden som Azure anger:

• lokalt ASN för Sophos Firewall
• Azure ASN
• BGP peer IPs
• tillåtna och annonserade prefix
• route advertisement i Azure
• firewallregler för faktisk trafik

BGP ersätter inte firewallregler. Det distribuerar bara routes. Om en server i Azure är nåbar avgörs fortfarande av routing, NSG, firewallregler och målsystem.

Den dokumenterade Azure-BGP-designen använder IPv4. Lokalt ASN måste skilja sig från Azure-ASN och får inte vara något reserverat Azure-ASN: 8075, 8076, 12076, 65515, 65517, 65518, 65519 eller 65520. Tillåt Dynamic Routing för VPN-zonen under Administration > Device access. Kontrollera sedan på Sophos att Azure-prefixen har lärts och i Azure under BGP peers att de lokala prefixen har kommit fram.

För brandväggsgenererad trafik kontrolleras först faktisk source IP, annonserade prefix och returväg. Om källan inte ingår i ett lokalt prefix som Azure routar kan en riktad sys-traffic-nat-mappning till brandväggens LAN-IP behövas; lägg inte till den enbart på grund av BGP. Dirigera systemtrafik selektivt via IPsec beskriver pre-check, Device Console-syntax, verifiering och exakt borttagning.

NAT bara som designbeslut

Azure NAT för överlappande nät är begränsat till route-based S2S på VpnGw2–VpnGw5 och VpnGw2AZ–VpnGw5AZ, utan policy-based traffic selectors. Static NAT är 1:1 och dubbelriktat; dynamic NAT är stateful och måste initieras från Internal mapping. Aktivera BGP route translation med BGP; APIPA BGP fungerar inte med Azure NAT. Dokumentera Internal/External mappings och översatta prefix före ändring, jämför med effektiva rutter och annonserade prefix på båda sidor och testa tillåtna initieringsriktningar. Detta är designgränser, inte en improviserad reparation.

Skapa firewallregler

Trafik genom tunneln behöver passande regler, normalt mellan intern zon och VPN-zon.

Rekommendation vid införande:

• sätt source och destination som konkreta nät eller hosts;
• välj tjänster för första testet, till exempel ICMP, RDP, HTTPS eller DNS;
• aktivera Log firewall traffic;
• låt inte regler stå kvar på Any efter första testet;
• kontrollera motsatt riktning separat om Azure också ska nå lokala system.

Om regeln inte matchar, använd Sophos Firewall: kontrollera varför en regel inte matchar.

Verifiera anslutningen

Acceptans ska alltid kontrollera två nivåer: tunnelstatus och verklig trafik.

Kontrollera Azure

I Azure:

1. Öppna VPN Gateway Connection.
2. Kontrollera anslutningsstatus.
3. Observera dataräknare.
4. Kontrollera effective routes för berörd Azure VM.
5. Kontrollera Network Security Group för mål-subnets.

Azure-status räcker inte ensam. En VM kan vara oåtkomlig trots etablerad Connection på grund av NSG, lokal Windows Firewall, fel route eller saknad returväg.

Kontrollera Sophos Firewall

I Sophos Firewall:

1. Kontrollera status under Site-to-site VPN > IPsec.
2. Kontrollera XFRM-interface under Network > Interfaces.
3. Kontrollera route till Azure-prefix.
4. Filtrera Log Viewer på testtrafik.
5. Använd Packet Capture eller strongswan.log vid behov.

För IPsec-loggar och CLI-analys, använd Sophos Firewall IPsec VPN Troubleshooting.

Använd i Azure VPN Gateway > Diagnostic settings med IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog och GatewayDiagnosticLog. Jämför tidsstämplar för samma test och gör reset först sist, eftersom den aktiva gatewayinstansen startas om och befintliga anslutningar kan avbrytas.

Använd realistisk testtrafik

ICMP är en bra start, men inte ett komplett test. Testa därefter den produktiva tjänsten:

• DNS till Azure DNS eller domain controller
• RDP eller SSH till test-VM
• HTTPS till intern applikation
• backup-, monitoring- eller managementtrafik

Källan är viktig. En ping direkt från brandväggen bevisar inte samma sak som ett test från en klient bakom brandväggen.

Typiska fel

Tunneln förblir down

Oftast matchar inte gateway-IP, IKE-version, Preshared Key, IDs eller IPsec/IKE-parametrar. I Sophos Firewall, kontrollera först strongswan.log och jämför Azure Connection Settings med Sophos IPsec Profile. Om flera IPsec-anslutningar använder samma endpoints ska även PSK-tilldelningen kontrolleras: IKEv2 stöder en unik PSK för varje kombination av Local ID och Remote ID. IKEv1 stöder endast en PSK per kombination av lokal och fjärransluten gateway; SFOS tillämpar då PSK:n från den senast konfigurerade anslutningen. Unika IDs med IKEv2 undviker denna kollision.

Tunneln är ansluten, men ingen trafik går

Ofta saknas routes, firewallregler, Azure NSG-regler eller returväg. På Sophos-sidan, kontrollera Log Viewer och route. På Azure-sidan, kontrollera Effective Routes och NSG.

Bara en riktning fungerar

Det tyder ofta på asymmetrisk routing, NSG, host firewall eller saknad omvänd regel. Testa båda riktningar separat och dokumentera källan för testtrafiken.

BGP lär inga routes

Kontrollera ASN, peer IP, BGP-aktivering, XFRM-adress och Azure BGP-konfiguration. Kontrollera sedan vilka prefix som verkligen annonseras och lärs. En etablerad IPsec-tunnel betyder inte automatiskt att BGP routar korrekt.

Tunneln kommer inte upp efter policyändring

Custom IPsec/IKE Policies måste vara kompletta och kompatibla. Om Azure och Sophos tolkar ett enda värde olika kan anslutningen misslyckas. Före ändringar, dokumentera aktuell profil, Azure Policy och fungerande läge.

Azure är initiator och child SA löper ut

När Azure är initiator görs rekey av en child SA som löper ut endast om tunneltrafik finns. Utan trafik tar Azure bort child SA medan fas 1 förblir aktiv. Senare trafik från Azure kan skapa en ny child SA; trafik som bara startar bakom Sophos Firewall får inte Azure att skapa den i detta läge. Därför passar Initiate the connection på Sophos för designen. Azure IKE SA-rekey kan också orsaka ett kort avbrott.

Återställ utan att förstöra tillståndet

Exportera eller dokumentera före ändringen Sophos-anslutning, profil, XFRM-adress, routes och regler samt Azure-SKU/generation, Connection, Shared Key, BGP och NAT. Ta inte bort fungerande Connection: klona Sophos-profilen och notera Azure-policy under Connection > Configuration eller med PowerShell.

Vid fel, tilldela föregående Sophos-profil och återställ exakt tidigare Azure Custom Policy, eller ta bara bort den nya om defaults användes förut. Aktivera anslutningen och upprepa tunnel-, route- och applikationstest. Ta inte förebyggande bort gateway, Local Network Gateway, XFRM, routes eller NAT; då förstörs känt tillstånd och publik IP eller routing kan ändras.

FAQ