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

Mit einer SD-WAN Connection Group baut Sophos Fusion (ehemals Sophos Central) route-based IPsec-Verbindungen zwischen mehreren verwalteten Firewalls auf. Das spart bei Hub-and-Spoke- oder Full-Mesh-Topologien viel wiederholte Konfigurationsarbeit. Sophos Fusion 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

Rolle Admin oder Super Admin, Central-Orchestration-Lizenz, Sophos Fusion-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 Sophos Fusion 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 Sophos Fusion abmelden. Beim Deregistrieren löscht Sophos Fusion 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 Sophos Fusion automatisch erstellt

Eine SD-WAN Connection Group verwendet route-based IPsec VPN. Sophos Fusion 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. Die Rollen ergeben sich aus den freigegebenen Ressourcen: Die Firewall, die eine Ressource bereitstellt, ist der Responder.

Wenn in einem Full Mesh beide Firewalls Ressourcen bereitstellen, bestimmt Sophos Fusion den Responder alphabetisch nach Hostname. Bei gleichen Hostnamen entscheidet die alphabetische Reihenfolge der Firewall-IDs. Das kann direkte Standortpfade ermöglichen, erzeugt aber deutlich mehr Tunnel und Abhängigkeiten. Hostnamen sollten daher stabil und eindeutig sein; die Rollen werden nicht frei pro Tunnel gewählt.

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 Sophos Fusion-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.
Hinter FW-BE liegt das Filialnetz 10.20.0.0/16, das auf die freigegebene Ressource zugreifen soll.
Hinter FW-ZH liegt das Filialnetz 10.30.0.0/16, das ebenfalls darauf zugreifen soll.
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

Sophos Fusion verwendet für die XFRM-Interfaces /30-Netze. Wenn kein eigener Pool hinterlegt ist, verwendet Sophos Fusion 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. Mehrere Pools sind möglich; ist der erste ausgeschöpft, verwendet Sophos Fusion den nächsten.

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 müssen mindestens SFOS 18.5 MR1 ausführen, Sophos Fusion-verwaltet sein und eine Central Orchestration-Lizenz besitzen. Zum Erstellen der vorausgesetzten Firewall-Gruppe und zum Zugriff auf ihre Policy verlangt Sophos Fusion die Rolle Admin oder Super Admin. Jede Connection Group benötigt mindestens zwei Firewalls, die bereits einer Sophos Fusion-Firewall-Gruppe angehören. Eine nur registrierte, aber keiner Gruppe zugewiesene Firewall lässt sich nicht hinzufügen.

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 Sophos Fusion viele dieser Schritte, die zugrunde liegenden Routing-, Regel- und Rückwegbedingungen bleiben aber gleich.

Connection Group in Sophos Fusion 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, und optional eine Beschreibung. Danach werden mindestens zwei Firewalls ausgewählt. Für jede Firewall legt man fest, welche IP-Adresse oder welcher Netzwerkbereich den übrigen Standorten als Shared resources zur Verfügung steht. Im Beispiel teilt nur FW-HQ das Servernetz; daraus entsteht die Hub-and-Spoke-Rollenverteilung.

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 Sophos Fusion 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

Sophos Fusion prüft die ausgewählten Ressourcen und WAN-Verbindungen auf Konflikte. Ein Konflikt bedeutet nicht automatisch, dass ein Netz falsch ist. Er zeigt, dass Sophos Fusion 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 Sophos Fusion 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 * im Feld Public IP or FQDN for selected WAN link ist nur zulässig, wenn die Remote-Gateway-Firewall als Responder arbeitet und mindestens SFOS 20.0 ausführt. Sie sollte nicht verwendet werden, um eine ungeklärte WAN- oder NAT-Situation zu überdecken. Initiator, öffentliche Erreichbarkeit und Peer-Identität müssen weiterhin eindeutig sein.

Gruppe speichern und Tasks überwachen

Nach dem Speichern erstellt Sophos Fusion die nötigen Aufgaben für alle beteiligten Firewalls. Währenddessen bleibt die bestehende Admin-Sitzung auf mindestens einer Firewall offen. In Sophos Fusion 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 Fusion 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 Sophos Fusion-Task öffnet man jede beteiligte Firewall einzeln. Zu prüfen sind:

Unter Site-to-site VPN > IPsec sind die erwarteten Sophos Fusion-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.

Wenn eine Gruppe sowohl Shared resources als auch Participating networks enthält, erzeugt die Firewall zwei ähnlich aussehende SD-WAN-Routen: eine für die freigegebenen Ressourcen und eine für die teilnehmenden Netze. Das ist erwartetes Deployment-Verhalten und kein Duplikat, das man vorschnell lokal löschen sollte.

Sophos Fusion 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 Sophos Fusion-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

Sophos Fusion unterstützt SD-WAN-Profile für Connection Groups ab SFOS 19.0. Die Routing-Strategie ist ab SFOS 19.5 verfügbar. Sophos Fusion erzeugt das Gateway für den VPN-Tunnel automatisch; als Backup wird ein bereits auf der Firewall vorhandenes Gateway gewählt. Das Profil kann First available gateway oder Load balancing verwenden; bei Load Balancing stehen Round-robin und verschiedene Session-Persistence-Typen zur Wahl. Es ersetzt keine saubere Route und keine funktionierende einzelne VPN-Verbindung.

Die XFRM-Adresse muss in einem /30-Netz liegen. Andernfalls zeigt Sophos Fusion Migrate an und weist beim Migrieren allen Tunneladressen Werte aus 10.252.0.0/15 und 10.254.0.0/16 zu. Diese Migration und jede Profiländerung verändern den Datenpfad: zuerst Backup und Out-of-Band-Zugang sichern, dann einen Standort beziehungsweise Pfad im Wartungsfenster ändern, Sophos Fusion-Tasks und lokale Konfiguration prüfen und erst danach ausrollen.

Vor dem Aktivieren eines Profils wird jeder WAN- und Tunnelpfad einzeln getestet. Danach kontrolliert man mit echtem Traffic, ob neue Verbindungen den vorgesehenen Pfad verwenden und bei einem geplanten Ausfall wie vorgesehen wechseln. Health Checks verwenden Ping oder TCP und höchstens zwei Probe Targets hinter dem Gateway. Ist ein Probe Target eine öffentliche IP-Adresse, benötigt die Ziel-Firewall eine Regel von der VPN- zur WAN-Zone. Erfüllt kein Gateway das Custom SLA, verwendet die Firewall die Strategie First available gateway. Dieses Verhalten wird deshalb in einem geplanten Failover-Test geprüft.

Die lokale Routinglogik, SLA-Werte und Failover-Abnahme stehen unter Sophos Firewall SD-WAN Route konfigurieren. Sophos Fusion 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

Sophos Fusion-Registrierung, gültige Lizenz beziehungsweise Orchestration-Berechtigung und Mitgliedschaft in einer Sophos Fusion-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.

Sophos Fusion 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 nimmt man im Assistenten nur die neu hinzugefügte Ressource, Firewall oder Profiländerung zurück. Anschliessend wartet man auf den Abschluss der Sophos Fusion-Tasks und prüft, ob Tunnel, Routen, Regeln und der zuvor dokumentierte Testfluss wieder dem Ausgangsstand entsprechen. Erst dieses Ergebnis bestätigt den Rollback; eine gespeicherte Änderung allein tut es nicht.

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 Sophos Fusion-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 Sophos Fusion-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. Sophos Fusion 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 Fusion?

Grün bedeutet laut Sophos Fusion, dass alle Firewalls der Connection Group aktiv sind. Orange bedeutet, dass mindestens eine Firewall inaktiv ist, Rot, dass alle inaktiv sind. Diese Tunnelübersicht 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 Fusion 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.