Sophos SD-RED einrichten und Fehler beheben

Mit einer Sophos SD-RED kann man Aussenstellen, Filialen oder kleinere Home-Office-Standorte an eine Sophos Firewall anbinden. Die RED baut einen verschlüsselten Tunnel zur Firewall auf und stellt am entfernten Standort ein Netzwerk bereit, das zentral über die Firewall gesteuert wird.

Der praktische Vorteil: Vor Ort braucht es normalerweise keine komplexe VPN-Konfiguration. Die SD-RED wird mit Internet verbunden, lädt ihre Konfiguration über den Sophos RED Provisioning Service und baut danach den Tunnel zur Sophos Firewall auf. Der Tunnel allein löst aber noch nicht alles. Zonen, Firewall-Regeln, DHCP, VLANs, Routing, DNS und Firmware-Stand müssen ebenfalls passen.

Noch vor der eigentlichen Konfiguration muss die Betriebsart feststehen. Sie bestimmt DHCP, Gateway, Internetpfad, zentrale Kontrolle und das Verhalten bei einem Tunnelausfall. Die Unterschiede und Entscheidungskriterien erklärt Sophos RED Betriebsarten richtig wählen.

Planung und Voraussetzungen

Einordnung: SD-RED und Firewall-zu-Firewall RED

Bei RED müssen zwei aktuelle Einsatzfälle getrennt werden. Dieser Artikel behandelt eine physische SD-RED 20 oder SD-RED 60 am Aussenstandort. Daneben unterstützt SFOS 22 weiterhin einen Site-to-Site-RED-Tunnel zwischen zwei Sophos Firewalls, bei dem eine Firewall als Firewall RED server und die andere als Firewall RED client arbeitet.

Für diesen zweiten Einsatzfall braucht es keine RED-Hardware. Provisioning-Datei, statische Routen ohne ausgewähltes Interface, Regeln auf beiden Seiten und der RED-Service werden im eigenen Ablauf Site-to-Site RED zwischen zwei Sophos Firewalls einrichten erklärt. Die RED-Betriebsarten einer SD-RED gelten dort nicht.

Voraussetzungen am Hauptstandort

Vor dem Anschliessen der RED sollten auf der Sophos Firewall diese Punkte klar sein:

• RED Service ist auf der Firewall aktiviert.
• Öffentliche IP-Adresse oder DNS-/DynDNS-Name der Firewall ist erreichbar.
• RED-Verbindungen zur Firewall sind auf der WAN-Seite erlaubt.
• RED ist unter Administration > Device access für die passende WAN-Zone erlaubt oder über Local Service ACL gezielt freigegeben.
• RED-Interface, Zone und IP-Konfiguration sind geplant.
• Firewall-Regeln vom RED-Netz zu den Zielnetzen sind vorgesehen.
• DHCP, DHCP Relay oder statische Adressierung für Clients hinter der RED ist geklärt.
• RED Firmware Pattern auf der Firewall ist aktuell.
• Backup und Firmware-Stand der Firewall sind vor grösseren Änderungen dokumentiert.

Für RED-Kommunikation sind insbesondere TCP 3400, UDP 3410 und NTP 123 relevant. Diese Verbindungen dürfen unterwegs nicht durch Provider-Router, vorgeschaltete Firewalls oder Security Gateways blockiert werden.

Voraussetzungen am Aussenstandort

Am entfernten Standort braucht die SD-RED eine saubere Internetverbindung. Entscheidend ist nicht nur Bandbreite, sondern vor allem Stabilität, Latenz, Paketverlust und ob der Provider die benötigten Verbindungen erlaubt.

Prüfen sollte man:

• Internetanschluss ist stabil.
• WAN-Port der RED erhält per DHCP eine Adresse oder hat eine korrekte statische Konfiguration.
• Standardgateway ist erreichbar.
• DNS funktioniert.
• NTP ist erreichbar.
• TCP 3400, UDP 3410 und NTP 123 werden nicht blockiert.
• Provider-Router oder vorgeschaltete Firewall macht kein unerwartetes Filtering.
• Bei VLANs ist klar, welcher Port tagged, untagged oder hybrid arbeitet.

Für einfache Standorte reicht oft eine kleine Leitung. In der Praxis sind aber Paketverlust, instabile Consumer-Router, CGNAT, DNS-Probleme oder restriktive Provider-Firewalls häufiger die Ursache als reine Bandbreite.

Provisioning und Inbetriebnahme

Automatisch über den Sophos Provisioning Service bereitstellen

Für das normale Online-Provisioning brauchen Firewall und SD-RED Internetzugang. Die SD-RED muss beim ersten Start per DHCP eine WAN-Adresse erhalten, damit sie ihre Konfiguration herunterladen kann. Für eine statische WAN-Konfiguration ist daher das manuelle USB-Provisioning erforderlich. Auf der Firewall wird unter System services > RED der RED Provisioning Service aktiviert, die Kontaktinformation eingetragen und den Sophos-Nutzungsbedingungen zugestimmt.

Danach wird unter Network > Interfaces > Add interface > Add RED ein Interface angelegt. Branch name, Gerätetyp, Automatically via provisioning service, Firewall-Adresse, Uplink, Betriebsart, RED-Netz, Zone und DHCP werden passend zum Standort gesetzt. Bei einer erstmals verwendeten RED bleibt Unlock code leer. Nach dem Speichern lädt die Firewall die Konfiguration zum Provisioning Service. Die SD-RED ruft sie ab, öffnet den Control-Kanal auf TCP 3400 und danach den Layer-2-Tunnel auf UDP 3410.

Für die eigene RED-Zone unter Network > Zones > Add einen Namen wie RED-Branch eingeben, Type auf LAN oder DMZ setzen und bei Device access nur die tatsächlich benötigten Dienste wählen. Mit Save speichern und diese Zone unter RED network settings am RED-Interface auswählen. In Administration > Device access wird der Dienst RED dagegen für die Zone freigegeben, aus der die RED die Firewall erreicht, normalerweise WAN; mit Apply übernehmen. Die Client-Zone hinter der RED und die Eingangszone des RED-Tunnels sind nicht dasselbe.

Der Provisioning Service erzeugt beim ersten Speichern den gerätespezifischen Unlock Code. Er ist im WebAdmin sichtbar und wird an die unter System services > RED hinterlegte E-Mail-Adresse gesendet. Der Code wird sicher dokumentiert, weil er beim Verschieben der RED auf eine andere Firewall wieder benötigt wird. Beim Löschen des Interfaces zeigt WebAdmin den Code nochmals an. Fehlt er, muss Sophos Support einbezogen werden.

Globale RED-Schutzvorgaben bewusst setzen

Bei der ersten Aktivierung unter System services > RED erzeugt SFOS aus Organization name, City, Country und Email ein Zertifikat für die RED-Kommunikation. In Organization name und City dürfen deshalb keine Umlaute oder Sonderzeichen stehen. Die E-Mail-Adresse muss dauerhaft erreichbar sein, weil Sophos neue Unlock Codes dorthin sendet.

Für aktuelle SD-RED 20 und 60 ist TLS v1.2 (strict) and later der sinnvolle Ausgangspunkt. Diese Auswahl verwendet nur die von Sophos empfohlenen TLS-1.2-Cipher. TLS v1.2 and later schliesst zusätzlich Cipher ein, die Sophos nicht empfiehlt, und wird nicht ohne einen belegten Kompatibilitätsgrund gewählt. Nach einer Umstellung werden alle produktiven RED-Tunnel kontrolliert neu verbunden und getestet.

Automatic device deauthorization verhindert, dass eine lange getrennte RED unbegrenzt autorisiert bleibt. Die Frist muss zum eigenen Störungs- und Ersatzprozess passen: Nach Ablauf wird das Gerät nicht gelöscht, das RED-Interface muss unter Network > Interfaces aber ausdrücklich wieder aktiviert werden. Monitoring und Unlock-Code-Dokumentation gehören deshalb zu dieser Schutzfunktion.

Bei SD-RED 20 und 60 bleibt RED unified firmware aktiviert. Ein neues RED-Firmware-Pattern wird unter Backup & firmware > Pattern updates bewusst installiert und nicht automatisch eingespielt. Dafür werden ein Wartungsfenster sowie ein anschliessender Tunnel- und Clienttest eingeplant.

Zum Einrichten Automatic device deauthorization einschalten, die Frist angeben und Apply wählen. Eine nach Ablauf deautorisierte RED unter Network > Interfaces über das Menu rechts am betroffenen Gerät wieder einschalten. Die Schutzfunktion betrifft auch einen Firewall RED Client. RED unified firmware ist standardmässig ausgewählt; bei einer Firewall-Migration wird jedoch die bestehende Einstellung übernommen. Nach einem Factory Reset ist die Option wieder ausgewählt. Deshalb nach Migration oder Reset den tatsächlichen Wert prüfen, nicht nur den Standard annehmen.

SD-RED anschliessen

Typischer Ablauf:

1. WAN-Port der SD-RED mit Provider-Router oder Modem verbinden.
2. LAN-Port mit Testclient, Switch oder lokalem Netz verbinden.
3. SD-RED mit Strom versorgen.
4. Warten, bis die RED startet, Gateway und Internet prüft, die Konfiguration lädt und den Tunnel aufbaut.
5. Auf der Sophos Firewall prüfen, ob das RED-Interface aktiv ist.
6. Testclient hinter der RED anschliessen und IP, DNS, Gateway und Zielzugriff prüfen.

Wenn alle relevanten LEDs grün sind, steht der technische Tunnel. Danach beginnt die eigentliche Netzwerkprüfung: Zone, DHCP, Firewall-Regeln, Rückrouting, DNS und bei Bedarf VLANs.

Manuelles Provisioning mit USB-Stick

Normalerweise wird eine SD-RED über den Sophos RED Provisioning Service bereitgestellt. Manuelles Provisioning per USB-Stick ist sinnvoll, wenn das Gerät in einem privaten oder stark eingeschränkten Netz steht, eine statische WAN-Konfiguration braucht oder der automatische Provisioning-Pfad nicht zuverlässig funktioniert.

Zeitquelle der Firewall und Zeitversorgung der RED sind nicht dasselbe: Die manuelle RED-Anleitung für SFOS 22 und 23 beschreibt unter Administration > Time die Auswahl Use custom NTP server, die eigene Firewall-IP in Search/Add sowie Add und Apply als Einrichtung eines NTP-Servers für die RED. Die Dokumentation zur Zeiteinstellung beschreibt dieses Feld dagegen als vorgelagerte Zeitquelle für die Uhr der Firewall. Die Rollen passen somit nicht eindeutig zusammen; dieses Rezept ist keine bedingungslose Voraussetzung und kein Nachweis, dass die Firewall NTP für die RED bereitstellt. Ohne bestätigten, für das installierte Release unterstützten Zeitpfad bleibt die funktionierende NTP-Konfiguration unverändert. Jede bestätigte Änderung zuerst gegen den dokumentierten Ausgangszustand planen: Ein Wechsel der NTP-Server verbindet alle IPsec-Verbindungen neu. Bei betroffenen produktiven Verbindungen ein Wartungsfenster und lokalen oder alternativen Managementzugang sicherstellen.

Der Ablauf ist etwas genauer als nur “Provisioning-Datei auf USB kopieren”:

1. Vor dem manuellen Provisioning den unterstützten Zeitpfad für das installierte Release klären und die funktionierenden NTP-Einstellungen sowie Uhrzeit und Synchronisationsstatus der Firewall dokumentieren. Die globale Zeitquelle nicht allein wegen dieses RED-Setups auf die eigene Firewall-IP umstellen; die Einschränkung und die NTP-/HTTPS-Prüfung stehen unten.
2. Unter Network > Zones eine eigene Zone für RED-Standorte vom Typ LAN oder DMZ anlegen. Eine eigene Zone verhindert, dass allgemeine LAN-Regeln ungewollt für die Aussenstelle gelten. Wird stattdessen die Zone VPN verwendet, beantwortet die Firewall DNS-Anfragen der RED-Clients nicht selbst; DHCP muss dann einen anderen erreichbaren DNS-Server verteilen.
3. Unter System services > RED den RED Provisioning Service aktivieren.
4. Unter Network > Interfaces > Add interface > Add RED das RED-Interface anlegen.
5. Bei Device deployment Manually via USB stick wählen.
6. RED-ID, Unlock Code, Uplink, RED network settings, Zone, DHCP und VLANs passend zum Standort eintragen.
7. Unter Network > Interfaces beim RED-Interface das Menu öffnen und die zu diesem Interface gehörende, nach Save erzeugte Provisioning-Datei herunterladen.
8. Datei ins Root-Verzeichnis des USB-Sticks kopieren.
9. RED ausschalten, USB-Stick einstecken und RED wieder einschalten.
10. Nach dem Start prüfen, ob Interface, LEDs, Client-IP, DNS, Firewall-Regel und Zielzugriff passen.

Nach einer bestätigten Zeitänderung die Firewall-Uhr unter Administration > Time nach Aktualisieren von WebAdmin, den Synchronisationsstatus und die IPsec-Verbindungen prüfen. Zusätzlich den RED-Zeitpfad, TLS-Handshake und Tunnelaufbau kontrollieren. Bei fehlgeschlagenem Zeitabgleich oder einer Regression die vorherigen funktionierenden Zeitquellen und Einstellungen unter Administration > Time wiederherstellen und dieselben Prüfungen wiederholen; auch dieser Rückwechsel kann IPsec-Verbindungen neu aufbauen.

Wenn die WAN-Seite der RED per DHCP konfiguriert ist, muss am Aussenstandort tatsächlich ein DHCP-Server antworten. Erhält die RED keine Adresse, kann sie in einer Neustartschleife landen. Bei statischer WAN-Konfiguration müssen IP-Adresse, Gateway, DNS und NTP besonders genau geprüft werden.

Auch eine offline provisionierte RED benötigt eine gültige Uhrzeit innerhalb der Zertifikatsgültigkeit für den TLS-Handshake. Für den direkten Zeitabgleich muss sie 0.sophos.pool.ntp.org bis 3.sophos.pool.ntp.org auflösen und per UDP 123 erreichen können. Gelingt das nicht, versucht sie den Zeitabgleich über HTTPS auf TCP 4444 mit der Firewall. Ist der HTTPS-Admin-Service für WAN unter Administration > Device access nicht freigegeben, kann dieser Fallback ohne gezielte Ausnahme scheitern. Dafür HTTPS nicht pauschal für die WAN-Zone aktivieren: Die Ausnahme erlaubt ebenfalls den HTTPS-Admin-Service und muss eng begrenzt sein.

Vor einer Änderung die vorhandenen Device-Access- und ACL-Einstellungen dokumentieren und prüfen, ob bereits eine passende Ausnahme besteht. Die an der Firewall tatsächlich beobachtete Quelladresse der RED-Verbindung mit Diagnostics > Packet capture bestimmen. Hinter einem NAT-Router ist dies normalerweise die öffentliche NAT-Ausgangsadresse der Aussenstelle, nicht die private WAN-Adresse der RED. Nur einen eindeutig bekannten, möglichst stabilen IP-Host verwenden; bei geteilter NAT-Adresse gilt die Freigabe auch für andere Geräte hinter dieser Adresse. Eine wechselnde oder unbekannte Quelle nicht durch eine Any-Freigabe ersetzen.

1. Administration > Device access > Local service ACL exception rule > Add öffnen und einen eindeutigen Namen vergeben.
2. Source zone auf WAN setzen. Unter Source network or host den IP-Host für die tatsächlich beobachtete Quelladresse wählen; falls nötig über Add einen passenden IP-Host anlegen.
3. Destination host auf den vorgesehenen WAN-Port der Firewall setzen, Services auf HTTPS und Action auf Accept. Mit Save speichern.
4. Die gespeicherte Quellbeschränkung und den Zielhost prüfen. Danach RED-Zeitabgleich, TLS-Handshake und Tunnelaufbau testen und kontrollieren, dass nicht weitere WAN-Quellen für HTTPS freigegeben wurden.

Ist eine neu angelegte Ausnahme nur temporär nötig, nach dem Test beziehungsweise nach Wiederherstellung des direkten NTP-Pfads entfernen. Ist sie wirkungslos oder führt sie zu unerwünschter Freigabe, ebenfalls entfernen; bei Änderung einer vorhandenen Ausnahme deren dokumentierten Ausgangszustand wiederherstellen. Anschliessend Quellbeschränkung, HTTPS-Erreichbarkeit und RED-Tunnel erneut prüfen. Eine dauerhaft benötigte Ausnahme samt NAT-Quelladresse dokumentieren und regelmässig überprüfen.

Status, Updates und Migration

LED-Status verstehen

Die Status-LEDs sind beim RED-Troubleshooting oft der schnellste Einstieg, weil daran erkennbar ist, an welchem Punkt der Startprozess hängen bleibt.

Legende:

• ⚫ aus
• 🟢 leuchtet grün
• 🟢 blinkt grün
• 🔴 leuchtet rot
• 🔴 blinkt rot

Je nach Blickwinkel, Foto oder Umgebungslicht kann eine LED gelblich oder orange wirken. Für die Diagnose zählt vor allem, welche LED leuchtet oder blinkt und ob sie grün oder rot ist.

Normaler Bootvorgang

Wenn alle vier LEDs grün leuchten, aber kein Traffic funktioniert, liegt das Problem meistens nicht mehr beim Tunnelaufbau. Dann sind Firewall-Regeln, DHCP, VLANs, DNS, NAT oder Routing wahrscheinlicher.

Fehlercodes

3G/4G-Failover

Bei SD-RED-Modellen mit 3G/4G-Failover oder entsprechendem Modul können zusätzliche Muster auftreten.

Firmware-Updates kontrollieren

Wenn die LEDs gemeinsam blinken, kann die RED gerade eine Firmware installieren. In dieser Phase sollte man das Gerät nicht ausschalten und nicht vom Internet trennen. Ein Update kann einige Minuten dauern. Die Deutung muss zum konkreten LED-Muster und Modell passen; gleichzeitiges Blinken allein ist keine eindeutige Firmware-Diagnose, wie auch die Failover-Muster zeigen.

Auf der Sophos Firewall sollte man zusätzlich prüfen:

Backup & firmware > Pattern updates

Dort muss das RED Firmware Pattern aktuell sein. Nach Sophos-Angaben dauern Download und Installation fünf bis zehn Minuten. Wenn eine RED in einer Schleife hängt oder nach einem Firewall-Update nicht mehr sauber startet, ist ein veraltetes RED Firmware Pattern ein sinnvoller Prüfschritt. Wie Status, automatisches Herunterladen und die bewusste Installation zusammenspielen, erklärt Sophos Firewall Pattern-Updates konfigurieren und prüfen.

Ein verwandter Betriebswunsch ist in Sophos Firewall Feature Request 2024 beschrieben: Bei RED- und Access-Point-Firmwareupdates fehlen oft direkt sichtbare Release-Notes im Backend. Für produktive Umgebungen sollte man Updates deshalb bewusst planen und nicht unkoordiniert während kritischer Betriebszeiten installieren.

RED-Interface, Zone und Regeln prüfen

Nach erfolgreichem Tunnelaufbau braucht die RED eine saubere Firewall-Konfiguration.

Typische Prüfpunkte:

• RED-Interface ist unter Network > Interfaces aktiv.
• Interface liegt in der richtigen Zone.
• DHCP Server oder DHCP Relay ist korrekt eingerichtet.
• Clients erhalten IP-Adresse, Gateway und DNS.
• Firewall-Regeln erlauben nur die benötigten Ziele.
• Rückrouting zum RED-Netz funktioniert.
• NAT wird nur verwendet, wenn es bewusst geplant ist.
• VLAN-Konfiguration passt zum RED-Modus und zum Switch-Port.

Für den ersten Funktionstest genügt eine eng begrenzte Regel unter Rules and policies > Firewall rules: Source zone ist die eigene Zone RED-Branch, unter Source networks and devices steht das RED-Clientnetz und als Ziel dient nur das benötigte interne Testnetz. Für den Internetzugriff ist eine separate Regel mit der WAN-Zone als Ziel und der vorgesehenen NAT-Behandlung erforderlich. Anschliessend werden Ziele und Dienste auf den produktiven Bedarf begrenzt. Damit testet man den gewünschten Pfad, ohne der Aussenstelle Zugriff auf alle internen Netze zu geben.

Für die Regelgrundlagen passt Sophos Firewall-Regeln verstehen und richtig konfigurieren. Wenn der Tunnel steht, aber Traffic nicht fliesst, sollte man Log Viewer und Packet Capture kombinieren.

Die optionale MAC filtering type kann eine geräteabhängig begrenzte Allow- oder Block-Liste am RED-Netz umsetzen, ersetzt aber keine Firewall-Regel. Remote IP assignment ist ebenfalls kein Standardwert: Die Option weist der Bridge mit dem RED-Tunnel auf der WAN-Seite eine Adresse per DHCP oder statisch zu und wird nur geprüft, wenn Geräte hinter der RED nicht auf ARP-Anfragen antworten. Beide Optionen werden nicht als allgemeiner Performance- oder Konnektivitätsfix aktiviert.

Upgrade- und Migrationsfallen

Site-to-Site RED nicht mit SD-RED verwechseln

Ein Firewall-zu-Firewall-RED-Tunnel ist auch unter SFOS 22 ein unterstützter eigener Aufbau. Er verwendet keine der vier SD-RED-Betriebsarten und wird nicht über DHCP oder die LAN-Ports einer SD-RED definiert. Beim Upgrade werden deshalb beide RED-Arten inventarisiert und danach mit ihrem jeweils passenden Funktionstest geprüft.

Für grössere Upgradeplanung passt zusätzlich Sophos Firewall Firmware Update richtig planen. Der vollständige Firewall-zu-Firewall-Ablauf steht unter Site-to-Site RED zwischen zwei Sophos Firewalls einrichten.

Legacy-Firewall-RED und alte RED-Geräte vor SFOS 22 entfernen

SFOS 22.0 und neuer unterstützt Firewall RED Server Legacy und Firewall RED Client Legacy nicht mehr. Solange eine solche UTM-zu-SFOS-Konfiguration vorhanden ist, sind Upgrade, Restore und Konfigurationsimport auf SFOS 22 blockiert. Das betrifft nicht die aktuellen Typen Firewall RED server und Firewall RED client. Vor dem Upgrade werden alle Abhängigkeiten der Legacy-Interfaces ersetzt, die Interfaces gelöscht und danach ein neues Konfigurationsbackup erstellt.

Auch RED 15, RED 15w und RED 50 sind End-of-Life. Ihre Tunnel verbinden sich seit SFOS 20.0 MR1 nicht mehr. Bei Upgrade oder Restore auf SFOS 22 bleibt die alte Konfiguration zwar sichtbar, wird aber nicht umgesetzt und kann nur noch gelöscht werden. Ein Import ist nicht möglich. Solche Standorte müssen vor der Migration auf SD-RED 20 oder SD-RED 60 umgestellt und mit ihrem echten Datenpfad getestet werden.

Korrigierte /32-Maske bei RED system hosts

Sophos hat die Subnetzmaske automatisch erzeugter RED system host objects in SFOS 21.0 MR2 und 21.5 MR1 auf /32 korrigiert. Wurden solche Objekte zuvor in Regeln oder anderen Konfigurationen für mehrere Host-Adressen verwendet, kann Traffic nach dem Update anders matchen.

Die Abhängigkeiten bereits vor dem Upgrade unter Hosts and services > IP host prüfen: Bei jedem RED-Systemhost Usage öffnen und in den aufgeführten Firewall-Regeln, Routen und sonstigen Konfigurationen den Systemhost durch den passenden IP- oder Network-Host ersetzen. Beispiel: Für die RED-Adresse 192.168.1.1/24 war der Systemhost früher 192.168.1.1/24, jetzt ist er 192.168.1.1/32. Eine Regel oder Route für das ganze Netz muss daher einen ausdrücklichen Network-Host verwenden; der Systemhost deckt nur noch die konfigurierte Interface-IP ab. Nach dem Upgrade die Regelmatches und den Datenpfad erneut testen.

Nach einem Upgrade sollte man deshalb prüfen:

• Werden RED system hosts in Firewall-Regeln verwendet?
• Erwartet eine Regel versehentlich ein Netz statt eines einzelnen Hosts?
• Müssen IP Host oder Network Host Objekte ersetzt werden?
• Stimmen Regel-Matches im Log Viewer noch?

RED und HA-Failover

In HA-Umgebungen sollte man RED-Standorte nach einem Failover bewusst testen. Sophos weist darauf hin, dass RED-Tunnel nach einem HA-Failover nicht immer sofort am Auxiliary-Gerät wieder verbunden sind. Die Dauer hängt unter anderem von Anzahl Interfaces und Konfiguration ab.

Für kritische Standorte sollte man deshalb nicht nur den Firewall-HA-Status prüfen, sondern auch:

• RED-Interface-Status nach Failover
• Client-Zugriff hinter der RED
• relevante Firewall-Regel-Matches
• DNS und DHCP hinter der RED
• Monitoring-Alarmierung bei längerer Tunnelunterbrechung

RED-Durchsatz und Performance prüfen

Sophos nennt für die SD-RED 20 maximal 250 Mbit/s und für die SD-RED 60 maximal 850 Mbit/s Tunneldurchsatz. Das sind Maximalwerte der Plattform und keine Zusage für einen einzelnen SMB-Transfer, einen Browser-Speedtest oder einen einzelnen TCP-Stream. Endpunkte, Datenträger, TCP-Fenster, echte Standortlatenz, Paketverlust, Providerpfad, Firewall-Last und Security-Profile wirken ebenfalls auf das Resultat.

Ein Ping von beispielsweise 8 ms zu einem öffentlichen Speedtest-Server beschreibt nicht automatisch die Latenz zwischen den beiden RED-Standorten. Auch ein Speedtest an jedem Internetanschluss prüft nicht den verschlüsselten End-to-End-Pfad durch den RED-Tunnel. Für diese Frage braucht es einen Testserver in einem LAN und einen Testclient im LAN der Gegenstelle.

RED-Tunnel mit iPerf3 in beiden Richtungen testen

Vor dem Tunneltest sollte mit denselben kabelgebundenen Endpunkten eine lokale Baseline erstellt werden. Danach wird iPerf3 über den RED-Tunnel zuerst mit einem TCP-Stream, dann in Gegenrichtung und zuletzt mit vier parallelen Streams ausgeführt:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 ist nur eine Beispieladresse und muss durch die IP des iPerf3-Servers im entfernten LAN ersetzt werden. Der Test erzeugt bewusst Last und gehört in ein geeignetes Zeitfenster. Installation, temporäre Firewall-Regel, UDP-Tests und die vollständige Auswertung erklärt Sophos Firewall Performance mit iPerf3 richtig testen.

Die drei Resultate beantworten unterschiedliche Fragen:

• Ist bereits die lokale Baseline langsam, zuerst Endpunkte, NIC, Treiber, Kabel, Switch und Datenträger prüfen.
• Ist ein Stream deutlich langsamer als -P 4, begrenzen eher Latenz, TCP-Fenster oder der einzelne Anwendungsfluss. Das ist noch kein Nachweis für ein RED-Limit.
• Bleiben ein und vier Streams in beiden Richtungen an derselben Grenze, physische Links, Providerpfad, Paketverlust, RED-Konfiguration und Firewall-Last untersuchen.
• Ist nur eine Richtung langsam, die jeweiligen Uploadraten, Interface-Zähler, Fehler, Drops und den Rückweg vergleichen.

Ein typisches Muster aus der Praxis wäre etwa 400 Mbit/s mit einem Stream und zwischen 700 Mbit/s und 800 Mbit/s mit -P 4. Das spricht dafür, dass der Pfad deutlich mehr Gesamtkapazität transportieren kann, ein einzelner TCP- oder SMB-Fluss diese aber nicht ausschöpft. Es ist keine Garantie, dass jede Anwendung denselben Mehrstream-Wert erreicht.

Während jedes Laufs sollten tatsächliche Round-Trip-Time und Paketverlust zwischen den Standorten, iPerf-Retransmits, Firewall Rule ID, Security-Profile, Firewall-CPU sowie die Zähler der beteiligten Ports dokumentiert werden. WAN- und LAN-Links müssen tatsächlich mit 1 Gbit/s, Full Duplex und ohne steigende Error- oder Drop-Zähler arbeiten. Speed und Duplex sollte man auf beiden Seiten per Auto-Negotiation belassen, statt nur eine Seite fest auf Gigabit zu setzen.

IPS oder andere Security-Profile werden nicht pauschal abgeschaltet. Für einen A/B-Test wird höchstens eine enge temporäre Regel für die konkrete Testquelle, das Testziel und den iPerf3-Dienst verwendet. Danach wird sie sofort zurückgebaut. Ändert sich das Resultat ohne IPS nicht, ist IPS für genau diesen Testpfad als Ursache weniger wahrscheinlich.

802.3az beziehungsweise EEE wirklich deaktivieren

Sophos empfiehlt für optimale Performance, 802.3az auf den Switches zu deaktivieren, die mit einer SD-RED 20 oder SD-RED 60 verbunden sind. Gemeint ist Energy Efficient Ethernet, kurz EEE. EEE versetzt Teile des Ethernet-PHY bei geringer Linkauslastung in den Zustand Lower Power Idle und spart damit Energie. Es ist nicht dasselbe wie PoE oder 802.3x Flow Control.

Die Einstellung befindet sich nicht im WebAdmin oder in der CLI der Sophos Firewall und auch nicht in einer dokumentierten SD-RED-Maske. Sie wird auf dem unmittelbar angeschlossenen Switch-Port geändert. Das gilt für verwendete LAN-Verbindungen zur RED und, wenn dort ein verwaltbarer Switch oder Router beteiligt ist, auch für den physischen WAN-Link. Auf Geräten anderer Hersteller kann die Option EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az oder Power Saving heissen. Eine universelle CLI gibt es dafür nicht.

Auf einem Sophos Switch geht es über die Seite Port settings:

1. Den Port auswählen, der direkt mit der SD-RED verbunden ist.
2. Edit öffnen.
3. EEE status auf Off setzen.
4. Mit Apply speichern.
5. Linkstatus, ausgehandelte Geschwindigkeit, Duplex und Fehlerzähler kontrollieren und denselben iPerf3-Test wiederholen.

Auf einem aktuellen Sophos Switch lässt sich der Zustand in der CLI lesend anzeigen:

show eee

Für den Beispielport 0/1 wird EEE so deaktiviert:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 muss durch den tatsächlich mit der RED verbundenen Port ersetzt werden. no eee verändert die Portkonfiguration. Wenn der Switch nur über diesen RED-Pfad erreichbar ist, braucht es ein Wartungsfenster sowie lokalen oder alternativen Managementzugang. Je nach Switch und Firmware kann die Änderung eine Link-Neuaushandlung auslösen.

Der Rückweg auf einem Sophos Switch verwendet im selben Interface Configuration Mode eee statt no eee:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Das Abschalten von EEE deaktiviert weder Ethernet noch Gigabit. Der Nachteil ist, dass die PHY-Schaltung in Leerlaufphasen nicht mehr dieselbe Energie spart und der Port dadurch etwas mehr Strom benötigt beziehungsweise Wärme erzeugt. Es gibt keine Garantie für einen bestimmten Mehrdurchsatz. Entscheidend ist der reproduzierbare Vorher-Nachher-Test. Bei einem unmanaged Switch ohne EEE-Option lässt sich die Einstellung nicht zuverlässig ändern; für den Test muss man das Gerät umgehen oder vorübergehend einen verwaltbaren Switch verwenden.

Tunnel Compression und MTU nur kontrolliert ändern

Unter Network > Interfaces lässt sich das RED-Interface bearbeiten. Dort stehen Tunnel compression und MTU. Sophos beschreibt Tunnel Compression als Möglichkeit, RED-Traffic zu komprimieren und den Durchsatz insbesondere auf langsamen Verbindungen zu erhöhen. Bereits komprimierte oder verschlüsselte Daten lassen sich jedoch kaum weiter verkleinern, während die Kompression zusätzliche Rechenarbeit erzeugt. Deshalb ist ein Wert nicht für alle Standorte richtig.

Für einen A/B-Test werden zuerst Ausgangszustand und Messwerte dokumentiert. Danach wird nur Tunnel compression geändert, gespeichert und exakt dieselbe iPerf3-Reihe wiederholt. Anschliessend wird der ursprüngliche Zustand wiederhergestellt oder die nachweislich bessere Variante bewusst dokumentiert. Das Speichern kann den RED-Tunnel kurz unterbrechen, weshalb ein Wartungsfenster und ein alternativer Zugriff sinnvoll sind.

Die MTU ist kein allgemeiner Geschwindigkeitsregler. Sie wird nur untersucht, wenn kleine Pakete funktionieren, grössere Transfers stocken, Fragmentierung sichtbar ist oder iPerf3 viele Retransmits zeigt. Den sicheren DF-Test, die Paketgrössen und den Rückweg erklärt Sophos Firewall MTU und MSS bei VPN-Problemen prüfen. Ohne reproduzierbaren MTU-Befund bleibt der dokumentierte Ausgangswert bestehen.

Troubleshooting

RED-Interface lässt sich nicht anlegen oder bearbeiten

Wenn schon das Anlegen oder Speichern eines RED-Interfaces scheitert, zuerst die Administratorberechtigungen, widersprüchliche Konfigurationen, die RED-ID und den Unlock Code prüfen. Die Firewall selbst muss den Provisioning Server erreichen; ein Test nur im WAN-Netz der RED genügt für diese Frage nicht. In 5. Device Management > 3. Advanced Shell auf der Firewall kann der Verbindungsaufbau geprüft werden:

telnet red.astaro.com 3400

Ein erfolgreicher Verbindungsaufbau bestätigt nur DNS-Auflösung und TCP 3400 von dieser Firewall. Er bestätigt weder die Registrierung noch den Unlock Code. Bei einem Fehlschlag den ausgehenden Pfad der Firewall prüfen; bei erfolgreichem Test die Berechtigungen und die konkrete Konfiguration weiter untersuchen. Ein bereits vorhandenes Interface nicht vorschnell löschen.

RED-IP lässt sich unter SFOS 22.0 MR2 nicht ändern

Unter SFOS 22.0 MR2 Build 546 kann beim Ändern der IP eines bestehenden RED-Interfaces die Meldung Failed to update RED interface erscheinen. Tückisch ist, dass der WebAdmin danach bereits die neue IP anzeigen kann, obwohl die Firewall intern weiterhin die alte Adresse verwendet. Die sichtbare IP allein ist in diesem Fall deshalb noch kein Erfolgsnachweis.

Der von Sophos dokumentierte Workaround ändert zusätzlich den Branch-Namen und speichert das Interface nochmals:

1. Aktuelle RED-IP, Netzmaske, Branch Name und einen vorhandenen RED-DHCP-Bereich dokumentieren.
2. Unter Network > Interfaces das betroffene RED-Interface öffnen und die gewünschte IP eintragen.
3. Erscheint Failed to update RED interface, das Interface erneut öffnen.
4. Branch Name tatsächlich ändern, beispielsweise von Branch-Zurich auf Branch-Zurich-01, und nochmals mit Save speichern.
5. In 5. Device Management > 3. Advanced Shell mit dem lesenden Befehl ifconfig prüfen, ob die neue Adresse am RED-Interface aktiv ist:

ifconfig

Der Interface-Name hängt von der Konfiguration ab und lässt sich unter Network > Interfaces zuordnen. Ein Neustart, Service-Restart oder Löschen des RED-Interfaces gehört nicht zu diesem Workaround.

Liegt die neue RED-IP in einem anderen Netz als der bisherige RED-DHCP-Bereich, deaktiviert SFOS den RED-DHCP-Server. Das ist unabhängig von der Fehlermeldung normales Produktverhalten. Unter Network > DHCP muss man dann den bestehenden Server an das neue Netz anpassen oder einen neuen DHCP-Server anlegen. Lease-Bereich, statische MAC-Zuordnungen, Gateway und DNS müssen zur neuen Adressierung passen.

Abschliessend an einem Client hinter der RED den DHCP-Lease erneuern und IP-Adresse, Gateway, DNS, Tunnelstatus sowie den vorgesehenen Zugriff prüfen. Im Log Viewer sollte der Traffic wieder die erwartete Firewall-Regel treffen. Bleibt die Backend-IP trotz erneutem Speichern alt, ist für NC-184971 derzeit kein veröffentlichter Produktionsfix dokumentiert. Abhängige Regeln oder Interfaces sollten nicht auf Verdacht gelöscht werden; stattdessen die Konfiguration sichern und Sophos Support einbeziehen.

RED erhält keine IP-Adresse

Wenn die RED beim Router-Schritt hängen bleibt oder der Fehlercode auf DHCP beziehungsweise Gateway zeigt, liegt die Ursache meist am Aussenstandort.

Prüfen:

• Gibt der Provider-Router per DHCP eine IP-Adresse aus?
• Ist das Netzwerkkabel am WAN-Port korrekt eingesteckt?
• Ist das Standardgateway erreichbar?
• Wurde eine statische IP-Adresse vollständig eingetragen?
• Stimmen IP-Adresse, Subnetzmaske, Gateway und DNS?
• Blockiert ein vorgeschaltetes Gerät den Traffic?

Wenn DHCP am Aussenstandort nicht funktioniert, kann die RED in einer Neustartschleife landen.

RED erreicht das Internet nicht

Wenn Router oder Gateway erreichbar ist, die Internet-LED aber nicht dauerhaft grün wird, liegt das Problem meist hinter dem lokalen Router.

Prüfen:

• Funktioniert der Internetanschluss mit einem normalen Client?
• Funktioniert DNS?
• Ist NTP erreichbar?
• Werden TCP 3400, UDP 3410 oder NTP 123 blockiert?
• Gibt es einen Proxy oder eine Firewall zwischen RED und Internet?
• Ist der Provideranschluss stabil genug?
• Ist HTTPS auf TCP 443 zum Provisioning Service erreichbar?

Für RED-Provisioning muss die RED den Sophos Provisioning Service erreichen. Sophos dokumentiert dafür *.astaro.com auf TCP 3400 und UDP 3410; die weiteren Herstellerziele und Prüfgrenzen stehen unter Sophos Firewall ausgehende Dienste und Ports prüfen.

Ein Client im selben Netz wie der WAN-Port der RED kann mit telnet red.astaro.com 3400 die DNS-Auflösung und den Aufbau einer TCP-Verbindung prüfen. Eine erfolgreiche Verbindung bestätigt jedoch nur die Erreichbarkeit von TCP 3400; sie sagt nichts über UDP 3410, Provisioning, Authentifizierung oder den RED-Tunnel aus.

Bei erfolgreicher TCP-Verbindung, aber weiterhin fehlgeschlagener Registrierung nennt Sophos auch hohe Netzlast als mögliche Ursache. Nach Prüfung von Internetzugang, DNS und ausgehendem HTTPS auf TCP 443 kann die Registrierung später erneut versucht werden. Der erfolgreiche TCP-Test beweist weder Netzlast noch eine erfolgreiche Registrierung; bleiben Fehler bestehen, die übrigen Ursachen weiter untersuchen.

RED erreicht die Sophos Firewall nicht

Wenn Internet erreichbar ist, der Tunnel aber nicht aufgebaut wird, prüft man die Firewall-Seite.

Prüfen:

• Ist der RED Service auf der Sophos Firewall aktiviert?
• Ist die RED korrekt angelegt?
• Stimmen RED-ID und Unlock Code?
• Ist die öffentliche IP oder der FQDN der Firewall erreichbar?
• Ist Administration > Device access für RED in der passenden WAN-Zone erlaubt?
• Erlaubt eine Local Service ACL den Zugriff vom Aussenstandort?
• Kommen TCP 3400 und UDP 3410 auf der Firewall an?
• Passt bei manuellem Provisioning die Zeit der RED für den TLS-Handshake?
• Erreicht eine Offline-RED NTP oder die geplante Local-Service-ACL-Ausnahme?

In der Advanced Shell kann man prüfen, ob RED-Traffic ankommt:

tcpdump -ni any port 3400 or port 3410

Wenn nichts ankommt, liegt das Problem meistens vor der Firewall: Provider-Router, NAT, vorgeschaltete Firewall, falsche öffentliche IP, FQDN oder Portblockade.

RED startet immer wieder neu

Eine Neustartschleife kann mehrere Ursachen haben:

• instabile Stromversorgung
• defektes Netzteil
• keine IP-Adresse per DHCP
• falsche statische IP-Konfiguration
• blockierte Ports
• veraltetes RED Firmware Pattern
• falscher Unlock Code
• beschädigte oder falsche RED-Konfiguration

Zuerst Stromversorgung, Kabel und DHCP prüfen. Danach RED Firmware Pattern, Port-Erreichbarkeit und Konfiguration kontrollieren. Ein Factory Reset kommt erst infrage, wenn die vorherigen Prüfungen keine Ursache ergeben haben. Zuvor müssen RED-ID, Unlock Code und Interface-Konfiguration gesichert werden. Fehlen diese Angaben, kann für die erneute Autorisierung Sophos Support erforderlich sein.

Tunnel ist grün, aber kein Traffic fliesst

Dieser Fall ist besonders häufig. Die RED ist verbunden, aber Clients erreichen keine internen Systeme oder kein Internet.

Mögliche Ursachen:

• Firewall-Regel fehlt oder steht zu tief.
• RED-Interface liegt in der falschen Zone.
• DHCP verteilt falsches Gateway oder falsche DNS-Server.
• Rückrouting zum RED-Netz fehlt.
• NAT übersetzt Traffic unerwartet.
• VLAN-Tagging passt nicht.
• Security Feature blockiert den Traffic.

Prüfreihenfolge:

1. Client-IP, Gateway und DNS prüfen.
2. Log Viewer auf Source-IP des RED-Clients filtern.
3. Firewall-Regel-Match prüfen.
4. Packet Capture auf RED-Interface und Zielinterface ausführen.
5. Rückweg vom Zielsystem oder Zielnetz prüfen.
6. NAT und Routing kontrollieren.

Bei unklaren Regel-Matches hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Tritt der Ausfall direkt nach einem Reset mit erneuter Provisionierung auf, ist zusätzlich NC-181808 relevant. SFOS 22.0 MR3 Build 576 vom 16. Oktober 2026 behebt laut Release Notes eine Verkehrsblockade durch verbliebene RED_DEVICE_DROP-Einträge. Das ist keine Erklärung für jeden grünen Tunnel ohne Nutztraffic. Reset-/Provisionierungszeitpunkt, SFOS-Build und die zum Test passenden RED- und Paketlogs sichern und bei passendem Verdacht mit Sophos Support abgleichen. Keine internen Einträge auf eigene Faust löschen und nicht wiederholt zurücksetzen; nach einer kontrollierten Korrektur denselben Hin- und Rückweg erneut testen.

Grüne LEDs schliessen eine Blockade des UDP-Datenpfads nicht aus. Für diesen Fall in 5. Device Management > 3. Advanced Shell gezielt den Tunnel-Datenverkehr prüfen:

tcpdump -ni any port 3410

Während eines kontrollierten Clienttests zusätzlich Diagnostics > Packet capture verwenden und klären, ob der Provider oder ein vorgeschaltetes Gerät UDP 3410 blockiert. Ein sichtbares Paket in einer Richtung bestätigt noch keinen funktionierenden Hin- und Rückweg; fehlende Pakete allein identifizieren die blockierende Stelle nicht.

VLAN-Traffic funktioniert nicht

Bei SD-RED 60 sind VLAN-Szenarien möglich, aber Portmodus, VLAN-ID und RED-Modus müssen zusammenpassen.

Die Sophos-Fehlerhilfe für SFOS 22 und 23 beschränkt VLAN-Traffic ausdrücklich auf standard/unified. Zusätzlich müssen die VLANs auch am RED-Gerät angelegt und die RED-LAN-Portmodi passend gesetzt sein. Deshalb die VLAN-Zuordnung nicht allein auf der Firewall oder am Switch prüfen. Die VLAN-Möglichkeiten anderer Betriebsarten nicht aus einem erfolgreichen untagged Test ableiten; die konkrete Betriebsart und das Portdesign anhand der RED-Betriebsarten prüfen.

Prüfen:

• VLAN-IDs stimmen auf Firewall, RED und Switch.
• RED-Port ist als Access, Hybrid oder Tagged Trunk passend konfiguriert.
• Switch-Port am Aussenstandort ist korrekt tagged oder untagged.
• DHCP und DNS sind pro VLAN geplant.
• Firewall-Regeln existieren für die jeweiligen VLAN-Netze.
• Der gewählte RED-Modus unterstützt das gewünschte VLAN-Szenario.

Für die Fehlersuche ist ein einfaches untagged Testnetz hilfreich. Wenn dieses funktioniert, liegt die Ursache meist bei VLAN-ID, Tagging, Portmodus oder Switch-Konfiguration.

RED Access Points bleiben inaktiv

Wenn RED Access Points oder Wi-Fi-Funktionen in VLAN-Szenarien inaktiv bleiben, kann DHCP Option 234 relevant sein. Das betrifft vor allem Fälle, in denen RED- beziehungsweise Access-Point-Kommunikation über VLAN-Interfaces läuft. Sophos nennt für dieses Access-Point-Szenario SD-RED 20 und SD-RED 60.

Diese Option sollte man nur setzen, wenn das konkrete Szenario passt und klar ist, welche Firewall-Interface-IP die Geräte erreichen sollen. Die vollständige Zuordnung von WLAN-Zone, VLAN und DHCP Option 234 steht unter Sophos RED Betriebsarten richtig wählen. Bei allgemeinen RED-Verbindungsproblemen ist Option 234 nicht der erste Schritt.

Sophos beschreibt für diesen speziellen VLAN-Fehler auch eine verzögerte Erholung: Nach 30 Wiederholungen kann die RED eine LAN-IP vom DHCP-Server erhalten und wieder Active erscheinen. Das ist kein Nachweis, dass der gewünschte VLAN-Pfad funktioniert. Deshalb nicht nur auf Active warten, sondern die IP auf dem VLAN-Interface und die gespeicherte Option 234 prüfen.

Abhilfe unter SFOS 23: Die folgenden Schritte gelten für RED Access Points, die in einem VLAN konfiguriert sind, nach einem Neustart als Inactive angezeigt werden und für deren VLAN DHCP Option 234 fehlt:

1. Network > DHCP öffnen und den DHCP-Server bearbeiten, der für das VLAN des RED Access Points konfiguriert ist.
2. Unter DHCP options zuerst nach Code 234 suchen und den bisherigen Wert oder das Fehlen der Option dokumentieren. Eine vorhandene funktionierende Option nicht blind überschreiben und keine zweite konkurrierende Option anlegen. Bei vorhandenem Wert zuerst VLAN- und Interface-Zuordnung klären; die folgenden Ergänzungsschritte gelten nur bei fehlender Option.
3. Unter DHCP options Options auf Custom setzen und bei Code 234 eintragen.
4. Bei Value die IP-Adresse eintragen, die für das mit diesem VLAN verbundene RED-Access-Point-Interface konfiguriert ist. Dieser Wert hängt von der eigenen Interface-Konfiguration ab; gemeint ist nicht die zugewiesene Geräte- oder Client-IP und auch nicht eine beliebige öffentliche Firewall-Adresse.
5. Die Änderungen speichern.

Anschliessend die gespeicherte Option samt Code und Interface-IP im DHCP-Server kontrollieren. Der RED Access Point sollte nach kurzer Zeit eine IP-Adresse auf seinem VLAN-Interface erhalten. Diese Adressvergabe und danach den Status des RED Access Points erneut prüfen. Bleibt er Inactive, zuerst die Zuordnung von DHCP-Server, VLAN und Interface-IP kontrollieren.

Abhilfe unter SFOS 22: Die versionsbezogene Sophos-Anleitung verwendet für denselben VLAN-Fehler die Device Console statt der oben beschriebenen WebAdmin-Eingabe. In der CLI 4. Device Console wählen und vor jeder Änderung die Bindungen des richtigen VLAN-DHCP-Servers lesend prüfen:

system dhcp dhcp-options binding show dhcpname <dhcp server name>

<dhcp server name> durch den Namen des DHCP-Servers im RED-Access-Point-VLAN ersetzen. Die vorhandene Bindung für Option 234 samt Wert oder ihr Fehlen dokumentieren. Eine funktionierende Bindung nicht blind überschreiben und keine konkurrierende Bindung hinzufügen. Ist ein Wert vorhanden, zuerst die VLAN- und Interface-Zuordnung klären. Vor einer neuen Bindung auch den dokumentierten Verwaltungsweg zum Ändern beziehungsweise Entfernen von DHCP-Optionsbindungen für das installierte Release klären. Ist dieser Rückweg unklar, nicht ändern, sondern Sophos Support einbeziehen. Nur bei fehlender Option die Bindung gezielt hinzufügen:

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

<dhcp server name> wie oben ersetzen und <interface ip address> durch die konfigurierte IP des RED-Access-Point-Interfaces, das mit dem VLAN verbunden ist. Nicht die Client-IP einsetzen. Nach der Änderung denselben lesenden system dhcp dhcp-options binding show dhcpname <dhcp server name> erneut ausführen und die gespeicherte Bindung samt Wert prüfen. Anschliessend die IP auf dem VLAN-Interface und den Status prüfen. Die SFOS-22-CLI-Bindung und den SFOS-23-WebAdmin-Weg nicht unkontrolliert parallel anwenden; die zum installierten Release passende Variante wählen und die gespeicherte Option verifizieren.

Rückweg für beide Varianten: Bleibt die Abhilfe wirkungslos oder verschlechtert sich die VLAN-Adressvergabe beziehungsweise der Status, den dokumentierten Ausgangszustand wiederherstellen. Unter SFOS 23 im selben DHCP-Server unter Network > DHCP > DHCP options den vorherigen Wert wieder einsetzen oder nur die neu hinzugefügte Option 234 entfernen und speichern. Unter SFOS 22 dafür den zuvor geklärten, für das installierte Release dokumentierten Verwaltungsweg für DHCP-Optionsbindungen verwenden: die aufgezeichnete Bindung wiederherstellen oder nur die neu angelegte Bindung entfernen. Keine andere Option und keinen DHCP-Server löschen; keine nicht bestätigte Löschsyntax ausprobieren. Danach die gespeicherten Optionen beziehungsweise Bindungen, die IP auf dem VLAN-Interface und den RED-Access-Point-Status erneut prüfen.

Offline Provisioning wird überschrieben

Wenn eine RED zuerst online provisioniert wurde und später per USB offline provisioniert wird, kann eine alte Online-Konfiguration auf dem Sophos Provisioning Server erhalten bleiben. Wenn die RED die Firewall nicht erreicht, kann sie erneut online provisionieren und die USB-Konfiguration überschreiben.

Dann muss die RED erneut offline provisioniert werden. Zusätzlich sollte die alte Online-Konfiguration über Sophos Support entfernt werden.

Diagnose und Betriebscheck

Diagnosepunkte auf der Sophos Firewall

Für RED-Probleme sind diese Stellen hilfreich:

• Network > Interfaces für RED-Interface und Status
• Administration > Device access für RED-Service-Freigaben
• Rules and policies > Firewall rules für Traffic vom RED-Netz
• Diagnostics > Packet capture für Pfadprüfung
• Log viewer mit RED-, Firewall- und System-Events
• Backup & firmware > Pattern updates für RED Firmware Pattern
• Advanced Shell mit tcpdump

Ein erfolgreicher Verbindungsaufbau lässt sich zusätzlich in den gerätespezifischen Logs belegen. In /log/red.log erscheint eine Meldung wie New connection from ... with ID <RED ID>. In /log/red-<RED ID>.log folgen unter anderem connected OK, pushing config und nach einem erneuten Aufbau is now re-connected. Diese Zeilen bestätigen Verbindung und Konfigurationsübergabe, aber noch keinen funktionierenden Nutztraffic. Das vollständige gerätespezifische Log kann Provisionierungs- und Konfigurationsdaten enthalten und wird vor einer Weitergabe bereinigt.

Für Logdateien und Service-Zuordnung passt Sophos Firewall Troubleshooting: Services und Logs.

Startet dagegen die gesamte Firewall mit Failed to start Red server service im Failsafe-Modus, ist das kein gewöhnlicher RED-Tunnelfehler. Das Failsafe-Runbook erklärt die Build-Abgrenzung und die Beweissicherung vor dem Recovery.

Betriebscheckliste

Vor dem Rollout:

• RED-ID und Unlock Code dokumentiert.
• Öffentliche Firewall-Adresse oder FQDN geprüft.
• TCP 3400, UDP 3410 und NTP 123 geprüft.
• RED Service und Device Access auf der Firewall geplant.
• Zone, DHCP, Routing und Firewall-Regeln definiert.
• VLAN-Modus bei Bedarf vorab getestet.

Nach dem Anschliessen:

• LEDs zeigen erfolgreichen Tunnelaufbau.
• RED-Interface ist aktiv.
• Client erhält IP, Gateway und DNS.
• Log Viewer zeigt erwartete Firewall-Regel.
• Interne Zielsysteme und Internetpfad funktionieren wie geplant.
• Firmware Pattern ist aktuell.

Im Betrieb:

• RED-Firmware-Pattern regelmässig prüfen.
• Standortverbindungen nach Firewall-Upgrades testen.
• Firewall-zu-Firewall-RED-Tunnel getrennt von physischen SD-RED-Standorten testen.
• Auswirkungen der korrigierten /32-Maske auf RED system hosts nach einem Upgrade auf SFOS 21.0 MR2 oder 21.5 MR1 prüfen.
• RED-Durchsatz mit lokaler Baseline, einem und vier iPerf3-Streams sowie beiden Richtungen vergleichen.
• 802.3az beziehungsweise EEE auf direkt angeschlossenen Switch-Ports deaktiviert halten und nach Switchwechseln erneut prüfen.
• Tunnel Compression und MTU nur mit dokumentiertem Vorher-Nachher-Test ändern.
• RED-Standorte in Monitoring, Backup- und Notfallplanung aufnehmen.

FAQ