Sophos Firewall met Azure VPN Gateway verbinden

Een Azure VPN Gateway verbindt een lokaal netwerk via Site-to-Site IPsec met een Azure Virtual Network. Op Sophos Firewall wordt dit meestal als route-based IPsec VPN gebouwd. Grotere of dynamische omgevingen gebruiken vaak aanvullend BGP.

Dit artikel legt de praktische flow met SFOS 22 en een actuele Azure VPN Gateway uit: welke Azure-objecten nodig zijn, hoe de Sophos-kant wordt opgebouwd, welke IPsec/IKE-parameters bewust moeten matchen en hoe na het opslaan wordt gecontroleerd of verkeer echt loopt. Voor algemene IPsec-basis past eerst Sophos Firewall Site-to-Site IPsec VPN configureren. Als een bestaande tunnel groen is maar geen verkeer transporteert, past Sophos Firewall IPsec VPN Troubleshooting.

Wanneer dit artikel past

Dit artikel past wanneer een lokaal netwerk achter Sophos Firewall met een Azure Virtual Network moet worden verbonden. Het gaat om een Site-to-Site-tunnel tussen Azure VPN Gateway en lokale firewall, niet om Point-to-Site VPN voor individuele gebruikers en niet om Sophos Firewall als virtuele appliance in Azure.

Typische scenario’s:

• lokaal servernetwerk naar Azure VMs
• filiaal of hoofdlocatie naar Azure Virtual Network
• hybride scenario met AD, DNS, backup, monitoring of management in Azure
• migratie van policy-based designs naar route-based IPsec
• optioneel BGP voor dynamische routing tussen lokaal netwerk en Azure

Azure en Sophos gebruiken niet altijd dezelfde termen. In Azure werkt men met Virtual network, Gateway subnet, Virtual network gateway, Local network gateway en Connection. Op Sophos Firewall met IPsec-verbinding, XFRM-interface, routes, firewallregels en eventueel BGP.

Voor de configuratie plannen

Een Azure-tunnel is geen pure klik-wizard. De meeste fouten ontstaan door overlappende netwerken, verkeerde gateway-SKU’s, niet passende IPsec/IKE-parameters, ontbrekende routes of firewallregels zonder logging.

Netwerken en adresruimten

Lokale netwerken en Azure address spaces mogen niet overlappen. Azure routeert de lokale prefixen uit Local network gateway naar Sophos Firewall. Sophos Firewall routeert Azure-prefixen via de XFRM-interface of via BGP.

Vooraf documenteren:

• Azure Virtual Network Address Space, bijvoorbeeld 10.50.0.0/16
• Azure-subnets, vooral workload subnets
• lokaal netwerk achter Sophos Firewall, bijvoorbeeld 172.16.10.0/24
• publiek IP van Sophos Firewall of upstream router
• Azure public IP van de Virtual Network Gateway
• BGP ja of nee
• gedeelde Preshared Key
• geplande testsystemen aan beide kanten

Als lokale en Azure-netwerken overlappen, moet het design eerst worden gecorrigeerd. NAT over IPsec is mogelijk, maar maakt beheer en troubleshooting veel moeilijker.

Route-based in plaats van policy-based

Voor Azure is route-based IPsec de juiste keuze. Actuele VpnGw*AZ-SKU’s zijn route-based; een echte policy-based gateway bestaat alleen met de beperkte Basic-SKU en IKEv1. Een route-based Azure-gateway kan Use policy based traffic selectors gebruiken voor een lokale policy-based firewall, maar dit is een compatibiliteitsmodus met selectors voor elke prefixcombinatie. Met SFOS 22 is een route-based tunnel met XFRM duidelijker en vereist voor BGP, active-active en Azure NAT.

Op Sophos Firewall betekent dit:

• IPsec-verbinding als route-based tunnel interface plannen.
• XFRM-interface na opslaan controleren.
• Routes of BGP voor Azure-prefixen zetten.
• Firewallregels tussen lokale zones en VPN-zone maken.
• Verkeer met Log Viewer en Azure connection status controleren.

Een groene tunnelstatus is slechts een deel van de acceptatie. Pas wanneer een gedefinieerde client een gedefinieerd Azure-doel bereikt en beide kanten logs of tellers tonen, is de tunnel echt getest.

IPsec/IKE-parameters niet gokken

Azure VPN Gateway ondersteunt custom IPsec/IKE policies op VpnGw1–VpnGw5 en VpnGw1AZ–VpnGw5AZ, maar niet op Basic. Microsoft vereist één complete combinatie per Connection. Controleer de Microsoft-documentatie.

Voor beheer betekent dit:

• IKE-versie bewust kiezen, meestal IKEv2.
• Encryption, integrity, DH group, PFS en lifetimes documenteren.
• Azure Custom Policy en Sophos IPsec Profile spiegelen.
• Geen Sophos-naar-Sophos-defaults ongecontroleerd op Azure toepassen.
• Na elke policywijziging onderhoudsvenster en rollbackpunt plannen.

Zonder Custom Policy moet minstens één Sophos-voorstel passen bij de Azure-standaardparameters. SFOS 22 ondersteunt in IPsec-profielen de DH-groepen 1, 2, 5, 14 tot en met 21 en 25 tot en met 31, maar niet DH-groep 24. Een Custom Policy mag daarom alleen waarden gebruiken die in de actuele lijsten van beide leveranciers staan.

Azure legt de IKE SA lifetime vast op 28 800 seconden; de route-based Default Policy gebruikt 27 000 seconden en 102 400 000 KB voor de Quick Mode SA. Een Custom Policy stelt deze grenzen expliciet in, terwijl Microsoft afwijkende lokale SA lifetimes toestaat. SFOS adviseert desondanks een kortere Key lifetime op de initiator en een fase 2 lifetime onder fase 1 om rekey-collisions te voorkomen. Omdat Sophos hier initieert, pas je die volgorde toe zonder universele waarden te verzinnen en observeer je minstens één rekey.

Azure-kant voorbereiden

De Azure-configuratie bestaat uit meerdere objecten. Namen moeten duidelijk zijn, omdat troubleshooting anders snel rommelig wordt.

Virtual Network en Gateway subnet

Het Azure Virtual Network heeft een dedicated GatewaySubnet nodig. Dit subnet wordt door Azure VPN Gateway gebruikt en mag niet voor gewone VMs worden gebruikt.

Controleren:

1. Azure Virtual Network bestaat.
2. Address Space overlapt niet met lokale netwerken.
3. GatewaySubnet bestaat en is groot genoeg. Behalve Basic met minimaal /29 vereisen actuele SKU’s minstens /27; Microsoft adviseert groter dan /27 voor uitbreiding.
4. GatewaySubnet bevat geen VMs of NSG. Een 0.0.0.0/0 UDR is niet ondersteund en BGP route propagation moet actief blijven.
5. Workload subnets en Network Security Groups laten gewenst verkeer toe.

Virtual Network Gateway maken

De Virtual network gateway is de eigenlijke Azure VPN Gateway. Belangrijk:

• Gateway type: VPN
• VPN type: Route-based
• SKU passend bij bandbreedte, SLA, Availability Zone en BGP-behoefte
• Public IP voor de gateway
• Active-active alleen als de lokale kant twee tunnels naar de twee publieke Azure-IP’s kan opbouwen
• BGP alleen als ASN, peer IP en routingconcept vaststaan

Gebruik voor nieuwe gateways VpnGw*AZ: VpnGw1AZ–VpnGw3AZ bestaan als Generation 1 en Generation 2 loopt van VpnGw2AZ tot VpnGw5AZ. Microsoft reserveert VpnGw1–VpnGw5 voor migraties en raadt Basic af voor productie. Controleer de actuele SKU-tabel.

In active-active behoren beide IPsec-tunnels tot dezelfde Azure Connection, maar elke Azure-instance heeft een eigen publiek IP. Sophos heeft daarom per Azure-IP een aparte route-based verbinding en XFRM-interface nodig. Het routingdesign moet verkeer over beide tunnels en uitval van elk pad aankunnen; test opbouw, belasting en failover per tunnel afzonderlijk.

Local Network Gateway maken

De Local network gateway beschrijft de lokale kant vanuit Azure.

Invullen:

1. Naam, bijvoorbeeld lng-sophos-hq.
2. Endpoint als publiek IP-adres of FQDN van de Sophos-kant.
3. Local Address spaces: alle lokale prefixen zonder BGP; met BGP mag het veld leeg blijven. Voeg statische prefixen alleen toe als ze niet via BGP worden geleerd.
4. Activeer onder Advanced BGP en vul Sophos ASN en BGP Peer IP in.

Azure gebruikt normaal een privé-adres uit GatewaySubnet als BGP-peer. Gebruikt Sophos APIPA, geef Azure dan een uniek adres van 169.254.21.0 tot 169.254.22.255; lokaal mag 169.254.0.1 tot 169.254.255.254 worden gebruikt. Adressen mogen niet overlappen en Sophos moet de APIPA-sessie initiëren. Zie de Azure BGP-handleiding.

Als Sophos Firewall achter NAT staat, moet exact worden gecontroleerd welk publiek IP Azure ziet en hoe NAT-T, port forwarding en IDs lokaal worden uitgevoerd. Het eenvoudige standaardpad is Sophos Firewall met eigen publiek IP.

Connection maken

De Connection verbindt Virtual Network Gateway en Local Network Gateway.

Belangrijke waarden:

• Connection type: Site-to-site (IPsec)
• Shared key: identiek aan Sophos Preshared Key
• IKE Protocol: passend bij Sophos-configuratie
• BGP: alleen activeren als beide kanten BGP gebruiken
• Custom IPsec/IKE policy: alleen zetten als de waarden bewust gepland zijn

Na het maken van de Connection is Azure klaar, maar nog niet automatisch productief. De Sophos-kant moet dezelfde tunnel, dezelfde parameters en het retourpad kennen.

Sophos Firewall configureren

Op Sophos Firewall wordt de tunnel onder Site-to-site VPN > IPsec gemaakt.

IPsec-profiel voorbereiden

Onder Profiles > IPsec profiles een profiel gebruiken of maken dat bij Azure past. Hoe de Sophos-velden samenhangen en een eigen profiel correct wordt gekloond, wordt uitgelegd in IPsec-profielen op Sophos Firewall begrijpen en veilig configureren. De concrete waarden moeten nog steeds exact passen bij Azure default policy of custom IPsec/IKE policy van de Connection.

Documenteren:

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

Als Azure een Custom Policy gebruikt, moet de profielnaam dit tonen, bijvoorbeeld Azure_IKEv2_AES256_G14.

Route-based IPsec-verbinding maken

Menupad:

Site-to-site VPN > IPsec

Procedure:

1. Add openen.
2. Route-based of tunnel interface als verbindingstype kiezen.
3. Naam zetten, bijvoorbeeld azure-vnet-prod.
4. Gateway type op Sophos meestal op Initiate the connection zetten.
5. Azure Public IP van de Virtual Network Gateway als Remote Gateway invullen.
6. Preshared Key identiek aan Azure Connection zetten.
7. Local ID en Remote ID controleren, vooral bij NAT of meerdere tunnels.
8. IPsec-profiel kiezen.
9. Verbinding opslaan en activeren.

Na opslaan de XFRM-interface onder Network > Interfaces controleren. Ze blijft toegewezen aan de VPN-zone. Afhankelijk van het design wordt ze gebruikt met statische route, SD-WAN route of BGP.

Zet beide Sophos traffic selectors op Any. De firewall maakt dan automatisch een genummerde xfrm-interface. Voor Any-to-Any maakt SFOS geen automatische firewallregels. NAT-T staat altijd aan; achter upstream NAT moeten ook de peer-IDs exact overeenkomen.

Route of BGP configureren

Gebruik zonder BGP Download configuration bij de Azure Connection voor de generieke parameters en wijs de vermelde eerste tunnel-IP, netmask en MSS toe aan XFRM onder Network > Interfaces. Voeg onder Routing > Static routes > IPv4 unicast route elk Azure-prefix via die interface toe. Gateway mag leeg blijven of het peeradres uit het gedownloade transfernetwerk gebruiken. Met BGP wijs je in plaats daarvan de lokale BGP peer IP en netmask uit de Local Network Gateway toe aan XFRM; de Sophos-neighbor is de Azure BGP Peer IP onder Virtual network gateway > Configuration. Verzin geen transferadressen.

Met BGP moeten beide kanten zorgvuldig worden gepland. BGP op Sophos Firewall configureren legt de basisconfiguratie, veilige toegang en validatie uit; voor Azure worden daarna de door Azure opgegeven peerwaarden gebruikt:

• lokaal ASN van Sophos Firewall
• Azure ASN
• BGP peer IPs
• toegestane en geadverteerde prefixen
• route advertisement in Azure
• firewallregels voor werkelijk verkeer

BGP vervangt geen firewallregels. Het verdeelt alleen routes. Of een server in Azure bereikbaar is, hangt daarna nog steeds af van routing, NSG, firewallregels en doelsysteem.

Het gedocumenteerde Azure-BGP-ontwerp gebruikt IPv4. Het lokale ASN moet afwijken van Azure’s ASN en mag geen gereserveerd Azure-ASN zijn: 8075, 8076, 12076, 65515, 65517, 65518, 65519 of 65520. Sta Dynamic Routing toe voor de VPN-zone en controleer daarna aan beide kanten de geleerde prefixen.

Controleer voor firewall-generated traffic eerst het werkelijke bronadres, geadverteerde prefixen en retourpad. Als de bron niet in een door Azure gerouteerde lokale prefix valt, kan een gerichte sys-traffic-nat-toewijzing naar het LAN-IP van de firewall nodig zijn; voeg die niet alleen vanwege BGP toe. Systeemverkeer gericht via IPsec routeren beschrijft pre-check, Device Console-syntaxis, validatie en exacte verwijdering.

NAT alleen als ontwerpkeuze

Azure NAT voor overlappende netwerken is beperkt tot route-based S2S op VpnGw2–VpnGw5 en VpnGw2AZ–VpnGw5AZ, zonder policy-based traffic selectors. Static NAT is 1:1 en bidirectioneel; dynamic NAT is stateful en moet vanaf Internal mapping worden gestart. Activeer bij BGP BGP route translation; APIPA BGP werkt niet met Azure NAT. Zie de Microsoft NAT-limieten.

Firewallregels maken

Verkeer door de tunnel heeft passende regels nodig, meestal tussen interne zone en VPN-zone.

Aanbevolen bij introductie:

• bron en doel als concrete netwerken of hosts zetten;
• diensten voor de eerste test bewust kiezen, bijvoorbeeld ICMP, RDP, HTTPS of DNS;
• Log firewall traffic activeren;
• regels na eerste test niet op Any laten staan;
• tegenrichting apart controleren als Azure ook lokale systemen moet bereiken.

Als de regel niet matcht, helpt Sophos Firewall: controleren waarom een regel niet matcht.

Verbinding controleren

Acceptatie moet altijd twee niveaus controleren: tunnelstatus en echt verkeer.

Azure controleren

In Azure:

1. Naar de Connection van de VPN Gateway gaan.
2. Verbindingsstatus controleren.
3. Datatellers bekijken.
4. Effective routes van de betrokken Azure VM controleren.
5. Network Security Group van de doel-subnets controleren.

Azure-status alleen is niet genoeg. Een VM kan ondanks actieve Connection onbereikbaar zijn door NSG, lokale Windows Firewall, verkeerde route of ontbrekend retourpad.

Sophos Firewall controleren

Op Sophos Firewall:

1. Status onder Site-to-site VPN > IPsec controleren.
2. XFRM-interface onder Network > Interfaces controleren.
3. Route naar Azure-prefixen controleren.
4. Log Viewer op testverkeer filteren.
5. Indien nodig Packet Capture of strongswan.log gebruiken.

Voor IPsec-logs en CLI-analyse past Sophos Firewall IPsec VPN Troubleshooting.

Gebruik in Azure VPN Gateway > Diagnostic settings met IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog en GatewayDiagnosticLog. Vergelijk timestamps van dezelfde test en reset pas als laatste stap, want een reset herstart de actieve gatewayinstantie.

Realistisch testverkeer gebruiken

ICMP is een goede start, maar geen volledige test. Daarna de productieve dienst testen:

• DNS naar een Azure-DNS- of domain controller
• RDP of SSH naar een test-VM
• HTTPS naar een interne applicatie
• backup-, monitoring- of managementverkeer

De bron is belangrijk. Een ping direct vanaf de firewall bewijst niet hetzelfde als een test vanaf een client achter de firewall.

Typische fouten

Tunnel blijft down

Meestal passen gateway-IP, IKE-versie, Preshared Key, IDs of IPsec/IKE-parameters niet. Op Sophos Firewall eerst strongswan.log controleren en Azure Connection Settings met Sophos IPsec Profile vergelijken. Als meerdere IPsec-verbindingen dezelfde endpoints gebruiken, controleer dan ook de PSK-toewijzing: IKEv2 ondersteunt een unieke PSK voor elke combinatie van Local ID en Remote ID. IKEv1 ondersteunt slechts één PSK per combinatie van lokale en remote gateway; SFOS gebruikt dan de PSK van de laatst geconfigureerde verbinding. Unieke IDs met IKEv2 voorkomen deze botsing.

Tunnel is verbonden, maar er loopt geen verkeer

Vaak ontbreken routes, firewallregels, Azure NSG-regels of retourpad. Aan Sophos-kant Log Viewer en route controleren. Aan Azure-kant Effective Routes en NSG.

Slechts één richting werkt

Dit wijst vaak op asymmetrische routing, NSG, host firewall of ontbrekende tegenregel. Beide richtingen apart testen en de bron van testverkeer documenteren.

BGP leert geen routes

ASN, peer IP, BGP-activering, XFRM-adres en Azure-BGP-configuratie controleren. Daarna controleren welke prefixen echt geadverteerd en geleerd worden. Een actieve IPsec-tunnel betekent niet automatisch dat BGP correct routeert.

Na policywijziging komt de tunnel niet op

Custom IPsec/IKE Policies moeten volledig en compatibel zijn. Als Azure en Sophos één waarde anders interpreteren, kan de verbinding falen. Voor wijzigingen altijd huidig profiel, Azure Policy en werkende toestand documenteren.

Azure is initiator en de child SA verloopt

Als Azure de initiator is, vernieuwt het een verlopende child SA alleen zolang er tunnelverkeer is. Zonder verkeer verwijdert Azure de child SA, terwijl fase 1 actief blijft. Later verkeer vanuit Azure kan een nieuwe child SA maken; verkeer dat uitsluitend achter Sophos Firewall begint kan Azure daar in deze toestand niet toe brengen. Daarom past Initiate the connection op Sophos bij dit ontwerp. Een Azure IKE SA-rekey kan ook een korte onderbreking veroorzaken.

Terugrollen zonder de toestand te vernietigen

Exporteer of documenteer vóór een wijziging de Sophos-verbinding, het profiel, XFRM-adres, routes en regels, plus Azure-SKU/generatie, Connection, Shared Key, BGP en NAT. Verwijder de werkende Connection niet: kloon het Sophos-profiel en noteer de Azure-policy onder Connection > Configuration of met PowerShell.

Wijs bij een fout het vorige Sophos-profiel toe en herstel exact de vorige Azure Custom Policy, of verwijder alleen de nieuwe policy als eerder defaults golden. Activeer de verbinding en herhaal tunnel-, route- en applicatietests. Verwijder gateway, Local Network Gateway, XFRM, routes of NAT niet preventief; daarmee verdwijnt de bekende toestand en kunnen publiek IP of routing veranderen.

FAQ