Naar de inhoud
Avanet

Sophos Firewall op Azure implementeren en routeren

Sophos Firewall kan vanuit Azure Marketplace als één appliance of via een Load Balancer-template met twee firewalls worden geïmplementeerd. Sophos noemt het tweede ontwerp active-active, maar het is geen native SFOS-HA-cluster. Configuratie, sessies en status worden niet gesynchroniseerd zoals tussen twee HA-appliances.

⚠️ Azure-routing hoort bij de firewallconfiguratie. Een correcte SFOS-regel is niet genoeg wanneer een User Defined Route, Network Security Group of het retourpad van de Load Balancer ontbreekt. Valideer elke vrijgave als volledige heen- en terugweg.

Bedrijfsmodel en licentie kiezen

ModelLicentieBelangrijke grens
StandaloneBYOL of PAYGEén appliance zonder redundantie, voor beheerste workloads met een geaccepteerd onderhoudsvenster.
Active-active met Load BalancerEén BYOL-licentie per firewall of PAYGTwee zelfstandige firewalls achter Standard Load Balancers met HA Ports; de template ondersteunt geen active-passive.

Voor standalone adviseert Sophos minimaal Standard_F2s_v2, twee vCPU en 4 GB RAM. Gebruik een statisch toegewezen publiek IP met Standard SKU. Basic SKU is uitgefaseerd en hoort niet in nieuwe implementaties.

Standalone vanuit Marketplace implementeren

Appliance maken en beveiligen

  1. Selecteer Sophos Firewall in Azure Marketplace en kies BYOL of PAYG.
  2. Definieer Resource Group, regio en grootte. VNet, subnetten en externe netwerken mogen niet overlappen.
  3. Koppel PortA aan LAN en PortB aan WAN. Open NSG’s aanvankelijk alleen voor vereiste beheerbronnen.
  4. Voltooi de implementatie en open WebAdmin op https://<dns-name>:4444.
  5. Rond setup, registratie, licentie en firmware gecontroleerd af.
  6. Zet het private adres van de LAN-NIC op Static. Voeg aan elk workloadsubnet een UDR 0.0.0.0/0 toe met Virtual appliance en dit LAN-adres als Next Hop.
  7. Test IP Forwarding, NSG’s, SFOS-regels en retourpad met een gedefinieerde client.

De UDR dwingt uitgaand LAN-verkeer door de firewall. Zonder UDR gebruikt Azure het standaardpad. Een route-based verbinding met Azure VPN Gateway gebruikt de XFRM-interface daarnaast met statische routes, SD-WAN of BGP.

Adresplan voorbereiden

Maak voor een nieuwe implementatie eerst het publieke IP onder Public IP addresses > Create met IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static en Routing preference: Microsoft network. Stel een uniek DNS name label in en kies Domain name label scope: None. Sophos vermeldt voor deze procedure ook DDoS protection > Protection type: Network. Die optie vereist een passend Azure DDoS-plan en kan extra kosten veroorzaken; stem het plan daarom vóór het maken van het adres af met de Azure-verantwoordelijke. Selecteer het adres daarna bij Public IP name. Sophos ondersteunt voor deze procedure expliciet alleen zone 1. De vroegere dynamische Basic-optie is na uitfasering door Azure geen basis meer voor een nieuwe implementatie.

Een aanpasbaar voorbeeld gebruikt VNet 10.20.0.0/16, LAN 10.20.10.0/24 op PortA, WAN 10.20.20.0/24 op PortB en statisch LAN-IP 10.20.10.4. Vervang deze RFC 1918-waarden door vrije bereiken zonder overlap met peering, VPN of on-premises-netwerken.

LAN-UDR met exacte Azure-velden maken

Sophos vereist dat de VM stopt voordat het LAN-IP statisch wordt: Virtual machines > > Stop, daarna LAN-NIC, Settings > IP configurations > ipconfig, Allocation: Static. Maak na herstart de tabel via Route tables > Create. Koppel onder Subnets > Associate elk client- of workloadsubnet waarvan het verkeer door de appliance moet lopen. Bevinden clients zich rechtstreeks in het LAN-subnet van PortA, koppel dan dat LAN-subnet, zoals in het basisvoorbeeld van Sophos. Koppel het WAN-subnet van de firewall niet. Gebruik onder Routes > Add: Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance en Next hop address: 10.20.10.4. Controleer Enable IP forwarding op beide NIC’s. Laat Propagate gateway routes: Yes alleen staan als dit past bij VPN/ExpressRoute. Maak ten slotte een beperkte, gelogde LAN-naar-WAN-regel onder Rules and policies > Firewall rules.

Active-active met Load Balancer beheren

De Sophos-template maakt twee firewalls en een externe en interne Standard Load Balancer met HA Ports. Ze vereist een /16 VNet en /24 LAN- en WAN-subnetten; Sophos vraagt overleg met de Sophos-contactpersoon voordat andere subnetgroottes worden gebruikt.

Health probes bereiken WebAdmin op 4444 en de proxy op 3128. Interne probes zijn ook afhankelijk van speciale routes naar platformadres 168.63.129.16 die het Automation Runbook in de kernelroutingtabel injecteert. Deze routes blijven niet bestaan na een firmware-upgrade; voer het meegeleverde runbook daarna opnieuw uit en controleer het.

Tijdens de implementatie moet Trusted network eerst * zijn, omdat Azure Automation Runbook vanaf publieke Azure-IP’s verbindt. Beperk de NSG direct na succes tot gedocumenteerde beheer-CIDR’s. De eerste firewall gebruikt WebAdmin 4444 en SSH 2222, de tweede 4445 en 2223. Registreer beide appliances afzonderlijk en houd firewall-, NAT- en routingregels gelijk.

Probes en egress configureren

Configureer op beide firewalls gateways onder Routing > Gateways en proberoutes onder Routing > SD-WAN routes; de externe route staat boven de interne. De workload-UDR 0.0.0.0/0 gebruikt Next hop type: Virtual appliance en het frontend-IP van de interne Load Balancer. In de appliance verschijnen TCP-probes 4444 en 3128 met bron 168.63.129.16. Bij andere poorten moeten interne en externe probe verschillend blijven. Sta het probepad in de NSG toe met Source Service Tag AzureLoadBalancer; ook SFOS-listeners en speciale Sophos-routes moeten overeenkomen. Noch de Service Tag, noch het platformadres is een algemeen vertrouwde internetbron. Controleer beide backends via Load balancer > Monitoring > Insights of Health Probe Status; een gezonde probe valideert applicatie en retourpad niet.

DNAT en retourpad

De externe Load Balancer kiest een firewall. HA Ports dragen NVA-flows over protocollen en poorten, maar vervangen geen servicespecifieke publicatie. Maak voor de gepubliceerde TCP-service op de externe Load Balancer een passende health probe en een Load Balancing-regel die aan die probe is gekoppeld. De SFOS-NAT-regel vertaalt vervolgens naar de server. Stel in Rules and policies > NAT rules Translated source (SNAT): MASQ in, zodat de server naar het LAN-IP van dezelfde firewall antwoordt. Zonder MASQ kan de retourstroom de andere firewall kruisen en de sessie breken.

Directe RDP-publicatie wordt niet aanbevolen. Gebruik liever VPN of ZTNA. Als publicatie nodig is, beperk bron, service en bestemming in Azure en SFOS, activeer logging en IPS en voer een negatieve test uit.

Valideren, problemen oplossen en terugdraaien

Acceptatiecontroles

  1. Controleer bij een test-VM in Effective routes dat 0.0.0.0/0 naar het SFOS-LAN-IP of bij active-active naar het interne Load Balancer-IP wijst.
  2. Test DNS, HTTPS en de applicatie en bevestig Rule ID, bron en doel in Log viewer > Firewall. Voer voor publicatie een toegestane positieve en een niet-toegestane negatieve test uit.
  3. Controleer bij active-active Health Probe Status en Backend Pool. Verwijder alleen in een onderhoudsvenster één firewall, test nieuwe verbindingen via de andere en herstel een gezonde backend vóór de tweede test. Bestaande sessies worden niet gesynchroniseerd en kunnen worden verbroken.

Typische fouten

Controleer bij ontbrekende egress achtereenvolgens Effective Routes, koppeling van het workloadsubnet, statisch LAN-IP, IP forwarding, NSG en SFOS Rule ID. Controleer bij een unhealthy probe TCP-protocol en -poort, listener, NSG en SD-WAN-routes naar 168.63.129.16. Geïnjecteerde routes blijven na een firmware-upgrade niet bestaan: voer het Sophos-runbook voor beide VM’s opnieuw uit, controleer de probes en herstel meteen de beheer-CIDR’s in de SSH-NSG. Vergelijk bij onregelmatige DNAT de regels op beide appliances, MASQ, Backend Pool en retourroute van de server.

Leg vóór een egressrollback de eerder goedgekeurde Next Hop vast. Koppel de vorige Route Table opnieuw of isoleer het workloadsubnet tijdens de wijziging. Alleen de nieuwe tabel loskoppelen kan Azures systeemroute 0.0.0.0/0 -> Internet activeren en de firewall omzeilen; doe dit uitsluitend wanneer dat pad expliciet is beoordeeld en geaccepteerd. Verwijder UDR en tijdelijke regels pas nadat het herstelde retourpad is gevalideerd. Schakel voor DNAT eerst de externe Load Balancer-regel uit. Azure-snapshots vervangen geen geëxporteerde SFOS-back-up.

Officiële bronnen