Zum Inhalt springen
Avanet

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 zwischen Sophos Firewall und Microsoft Azure: 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 den meisten aktuellen Designs die richtige Wahl. Azure VPN Gateway wird typischerweise route-based betrieben, besonders wenn mehrere Präfixe, BGP, Active-Active oder spätere Erweiterungen geplant sind.

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 bei passenden Gateway-SKUs auch eigene IPsec/IKE Policies. Microsoft weist darauf hin, dass eine benutzerdefinierte Policy vollständig angegeben werden muss; Teilangaben reichen nicht.

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 das Sophos-Profil zu den Azure-Defaults passen. Wenn eine Custom Policy gesetzt wird, müssen alle Werte sauber auf beiden Seiten gepflegt werden.

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.
  4. 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 passend zu Bandbreite, SLA, Availability Zone und BGP-Anforderung
  • Public IP für das Gateway
  • Active-Active nur planen, wenn die lokale Seite dafür ausgelegt ist
  • BGP nur aktivieren, wenn ASN, Peer-IP und Routingkonzept feststehen

Die Gateway-Erstellung in Azure dauert oft deutlich länger als ein normaler Firewall-Dialog. Das sollte im Zeitplan berücksichtigt werden.

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, wenn ohne BGP gearbeitet wird.
  4. BGP settings, wenn dynamisches Routing verwendet wird.

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. Die Werte müssen zu 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.

Route oder BGP konfigurieren

Ohne BGP braucht die Sophos Firewall eine Route zu den Azure-Präfixen. Meistens ist das eine statische Route oder SD-WAN Route über das XFRM-Interface.

Mit BGP müssen beide Seiten sauber geplant sein:

  • 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.

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.

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.

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.

FAQ

Soll man Sophos Firewall zu Azure policy-based oder route-based verbinden?

Für Azure ist route-based IPsec normalerweise die bessere Wahl, besonders bei mehreren Netzen, BGP oder späteren Erweiterungen. Policy-based Designs sind für Azure meist weniger flexibel.

Braucht Azure VPN Gateway BGP?

Nein, für einfache Verbindungen reichen statische Routen beziehungsweise Address Spaces im Local Network Gateway. BGP lohnt sich, wenn Präfixe dynamisch gelernt werden sollen oder mehrere Pfade geplant sind.

Warum ist der Azure-Tunnel grün, aber die VM nicht erreichbar?

Dann ist IPsec wahrscheinlich aufgebaut, aber Routing, Firewall-Regel, Azure NSG, lokale Windows-Firewall oder Rückweg passen nicht. Deshalb müssen Tunnelstatus und echter Anwendungstraffic separat getestet werden.

Kann die Sophos Firewall hinter NAT stehen?

Es kann funktionieren, ist aber nicht der einfache Standardfall. Dann müssen öffentliche IP, NAT-T, Portweiterleitung, Local ID, Remote ID und Azure Local Network Gateway besonders sauber geplant und getestet werden.

Muss man Azure-IPsec-Parameter explizit setzen?

Nicht immer. Wenn keine Custom IPsec/IKE Policy verwendet wird, muss das Sophos-Profil zu den Azure-Defaults passen. Wenn eine Custom Policy verwendet wird, müssen alle Parameter vollständig und auf beiden Seiten kompatibel gesetzt werden.