Sophos Central SD-WAN Connection Group einrichten und prüfen

Mit einer SD-WAN Connection Group baut Sophos Central route-based IPsec-Verbindungen zwischen mehreren verwalteten Firewalls auf. Das spart bei Hub-and-Spoke- oder Full-Mesh-Topologien viel wiederholte Konfigurationsarbeit. Central kann Tunnel, XFRM-Interfaces, Routen, Netzwerkobjekte und auf Wunsch passende Firewall-Regeln erzeugen.

Die Automatisierung nimmt dem Administrator jedoch nicht die Netzplanung und Abnahme ab. Ein grüner Gruppenstatus bestätigt vor allem, dass die beteiligten Firewalls verbunden sind. Er beweist noch nicht, dass ein bestimmter Client das entfernte Ziel über die erwartete Regel, Route und NAT-Behandlung erreicht.

Kurzweg zur funktionierenden Connection Group

Central-Orchestration-Berechtigung, Central-Verwaltung und Gruppenmitgliedschaft aller Firewalls prüfen.
Lokale Netze, WAN-Adressen, NAT-Situationen, Redundanz und gewünschte Topologie dokumentieren.
Sicherstellen, dass die XFRM-Adresspools mit keinem produktiven Netz überlappen.
Unter My Products > Firewall Management > SD-WAN Connection Groups eine Gruppe erstellen.
Firewalls, gemeinsam erreichbare Ressourcen, Dienste und optional die automatische Firewall-Regel auswählen.
Von Central erkannte Netz- und WAN-Konflikte einzeln auflösen.
Task Queue und Gruppenstatus beobachten, bis alle beteiligten Firewalls verarbeitet wurden.
Auf jeder Firewall Tunnel, Central_-Objekte, XFRM-Adressen, Routen und Regeln kontrollieren.
Echten bidirektionalen Traffic erzeugen und Firewall Rule ID, Route, NAT und Rückweg prüfen.
Erst nach erfolgreicher Abnahme weitere Ressourcen oder Firewalls aufnehmen.

⚠️ Eine bestehende Connection Group nicht während des laufenden Betriebs unkontrolliert löschen oder eine Firewall aus Central abmelden. Beim Deregistrieren löscht Sophos Central die zugehörige Connection Group und deren automatisch erzeugte Tunnel. Vor solchen Änderungen braucht es ein aktuelles Backup, ein Wartungsfenster und einen dokumentierten Rückfallweg.

Was Central automatisch erstellt

Eine SD-WAN Connection Group verwendet route-based IPsec VPN. Sophos Central erzeugt je nach Topologie die benötigten Verbindungen und Konfigurationsobjekte auf den Mitgliedsfirewalls. Automatisch erzeugte Objekte tragen in der lokalen Konfiguration Namen mit dem Präfix Central_. Dazu gehören unter anderem IPsec-Verbindungen, XFRM-Interfaces, Netzwerkobjekte und Routen.

Bei einer Hub-and-Spoke-Topologie werden die gemeinsam bereitgestellten Ressourcen hinter der Hub-Firewall veröffentlicht. Der Hub antwortet als Remote Gateway auf die von den Spokes initiierten Tunnel. Das passt beispielsweise für eine Zentrale mit Servernetzen und mehrere Filialen.

Bei Full Mesh verbindet Central jede Firewall mit den übrigen Gruppenmitgliedern. Das kann direkte Standortpfade verkürzen, erzeugt aber deutlich mehr Tunnel und Abhängigkeiten. Vor der Wahl sollte deshalb geklärt werden, ob direkte Kommunikation zwischen allen Standorten wirklich benötigt wird.

Die Option zum automatischen Erstellen von Firewall-Regeln ist praktisch, ersetzt aber keine Prüfung der erlaubten Quellen, Ziele und Dienste. Wird sie nicht gewählt, müssen die benötigten Regeln lokal oder über die zuständige Central-Gruppenrichtlinie vorhanden sein. Wird sie gewählt, kontrolliert man die generierten Regeln trotzdem auf Reihenfolge, Umfang und Logging. Die Grundlagen dafür stehen unter Firewall-Regeln auf Sophos Firewall planen und erstellen.

Topologie und Beispielwerte planen

Für ein nachvollziehbares Beispiel verbindet die Connection Group drei Firewalls:

FW-HQ stellt das Servernetz 10.10.0.0/16 bereit.
FW-BE stellt das Filialnetz 10.20.0.0/16 bereit.
FW-ZH stellt das Filialnetz 10.30.0.0/16 bereit.
Als benötigte Dienste gelten zunächst nur HTTPS und RDP zu ausgewählten Systemen im Servernetz.
Das Beispiel verwendet Hub-and-Spoke mit FW-HQ als Hub.

Diese Namen und Netze sind reine Dokumentationswerte. Sie werden durch die tatsächlichen Firewall-Namen, lokalen Ressourcen und Dienste ersetzt. Bei der Planung zählen nicht nur direkte Überschneidungen zwischen den drei Standorten. Auch entfernte Cloud-, Partner-, VPN-Client-, RED- und Managementnetze müssen gegen die geplanten Ressourcen und XFRM-Pools geprüft werden.

XFRM-Adresspools verstehen

Central verwendet für die XFRM-Interfaces /30-Netze. Wenn kein eigener Pool hinterlegt ist, verwendet Sophos Central standardmässig 10.252.0.0/15 und 10.254.0.0/16. Wenn diese Netze in der eigenen Umgebung bereits vorkommen, wird vor dem ersten Aufbau ein freier benutzerdefinierter Pool gewählt.

Die Einstellung findet sich unter:

My Products > Firewall Management > SD-WAN Connection Groups > Add IP Pool

Eine Änderung des Pools wirkt nur auf neue Connection Groups. Bereits bestehende Gruppen behalten ihre zugewiesenen XFRM-Adressen. Ein Poolwechsel ist daher kein nachträglicher Reparaturschritt für eine produktive Gruppe.

Voraussetzungen vor dem Erstellen

Alle beteiligten Firewalls benötigen Central Management und die passende Central-Orchestration-Berechtigung. Ausserdem müssen sie bereits Mitglied einer Firewall-Gruppe in Sophos Central sein. Eine nur registrierte, aber keiner Central-Firewall-Gruppe zugewiesene Firewall steht für die Connection Group nicht wie erwartet zur Verfügung.

Vor dem Erstellen werden zusätzlich geprüft:

Erreichbare öffentliche IP-Adresse oder FQDN je WAN-Pfad
NAT vor einer Firewall und die daraus resultierende Initiator-/Responder-Rolle
eindeutige lokale Ressourcen ohne Überlappung
freie XFRM-Netze
aktive WAN-Links und gewünschte Backup-Gateways
erlaubte Dienste zwischen den Standorten
bestehende lokale IPsec-, Routing-, NAT- und SD-WAN-Konfigurationen
unabhängiger Managementzugang und aktuelles Konfigurationsbackup

Wie eine einzelne route-based Verbindung aufgebaut ist, erklärt Sophos Firewall Site-to-Site IPsec VPN einrichten. In einer Connection Group übernimmt Central viele dieser Schritte, die zugrunde liegenden Routing-, Regel- und Rückwegbedingungen bleiben aber gleich.

Connection Group in Sophos Central erstellen

Firewalls und Ressourcen auswählen

Der Einstieg erfolgt unter:

My Products > Firewall Management > SD-WAN Connection Groups > Create Connection Group

Zuerst erhält die Gruppe einen eindeutigen Namen, etwa HQ-Branches. Danach werden die beteiligten Firewalls und die gewünschte Topologie ausgewählt. Für jede Firewall legt man fest, welche lokalen Netzwerke oder Hosts den übrigen Standorten als Shared resources zur Verfügung stehen.

Ressourcen sollten so eng wie möglich gewählt werden. Statt das gesamte HQ-Netz freizugeben, ist häufig ein Server- oder Applikationsnetz ausreichend. Auch bei den Services sollte nicht vorsorglich Any gewählt werden, wenn nur wenige Anwendungen benötigt werden.

Optional kann Central Firewall-Regeln erstellen. Dabei werden auch Einstellungen für authentifizierte Benutzer und Security Heartbeat berücksichtigt. Vor dem Speichern wird dokumentiert, ob Regeln automatisch erzeugt oder bewusst separat verwaltet werden. So bleibt später klar, ob eine fehlende Regel ein Fehler oder eine Designentscheidung ist.

Netz- und WAN-Konflikte auflösen

Central prüft die ausgewählten Ressourcen und WAN-Verbindungen auf Konflikte. Ein Konflikt bedeutet nicht automatisch, dass ein Netz falsch ist. Er zeigt, dass Central ohne weitere Angabe keine eindeutige Verbindung erzeugen kann.

Je nach Befund stehen beispielsweise diese Entscheidungen zur Verfügung:

ein überlappendes Subnetz für diese Verbindung deaktivieren
dem Netz eine eindeutige NAT-Adresse zuweisen
ein zusätzliches Netzwerkobjekt definieren
den passenden WAN-Link auswählen
ein Backup-Gateway festlegen
die von Central ermittelte Adresse manuell überschreiben

Jede Entscheidung verändert den späteren Datenpfad. NAT-Adressen, WAN-Overrides und deaktivierte Netze werden deshalb nicht nur bis zum grünen Status konfiguriert, sondern in einem Adress- und Routingplan festgehalten.

Eine Wildcard * als öffentliche Adresse oder FQDN ist nur für eine Remote-Gateway-Seite sinnvoll, die als Responder arbeitet. Sie sollte nicht verwendet werden, um eine ungeklärte WAN- oder NAT-Situation zu überdecken. Initiator, DNS, öffentliche Erreichbarkeit und Peer-Identität müssen weiterhin eindeutig sein.

Gruppe speichern und Tasks überwachen

Nach dem Speichern erstellt Central die nötigen Aufgaben für alle beteiligten Firewalls. Währenddessen bleibt die bestehende Admin-Sitzung auf mindestens einer Firewall offen. In Central prüft man Status und Details der Connection Group sowie:

My Products > Firewall Management > Tasks Queue

Pending, Failed oder Partial Success werden nicht einfach übersprungen. Firewall, Entity, Fehlermeldung und Zeitpunkt werden dokumentiert und mit der lokalen Konfiguration verglichen. Sophos Central Firewall Task Queue prüfen erklärt Retry, Skip, Force Sync und die lokale Abnahme im Detail.

Automatisch erzeugte Konfiguration lokal prüfen

Nach einem erfolgreichen Central-Task öffnet man jede beteiligte Firewall einzeln. Zu prüfen sind:

Unter Site-to-site VPN > IPsec sind die erwarteten Central-Verbindungen aktiv.
Unter Network > Interfaces besitzen die XFRM-Interfaces eindeutige /30-Adressen aus dem geplanten Pool.
Unter Routing zeigen die erzeugten Routen über das erwartete XFRM-Interface.
Netzwerk-, Host- und Serviceobjekte mit Central_ stimmen mit den freigegebenen Ressourcen überein.
Automatisch oder separat erzeugte Firewall-Regeln erlauben nur die geplanten Quellen, Ziele und Dienste.
NAT greift nur dort, wo es zur Konfliktauflösung bewusst vorgesehen wurde.
Bei mehreren WAN-Pfaden zeigen Gateway- und SD-WAN-Status die geplante Primär- und Backup-Auswahl.

Central verwaltet die erzeugten Objekte. Manuelle lokale Änderungen an Central_-Objekten können bei einer späteren Gruppenänderung überschrieben werden oder zu Inkonsistenzen führen. Änderungen gehören deshalb zurück in das Connection-Group-Design beziehungsweise in die zuständige Central-Policy.

Echten Traffic abnehmen

Für die Erstabnahme wird pro freigegebenem Ressourcenpfad mindestens ein echter Test durchgeführt. Im Beispiel verbindet sich ein Client aus 10.20.0.0/16 per HTTPS zu einem ausdrücklich freigegebenen Server in 10.10.0.0/16; anschliessend folgt ein Test aus 10.30.0.0/16.

Auf beiden Seiten kontrolliert man:

aktive IKE- und Child-SA
richtige Firewall Rule ID
eingehendes und ausgehendes Interface im Packet Capture
erwartete Source- und Destination-Adresse nach einer bewussten NAT-Übersetzung
Hin- und Rückweg
Anwendungsergebnis statt nur Ping

Ein grüner Tunnel oder Gruppenstatus ist dabei nur ein Zwischenergebnis. Die vollständige Prüfung mit Log Viewer, Policy Test und Packet Capture beschreibt Sophos Firewall Regel testen.

SD-WAN-Profile und Redundanz ergänzen

Central kann SD-WAN-Profile für Connection Groups verwenden, wenn die beteiligten Firewalls und XFRM-Interfaces die Voraussetzungen erfüllen. Ein Profil definiert, wie mehrere Gateways bewertet und verwendet werden. Es ersetzt keine saubere Route und keine funktionierende einzelne VPN-Verbindung.

Vor dem Aktivieren eines Profils wird jeder WAN- und Tunnelpfad einzeln getestet. Danach kontrolliert man mit echtem Traffic, ob neue Verbindungen den vorgesehenen Primärpfad verwenden und bei einem geplanten Ausfall auf den Backup-Pfad wechseln. Health Checks sollten ein Ziel prüfen, das den tatsächlich benötigten Ende-zu-Ende-Pfad sinnvoll abbildet.

Die lokale Routinglogik, SLA-Werte und Failover-Abnahme stehen unter Sophos Firewall SD-WAN Route konfigurieren. Central vereinfacht die Verteilung, ändert aber nicht die Bedeutung von Gateway, Route Precedence, NAT oder Sessionverhalten.

Probleme nach Symptom eingrenzen

Firewall lässt sich nicht auswählen

Central-Registrierung, gültige Lizenz beziehungsweise Orchestration-Berechtigung und Mitgliedschaft in einer Central-Firewall-Gruppe prüfen. Danach kontrollieren, ob ein offener Gruppen- oder Synchronisationstask die Änderung blockiert.

Task ist fehlgeschlagen oder nur teilweise erfolgreich

Nicht sofort neu erstellen. Zuerst Taskdetails und lokale Teilkonfiguration sichern. Häufige Ursachen sind Objekt- oder Netzkonflikte, nicht erreichbare Firewalls, Lizenzgrenzen oder eine Gruppenrichtlinie, die nicht vollständig angewendet werden konnte. Erst nach behobener Ursache gezielt wiederholen.

Tunnel ist aktiv, aber Nutztraffic fehlt

Shared resources, Serviceauswahl und Firewall-Regel mit dem echten Flow vergleichen. Danach Route, XFRM-Interface, NAT, Route Precedence und Rückweg prüfen. Ein Ping ist nur aussagekräftig, wenn ICMP tatsächlich erlaubt und das Ziel dafür vorgesehen ist.

Nur ein WAN- oder Backup-Pfad funktioniert

Öffentliche Adresse beziehungsweise FQDN, NAT vor der Firewall, Gateway-Rolle, WAN-Link und Backup-Gateway kontrollieren. Bei einem SD-WAN-Profil folgen SLA-Ziel und Gatewaystatus. Eine Wildcard-Adresse oder ein grüner Tunnel darf fehlende Ende-zu-Ende-Erreichbarkeit nicht verdecken.

Eine Pooländerung erscheint nicht in der Gruppe

Das ist für bestehende Connection Groups erwartbar. Neue IP-Pools werden erst bei neu erstellten Gruppen verwendet. Eine produktive Gruppe nicht nur wegen einer gewünschten Adressänderung löschen und neu erstellen; zuerst Auswirkungen, Downtime und Rollback planen.

Central zeigt grün, die Anwendung bleibt gestört

Der Gruppenstatus wird nicht als Anwendungsmonitoring interpretiert. Auf beiden Firewalls werden zeitgleich Logs, Rule IDs, Packet Capture, Route und NAT geprüft. Bei HA oder verteiltem Traffic zählt jeweils der Node, der den Testverkehr verarbeitet hat.

Änderungen und Rollback sicher durchführen

Vor jeder grösseren Gruppenänderung werden Connection-Group-Konfiguration, Firewall-Mitglieder, Shared resources, WAN-Zuordnung, XFRM-Pool, automatisch erstellte Regeln und ein funktionierender Testfluss dokumentiert. Zusätzlich wird ein aktuelles Firewall-Backup gesichert.

Bei einer fehlgeschlagenen Erweiterung wird nicht die gesamte Gruppe reflexartig gelöscht. Zuerst entfernt man nur die neu hinzugefügte Ressource, Firewall oder Profiländerung und prüft, ob Central die vorherige Konfiguration wieder vollständig verteilt. Danach folgen lokale Tunnel-, Routen-, Regel- und Traffic-Tests.

Soll die Connection Group vollständig entfernt werden, geschieht dies im Wartungsfenster. Vorher müssen alternative Standortpfade oder manuell verwaltete Tunnel bereitstehen. Nach dem Löschen kontrolliert man auf jeder Firewall, ob die zugehörigen Central_-Objekte entfernt wurden und keine verwaisten Regeln, Routen oder NAT-Abhängigkeiten zurückbleiben.

Checkliste für die Freigabe

Alle Firewalls sind Central-verwaltet, lizenziert und einer Firewall-Gruppe zugeordnet.
Ressourcen, Dienste, WAN-Pfade und XFRM-Netze sind dokumentiert und überschneidungsfrei.
Jeder erkannte Konflikt wurde bewusst aufgelöst.
Alle Central-Tasks sind nachvollziehbar abgeschlossen.
Tunnel, XFRM-Interfaces, Routen, Regeln und Central_-Objekte wurden lokal geprüft.
Ein echter bidirektionaler Anwendungstest funktioniert pro Standortpfad.
Primär- und Backup-Pfad wurden im Wartungsfenster abgenommen.
Backup, Managementzugang und Rückfallweg sind dokumentiert.

Häufige Fragen

Ersetzt eine Connection Group die lokale IPsec- und Routingkenntnis?

Nein. Central automatisiert die wiederholte Erstellung, aber der Datenpfad bleibt route-based IPsec mit XFRM-Interfaces, Routen, Firewall-Regeln und gegebenenfalls NAT. Diese Ebenen müssen für Fehlersuche und Abnahme weiterhin verstanden werden.

Was beweist ein grüner Status in Sophos Central?

Er zeigt, dass die beteiligten Firewalls der Gruppe aktiv sind beziehungsweise der Gruppenstatus insgesamt gesund erscheint. Er beweist nicht, dass jede Ressource über jede Regel und Anwendung erreichbar ist. Dafür braucht es lokale Kontrollen und echte Testverbindungen.

Was passiert beim Deregistrieren einer Firewall?

Sophos Central löscht die zugehörige Connection Group und die von ihr erstellten Tunnel. Eine Firewall wird deshalb nicht als normale Troubleshooting-Massnahme ab- und wieder angemeldet. Diese Änderung gehört in ein Wartungsfenster mit Backup und vorbereitetem Ersatzpfad.