Site-to-Site RED zwischen zwei Sophos Firewalls einrichten
Ein Site-to-Site-RED-Tunnel verbindet zwei Sophos Firewalls direkt miteinander, ohne dass an einem Standort eine SD-RED-Appliance steht. Eine Firewall arbeitet als Firewall RED server und nimmt die Verbindung an. Die andere arbeitet als Firewall RED client und baut den Tunnel zum Server auf.
Dieser aktuelle SFOS-22-Ablauf ist nicht mit einer RED-Betriebsart wie Standard/Unified oder Standard/Split zu verwechseln. Diese Modi gehören zu einer physischen SD-RED. Für ein Firewall-zu-Firewall-Design werden stattdessen auf beiden Firewalls RED-Interfaces, statische Routen und passende Firewall-Regeln eingerichtet.
⚠️ Vor der Änderung braucht es auf beiden Firewalls ein aktuelles Backup, eine unabhängige Adminverbindung und einen dokumentierten Rückfallweg. Die öffentliche Adresse des Firewall RED Servers sollte nach Möglichkeit nicht per NAT übersetzt werden, weil die Übersetzung eingehende RED-Verbindungen stören kann.
Der Ablauf in acht Schritten
- Rollen, RED-IPs, Standortnetze und erreichbare Serveradresse planen.
- Auf beiden Firewalls den RED Provisioning Service aktivieren.
- Auf der Zentrale das Interface Firewall RED server erstellen.
- Die erzeugte Provisioning-Datei geschützt zur Gegenstelle übertragen.
- Auf der Filiale das Interface Firewall RED client erstellen und die Datei importieren.
- Auf beiden Seiten eine statische Route zum entfernten LAN anlegen, mit der Peer-RED-IP als Gateway und ohne ausgewähltes Interface.
- Den Nutztraffic auf beiden Firewalls mit engen, geloggten Regeln erlauben und den RED-Dienst nur aus den erforderlichen Zonen freigeben.
- Tunnel, Route, Regelmatch und echten bidirektionalen Traffic getrennt prüfen.
Ein grünes RED-Interface bestätigt nur, dass der Tunnel aufgebaut wurde. Es beweist noch nicht, dass Routing, Firewall-Regeln und Rückweg funktionieren.
Wann Site-to-Site RED passt
Site-to-Site RED ist eine schlanke Möglichkeit, zwei Sophos Firewalls miteinander zu verbinden. Die RED-Provisionierung nimmt einen Teil der klassischen VPN-Aushandlung ab, während die entfernten LAN-Netze weiterhin über normale Routing- und Firewall-Regeln geführt werden.
Für neue Designs sollte trotzdem bewusst zwischen RED und Site-to-Site IPsec entschieden werden. IPsec bietet mehr Profil-, Routing-, Interoperabilitäts- und Redundanzoptionen. Site-to-Site RED ist attraktiv, wenn beide Endpunkte Sophos Firewalls sind und ein einfacher, Sophos-spezifischer Tunnel genügt.
Eine physische SD-RED wird mit Sophos SD-RED einrichten und Fehler beheben konfiguriert. Die RED-Betriebsarten gelten nicht für den hier beschriebenen Firewall-zu-Firewall-Tunnel.
Beispieltopologie planen
Das folgende Beispiel verwendet bewusst Dokumentationsadressen. Sie werden vollständig durch die echten Netze und Adressen der beiden Standorte ersetzt:
- Zentrale, Rolle Firewall RED server: öffentliche Adresse
198.51.100.10, LAN10.10.0.0/16 - Filiale, Rolle Firewall RED client: öffentliche Adresse
203.0.113.20, LAN10.20.0.0/16 - RED-IP der Zentrale:
10.255.100.1 - RED-IP der Filiale:
10.255.100.2
Die beiden RED-IPs bilden das Adresspaar zwischen den Firewalls. Sie dürfen weder mit einem Standort-LAN noch mit einem anderen Interface- oder VPN-Netz kollidieren. Die Client-Firewall muss die öffentliche IP oder den FQDN des Servers zuverlässig erreichen können.
Firewall RED Server erstellen
Auf der Firewall mit stabil erreichbarer öffentlicher Adresse wird zuerst der Server angelegt:
- Unter System services > RED den RED provisioning service aktivieren.
- Network > Interfaces öffnen.
- Add interface > Add RED wählen.
- Bei Branch name beispielsweise
RED-HQ-Brancheintragen. - Type auf Firewall RED server setzen.
- Tunnel ID auf Automatic belassen.
- Als RED IP
10.255.100.1eintragen. - Eine bewusst gewählte Zone zuweisen und speichern.
- Im Menü des neuen RED-Interfaces die Provisioning-Datei herunterladen.
Die Provisioning-Datei gehört zu diesem Tunnel und sollte wie ein sensibles Konfigurationsartefakt behandelt werden. Sie wird über einen geschützten Kanal an die Filiale übertragen und nach dem Import nicht in einem allgemein zugänglichen Download- oder Share-Ordner liegen gelassen.
Die Zone beeinflusst später Regel- und Device-Access-Matches. LAN ist möglich, eine eigene Zone schafft bei mehreren Standorten aber meist die klarere Sicherheitsgrenze. Die allgemeinen Zusammenhänge erklärt Zonen und Interfaces auf Sophos Firewall.
Firewall RED Client erstellen
Auf der Gegenstelle wird der Client mit der vom Server erzeugten Datei angelegt:
- Auch hier unter System services > RED den RED provisioning service aktivieren.
- Unter Network > Interfaces > Add interface > Add RED ein neues Interface erstellen.
- Als Branch name beispielsweise
RED-Branch-HQverwenden. - Type auf Firewall RED client setzen.
- Bei Firewall IP/hostname die öffentliche Adresse oder den FQDN des Servers eintragen.
- Unter Provisioning file die Datei der Server-Firewall auswählen.
- Als RED IP
10.255.100.2eintragen. - Die geplante Zone zuweisen und speichern.
Wenn der Client den Server nur über eine übersetzte oder wechselnde Adresse erreicht, müssen DNS, vorgeschaltetes NAT und der Rückweg besonders sauber getestet werden. Sophos empfiehlt, den Server nach Möglichkeit ohne NAT unter seiner direkt erreichbaren Adresse bereitzustellen.
Statische Routen ohne Interface anlegen
Der Tunnel kennt nach dem Aufbau noch nicht automatisch die LAN-Netze hinter den Firewalls. Deshalb wird auf beiden Seiten eine IPv4-Unicast-Route erstellt:
- Zentrale: Ziel
10.20.0.0/16, Gateway10.255.100.2 - Filiale: Ziel
10.10.0.0/16, Gateway10.255.100.1
Der entscheidende RED-Sonderfall: Bei diesen beiden Routen wird kein Interface ausgewählt. Die Firewall sendet ARP-Anfragen, um das erreichbare RED-Interface für die Peer-Adresse zu bestimmen. Ein nachträglich ausgewähltes Interface kann diesen Mechanismus stören und ist keine Verbesserung.
Die Route wird unter Routing > Static routes > IPv4 unicast route > Add angelegt. Administrative Distance und Metric werden bewusst zum übrigen Routingdesign gewählt. Die allgemeine Feldlogik und die Abnahme mit Route Lookup erklärt Statische Route auf Sophos Firewall einrichten und testen.
Firewall-Regeln und RED-Dienst begrenzen
Auf beiden Firewalls braucht der weitergeleitete Traffic eine passende Regel. Eine pauschale LAN-to-LAN-Regel ist zwar ein einfaches Funktionsbeispiel, für den produktiven Betrieb werden Source-Netz, Destination-Netz und Services enger auf den tatsächlichen Bedarf begrenzt. Logging bleibt für die Abnahme aktiviert.
Für das Beispiel bedeutet das auf der Zentrale eine Regel vom LAN 10.10.0.0/16 zum Filialnetz 10.20.0.0/16. Auf der Filiale wird der benötigte Rück- oder Gegenverkehr passend abgebildet. NAT ist für eine normal geroutete Standortverbindung meist nicht erforderlich; beide Seiten sollen die echten Quelladressen sehen und einen vollständigen Rückweg besitzen. Die Regelmechanik vertieft Sophos Firewall-Regeln verstehen und richtig konfigurieren.
Zusätzlich muss der RED-Dienst für die Zonen erreichbar sein, aus denen die RED-Verbindung eintrifft. Unter Administration > Device access kann RED für eine Zone aktiviert werden. Sind die Quelladressen stabil bekannt, ist eine enge Local service ACL exception rule besser als eine breite Freigabe für die gesamte WAN-Zone. Die Ausnahme gilt nur für den RED-Control-Pfad und ersetzt keine Firewall-Regel für den Standorttraffic. Details stehen unter Device Access und Local Service ACL.
Den Tunnel kontrolliert abnehmen
Die Abnahme beginnt mit einem einzelnen, zeitlich dokumentierten Testflow. Zuerst wird geprüft, ob beide RED-Interfaces aktiv sind und ob Route Lookup für eine Zieladresse im entfernten LAN den erwarteten Pfad liefert. Danach muss der Flow auf beiden Firewalls die vorgesehene Rule ID treffen.
Ein Packet Capture auf Sophos Firewall zeigt, ob das Paket auf der Quellseite in das RED-Interface gelangt, auf der Gegenstelle ankommt und zum Ziel-LAN weitergeleitet wird. Der Rückweg wird separat geprüft. Ein Ping allein reicht nicht, wenn die produktive Anwendung TCP oder UDP mit anderen Ports verwendet.
Erfolg bedeutet deshalb gleichzeitig:
- RED-Interfaces stehen auf beiden Seiten.
- Route Lookup zeigt für beide Richtungen den geplanten Pfad.
- Die erwartete Firewall-Regel matcht auf beiden Firewalls.
- Ein echter Anwendungsflow funktioniert bidirektional.
- Source- und Destination-Adressen erscheinen ohne unbeabsichtigtes NAT.
- Nach einem kontrollierten Neustart oder Failover wird der neue Flow erneut erfolgreich aufgebaut.
Fehler systematisch eingrenzen
Der Client baut den Tunnel nicht auf: RED Provisioning Service, Serveradresse, DNS, Erreichbarkeit, Device Access und die zum Tunnel gehörende Provisioning-Datei prüfen. Eine neue Datei nicht blind mit einer alten Clientkonfiguration mischen.
Der Tunnel steht, aber das entfernte LAN ist nicht erreichbar: Auf beiden Seiten Zielnetz und Peer-RED-IP der statischen Route kontrollieren. Bei der RED-Sonderroute darf kein Interface ausgewählt sein. Danach Regelmatch und Rückroute prüfen.
Nur eine Richtung funktioniert: Meist fehlt auf einer Firewall die passende Regel oder Route, oder ein Standortnetz wird bereits über einen spezifischeren beziehungsweise höher priorisierten Pfad erreicht. Route Lookup, Packet Capture und echter Rücktraffic müssen zusammenpassen.
Die Verbindung ist instabil: Latenz, Paketverlust, öffentliche Servererreichbarkeit, NAT vor dem Server und Änderungen am WAN-Pfad korrelieren. Node-lokale Logs werden zum exakten Testzeitpunkt gesichert. Die Logdateien und Support-Pfade erklärt Sophos Firewall Service Logs finden und auswerten.
Keine breite Any-Regel, pauschale WAN-Freigabe, Service-Neustarts oder zufällige Änderungen an RED-IPs und Routen ersetzen diese Korrelation. Bleibt der Fehler trotz korrektem Aufbau unklar, werden Backup, SFOS-Build, Zeitstempel, Interface-Status, Routes, Rule IDs, Packet Capture und relevante Logs für Sophos Support gesichert.
Sicher zurückrollen
Wenn der Pilot nicht funktioniert oder das Design verworfen wird, werden zuerst die zusätzlich erstellten Firewall-Regeln deaktiviert und die beiden statischen Routen entfernt. Danach kann das Client- und zuletzt das Server-RED-Interface kontrolliert gelöscht werden. Temporäre Device-Access- oder Local-Service-ACL-Freigaben werden auf ihren dokumentierten Vorzustand zurückgesetzt.
Ein bestehender Managementpfad über genau diesen Tunnel wird nicht entfernt, bevor ein alternativer Zugang positiv getestet ist. Nach dem Rollback werden das normale Routing, die bisherigen Regeln und die Erreichbarkeit beider Firewalls erneut geprüft.