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

1. Rollen, RED-IPs, Standortnetze und erreichbare Serveradresse planen.
2. Auf beiden Firewalls den RED Provisioning Service aktivieren und den RED-Control-Pfad freigeben.
3. Auf der Zentrale das Interface Firewall RED server erstellen.
4. Die erzeugte Provisioning-Datei geschützt zur Gegenstelle übertragen.
5. Auf der Filiale das Interface Firewall RED client erstellen und die Datei importieren.
6. Auf beiden Seiten eine statische Route zum entfernten LAN anlegen, mit der Peer-RED-IP als Gateway und ohne ausgewähltes Interface.
7. Den Nutztraffic auf beiden Firewalls mit engen, geloggten Regeln erlauben; keine verknüpfte NAT-Regel erstellen.
8. 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.

Planung und Design

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, LAN 10.10.0.0/16
• Filiale, Rolle Firewall RED client: öffentliche Adresse 203.0.113.20, LAN 10.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.

Für das Beispiel wird 255.255.255.252 (/30) als RED netmask verwendet. Dieses kleine Transitnetz enthält genau das benötigte Adresspaar. Wer ein anderes freies Transitnetz wählt, ersetzt beide RED-IPs und die Netzmaske konsistent. Überlappen die Standort-LANs, löst RED diesen Adresskonflikt nicht; das Adress- oder NAT-Design muss vor dem Tunnel geklärt werden.

Sophos beschreibt RED-Interfaces ausdrücklich als sichere, verschlüsselte Tunnel. Bei der Registrierung des RED Provisioning Service erzeugt SFOS aus den Registrierungsangaben ein Zertifikat für die sichere RED-Kommunikation. Im dokumentierten Firewall-zu-Firewall-Ablauf wird in der Interface-Maske deshalb weder ein PSK noch ein Zertifikat manuell ausgewählt: Der Server erzeugt eine Provisioning file mit den Konfigurationsdaten für den Client. Die Datei wird trotzdem nur geschützt übertragen. Siehe RED tunnels and provisioning und RED.

Tunnel und Datenpfad konfigurieren

Firewall RED Server erstellen

Auf der Firewall mit stabil erreichbarer öffentlicher Adresse wird zuerst der Server angelegt:

1. Unter System services > RED den RED provisioning service aktivieren.
2. Network > Interfaces öffnen.
3. Add interface > Add RED wählen.
4. Bei Branch name beispielsweise RED-HQ-Branch eintragen.
5. Type auf Firewall RED server setzen.
6. Tunnel ID auf Automatic belassen.
7. Als RED IP 10.255.100.1 eintragen.
8. Als RED netmask 255.255.255.252 eintragen.
9. Eine bewusst gewählte Zone zuweisen. Im Beispiel heisst die eigene Zone RED-S2S.
10. Tunnel compression und MTU zunächst unverändert lassen und speichern.
11. Unter Network > Interfaces im Menü des neuen RED-Interfaces Download provisioning file wählen.

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.

Automatic vermeidet eine versehentlich doppelt vergebene Tunnel ID. Wird sie aus einem zwingenden Betriebsgrund manuell gesetzt, muss sie laut Sophos auf beiden Geräten unbenutzt sein. Beim dokumentierten Client-Ablauf gibt man keine zweite Tunnel ID ein; die Zuordnung kommt aus der Provisioning-Datei des Servers. Tunnel compression kann bei langsamen Internetverbindungen den Durchsatz erhöhen, kostet aber Verarbeitung; sie wird erst nach einer reproduzierbaren Vorher-Nachher-Messung geändert. Auch eine kleinere MTU ist kein pauschaler Fix, sondern wird nur bei nachgewiesenen Fragmentierungs- oder Path-MTU-Problemen getestet.

Firewall RED Client erstellen

Auf der Gegenstelle wird der Client mit der vom Server erzeugten Datei angelegt:

1. Auch hier unter System services > RED den RED provisioning service aktivieren.
2. Unter Network > Interfaces > Add interface > Add RED ein neues Interface erstellen.
3. Als Branch name beispielsweise RED-Branch-HQ verwenden.
4. Type auf Firewall RED client setzen.
5. Bei Firewall IP/hostname die öffentliche Adresse oder den FQDN des Servers eintragen.
6. Unter Provisioning file die Datei der Server-Firewall auswählen.
7. Als RED IP 10.255.100.2 eintragen.
8. Als RED netmask ebenfalls 255.255.255.252 eintragen.
9. Dieselbe geplante Zone RED-S2S zuweisen, Tunnel compression und MTU zunächst unverändert lassen 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.

Die aktuelle Sophos-Anleitung für Site-to-Site RED bestätigt diese Rollen, die Provisioning-Datei und die Empfehlung, den Server nicht per NAT zu übersetzen. Die Client-Firewall initiiert die ausgehende Verbindung; deshalb benötigt die Filiale keine gleichartige eingehende Veröffentlichung.

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, Gateway 10.255.100.2
• Filiale: Ziel 10.10.0.0/16, Gateway 10.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.

RED-Dienst und Firewall-Regeln begrenzen

Zuerst muss der lokale RED-Dienst den Verbindungsaufbau annehmen dürfen. Unter Administration > Device access wird RED nur für die Zone aktiviert, aus der die RED-Verbindung tatsächlich eintrifft. Sind die öffentlichen Quelladressen stabil bekannt, wird unter Local service ACL exception rule > Add stattdessen eine enge Accept-Regel mit Source zone, Source Network / Host, dem WAN-Interface als Destination host und Services: RED erstellt. Lokale Dienste lassen sich nicht mit einer normalen Firewall-Regel steuern. Die Sophos-Hilfe zu Device access und Device Access und Local Service ACL erklären die Trennung.

Danach braucht der weitergeleitete Traffic unter Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule passende Regeln. Für einen von der Zentrale initiierten Testflow sind das bei der eigenen Zone RED-S2S:

• Zentrale: Source zones LAN, Source networks and devices 10.10.0.0/16, Destination zones RED-S2S, Destination networks 10.20.0.0/16, nur die benötigten Services.
• Filiale: Source zones RED-S2S, Source networks and devices 10.10.0.0/16, Destination zones LAN, Destination networks 10.20.0.0/16, dieselben benötigten Services.

Für Verbindungen, die die Filiale initiiert, wird das Paar mit vertauschten Netzen und Zonen ergänzt. Log firewall traffic bleibt während der Abnahme aktiv; die Regelposition wird so gewählt, dass keine allgemeinere Regel vorher matcht. Create linked NAT rule bleibt deaktiviert. Bei dieser normal gerouteten Standortverbindung sollen beide Seiten die echten Quelladressen sehen und einen vollständigen Rückweg besitzen. Eine bestehende, absichtlich erforderliche NAT-Ausnahme wird nicht ungeprüft überschrieben. Die Regelmechanik vertieft Sophos Firewall-Regeln verstehen und richtig konfigurieren.

Abnahme, Troubleshooting und Rollback

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 wird ein neuer Flow erneut erfolgreich aufgebaut; in einem HA-Cluster folgt zusätzlich ein eigener Failover-Test.

Für HA dokumentiert Sophos ausdrücklich eine Verzögerung, bis RED-Tunnel nach einem Failover wieder mit der Auxiliary Firewall verbunden sind. Die Dauer hängt von der Anzahl der Interfaces und weiteren Einstellungen ab und gilt für Site-to-Site RED ebenso wie für RED-Appliances. Deshalb wird kein sofortiger Wiederaufbau versprochen: Failover-Zeitpunkt, Interface-Status und Wiederanlaufzeit werden gemessen, danach wird der Anwendungsflow erneut geprüft. Siehe Add a RED interface.

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.

Die Provisioning-Datei wird abgelehnt: Kontrollieren, ob sie vom aktuell verwendeten Server-Interface stammt und beim Transfer unverändert blieb. Server-Interface nicht vorschnell löschen: Zuerst den Vorzustand sichern, dann bei Bedarf serverseitig eine neue Datei herunterladen und den Client in einem Wartungsfenster sauber neu anlegen.

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.

Kleine Verbindungen funktionieren, grosse Transfers hängen: Packet Capture auf Fragmentierung und ICMP-Meldungen zum Path MTU prüfen. Erst mit diesem Nachweis wird die MTU auf beiden RED-Interfaces schrittweise und gleichartig getestet. Compression und MTU nie gleichzeitig ändern, sonst bleibt die Ursache unklar.

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, geänderte MTU- oder Compression-Werte und gegebenenfalls angelegte Host-/Netzobjekte werden auf ihren dokumentierten Vorzustand zurückgesetzt beziehungsweise entfernt, sofern sie nicht anderweitig verwendet werden.

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.

FAQ