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.

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.

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.

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

1. Auf der Firewall unter Administration > Time prüfen, ob die Firewall als NTP-Server für das RED-Szenario geeignet ist. Beim manuellen Setup muss die RED eine gültige Zeit bekommen, damit der TLS-Handshake zur Firewall funktioniert.
2. Unter Network > Zones eine eigene Zone für RED-Standorte anlegen oder eine bestehende Zone wie VPN oder WiFi verwenden. Die LAN-Zone sollte für RED vermieden werden, damit LAN-Regeln nicht ungewollt für den entfernten Standort gelten.
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. Die erzeugte Provisioning-Datei beim RED-Interface 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.

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.

Offline-REDs brauchen trotzdem eine gültige Zeit. Entweder darf die RED die Sophos-NTP-Server erreichen, oder man plant eine gezielte Local service ACL exception rule, damit die RED von der WAN-Zone zur Firewall sprechen darf. Dabei sollte als Source nur die bekannte RED-IP verwendet werden, Destination ist der WAN-Port der Firewall, Service in diesem Szenario HTTPS, Action Accept. Diese Ausnahme ist kein Ersatz dafür, RED pauschal über WAN zu öffnen.

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.

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

Backup & firmware > Pattern updates

Dort muss das RED Firmware Pattern aktuell sein. 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 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.

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.

RED system hosts nach SFOS 21.5 MR1

Seit SFOS 21.5 MR1 erhalten RED system host objects die korrekte /32-Subnetzmaske. Wenn solche automatisch erzeugten RED-Systemobjekte früher in Regeln oder anderen Konfigurationen für mehr als eine Host-IP verwendet wurden, kann nach dem Update Traffic anders matchen.

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-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?

Für RED-Provisioning muss die RED den Sophos Provisioning Service erreichen. In vielen Umgebungen ist dabei red.astaro.com auf TCP 3400 relevant.

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. Wenn die RED neu angelegt oder zurückgesetzt wird, müssen RED-ID und Unlock Code vorher dokumentiert 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.

VLAN-Traffic funktioniert nicht

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

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.

Diese Option sollte man nur setzen, wenn das konkrete Szenario passt und klar ist, welche Firewall-Interface-IP die Geräte erreichen sollen. Bei allgemeinen RED-Verbindungsproblemen ist DHCP Option 234 nicht der erste Schritt.

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.

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

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.
• RED system hosts nach SFOS 21.5 MR1 auf /32-Auswirkungen 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