Site-to-Site-VPN zwischen Sophos XGS und Azure: IPsec, BGP und die üblichen Stolpersteine

Das Site-to-Site-VPN zwischen Sophos XGS und Azure hat einen zwiespältigen Ruf: Der Tunnel steht in einer Stunde — und reißt dann drei Wochen später nachts um zwei, scheinbar grundlos. Die Kurzantwort vorab: XGS und Azure vertragen sich ausgezeichnet, wenn drei Dinge zusammenpassen. Erstens die IKE-Parameter — und zwar exakt, auf beiden Seiten, am besten per eigener IPsec-Richtlinie an der Azure-Verbindung statt Verhandlungslotterie; die berüchtigten sporadischen Abrisse sind fast immer ein Rekeying-Mismatch, der beim ersten Verbindungsaufbau schlicht noch nicht auffällt. Zweitens die passende Gateway-SKU, damit der Durchsatz zur Leitung passt und niemand versehentlich die Basic-Falle kauft. Und drittens das Routing: Für ein einzelnes VNet reicht statisch, ab Peering-Landschaften und Redundanz wird BGP zur Pflicht. Dieser Artikel liefert die funktionierende Parameterkombination als Tabelle, die Schritt-für-Schritt-Konfiguration beider Seiten, die Routing- und Redundanz-Entscheidung — und die Diagnose-Werkzeuge, mit denen du einen zickenden Tunnel in Minuten statt Nächten einkreist.

Azure-VPN-Gateway-Grundlagen und SKU-Wahl

Auf der Azure-Seite besteht die Anbindung aus vier Objekten, die man einmal verstanden haben sollte, weil jede Fehlermeldung später auf eines davon zeigt: Das VPN Gateway ist der eigentliche Tunnelendpunkt — es wohnt in einem dedizierten Subnetz namens GatewaySubnet (spendiere ein /27, damit spätere Ausbauten Platz haben) und bekommt eine eigene öffentliche IP; die Bereitstellung dauert gemütliche 30 bis 45 Minuten, also nicht am Provisioning-Balken verzweifeln. Das Local Network Gateway ist Azures Steckbrief deiner On-Prem-Seite: die öffentliche IP der XGS plus deine lokalen Netze (beziehungsweise die BGP-Parameter). Die Connection verknüpft beides und trägt PSK sowie — wichtig — die eigene IPsec-Richtlinie. Und das VNet ist das Ziel der Reise, dessen Adressraum sich mit keinem On-Prem-Netz überlappen darf.

Bleibt die SKU-Wahl, und die ist eine Durchsatz- und Funktionsfrage: Die Generation-2-SKUs VpnGw1 bis VpnGw5 skalieren von rund 650 Megabit bis in den Multi-Gigabit-Bereich, können BGP, aktiv/aktiv und (in den AZ-Varianten) Verfügbarkeitszonen. Für den typischen Mittelstand mit einer Leitung bis 500 Megabit ist VpnGw1 der Startpunkt; wer die Leitung im Gigabit-Bereich auslasten will oder viele Standorte terminiert, greift zu VpnGw2. Die Preislogik läuft pro Betriebsstunde plus ausgehendem Datenverkehr — das Gateway kostet also auch nachts. Die Tabelle liefert die Orientierungswerte; und zur Basic-SKU, die im Portal so verführerisch günstig blinkt, sagt der Warn-Kasten das Nötige.

IPsec-Parameter, die zueinander passen

Jetzt zum Herzstück und zur Ursache der meisten Azure-Tunnel-Mysterien. Azures Gateway verhandelt im Standardmodus aus einem breiten Strauß an Vorschlägen — was verführerisch klingt, aber ein Problem erzeugt: Der initiale Verbindungsaufbau findet fast immer eine gemeinsame Sprache, und erst beim Erneuern der Schlüssel (Rekeying) zeigt sich, ob beide Seiten wirklich dasselbe meinen. Genau dort wohnen die sporadischen Abrisse: Der Tunnel läuft stundenlang tadellos und stirbt dann zuverlässig beim ersten oder zweiten Rekey — gern nachts, gern »ohne dass jemand etwas geändert hat«. Die Lösung ist Determinismus statt Verhandlung: Auf der Azure-Connection wird eine eigene IPsec-Richtlinie gesetzt, auf der XGS ein passendes IPsec-Profil gebaut, und beide enthalten Wert für Wert dieselben Parameter. Die Tabelle liefert die in Projekten bewährte Kombination.

Konfiguration Schritt für Schritt: Sophos XGS und Azure Site-to-Site verbinden

Die Reihenfolge, die sich bewährt hat, beginnt in Azure — schon weil das Gateway-Provisioning die Kaffeepause vorgibt. Schritt eins: VNet prüfen (Adressraum überlappungsfrei zu allen On-Prem-Netzen!), GatewaySubnet anlegen, VPN Gateway mit gewählter SKU und Public IP bereitstellen. Schritt zwei: das Local Network Gateway mit der öffentlichen IP der XGS und den On-Prem-Netzen anlegen — hier gehört Sorgfalt hinein, denn vergessene Netze sind später »geht von Standort A, aber nicht von B«-Tickets. Schritt drei: die Connection erstellen — IKEv2, ein langer zufälliger PSK aus dem Passwortgenerator (kein Firmenname mit Jahreszahl), und direkt die eigene IPsec-Richtlinie mit den Werten aus der Parametertabelle. Die Architektur-Skizze zeigt, wie die vier Objekte zusammenhängen und was die XGS-Seite spiegeln muss.

Schritt vier wechselt auf die XGS: ein IPsec-Profil »Azure« mit exakt denselben Phase-1- und Phase-2-Werten anlegen (zeitbasiertes Rekeying, PFS Gruppe 14, DPD aktiv), dann die Site-to-Site-Verbindung — Gateway-Adresse ist die Public IP des Azure-Gateways, Authentifizierung per PSK, die XGS als Initiator. Für den statischen Einstieg definierst du lokale und entfernte Netze direkt an der Verbindung; für den BGP-Weg kommt stattdessen ein Route-based-VPN mit Tunnel-Interface zum Einsatz, dazu gleich mehr im Routing-Kapitel. Schritt fünf wird gern vergessen und kostet dann eine Stunde Rätselraten: die Firewall-Regeln für den Tunnelverkehr — LAN zu VPN-Zone und zurück, mit den Azure-Netzen als Gegenstelle; ein stehender Tunnel ohne Regeln transportiert exakt nichts. Und Schritt sechs ist der Beweis: Verbindung aktivieren, Status grün, Ping auf eine VM im VNet — und danach ein großer Dateitransfer als Lasttest, denn der entlarvt MTU-Probleme, die der Ping charmant verschweigt.

Skizze 1: Vier Azure-Objekte, eine XGS-Verbindung — und beidseitig exakt dieselben IKE-Parameter. Überlappende Adressräume sind der Baufehler, den keine Konfiguration mehr rettet.

Routing: statisch vs. BGP

Die Routing-Frage entscheidet, wie viel Handarbeit die Anbindung dauerhaft kostet. Statisch heißt: Beide Seiten kennen die Netze der Gegenseite als feste Liste — auf der XGS die VNet-Adressräume in der Verbindung, in Azure die On-Prem-Netze im Local Network Gateway. Das ist schnell gebaut, leicht zu verstehen und für das klassische Szenario »ein Standort, ein VNet« völlig ausreichend. Der Preis zeigt sich beim Wachsen: Jedes neue Subnetz, jedes zusätzliche VNet, jeder weitere Standort bedeutet Pflege an mehreren Stellen — und die vergessene Zeile ist der Stoff, aus dem die »warum erreiche ich das neue Netz nicht«-Tickets sind.

BGP dreht das um: Die XGS (mit einer frei gewählten privaten ASN, etwa 65010) und das Azure-Gateway (Standard-ASN 65515) werden über den Tunnel BGP-Nachbarn und tauschen ihre Netze automatisch aus — technisch auf der XGS als Route-based-VPN mit Tunnel-Interface, über das das Peering zur BGP-Adresse des Gateways läuft. Neue VNets, die per Peering mit Gateway-Transit am Hub hängen, neue On-Prem-Netze, ein zusätzlicher Standort aus der Multi-Site-Welt [LINK: A1] — alles wandert von selbst in die Routing-Tabellen, und beim Ausfall eines Pfades rechnet BGP den Weg neu, was es zur Voraussetzung für echte Redundanz macht. Die Pflicht-Fälle für BGP sind damit klar: aktiv/aktiv-Gateways, mehrere Tunnel, wachsende VNet-Landschaften. Zwei Spielregeln aus der Skizze gehören ins Gedächtnis: private ASNs aus dem Bereich 64512 bis 65534 verwenden, dabei aber die von Azure reservierten (65515 bis 65520) auf der eigenen Seite meiden.

Skizze 2: Zwei autonome Systeme, ein Peering durch den Tunnel — Netze werden angekündigt statt gepflegt, und die ASN-Spielregeln stehen gleich dabei.

Redundanz: aktiv/aktiv und zweite Tunnel

Ein einzelner Tunnel ist eine Verfügbarkeitswette mit mehreren Einsätzen: Azure wartet seine Gateway-Instanzen (der aktiv/passiv-Failover kostet einen kurzen Umschalt-Moment), deine Leitung hat einen Bagger als natürlichen Feind, und dazwischen liegt das Internet. Die Ausbaustufen dagegen: Stufe eins ist der Einzeltunnel — legitim für unkritische Workloads und Testphasen. Stufe zwei ist die Empfehlung für produktive Anbindungen: das Azure-Gateway im aktiv/aktiv-Modus mit zwei Public IPs, dazu zwei Tunnel von der XGS (je einer pro Gateway-Instanz) und BGP als Dirigent, der die Routen auf beide Pfade verteilt und beim Ausfall einer Instanz unterbrechungsarm schwenkt — Azure-Wartungsfenster werden damit zum Nicht-Ereignis. Stufe drei ergänzt die On-Prem-Seite: eine zweite WAN-Leitung (idealerweise anderer Provider, anderer Weg ins Haus) mit weiteren Tunneln darüber, denn gegen den Bagger vor der eigenen Tür hilft die schönste Azure-Redundanz nichts.

Zwei ehrliche Einordnungen dazu: Erstens schützt ein XGS-HA-Paar vor dem Geräteausfall, ist aber nach außen eine logische Firewall — es ergänzt Tunnel- und Leitungsredundanz, ersetzt sie nicht. Und zweitens gehört zur Redundanz der Test: Ein nie geprobtes Failover ist eine Hoffnung, kein Konzept — halbjährlich eine Gateway-Instanz respektive Leitung kontrolliert aus dem Spiel nehmen und zusehen, ob BGP liefert. Die Skizze zeigt die Stufen im Zusammenhang.

Skizze 3: Aktiv/aktiv mit zwei Tunneln und BGP als empfohlene Betriebsstufe — die zweite WAN-Leitung ist die Antwort auf den Bagger, nicht auf Azure.

Troubleshooting mit den Diagnose-Werkzeugen beider Seiten

Wenn der Tunnel zickt, hilft Systematik von beiden Enden. Auf der XGS-Seite: Der Log Viewer mit dem VPN-Filter zeigt die IKE-Verhandlung im Klartext — dort steht, ob die Authentifizierung scheitert (dann ist es der PSK oder die Gateway-Adresse), ob kein gemeinsamer Vorschlag zustande kommt (Parametertabelle abgleichen, Wert für Wert) oder ob die Traffic-Selektoren abgelehnt werden (Netze-Definitionen beider Seiten vergleichen). Auf der Azure-Seite: Die Verbindungsübersicht zeigt Status und Datenzähler je Tunnel, die Gateway-Metriken machen Abrisse im Zeitverlauf sichtbar (reißt es immer nach derselben Laufzeit, schreit das nach dem Rekeying-Kasten), der BGP-Peer-Status verrät, ob das Peering steht und welche Routen ankommen — und für harte Fälle gibt es die Paketmitschnitt-Funktion am Gateway sowie als robusten Klassiker den Gateway-Reset, der beide Instanzen nacheinander durchstartet. Wer die Tunnel-Ereignisse dauerhaft neben den übrigen Sicherheitsereignissen sehen will, findet die Log-Anbindung ans SIEM im Sentinel-Artikel [LINK: B8].

Zwei Spezialfälle verdienen eigene Erwähnung, weil sie mit Tunnel-Diagnose allein nicht zu fassen sind. Erstens das MTU-Phänomen: Ping funktioniert, RDP-Sitzungen bauen auf und frieren ein, Dateitransfers hängen — das ist fast immer die Paketgröße, denn der IPsec-Overhead schrumpft die nutzbare MTU, und irgendwo verwirft etwas die zu großen Pakete. Die Abhilfe ist MSS-Clamping auf der XGS für den Tunnelverkehr (bewährter Wert: 1350 Byte, Microsofts eigene Empfehlung für VPN-Pfade) — Details im Praxis-Kasten. Zweitens die Namensauflösung: Der Tunnel steht, IP-Zugriffe laufen, aber Serverzugriffe per Name scheitern — das ist kein VPN-, sondern ein DNS-Thema, denn die Azure-VMs und die On-Prem-Welt müssen sich gegenseitig auflösen können; die saubere Konstruktion dafür steht im Split-DNS-Artikel [LINK: B10].

FAQ — häufige Fragen zum Site-to-Site-VPN zwischen XGS und Azure

Welche IPsec-Einstellungen brauche ich für Azure?

Die bewährte Kombination, beidseitig identisch: IKEv2 mit AES-256 und SHA-256 in beiden Phasen, Diffie-Hellman-Gruppe 14 in Phase 1, PFS mit Gruppe 14 in Phase 2 — ausdrücklich auf beiden Seiten gesetzt —, Lebensdauern von 28.800 Sekunden (Phase 1) und 27.000 Sekunden (Phase 2), Rekeying ausschließlich zeitbasiert (Volumenlimits auf der XGS deaktivieren), Dead Peer Detection aktiv und die XGS als Initiator. Entscheidend ist weniger die exakte Cipher-Wahl als die Disziplin dahinter: Setze an der Azure-Connection eine eigene IPsec-Richtlinie mit genau diesen Werten, statt dich auf die Standardverhandlung zu verlassen — dann verhandeln beide Seiten nicht, sie wissen. Damit verschwinden die klassischen Spätzünder-Fehler, die beim Aufbau unsichtbar sind und erst beim Schlüsseltausch zuschlagen. Die vollständige Tabelle mit Anmerkungen steht im Parameterkapitel dieses Artikels.

Warum bricht der Tunnel nach einiger Zeit ab?

Weil beim Aufbau verhandelt wird, beim Rekeying aber Übereinstimmung herrschen muss — und genau dort klaffen die Konfigurationen auseinander. Verdächtiger Nummer eins: PFS nur auf einer Seite (typisch: XGS-Vorlage ja, Azure-Standard nein) — der initiale Aufbau gelingt, die Phase-2-Erneuerung scheitert, der Tunnel reißt nach Stunden. Verdächtiger Nummer zwei: volumenbasiertes Rekeying auf der XGS, das unter Last (Backups!) mitten im Azure-Zeitfenster erneuert — das erklärt Abrisse, die nur bei hohem Durchsatz auftreten. Verdächtiger Nummer drei: Dead Peer Detection ohne Wiederverbinden, sodass ein kurzer Schluckauf zum Dauerausfall wird. Die Diagnose ist dankbar: Reißt der Tunnel wiederkehrend nach ähnlicher Laufzeit oder unter Last, ist es mit hoher Sicherheit das Rekeying — die Azure-Gateway-Metriken zeigen das Muster im Zeitverlauf, das XGS-Log die scheiternde Verhandlung im Detail. Die Therapie: Parametertabelle beidseitig durchsetzen, eigene IPsec-Richtlinie an der Connection, Volumenlimits aus.

Brauche ich BGP für ein einzelnes VNet?

Nein — für das Szenario »ein Standort, ein VNet, ein Tunnel« ist statisches Routing die angemessene Wahl: schneller gebaut, leichter zu verstehen, und es gibt schlicht nichts, was dynamisch werden müsste. BGP wird in drei Situationen zur richtigen Antwort, und in zweien davon faktisch zur Pflicht: Erstens bei Redundanz — aktiv/aktiv-Gateways und mehrere Tunnel brauchen einen Mechanismus, der Routen verteilt und beim Ausfall schwenkt; das ist BGPs Kernjob. Zweitens bei wachsenden Landschaften — mehrere VNets über Peering, zusätzliche Standorte, häufig neue Subnetze: Ohne BGP pflegst du Selektoren-Listen an mehreren Stellen, mit BGP kündigen sich die Netze selbst an. Drittens als Zukunftsvorsorge — wer absehbar Richtung Redundanz oder ExpressRoute wächst, baut mit BGP von Anfang an migrationsarm. Der Aufwand ist überschaubar: eine private ASN wählen, Route-based-VPN mit Tunnel-Interface, Peering zur Gateway-BGP-Adresse — eine Stunde Mehrarbeit, die sich beim ersten Ausbau zurückzahlt.

Welche Gateway-SKU reicht für den Mittelstand?

Für die große Mehrheit: VpnGw1, gern in der AZ-Variante mit Verfügbarkeitszonen. Die Rechnung dahinter ist simpel — die SKU muss zur Internetleitung passen: Mit rund 650 Megabit aggregiertem Durchsatz deckt VpnGw1 Leitungen bis etwa 500 Megabit komfortabel ab, kann BGP und aktiv/aktiv und lässt alle Redundanz-Ausbaustufen offen. VpnGw2 wird interessant, wenn eine Gigabit-Leitung tatsächlich durch den Tunnel ausgelastet werden soll oder viele Standorte am selben Gateway terminieren; alles darüber ist Konzern-Terrain. Zwei Fußnoten: Die Basic-SKU ist keine Sparoption, sondern eine Sackgasse ohne BGP und ohne Upgrade-Pfad (siehe Warn-Kasten) — und die Preisangaben in diesem Artikel sind Größenordnungen zum Redaktionsstand; verbindlich rechnet der Azure-Preisrechner, und zum Gateway-Betrieb addiert sich immer der ausgehende Datenverkehr.

Wie baue ich Redundanz in die Anbindung?

In drei Stufen, je nach Schutzbedarf. Stufe eins ist der Einzeltunnel — akzeptabel für Unkritisches, aber jede Gateway-Wartung und jeder Leitungsschluckauf schlägt durch. Stufe zwei ist die Empfehlung für produktive Workloads: das Gateway auf aktiv/aktiv umstellen (zwei Instanzen, zwei Public IPs), von der XGS zwei Tunnel bauen — je einer pro Instanz — und BGP die Routen auf beide Pfade verteilen lassen; Instanzwartungen werden damit zum unterbrechungsarmen Nicht-Ereignis. Stufe drei adressiert die On-Prem-Seite: eine zweite WAN-Leitung, idealerweise anderer Provider und anderer Hauseingang, mit weiteren Tunneln darüber — gegen den Bagger vor der eigenen Tür hilft keine Azure-Redundanz. Dazu zwei Betriebsregeln: Ein XGS-HA-Paar schützt vor Geräteausfall, ersetzt aber weder Tunnel- noch Leitungsredundanz. Und jedes Failover-Konzept gilt erst als vorhanden, wenn es geprobt wurde — halbjährlich eine Komponente kontrolliert ziehen.

Kann ich mehrere VNets über einen Tunnel erreichen?

Ja — die saubere Konstruktion dafür heißt Hub-and-Spoke mit Gateway-Transit: Das VPN Gateway wohnt in einem Hub-VNet, die weiteren VNets werden per Peering mit dem Hub verbunden und nutzen dessen Gateway mit (»Remote-Gateway verwenden« auf Spoke-Seite, »Gatewaytransit zulassen« auf Hub-Seite). Damit erreicht die On-Prem-Welt sämtliche gepeerten VNets über den einen Tunnel, ohne pro VNet ein eigenes Gateway zu bezahlen. Der Komfortunterschied liegt im Routing: Mit BGP kündigt das Gateway die Spoke-Adressräume automatisch an — neue VNets erscheinen von selbst in der XGS-Routingtabelle. Statisch geht es auch, bedeutet aber Pflege: Jeder Spoke-Adressraum muss on-prem-seitig nachgetragen werden, und die vergessene Zeile ist der übliche Verdächtige, wenn »das neue VNet nicht erreichbar« ist. Ab dem zweiten Spoke ist BGP deshalb die klare Empfehlung — und die Adressraum-Disziplin bleibt Grundgesetz: Auch Spokes dürfen sich mit keinem On-Prem-Netz überlappen.

Fazit: Determinismus schlägt Verhandlungsglück

Die Azure-Anbindung der XGS ist kein Glücksspiel, auch wenn sporadisch reißende Tunnel diesen Eindruck erwecken — sie ist ein Konfigurationsthema mit drei Hebeln: exakt gespiegelte IKE-Parameter (per eigener IPsec-Richtlinie festgezurrt, PFS beidseitig, Rekeying nur zeitbasiert), eine SKU-Wahl mit Zukunft statt Basic-Sackgasse, und ein Routing, das zur Ausbaustufe passt — statisch für den Einstieg, BGP ab Redundanz und Peering-Landschaften. Dazu die Betriebsreife: MSS-Clamping gegen die MTU-Geister, ein geprobtes Failover statt eines gehofften, und die Diagnose-Werkzeuge beider Seiten im Griff. Wer so baut, bekommt eine Anbindung, die auch das hundertste Rekeying kommentarlos übersteht — und nachts um zwei schläft dann wieder der Admin statt des Tunnels.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie sich die Azure-Anbindung in eine Mehrstandort-Topologie mit Hub-and-Spoke und Zonenmodell einfügt, behandelt der Multi-Site-Artikel [LINK: A1]. Warum nach dem stehenden Tunnel die Namensauflösung das nächste Kapitel ist, klärt [LINK: B10]. Und wie Tunnel-Ereignisse und Firewall-Logs gemeinsam im SIEM landen, zeigt [LINK: B8].