Sophos Firewall auf Azure bereitstellen und routen

Sophos Firewall kann aus dem Azure Marketplace als einzelne Appliance oder über das Sophos-Template mit zwei Firewalls und Azure Load Balancern bereitgestellt werden. Sophos nennt das zweite Design active-active HA. Es ist jedoch kein natives SFOS-HA-Paar: Beide Firewalls werden separat registriert und konfiguriert; das Template synchronisiert weder Konfiguration noch Sessions.

⚠️ Azure-Routing gehört zur Firewall-Konfiguration. Eine korrekte SFOS-Regel reicht nicht, wenn eine User Defined Route (UDR), Network Security Group (NSG) oder der Rückweg am Load Balancer fehlt. Eine Änderung wird deshalb immer als kompletter Hin- und Rückpfad geprüft.

Betriebsmodell und Lizenz wählen

Azure-Infrastruktur und Sophos-Software werden getrennt berechnet. PAYG wird im dokumentierten Modell stündlich ohne Mindestbindung abgerechnet und umfasst das Xstream-Paket; einzelne Software-Abonnements und Enhanced Plus Support lassen sich nicht hinzufügen. PAYG ist auf Microsoft-Remittance-Länder begrenzt: Rechnungsland und konkretes Angebot vor dem Kauf prüfen, andernfalls BYOL wählen. BYOL wird über einen autorisierten Reseller beschafft und erlaubt die Auswahl von Paketen, Einzelabonnements wie Network Protection, Web Protection und Zero-Day Protection sowie Support einschliesslich Enhanced Plus Support. Dokumentierte Laufzeiten sind ein, zwei oder drei Jahre; tatsächliches Angebot und Berechtigungen prüfen, keine Preis- oder Supportzusage ableiten. Ein Nutzungsstopp entfernt nicht automatisch kostenpflichtige Azure-Ressourcen.

Sophos nennt Standard_F2s_v2 mit zwei vCPU, 4 GB RAM und mindestens zwei NICs als Mindestgrösse. Die tatsächliche Grösse richtet sich zusätzlich nach Durchsatz, aktivierten Schutzfunktionen und Azure-Quotas.

Für neue Standalone-Deployments wird eine Standard-SKU-Public-IP verwendet. Sie wird vor dem Marketplace-Deployment unter Public IP addresses > Create mit IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static und Routing preference: Microsoft network angelegt. Einen eindeutigen DNS name label festlegen und Domain name label scope: None wählen. Sophos nennt für diesen Ablauf ausserdem DDoS protection > Protection type: Network. Diese Option setzt einen passenden Azure-DDoS-Plan voraus und kann zusätzliche Kosten verursachen; deshalb wird der Plan vor dem Erstellen mit dem Azure-Verantwortlichen geklärt. In der Sophos-Maske wird die Adresse danach unter Public IP name ausgewählt. Availability zone: 1 ist die dokumentierte Beispielauswahl. Davon getrennt gilt die Begrenzung auf eine Availability Zone; daraus folgt weder exklusive Unterstützung nur für Zone 1 noch ein Nachweis für andere Zonen oder Multi-Zone-Designs. Die frühere Alternative mit einer dynamischen Basic-SKU-IP ist seit dem Azure-Rückzug der Basic SKU keine Grundlage für ein neues Deployment.

Standalone aus dem Marketplace bereitstellen

Adressplan vorbereiten

Ein übertragbares Beispiel ist:

• VNet 10.20.0.0/16
• LAN-Subnetz 10.20.10.0/24, PortA
• WAN-Subnetz 10.20.20.0/24, PortB
• statische private LAN-IP der Firewall 10.20.10.4

Diese privaten RFC-1918-Netze sind Platzhalter. Sie werden durch freie Bereiche der eigenen Umgebung ersetzt und dürfen sich weder untereinander noch mit Peering-, VPN- oder On-Premises-Netzen überschneiden. Die LAN-IP bleibt innerhalb des LAN-Subnetzes für die Appliance reserviert; sie ist später der Next Hop der UDR.

Appliance erstellen und absichern

1. Im Azure Marketplace Sophos Firewall > Create öffnen und unter Basics Subscription, Resource Group, Region, VM name sowie ein starkes initiales admin-Passwort eintragen.
2. Unter Instance details BYOL oder PAYG und die geprüfte VM-Grösse wählen. VNet, LAN subnet, WAN subnet, die zuvor erstellte Standard-SKU-IP unter Public IP name sowie einen Storage Account festlegen.
3. Nach erfolgreicher Azure-Validierung Create wählen. Anschliessend unter Virtual machines > den DNS-Namen kopieren und https://<dns-name>:4444 öffnen.
4. Mit admin und dem Deployment-Passwort anmelden, Nutzungsbedingungen bestätigen, die Firewall registrieren und die Erstkonfiguration abschliessen.
5. Die NSG an der WAN-NIC so einschränken, dass WebAdmin und SSH nur aus benannten Adminnetzen erreichbar sind. Geschäftsdienste werden erst geöffnet, wenn SFOS-Regel, Azure-Regel und Rückweg gemeinsam vorbereitet sind.

LAN-UDR mit exakten Azure-Feldern erstellen

Für die Umstellung wird ein Wartungsfenster benötigt: Sophos verlangt, die VM vor dem Wechsel der privaten LAN-IP auf statisch zu stoppen.

1. Unter Virtual machines > > Stop die VM anhalten.
2. Die LAN-NIC öffnen, dann Settings > IP configurations > ipconfig. Allocation: Static wählen, die aktuelle LAN-IP beibehalten beziehungsweise die reservierte Adresse eintragen und speichern. Danach die VM wieder starten.
3. Unter Route tables > Create Subscription, dieselbe Resource Group und Region sowie beispielsweise den Namen rt-workloads-via-sfos eintragen. Propagate gateway routes bleibt nur dann Yes, wenn propagierte Gateway-Routen zum eigenen VPN-/ExpressRoute-Design passen.
4. In der Route Table unter Subnets > Associate jedes Client- oder Workload-Subnetz auswählen, dessen Traffic durch die Appliance laufen soll. Liegen die Clients direkt im LAN-Subnetz von PortA, wird genau dieses LAN-Subnetz zugeordnet, wie es Sophos im Basisbeispiel zeigt. Das WAN-Subnetz der Firewall wird nicht zugeordnet.
5. Unter Routes > Add folgende Werte setzen: Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance, Next hop address: 10.20.10.4.
6. An beiden Azure-NICs der Firewall Enable IP forwarding kontrollieren. Azure benötigt diese Einstellung, damit eine NIC Pakete weiterleiten darf, deren Quelle oder Ziel nicht ihre eigene IP ist.
7. In SFOS unter Rules and policies > Firewall rules eine möglichst enge LAN-zu-WAN-Regel mit Logging erstellen. Netzwerkobjekte, Zonen und Dienste werden an die eigene Umgebung angepasst; Any ist kein sinnvoller Dauerzustand.

Die Default-UDR zwingt Internet-Traffic des verknüpften Workload-Subnetzes zur Firewall. Spezifischere Azure-Routen haben weiterhin Vorrang. Für eine route-based Verbindung zum Azure VPN Gateway müssen deshalb auch propagierte und selbst definierte Routen zum XFRM-, SD-WAN- oder BGP-Design passen.

Load-balanced active-active betreiben

Das aktuelle Sophos-Template erstellt zwei Firewalls, einen externen und einen internen Standard Load Balancer mit HA Ports. Die Vorgaben des Templates sind ein /16-VNet sowie je ein /24 für LAN und WAN. Diese Präfixe werden nicht eigenmächtig geändert: Sophos verlangt vor abweichenden Subnetzgrössen die Abstimmung mit dem Sophos-Ansprechpartner.

Bei der Bereitstellung wird Trusted network zunächst als * benötigt, weil das Azure Automation Runbook über öffentliche Azure-Adressen zugreift. Nach erfolgreichem Runbook wird die NSG sofort wieder auf dokumentierte Admin-CIDRs begrenzt. Die erste Firewall erreicht man standardmässig über WebAdmin-Port 4444 und SSH-Port 2222, die zweite über 4445 und 2223. Beide Appliances werden separat registriert; Firewall-, NAT- und Routingänderungen müssen auf beiden identisch gepflegt werden.

Probes und Egress konfigurieren

Die Load Balancer prüfen TCP 4444 und 3128. Wenn andere Ports verwendet werden, müssen interne und externe Probe unterschiedliche Ports nutzen. Die NSG erlaubt den Probe-Pfad mit dem Source Service Tag AzureLoadBalancer; in der Appliance erscheint 168.63.129.16 als Quelladresse. SFOS-Listener und die von Sophos dokumentierten Spezialrouten müssen ebenfalls passen. Weder der Service Tag noch die Plattformadresse werden als allgemeine vertrauenswürdige Internetquelle behandelt.

Auf beiden Firewalls werden unter Routing > Gateways die internen und externen Load-Balancer-Gateways und unter Routing > SD-WAN routes die dokumentierten Probe-Routen angelegt. Die externe Probe-Route muss über der internen stehen. Für Workload-Egress zeigt die Azure-Route 0.0.0.0/0 mit Next hop type: Virtual appliance nicht auf eine Firewall-NIC, sondern auf die Frontend-IP des internen Load Balancers. Auf beiden Firewalls braucht es zusätzlich dieselbe geloggte LAN-zu-WAN-Regel.

Unter Load balancer > Monitoring > Insights beziehungsweise in der Metrik Health Probe Status müssen beide Backend-Instanzen gesund erscheinen. Eine erfolgreiche Probe bestätigt nur, dass der konfigurierte Probe-Port antwortet; sie ersetzt keinen Anwendungs- oder Rückwegtest.

Template kontrolliert bereitstellen

Die Active-Active-Deployment-Ressource öffnen, Template-Revision prüfen und festhalten, dann Deploy to Azure wählen. Vor Next > Create kontrollieren:

• Subscription, Resource group, Region, Location; zuerst prüfen, ob Automation accounts in dieser Subscription und Zielregion verfügbar sind.
• Den geprüften Base URL beibehalten; VM name, sicher verwahrtes Admin password, Image SKU (BYOL/PAYG-new) und VM size mit mindestens zwei NICs.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24); Loadbalancer Int IP muss im LAN frei sein.
• Neu/bestehend, Gruppen und Namen für Public IP, Storage, Network security group, Availability set, Automation account; dazu Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Bestehende Ressourcen und eindeutiges DNS-Label prüfen.
• Ursprüngliche NSG-Regeln und Freigabezeit für Trusted network: * dokumentieren. Managementzugriff auch bei Automationsfehler wieder einschränken; ohne genehmigte, befristete Ausnahme nicht öffentlich unbeschränkt bereitstellen.

Danach tatsächliche NICs, Subnetze, Gateways, LB-Frontends, Probes und Management-Portzuordnungen erfassen; nicht die Standalone-Beispielwerte übertragen.

Gateways und Probe-Routen auf beiden Firewalls

Unter Routing > Gateways > Add zwei Gateways anlegen und speichern:

Das erhaltene Beispiel verwendet 10.54.11.1/10.54.22.1 und WAN für beide Gateways, bindet später aber die interne Route an #PortA, die externe an #PortB. Diese ungewöhnliche Zuordnung ist deploymentspezifisch. NICs, SFOS-Interfaces und Subnetz-Erreichbarkeit prüfen; bei Widerspruch stoppen und mit dem Deployment-Verantwortlichen klären, nicht IPs blind kopieren oder eine universelle Zuordnung erfinden.

Unter Routing > SD-WAN routes > Add zuerst intern, dann extern, jeweils Top:

Interfaceobjekte und Service-Definition am tatsächlichen Probe-Verkehr prüfen: HTTP in der externen Quellrezeptur bedeutet nicht, Probes 4444/3128 auf 80 zu ändern. Einen nicht genannten internen Service nicht zu einer breiten Produktionsroute verallgemeinern; Quelle und Ziel bleiben eng gebunden. Speichern, externe Route über der internen halten und geprüfte Zuordnung auf Firewall 2 wiederholen. Load balancers > Monitoring > Metrics > Health probe status, Aggregation Avg, Filter Backend IP address, für beide Backends und LBs prüfen; danach echten Egress und Rückweg testen.

Eingespeiste Routen nach Firmwarewechsel wiederherstellen

Wartungsfenster einplanen: das dokumentierte Runbook startet die Firewall-VM neu und kann Sitzungen unterbrechen. SFOS-Backups exportieren, Runbook und NSG-Regeln sichern und vor Arbeit an einer VM den anderen Backend-Zustand prüfen. Sind beide ungesund, eine Unterbrechung planen statt unterbrechungsfreie Recovery zu versprechen.

1. Network security groups > [Firewall-NSG] > Inbound security rules > allow_ssh öffnen. Den Runner-Zugriff auf den tatsächlichen SSH-Port klären. Die Quelle setzt Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0: nur eine risikoreiche temporäre Ausnahme, keine Dauerempfehlung. Verifizierten engeren Runner-Pfad bevorzugen; andernfalls explizite Freigabe, kurze Frist und Beschränkung auf benötigtes SSH-Mapping verlangen. Keine Azure-Quell-CIDRs raten oder andere Ports öffnen.
2. Deployment-Ressourcengruppe > Automation account > Runbooks > [bereitgestelltes Runbook] > Edit > Edit in portal. Die erhaltene Revision nennt Auskommentieren von Zeilen 20–24: zuerst den vorgesehenen Block im eingesetzten Skript identifizieren und Original sichern. Nummern nicht auf andere Revisionen übertragen; bei unklarem Zweck stoppen. Save > Publish, Diff prüfen, Start.
3. Werte pro VM eingeben:

4. Job-Ausgabe, Fehler und Status prüfen. Completed bestätigt nur den Job: Neustart und Management-Erreichbarkeit abwarten, eingespeiste 168.63.129.16-Route, beide Probe-Pfade und Anwendung/Egress testen. Erst dann die zweite VM mit ihren eigenen Parametern bearbeiten.
5. Aufgezeichnete NSG-Einschränkungen sofort wiederherstellen, auch bei Fehlern, und effektiven Zugriff prüfen. Gesundes Backend weiterbetreiben, Fehlernachweise sichern, bei falschem Edit gespeichertes Skript wiederherstellen und vor erneutem Lauf oder zweitem Backend eskalieren. Completed beweist weder 100 % Probe-Gesundheit noch Internetzugriff. Recovery und Rollback vor der Umsetzung für die konkrete Cloud- und Appliance-Konfiguration planen.

DNAT und symmetrischen Rückweg planen

Bei eingehendem Traffic verteilt der externe Load Balancer den Dienst an eine Firewall. HA Ports transportieren NVA-Flows protokoll- und portübergreifend, ersetzen aber keine dienstspezifische Veröffentlichung. Für den veröffentlichten TCP-Dienst wird deshalb am externen Load Balancer eine passende Health Probe und Load-Balancing-Regel erstellt und miteinander verknüpft. Die SFOS-NAT-Regel übersetzt danach zum internen Server. In diesem Design setzt man in Rules and policies > NAT rules Translated source (SNAT): MASQ, damit der Server an die LAN-IP derselben Firewall antwortet. Ohne MASQ kann die Antwort über den internen Load Balancer und die andere Firewall laufen; die Session bricht dann durch asymmetrisches Routing.

Direktes RDP aus dem Internet ist keine Empfehlung. Wenn möglich werden VPN oder ZTNA verwendet. Muss ein Dienst veröffentlicht werden, werden Load-Balancer-Regel, NSG sowie NAT- und Firewall-Regel auf die erforderlichen Quellen und Ports begrenzt. Logging und ein passendes IPS-Profil gehören zur Freigabe.

Validieren, Fehler eingrenzen und zurückrollen

Abnahme

1. In Azure die Effective routes einer Test-VM prüfen: Für 0.0.0.0/0 muss die erwartete Firewall-LAN-IP oder beim Active-Active-Design die interne Load-Balancer-IP als Next Hop erscheinen.
2. Von einer definierten Test-VM DNS, HTTPS-Egress und den tatsächlich benötigten Dienst testen. Gleichzeitig in Log viewer > Firewall die erwartete Rule ID, Quell- und Zieladresse kontrollieren.
3. Bei einer Veröffentlichung einen Positivtest aus einem erlaubten und einen Negativtest aus einem nicht erlaubten Quellnetz durchführen. DNAT-Ziel und Server-Rückweg separat prüfen.
4. Beim Active-Active-Design Health Probe Status und Backend Pool kontrollieren. Nur im Wartungsfenster jeweils eine Firewall aus dem Backend nehmen, neue Verbindungen über die verbleibende Instanz prüfen und die entfernte Instanz vor dem zweiten Durchlauf wieder als gesundes Backend aufnehmen. Bestehende Sessions sind nicht synchronisiert und können bei diesem Test abbrechen.

Typische Fehler

• Kein Egress nach Zuordnung der Route Table: Effective Routes, Zuordnung zum richtigen Workload-Subnetz, statische LAN-IP, IP Forwarding, NSG und SFOS Rule ID in dieser Reihenfolge prüfen.
• Probe ist unhealthy: Port und TCP-Protokoll, Listener, NSG sowie die SD-WAN-Routen für 168.63.129.16 kontrollieren. Eine pauschale Freigabe aus dem Internet behebt keine Probe.
• Probe fällt nach einem SFOS-Upgrade aus: Die vom Automation Runbook injizierten Spezialrouten sind nicht persistent. Das von Sophos gelieferte Runbook für beide VMs erneut ausführen, Probe-Status prüfen und eine dafür vorübergehend erweiterte SSH-NSG unmittelbar wieder auf die erlaubten Admin-CIDRs zurücksetzen.
• DNAT funktioniert nur sporadisch: Auf beiden Firewalls dieselbe NAT-/Firewall-Regel, Translated source (SNAT): MASQ, Load-Balancer-Backend und Rückroute des Zielservers vergleichen.

Vor einem Egress-Rollback wird der frühere, freigegebene Next Hop dokumentiert. Dann wird entweder die vorherige Route Table wieder zugeordnet oder das Workload-Subnetz während der Änderung isoliert. Die neue Route Table einfach zu trennen kann Azures Systemroute 0.0.0.0/0 -> Internet aktivieren und die Firewall umgehen; das ist nur zulässig, wenn dieser Pfad ausdrücklich geprüft und gewollt ist. Erst nach wiederhergestelltem, validiertem Rückweg werden UDR oder temporäre Regeln entfernt. Bei einer DNAT-Freigabe wird die externe Load-Balancer-Regel deaktiviert beziehungsweise entfernt, bevor Azure- und SFOS-Regeln zurückgebaut werden. Azure-Snapshots ersetzen kein exportiertes SFOS-Backup; Backup, Wiederaufbau, Lizenzzuordnung, Owner und Kostenalarm werden separat dokumentiert.

Für die nächste Integration das interne Azure-VPN-Gateway-Runbook oder den Entra-Domain-Services-Ablauf im AD-Runbook verwenden.