Sophos XGS an mehreren Standorten: VPN, RED und Segmentierung richtig aufsetzen

Wer eine Sophos Firewall für mehrere Standorte plant, steht nicht vor einer Kaufentscheidung, sondern vor einer Designentscheidung. Die Kurzfassung vorab: Multi-Site heißt nicht, zehnmal dieselbe XGS zu konfigurieren, sondern einmal ein Design zu bauen, das an jedem Standort funktioniert. Drei Fragen entscheiden über Erfolg oder Regel-Chaos: Erstens die Topologie — Hub-and-Spoke, Mesh oder SD-WAN-Overlay. Zweitens der Transport — RED für kleine Standorte ohne eigene Infrastruktur, IPsec für Standorte mit eigener Firewall, SD-WAN sobald mehrere Leitungen im Spiel sind. Drittens die Segmentierung — Zonen und VLANs, die an jedem Standort gleich heißen, gleiche IDs tragen und demselben IP-Schema folgen. Wer diese drei Punkte sauber festlegt, verwaltet später ein Regelwerk statt zehn Baustellen. Wer sie überspringt, bekommt das, was ich in Projekten regelmäßig vorfinde: historisch gewachsene Einzelkunstwerke, bei denen niemand mehr weiß, warum Regel 247 existiert. Dieser Artikel führt dich durch alle drei Entscheidungen — mit Praxiswerten statt Datenblatt-Prosa.

Ausgangslage: typische Multi-Site-Szenarien im Mittelstand

In der Praxis begegnen mir immer wieder dieselben drei Ausgangslagen. Szenario eins: eine Zentrale mit Servern, ERP und Internetanbindung, dazu zwei bis fünf kleine Außenstellen — Vertriebsbüros, Lager, Werkstätten. Dort stehen ein Switch, ein Drucker und ein Dutzend Clients, aber keine Server. Szenario zwei: mehrere gleichberechtigte Standorte, etwa Produktionswerke, jedes mit eigener lokaler Infrastruktur, eigenen Servern und teils eigener Internetleitung. Und Szenario drei, der Klassiker nach Übernahmen: eine zusammengekaufte Landschaft, in der drei Firewall-Hersteller, vier IP-Konzepte und null Dokumentation aufeinandertreffen.

Alle drei Szenarien haben eines gemeinsam: Sie sind gewachsen, nicht geplant. Jede Firewall wurde einzeln aufgesetzt, meist von der Person, die gerade Zeit hatte. Die Regelwerke driften auseinander, die Zonen heißen überall anders, und spätestens beim ersten Sicherheitsvorfall stellt sich heraus, dass niemand sagen kann, was zwischen Standort C und der Zentrale eigentlich alles erlaubt ist. Übrigens zählt heute fast immer noch ein vierter »Standort« mit: das Azure-VNet. Für das Design behandelst du die Cloud wie eine weitere Niederlassung — die Details der Anbindung habe ich in einem eigenen Artikel beschrieben.

Die gute Nachricht: Die XGS bringt alles mit, was du für ein sauberes Multi-Site-Design brauchst — RED-Tunnel, IPsec, SD-WAN-Funktionen und die zentrale Verwaltung über Sophos Central. Die schlechte Nachricht: Nichts davon ersetzt das Konzept. Werkzeuge hast du genug, jetzt brauchst du einen Plan. Den Gesamtüberblick über die XGS in Microsoft-Umgebungen findest du im Pillar-Artikel [LINK: Pillar].

Topologie-Entscheidung für mehrere Standorte: Hub-and-Spoke, Mesh oder SD-WAN

Bevor du auch nur einen Tunnel konfigurierst, brauchst du die Antwort auf eine Frage: Wie fließt der Verkehr zwischen deinen Standorten? Beim Hub-and-Spoke-Design laufen alle Verbindungen sternförmig über die Zentrale. Jeder Standort hat genau einen Tunnel, das Regelwerk konzentriert sich am Hub, und du behältst an einer Stelle die Kontrolle über alles, was zwischen den Standorten passiert. Der Preis: Sämtlicher Querverkehr zwischen zwei Außenstellen nimmt den Umweg über die Zentrale — inklusive doppelter Latenz und doppelter Bandbreitenlast auf der Hub-Leitung. Und fällt der Hub aus, steht die gesamte Kommunikation.

Das Full-Mesh-Design verbindet dagegen jeden Standort direkt mit jedem anderen. Kurze Wege, kein zentrales Nadelöhr — aber die Tunnelzahl wächst quadratisch: Bei fünf Standorten sind es zehn Tunnel, bei zehn Standorten schon 45. Jeder davon will konfiguriert, überwacht und bei Änderungen angefasst werden. Die erste Skizze stellt beide Topologien nebeneinander und zeigt, warum der Querverkehr die eigentliche Entscheidungsgröße ist.

Skizze 1: Hub-and-Spoke bündelt alles über die Zentrale, Mesh verbindet jeden mit jedem — die Tunnelzahl macht den Unterschied.

In der Praxis fährt der Mittelstand fast immer gut mit Hub-and-Spoke — oder mit einem Partial Mesh als pragmatischem Mittelweg: Grundgerüst sternförmig, plus einzelne Direkttunnel genau dort, wo nennenswerter Querverkehr fließt, etwa zwischen zwei Werken mit gemeinsamer Produktionsplanung. SD-WAN ist übrigens keine dritte Topologie, sondern ein Overlay obendrauf: Die XGS überwacht mehrere Leitungen (Glasfaser, Kabel, LTE) auf Latenz, Jitter und Paketverlust und routet Anwendungen dynamisch über den jeweils besten Pfad. Das ändert nichts an der Frage »Stern oder Netz« — es macht die gewählten Pfade nur schlauer und ausfallsicherer.

RED, IPsec, SSL-VPN: was wofür

Steht die Topologie, folgt die Transportfrage — und hier sortiert sich das Sophos-Portfolio erfreulich klar. RED ist die Antwort für kleine Standorte ohne eigene IT: Box hinschicken, einstecken lassen, fertig. Die RED-Appliance holt sich ihre Konfiguration von der zentralen XGS und baut den Tunnel selbstständig auf — vor Ort muss niemand etwas können außer »Stecker rein«. Die zweite RED-Spielart ist der RED-Site-to-Site-Tunnel zwischen zwei XGS-Firewalls: proprietär, aber in fünf Minuten eingerichtet und im Betrieb angenehm wartungsarm.

IPsec ist der Standard für Standorte, die eine eigene XGS haben — also überall dort, wo lokale Server stehen, lokal geroutet wird oder eigene Security-Policies greifen sollen. IPsec ist herstellerübergreifend, sauber standardisiert und mit routenbasierten Tunnel-Interfaces auf der XGS auch für komplexere Routing-Szenarien gerüstet. SSL-VPN wiederum ist in dieser Liste der falsche Freund: Es ist ein Remote-Access-Verfahren für einzelne Benutzer im Homeoffice, keine Standortkopplung — auch wenn die XGS technisch eine Site-to-Site-Variante anbietet. Der Entscheidungsbaum in der folgenden Skizze bringt die Auswahl auf zwei Fragen herunter.

Skizze 2: Zwei Fragen genügen — braucht der Standort eine eigene Firewall, und hängen dort mehrere Leitungen?

SD-WAN kommt ins Spiel, sobald ein Standort mehr als eine Leitung hat. Die XGS misst die Qualität jedes Pfades und schickt Anwendungen über Performance-Kriterien dorthin, wo sie am besten laufen — die Videokonferenz über die Glasfaser, den Backup-Transfer über die Kabelleitung, und beim Leitungsausfall wandert alles unterbrechungsfrei auf den Ersatzpfad. Die Kernfunktionen dafür stecken bereits im SFOS-Betriebssystem, dazu gleich mehr in den FAQ. Die folgende Vergleichstabelle stellt die vier Varianten den entscheidenden Kriterien gegenüber.

Segmentierungskonzept: Zonen und VLANs standortübergreifend konsistent

Jetzt kommt der Teil, der über die nächsten zehn Jahre Betriebsfreude entscheidet — und der in fast allen gewachsenen Umgebungen fehlt: ein Segmentierungskonzept, das an jedem Standort identisch ist. Die Idee ist simpel: Du definierst einmal zentral, welche Zonen es gibt — etwa LAN, SERVER, VOIP, GAST und OT — und legst für jede Zone eine feste VLAN-ID und ein IP-Schema fest. Bewährt hat sich ein sprechendes Muster wie 10.<Standortnummer>.<VLAN-ID>.0/24: Die Zentrale bekommt 10.1.x.0, Standort Nord 10.2.x.0, und das VoIP-Netz ist überall die .30. Wer eine IP-Adresse sieht, weiß sofort, wo und was sie ist — das ist Gold wert, wenn nachts um zwei ein Incident läuft.

Auf der XGS sind Zonen Sicherheitsobjekte, an denen dein Regelwerk hängt. Und genau hier zahlt die Konsistenz aus: Heißt die Zone SERVER an jedem Standort gleich, kannst du Regeln einmal sauber formulieren und auf alle Standorte übertragen — »GAST darf nirgendwo ins SERVER-Netz« ist dann eine Regel, kein zehnfach unterschiedlich interpretiertes Bauchgefühl. Die dritte Skizze zeigt das Prinzip über drei Standorte hinweg, inklusive des wichtigen Details, dass nicht jeder Standort jede Zone braucht — sie muss nur reserviert und einheitlich benannt sein, falls sie später kommt.

Skizze 3: Dasselbe Zonenmodell an drei Standorten — wo eine Zone fehlt, bleibt sie reserviert statt anders belegt.

Wichtig: Konsistente Segmentierung ist kein Selbstzweck, sondern die Voraussetzung für alles, was danach kommt — sauberes Routing über die Tunnel, nachvollziehbare Firewall-Regeln, funktionierende Auditierbarkeit und im Ernstfall die Möglichkeit, ein befallenes Segment an allen Standorten mit demselben Handgriff zu isolieren. Die folgende Checkliste ist mein Standardwerkzeug, wenn ein neuer Standort ins Design aufgenommen wird.

Zentrale Verwaltung mit Sophos Central

Zehn Firewalls einzeln zu pflegen ist kein Betriebskonzept, sondern eine Beschäftigungstherapie. Sophos Central ist deshalb bei Multi-Site gesetzt: Alle XGS-Geräte hängen in einer Konsole, du siehst Zustand, Firmware-Stände und Alarme auf einen Blick, Backups der Konfigurationen laufen automatisch, und über Firewall-Gruppen verteilst du gemeinsame Objekte und Regeln auf mehrere Geräte gleichzeitig. Neue Standorte bindest du per Zero-Touch-Deployment an: Gerät registrieren, Grundkonfiguration hinterlegen, Box unkonfiguriert an den Standort schicken — beim ersten Einschalten zieht sie sich alles selbst.

Ehrlichkeit gehört aber dazu: Central ist ein sehr gutes Flotten-Cockpit, aber kein Zauberstab, der zehn historisch unterschiedliche Regelwerke nachträglich vereinheitlicht. Die Gruppenverwaltung spielt ihre Stärke genau dann aus, wenn die Standorte demselben Design folgen — womit wir wieder beim Kernthema dieses Artikels wären. Erst das Konzept, dann die Automatisierung. Andersherum automatisierst du nur dein Chaos, dann aber immerhin sehr effizient.

Fallstricke aus der Praxis

Zum Schluss die Klassiker, die in Multi-Site-Projekten immer wieder auf den Tisch kommen — jeder einzelne davon ist vermeidbar, wenn man ihn kennt. Fallstrick eins ist das Internet-Breakout-Design: Schickst du den gesamten Internetverkehr der Außenstellen durch den Tunnel zur Zentrale (zentraler Breakout), bekommst du maximale Kontrolle — und maximale Last auf der Hub-Leitung plus spürbare Latenz für Cloud-Dienste. Gerade Microsoft-365-Verkehr gehört nach Microsofts eigener Empfehlung lokal ausgekoppelt, direkt am Standort ins Internet. Die Mischform ist heute Standard: M365 und vertrauenswürdige SaaS-Dienste lokal raus, der Rest zentral durch die Security-Instanzen.

Fallstrick zwei: MTU und Fragmentierung. Jeder Tunnel kostet Header-Bytes, und irgendwo auf der Strecke steht garantiert eine PPPoE-Leitung. Wenn große Pakete hängen, während Pings fröhlich durchlaufen, ist es fast immer die MTU — MSS-Clamping auf den Tunnel-Interfaces gehört von Anfang an ins Design, nicht erst ins dritte Troubleshooting-Ticket. Fallstrick drei ist das vergessene Active-Directory-Standortkonzept: Wenn Clients am Standort Süd ihre Anmeldung gegen den Domain Controller der Zentrale fahren, obwohl ein lokaler DC daneben steht, sind die Subnetze in AD Sites and Services schlicht nicht gepflegt — und dann fühlt sich trotz bestem Routing alles zäh an.

Und Fallstrick vier, der unangenehmste: Failover, das noch nie jemand getestet hat. Ein Backup-Tunnel, der seit zwei Jahren konfiguriert ist, ist keine Redundanz — er ist eine Hoffnung. Redundanz existiert erst, wenn du den Stecker gezogen und zugesehen hast, was passiert. Plane den Test als festen Projektbestandteil und danach als jährliche Übung ein.

FAQ — häufige Fragen zu Sophos XGS an mehreren Standorten

Sophos RED oder IPsec-VPN — was ist besser für kleine Standorte?

Für kleine Standorte ohne eigene Server und ohne IT-Personal vor Ort ist RED fast immer die bessere Wahl: Die Box wird zentral provisioniert, vor Ort nur eingesteckt, und der Tunnel baut sich selbst auf — inklusive automatischem Reconnect nach Leitungsstörungen. IPsec spielt seine Stärken aus, sobald am Standort eine eigene XGS steht, weil lokale Server, lokales Routing oder eigene Sicherheitsrichtlinien gebraucht werden. Die Faustregel: kein Server am Standort, keine lokale Firewall nötig — dann RED. Steht dort eigene Infrastruktur, nimm eine XGS mit IPsec- oder RED-Site-to-Site-Tunnel. Falsch machst du mit beiden Varianten wenig; teuer wird nur die dritte Option, gar kein Konzept zu haben.

Wie viele Standorte verkraftet ein Hub-and-Spoke-Design?

Mehr, als die meisten denken — die Grenze ist selten die Standortzahl, sondern fast immer der Querverkehr und die Dimensionierung des Hubs. Bis acht bis zehn Standorte ist Hub-and-Spoke im Mittelstand der Normalfall, und auch zwanzig Spokes sind kein Problem, solange der Verkehr überwiegend zur Zentrale fließt und die Hub-Firewall samt Internetleitung die Summe der Standort-Bandbreiten verkraftet. Kritisch wird es, wenn Echtzeitanwendungen wie Telefonie zwischen zwei Außenstellen laufen oder nennenswerter Datenaustausch an der Zentrale vorbei müsste — dann ergänzt du gezielte Direkttunnel zum Partial Mesh, statt gleich alles zu vermaschen. Und: Der Hub braucht zwingend ein Redundanzkonzept, denn er ist der Single Point of Failure des Designs.

Kann ich SD-WAN mit der XGS ohne Zusatzlizenz nutzen?

Die SD-WAN-Kernfunktionen — SD-WAN-Profile, Performance-basierte Pfadauswahl, Link-Monitoring auf Latenz, Jitter und Paketverlust sowie automatisches Failover zwischen mehreren WAN-Leitungen — sind Bestandteil des SFOS-Betriebssystems und funktionieren mit der Base-Lizenz. Du brauchst dafür also keine zusätzliche Subscription, sondern vor allem eine zweite Leitung am Standort. Kostenpflichtig wird es an anderen Stellen: Der Sophos SD-WAN-Orchestrierungskomfort in Central sowie Features aus dem Xstream-Paket sind lizenzgebunden. Wie sich die Sophos-Lizenzbausteine insgesamt sortieren und wo die Grenze zwischen Base und Xstream verläuft, nimmt sich der Lizenzierungs-Artikel [LINK: A2] im Detail vor.

Wie segmentiere ich standortübergreifend konsistent?

Mit einem zentral definierten Zonenmodell, das du an jedem Standort identisch ausrollst: gleiche Zonennamen, gleiche VLAN-IDs, ein durchgängiges IP-Schema wie 10.<Standortnummer>.<VLAN-ID>.0/24. Definiere die Zonen nach Schutzbedarf — etwa LAN, SERVER, VOIP, GAST, OT — und leg eine zentrale Regelmatrix fest, welche Zone mit welcher sprechen darf. Diese Matrix gilt überall; lokale Abweichungen sind dokumentationspflichtige Ausnahmen, keine Gewohnheit. Standorte, die eine Zone nicht brauchen, lassen sie reserviert statt die VLAN-ID anderweitig zu belegen. Der Lohn: kopierbare Regelwerke, sofort lesbare IP-Adressen und die Möglichkeit, im Sicherheitsvorfall ein Segment an allen Standorten mit demselben Handgriff zu isolieren.

Brauche ich an jedem Standort dieselbe XGS-Modellgröße?

Nein — im Gegenteil: Einheitliche Modellgrößen überall sind meist Geldverschwendung. Die Firewall wird pro Standort dimensioniert, nach Benutzerzahl, Traffic-Profil und den dort aktivierten Features; entscheidend ist der Durchsatz mit eingeschalteter TLS-Inspection und IPS, nicht der Datenblattwert. Typisch ist ein gestuftes Bild: eine kräftige XGS in der Zentrale, die als Hub den gesamten Tunnelverkehr und die Security-Last stemmt, mittlere Desktop-Modelle an Standorten mit eigener Infrastruktur und RED-Appliances an Kleinstandorten. Wichtig ist nur, dass der Hub die Summe verkraftet — er ist der Engpass des Designs. Welche Modellgröße konkret zu welcher Benutzerzahl passt, klärt der ehrliche Sizing-Guide [LINK: A3].

Wie manage ich viele XGS zentral?

Über Sophos Central, das bei jeder Multi-Site-Umgebung gesetzt sein sollte: Alle Firewalls laufen in einer Konsole zusammen, mit zentralem Monitoring, automatischen Konfigurations-Backups, orchestrierten Firmware-Updates und Firewall-Gruppen, über die du gemeinsame Objekte und Regeln auf mehrere Geräte verteilst. Neue Standorte kommen per Zero-Touch-Deployment dazu — Box registrieren, Konfiguration hinterlegen, unkonfiguriert versenden. Voraussetzung für den vollen Nutzen ist allerdings ein einheitliches Design: Die Gruppenfunktionen entfalten ihre Wirkung nur, wenn Zonen und Regellogik an allen Standorten gleich aufgebaut sind. Zusätzlich empfehlenswert: ein Wellenmodell für Firmware-Rollouts (Pilotstandort zuerst, Hub zuletzt) und Alarmierung auf Tunnel- und Pfadstatus.

Fazit: erst das Design, dann die Kartons

Multi-Site mit der Sophos XGS ist kein Hexenwerk — aber es ist Designarbeit, und die passiert vor der Bestellung, nicht nach der Lieferung. Die Reihenfolge steht: erst die Topologie (meist Hub-and-Spoke, bei Bedarf mit gezielten Direkttunneln), dann der Transport (RED für Kleinstandorte, IPsec für Standorte mit eigener XGS, SD-WAN bei mehreren Leitungen), dann das Segmentierungskonzept mit einheitlichen Zonen, VLAN-IDs und einem sprechenden IP-Schema. Dazu Sophos Central als Flotten-Cockpit und ein Failover-Test, der diesen Namen verdient — fertig ist eine Umgebung, die auch mit Standort Nummer elf noch Freude macht.

Vertiefend geht es von hier aus weiter: Der Pillar-Artikel [LINK: Pillar] liefert das Gesamtbild der XGS in Microsoft-Umgebungen, der Sizing-Guide [LINK: A3] beantwortet die Modellfrage je Standort, die Azure-Anbindung als »weiterer Standort« steht in [LINK: B6], und wie du mit Geo-Blocking die Angriffsfläche deiner Standort-Gateways verkleinerst, zeigt [LINK: A5].