Sophos Firewall mit Azure VPN Gateway verbinden

Ein Azure VPN Gateway verbindet ein lokales Netzwerk per Site-to-Site-IPsec mit einem Azure Virtual Network. Auf der Sophos Firewall sollte man dafür in der Regel ein route-based IPsec VPN verwenden. Bei grösseren oder dynamischeren Umgebungen kommt zusätzlich BGP dazu.

Dieser Artikel erklärt den praktischen Ablauf mit SFOS 22 und einem aktuellen Azure VPN Gateway: Welche Azure-Objekte nötig sind, wie die Sophos-Seite aufgebaut wird, welche IPsec/IKE-Parameter bewusst abgeglichen werden müssen und wie man nach dem Speichern prüft, ob wirklich Traffic fliesst. Für allgemeine IPsec-Grundlagen passt zuerst Sophos Firewall Site-to-Site IPsec VPN einrichten. Wenn ein bestehender Tunnel grün ist, aber kein Traffic läuft, passt Sophos Firewall IPsec VPN Troubleshooting.

Wann dieser Artikel passt

Der Artikel passt, wenn ein lokales Netz hinter einer Sophos Firewall mit einem Azure Virtual Network verbunden werden soll. Gemeint ist ein Site-to-Site-Tunnel zwischen Azure VPN Gateway und lokaler Firewall, nicht Point-to-Site VPN für einzelne Benutzer und nicht Sophos Firewall als virtuelle Appliance in Azure.

Typische Szenarien:

• lokales Servernetz zu Azure-VMs
• Filiale oder Hauptstandort zu Azure Virtual Network
• Hybrid-Szenario mit AD, DNS, Backup, Monitoring oder Management in Azure
• Migration von policy-based Designs auf route-based IPsec
• optionales BGP für dynamisches Routing zwischen lokalem Netz und Azure

Azure und Sophos verwenden nicht immer dieselben Begriffe. In Azure arbeitet man mit Virtual network, Gateway subnet, Virtual network gateway, Local network gateway und Connection. Auf der Sophos Firewall arbeitet man mit IPsec-Verbindung, XFRM-Interface, Routen, Firewall-Regeln und optional BGP.

Vor der Konfiguration planen

Ein Azure-Tunnel sollte nicht als reiner Klickassistent behandelt werden. Die meisten Fehler entstehen durch überlappende Netze, falsche Gateway-SKUs, nicht passende IPsec/IKE-Parameter, fehlende Routen oder Firewall-Regeln ohne Logging.

Netze und Adressräume

Die lokalen Netze und Azure-Adressräume dürfen sich nicht überschneiden. Azure routet die im Local network gateway eingetragenen lokalen Präfixe zur Sophos Firewall. Die Sophos Firewall routet Azure-Präfixe über das XFRM-Interface oder über BGP.

Vorher dokumentieren:

• Azure Virtual Network Address Space, zum Beispiel 10.50.0.0/16
• Azure Subnets, insbesondere Workload-Subnetze
• lokales Netz hinter der Sophos Firewall, zum Beispiel 172.16.10.0/24
• öffentliche IP der Sophos Firewall oder des vorgelagerten Routers
• Azure Public IP des Virtual Network Gateway
• BGP ja oder nein
• gemeinsamer Preshared Key
• geplante Testsysteme auf beiden Seiten

Wenn sich lokale Netze und Azure-Netze überschneiden, sollte das Design zuerst bereinigt werden. NAT über IPsec ist möglich, macht Betrieb und Fehlersuche aber deutlich schwieriger.

Route-based statt policy-based

Für Azure ist route-based IPsec in aktuellen Designs die richtige Wahl. Die aktuellen VpnGw*AZ-SKUs sind route-based; ein echtes policy-based Gateway gibt es nur mit der eingeschränkten Basic-SKU und IKEv1. Ein route-based Azure Gateway kann zwar mit Use policy based traffic selectors an eine lokale policy-based Firewall angepasst werden. Das bleibt aber ein Kompatibilitätsmodus mit Selektoren für jede lokale/Azure-Präfixkombination und ist nicht mit einem policy-based Azure Gateway gleichzusetzen. Mit Sophos SFOS 22 ist ein route-based Tunnel mit XFRM-Interface übersichtlicher und für BGP, Active-Active und Azure-NAT erforderlich.

Auf der Sophos Firewall bedeutet das:

• IPsec-Verbindung als route-based Tunnel Interface planen.
• XFRM-Interface nach dem Speichern prüfen.
• Routen oder BGP für Azure-Präfixe setzen.
• Firewall-Regeln zwischen lokalen Zonen und VPN-Zone erstellen.
• Traffic mit Log Viewer und Azure-Verbindungsstatus prüfen.

Ein grüner Tunnelstatus ist nur ein Teil der Abnahme. Erst wenn ein definierter Client ein definiertes Azure-Ziel erreicht und beide Seiten Logs oder Zähler zeigen, ist der Tunnel wirklich produktiv geprüft.

IPsec/IKE-Parameter nicht raten

Azure VPN Gateway unterstützt definierte IPsec/IKE-Parameter und erlaubt auf VpnGw1 bis VpnGw5 sowie VpnGw1AZ bis VpnGw5AZ eigene IPsec/IKE Policies. Die Basic-SKU unterstützt sie nicht. Microsoft verlangt pro Connection genau eine vollständige Kombination; Teilangaben reichen nicht. Die Microsoft-Übersicht der Custom IPsec/IKE Policies ist deshalb vor jeder Profiländerung die verbindliche Gegenprüfung.

Für den Betrieb heisst das:

• IKE-Version bewusst wählen, meistens IKEv2.
• Encryption, Integrity, DH Group, PFS und Lifetimes schriftlich festhalten.
• Azure Custom Policy und Sophos IPsec Profile spiegelbildlich prüfen.
• Keine Sophos-zu-Sophos-Standardwerte ungeprüft auf Azure übertragen.
• Nach jeder Policy-Änderung ein Wartungsfenster und einen Rollback-Punkt planen.

Wenn keine Custom Policy gesetzt wird, muss mindestens ein Sophos-Angebot zu den Azure-Standardparametern passen. Microsofts Custom-Policy-Beispiel mit DH24 ist dagegen keine geeignete Kopiervorlage für SFOS 22: SFOS 22 unterstützt in IPsec-Profilen die DH-Gruppen 1, 2, 5, 14 bis 21 sowie 25 bis 31, aber nicht DH-Gruppe 24. Eine Custom Policy darf daher nur Werte aus der Schnittmenge beider aktuellen Herstellerlisten verwenden.

Azure legt die IKE-SA-Lifetime auf 28 800 Sekunden fest; die route-based Default Policy verwendet für die Quick-Mode-SA 27 000 Sekunden und 102 400 000 KB. Bei einer Custom Policy werden die Quick-Mode-Grenzen explizit gesetzt, wobei lokale SA-Lifetimes laut Microsoft nicht identisch sein müssen. SFOS empfiehlt zur Vermeidung von Rekey-Kollisionen trotzdem eine kürzere Key Lifetime auf dem Initiator und eine Phase-2-Lifetime unter Phase 1. Da Sophos hier initiiert, setzt man diese Reihenfolge ohne erfundene Universalwerte um und beobachtet mindestens einen Rekey.

Azure-Seite vorbereiten

Die Azure-Konfiguration besteht aus mehreren Objekten. Die Namen sollten eindeutig sein, weil spätere Fehlersuche sonst schnell unübersichtlich wird.

Virtual Network und Gateway subnet

Im Azure Virtual Network braucht es ein dediziertes GatewaySubnet. Dieses Subnet wird vom Azure VPN Gateway verwendet und darf nicht für normale VMs genutzt werden.

Prüfen:

1. Azure Virtual Network existiert.
2. Address Space überschneidet sich nicht mit lokalen Netzen.
3. GatewaySubnet ist vorhanden und ausreichend gross geplant. Ausser Basic mit minimal /29 verlangen aktuelle SKUs mindestens /27; Microsoft empfiehlt für Erweiterungen grösser als /27.
4. Auf dem GatewaySubnet liegen weder VMs noch eine NSG. Eine UDR mit 0.0.0.0/0 wird dort nicht unterstützt; BGP route propagation darf nicht deaktiviert werden.
5. Workload-Subnetze und Network Security Groups erlauben den gewünschten Traffic.

Virtual Network Gateway erstellen

Das Virtual network gateway ist das eigentliche Azure VPN Gateway. Dabei sind besonders wichtig:

• Gateway type: VPN
• VPN type: Route-based
• SKU und Generation passend zu Bandbreite, SLA, Availability Zone, BGP und NAT-Anforderung
• Public IP für das Gateway
• Active-Active nur planen, wenn die lokale Seite zwei Tunnel zu den beiden öffentlichen Azure-IP-Adressen aufbauen kann
• BGP nur aktivieren, wenn ASN, Peer-IP und Routingkonzept feststehen

Für neue Gateways sind die VpnGw*AZ-SKUs der aktuelle Pfad. VpnGw1AZ bis VpnGw3AZ gibt es als Generation 1; Generation 2 beginnt bei VpnGw2AZ und reicht bis VpnGw5AZ. VpnGw1 bis VpnGw5 sind laut Microsoft nur noch für Migrationen vorgesehen. Basic ist wegen Funktions- und Leistungsgrenzen nicht für Produktionsworkloads empfohlen. Bandbreite, Tunnelzahl und Features ändern sich; deshalb die aktuelle SKU-Tabelle von Microsoft direkt im Planungszeitpunkt prüfen. Die Gateway-Erstellung dauert oft deutlich länger als ein normaler Firewall-Dialog.

Bei Active-Active gehören die beiden IPsec-Tunnel zur selben Azure Connection, aber jede Azure-Gateway-Instanz hat eine eigene Public IP. Auf Sophos braucht es deshalb je Azure-IP eine eigene route-based Verbindung und ein eigenes XFRM-Interface. Das Routing muss Traffic über beide Tunnel und den Ausfall jedes einzelnen Pfads verkraften; beide Tunnel werden separat aufgebaut, belastet und im Failover getestet.

Local Network Gateway erstellen

Das Local network gateway beschreibt die lokale Seite aus Azure-Sicht.

Eintragen:

1. Name, zum Beispiel lng-sophos-hq.
2. Endpoint als öffentliche IP-Adresse oder FQDN der Sophos-Seite.
3. Lokale Address spaces: ohne BGP alle erreichbaren lokalen Präfixe; mit BGP darf das Feld leer bleiben. Statische Präfixe trägt man zusätzlich nur ein, wenn sie nicht über BGP gelernt werden.
4. Unter Advanced BGP aktivieren sowie ASN und BGP Peer IP der Sophos Firewall eintragen, wenn dynamisches Routing verwendet wird.

Azure verwendet standardmässig eine private Adresse aus dem GatewaySubnet als BGP-Peer-IP. Nutzt die Sophos-Seite APIPA, muss man Azure zusätzlich eine eindeutige Adresse aus 169.254.21.0 bis 169.254.22.255 geben; die lokale APIPA-Adresse darf aus 169.254.0.1 bis 169.254.255.254 stammen. Keine Adresse darf sich zwischen Peers überschneiden, und bei APIPA muss die lokale Sophos-Seite die BGP-Sitzung initiieren. Die Werte stehen nach der Bereitstellung unter Virtual network gateway > Configuration; Details zeigt Microsofts BGP-Konfiguration im Portal.

Wenn die Sophos Firewall hinter NAT steht, muss bewusst geprüft werden, welche öffentliche IP Azure sieht und wie NAT-T, Portweiterleitung und IDs auf der lokalen Seite umgesetzt werden. Der einfache Standardpfad ist eine Sophos Firewall mit eigener öffentlicher IP.

Connection erstellen

Die Connection verbindet Virtual Network Gateway und Local Network Gateway.

Wichtige Werte:

• Connection type: Site-to-site (IPsec)
• Shared key: identisch zum Sophos Preshared Key
• IKE Protocol: passend zur Sophos-Konfiguration
• BGP: nur aktivieren, wenn beide Seiten BGP verwenden
• Custom IPsec/IKE policy: nur setzen, wenn die Werte bewusst geplant sind

Nach dem Erstellen der Connection ist Azure-Seite bereit, aber noch nicht automatisch produktiv. Die Sophos-Seite muss denselben Tunnel, dieselben Parameter und den Rückweg kennen.

Sophos Firewall konfigurieren

Auf der Sophos Firewall wird der Tunnel unter Site-to-site VPN > IPsec erstellt.

IPsec-Profil vorbereiten

Unter Profiles > IPsec profiles ein Profil verwenden oder erstellen, das zu Azure passt. Wie die Sophos-Felder zusammenhängen und ein eigenes Profil sauber geklont wird, erklärt IPsec-Profile auf Sophos Firewall verstehen und sicher konfigurieren. Die konkreten Werte müssen weiterhin exakt zur Azure Default Policy oder zur Custom IPsec/IKE Policy der Connection passen.

Dokumentieren:

• IKE version
• Phase-1 Encryption und Authentication
• DH Group
• Phase-2 Encryption und Authentication
• PFS
• Key lifetime

Wenn Azure eine Custom Policy nutzt, sollte der Profilname dies widerspiegeln, zum Beispiel Azure_IKEv2_AES256_G14.

Route-based IPsec-Verbindung erstellen

Menüpfad:

Site-to-site VPN > IPsec

Vorgehen:

1. Add öffnen.
2. Route-based beziehungsweise Tunnel Interface als Verbindungstyp wählen.
3. Namen setzen, zum Beispiel azure-vnet-prod.
4. Gateway type auf der Sophos-Seite meistens Initiate the connection setzen.
5. Azure Public IP des Virtual Network Gateway als Remote Gateway eintragen.
6. Preshared Key identisch zur Azure Connection setzen.
7. Local ID und Remote ID prüfen, besonders bei NAT oder mehreren Tunneln.
8. IPsec-Profil auswählen.
9. Verbindung speichern und aktivieren.

Nach dem Speichern das XFRM-Interface unter Network > Interfaces prüfen. Es bleibt der VPN-Zone zugeordnet. Je nach Design wird es mit statischer Route, SD-WAN Route oder BGP verwendet.

Für den klaren route-based Aufbau setzt man auf Sophos beide Traffic Selectors auf Any. Die Firewall erstellt dann automatisch ein xfrm-Interface mit fortlaufender Nummer. Bei Any-to-Any erstellt SFOS keine automatischen Firewall-Regeln. Die Regeln werden daher im nächsten Schritt bewusst manuell angelegt. NAT-T ist auf Sophos immer aktiv; hinter einem vorgeschalteten NAT müssen zusätzlich die IDs beider Peers exakt zusammenpassen.

Route oder BGP konfigurieren

Ohne BGP lädt man in der Azure Connection unter Download configuration die generischen Geräteparameter und übernimmt die dort ausgewiesene erste Tunnel-IP samt Netzmaske und MSS in das XFRM-Interface unter Network > Interfaces. Danach erstellt man unter Routing > Static routes > IPv4 unicast route eine Route für jedes Azure-Präfix über dieses XFRM-Interface. Gateway darf leer bleiben oder die Peer-Adresse aus demselben heruntergeladenen Transfernetz enthalten. Mit BGP wird stattdessen die im Local Network Gateway eingetragene lokale BGP-Peer-IP samt Netzmaske dem XFRM-Interface zugewiesen; als Sophos-BGP-Nachbar dient die unter Virtual network gateway > Configuration angezeigte Azure BGP Peer IP. Transferadressen werden nicht frei geraten.

Mit BGP müssen beide Seiten sauber geplant sein. BGP auf Sophos Firewall konfigurieren erklärt die Grundkonfiguration, sichere Freigabe und Abnahme; für Azure werden anschliessend die von Azure vorgegebenen Peer-Werte verwendet:

• lokales ASN der Sophos Firewall
• Azure ASN
• BGP Peer IPs
• erlaubte und angekündigte Präfixe
• Route Advertisement in Azure
• Firewall-Regeln für den tatsächlichen Nutztraffic

BGP ersetzt keine Firewall-Regeln. Es verteilt nur Routen. Ob ein Server in Azure wirklich erreichbar ist, entscheiden danach weiterhin Routing, NSG, Firewall-Regeln und Zielsystem.

Das dokumentierte Azure-BGP-Design verwendet IPv4. Das lokale ASN darf nicht mit dem Azure-ASN übereinstimmen und keiner der reservierten Azure-ASNs 8075, 8076, 12076, 65515, 65517, 65518, 65519 oder 65520 sein. Unter Administration > Device access wird Dynamic Routing für die VPN-Zone freigegeben. Danach prüft man auf Sophos, ob die Azure-Präfixe wirklich gelernt werden, und in Azure unter BGP peers, ob die lokalen Präfixe angekommen sind.

Für firewall-eigenen Traffic prüft man zuerst tatsächliche Quelladresse, angekündigte Präfixe und Rückweg. Liegt die Quelle nicht in einem zu Azure gerouteten lokalen Präfix, kann eine gezielte sys-traffic-nat-Zuordnung zur LAN-IP der Firewall nötig sein; sie wird aber nicht pauschal nur wegen BGP gesetzt. Pre-Check, Device-Console-Syntax, Kontrolle und exakte Löschung beschreibt Systemtraffic über IPsec gezielt routen.

Überlappende Netze nur geplant mit NAT lösen

Wenn eine Umadressierung unmöglich ist, kann Azure VPN Gateway überlappende Netze für S2S-Verbindungen übersetzen. Azure-NAT gibt es nur auf VpnGw2 bis VpnGw5 und VpnGw2AZ bis VpnGw5AZ, nur mit route-based VPN und nicht zusammen mit policy-based Traffic Selectors. Statisches NAT bildet 1:1 ab und erlaubt Verbindungsaufbau in beide Richtungen; dynamisches NAT ist zustandsbehaftet und kann nur von der Seite der Internal mapping initiiert werden. Bei BGP muss Enable BGP route translation aktiv sein; BGP mit APIPA wird zusammen mit Azure-NAT nicht unterstützt. Die Azure-NAT-Grenzen und Zuordnungslogik sollten Bestandteil des Designs und nicht eine spontane Fehlerbehebung sein.

Firewall-Regeln erstellen

Für den Traffic durch den Tunnel braucht es passende Regeln. Typisch sind Regeln zwischen interner Zone und VPN-Zone.

Empfehlung für die Einführung:

• Quelle und Ziel als konkrete Netze oder Hosts setzen.
• Dienste für den ersten Test bewusst wählen, zum Beispiel ICMP, RDP, HTTPS oder DNS.
• Log firewall traffic aktivieren.
• Regeln nach erfolgreichem Test nicht auf Any stehen lassen.
• Gegenrichtung getrennt prüfen, wenn Azure auch lokale Systeme erreichen soll.

Wenn die Regel nicht matcht, hilft Sophos Firewall Regel greift nicht: Ursachen prüfen.

Verbindung prüfen

Die Abnahme sollte immer beide Ebenen prüfen: Tunnelstatus und echter Traffic.

Azure prüfen

In Azure:

1. Zur Connection des VPN Gateway wechseln.
2. Verbindungsstatus prüfen.
3. Datenzähler beobachten.
4. Effective routes der betroffenen Azure-VM prüfen.
5. Network Security Group der Ziel-Subnetze prüfen.

Ein Azure-Status alleine reicht nicht. Eine VM kann trotz stehender Connection durch NSG, lokale Windows-Firewall, falsche Route oder fehlenden Rückweg unerreichbar sein.

Sophos Firewall prüfen

Auf der Sophos Firewall:

1. Site-to-site VPN > IPsec Status prüfen.
2. XFRM-Interface unter Network > Interfaces kontrollieren.
3. Route zu Azure-Präfixen prüfen.
4. Log Viewer nach Testtraffic filtern.
5. Bei Bedarf Packet Capture oder strongswan.log verwenden.

Für IPsec-Logs und CLI-Analyse passt Sophos Firewall IPsec VPN Troubleshooting.

Auf Azure-Seite liefern VPN Gateway > Diagnostic settings mit IKEDiagnosticLog, TunnelDiagnosticLog, RouteDiagnosticLog und GatewayDiagnosticLog belastbarere Hinweise als ein Reset. Zeitstempel von Sophos und Azure müssen für denselben Testlauf verglichen werden. Einen Gateway-Reset verwendet man erst nach diesen Prüfungen, weil er die aktive Gateway-Instanz neu startet und bestehende Verbindungen unterbrechen kann.

Realistischen Testtraffic verwenden

ICMP ist ein guter Start, aber kein vollständiger Test. Danach sollte man den Dienst testen, der produktiv gebraucht wird:

• DNS zu einem Azure-DNS- oder Domain-Controller
• RDP oder SSH zu einer Test-VM
• HTTPS zu einer internen Anwendung
• Backup-, Monitoring- oder Management-Traffic

Dabei muss die Quelle stimmen. Ein Ping direkt von der Firewall beweist nicht dasselbe wie ein Test von einem Client hinter der Firewall.

Typische Fehler

Tunnel bleibt down

Meist passen Gateway-IP, IKE-Version, Preshared Key, IDs oder IPsec/IKE-Parameter nicht zusammen. Auf der Sophos Firewall zuerst strongswan.log prüfen und Azure Connection Settings mit dem Sophos IPsec Profile vergleichen. Gibt es mehrere IPsec-Verbindungen mit denselben Endpunkten, muss man auch die PSK-Zuordnung prüfen: IKEv2 unterstützt einen eigenen PSK je Kombination aus Local ID und Remote ID. IKEv1 unterstützt dagegen nur einen PSK je Kombination aus lokalem und entferntem Gateway; SFOS verwendet dafür den PSK der zuletzt konfigurierten Verbindung. Eindeutige IDs mit IKEv2 vermeiden diese Kollision.

Tunnel ist verbunden, aber kein Traffic fliesst

Dann fehlen oft Routen, Firewall-Regeln, Azure NSG-Regeln oder der Rückweg. Auf Sophos-Seite Log Viewer und Route prüfen. Auf Azure-Seite Effective Routes und NSG prüfen.

Nur eine Richtung funktioniert

Das deutet oft auf asymmetrisches Routing, NSG, Host-Firewall oder fehlende Gegenregel hin. Beide Richtungen separat testen und die Quelle des Testtraffic dokumentieren.

BGP lernt keine Routen

ASN, Peer IP, BGP-Aktivierung, XFRM-Adresse und Azure-BGP-Konfiguration prüfen. Danach kontrollieren, welche Präfixe wirklich angekündigt und gelernt werden. Ein stehender IPsec-Tunnel bedeutet nicht automatisch, dass BGP korrekt routet.

Nach Policy-Änderung kommt der Tunnel nicht mehr hoch

Custom IPsec/IKE Policies müssen vollständig und kompatibel sein. Wenn Azure und Sophos nur einen Wert unterschiedlich interpretieren, kann die Verbindung scheitern. Vor Änderungen immer aktuelles Profil, Azure Policy und funktionierenden Zustand dokumentieren.

Azure ist Initiator und der Child SA läuft ab

Wenn Azure der Initiator ist, rekeyt Azure einen ablaufenden Child SA nur bei vorhandenem Tunneltraffic. Ohne Traffic wird der Child SA gelöscht, Phase 1 bleibt aber bestehen. Späterer Traffic von Azure kann einen neuen Child SA aufbauen; beginnt der Traffic ausschliesslich hinter der Sophos Firewall, baut Azure ihn in diesem Zustand nicht auf. Deshalb ist für dieses Design Initiate the connection auf Sophos sinnvoll. Beim Azure-Rekey der IKE SA kann ausserdem eine kurze Unterbrechung entstehen.

Zustandserhaltend zurückrollen

Vor einer Änderung exportiert oder dokumentiert man Sophos-Verbindung, Profil, XFRM-Adresse, Routen und Regeln sowie Azure Gateway-SKU/-Generation, Connection, Shared Key, BGP- und NAT-Einstellungen. Die funktionierende Connection wird nicht gelöscht. Für einen Policy-Test klont man zuerst das Sophos-Profil; in Azure notiert man die bestehende Policy mit Connection > Configuration oder PowerShell.

Scheitert die Änderung, weist man der Sophos-Verbindung wieder das alte Profil zu und stellt auf Azure dieselbe bisherige Custom Policy wieder her beziehungsweise entfernt nur die neu hinzugefügte Custom Policy, falls zuvor die Azure-Defaults aktiv waren. Danach aktiviert man die bestehende Verbindung erneut und wiederholt Tunnel-, Routen- und Anwendungstest. Gateway, Local Network Gateway, XFRM-Interface, Routen oder NAT-Regeln werden nicht vorsorglich gelöscht: Das würde den bekannten Zustand vernichten und kann öffentliche IPs oder Routing verändern.

FAQ