Sophos RED Betriebsarten richtig wählen

Die Betriebsart einer Sophos SD-RED ist keine kleine Detailoption. Sie legt fest, wer am Aussenstandort DHCP und Gateway bereitstellt, welcher Traffic durch den RED-Tunnel läuft, ob Internetzugriffe zentral geprüft werden und was bei einem Tunnelausfall noch funktioniert. Ein Site-to-Site-RED-Tunnel zwischen zwei Sophos Firewalls ist ein anderer Aufbau und verwendet diese vier Betriebsarten nicht.

Für neue, zentral verwaltete Filialen ist Standard/Unified meistens der klarste Ausgangspunkt. Standard/Split spart Tunnelbandbreite, nimmt den lokalen Internettraffic aber aus der zentralen Kontrolle. Transparent/Split integriert die RED in ein bestehendes Netz. Manual/Split ist ein spezielles Verkabelungs- und Routingdesign für lokale Internetautonomie und kein gewöhnlicher Schnellmodus.

Die Betriebsart sollte vor DHCP, VLANs, Firewall-Regeln und Rollout feststehen. Ein späterer Wechsel verändert den Datenpfad und braucht ein Wartungsfenster mit kontrolliertem Funktionstest.

Diese Anleitung bezieht sich auf SFOS 22.0 und die von dieser Version unterstützten Modelle SD-RED 20 und SD-RED 60. RED 15/15w und RED 50 verbinden sich bereits ab SFOS 20.0 MR1 nicht mehr. Veraltete Firewall-RED-Interfaces zwischen UTM und SFOS müssen vor einem Upgrade auf SFOS 22.0 ersetzt und gelöscht werden; sonst sind Upgrade, Wiederherstellung und Import blockiert. Seit SFOS 21.0 MR2 beziehungsweise 21.5 MR1 erhalten RED-Systemhosts automatisch eine /32-Maske. Unter Hosts and services > IP host muss für jeden RED-Systemhost Usage geöffnet werden. Wo bisher das ganze Interface-Subnetz gemeint war, ist der Systemhost in den abhängigen Regeln und Routen durch den richtigen IP- oder Netzwerkhost zu ersetzen. Diese Migrationsprüfungen sollten deshalb vor einer Hardware- oder Firewall-Migration Teil des Änderungsplans sein.

Die Erläuterungen zu Betriebsarten, LAN-Portmodi und WLAN-Datenpfaden gelten für SFOS 22.0 und 23.0. Die Migrationshinweise im vorherigen Absatz bleiben an die dort ausdrücklich genannten Releases gebunden. Vor einem produktiven Moduswechsel muss das Verhalten auf dem eingesetzten Modell und Release kontrolliert geprüft werden.

Die vier RED-Betriebsarten im Überblick

Die Kurzfassung hilft bei der ersten Auswahl, ersetzt aber nicht den Blick auf Ausfallverhalten, VLANs und Security. Besonders Split bedeutet nicht automatisch Fail-open und Transparent bedeutet nicht automatisch, dass VLAN-Tags durchgereicht werden.

Standard/Unified: Alles über die Zentrale

In Standard/Unified stellt die Sophos Firewall über das RED-Interface DHCP und das Standardgateway bereit. Die SD-RED leitet den gesamten Traffic durch den verschlüsselten Tunnel, einschliesslich des Internetverkehrs der Filiale.

Das bringt die höchste zentrale Kontrolle. Firewall-Regeln, Web Policies, IPS, Application Control, Reporting und zentrale Internetanbindung können am Hauptstandort konsistent umgesetzt werden. Gleichzeitig steigen die Anforderungen an den Tunnel und die zentrale WAN-Verbindung, weil auch gewöhnlicher Internettraffic zweimal über den Standortpfad läuft.

Fällt der RED-Tunnel aus, fehlt den Clients nicht nur der Weg zu internen Netzen. Da ihr Gateway über den Tunnel an der Sophos Firewall liegt, fällt normalerweise auch der Internetzugang aus. Standard/Unified ist deshalb passend, wenn zentrale Security wichtiger ist als lokaler Internetbetrieb während einer Tunnelstörung.

Wann Standard/Unified passt

• Der gesamte Standorttraffic soll zentral geprüft und protokolliert werden.
• DHCP, DNS-Weiterleitung, Regeln und Internetzugang sollen an der Sophos Firewall zusammenlaufen.
• Die zentrale WAN-Kapazität reicht für den zusätzlichen Internettraffic der Filiale.
• Ein Tunnelausfall darf den Standort kontrolliert offline nehmen oder es existiert ein getesteter zweiter RED-Uplink.
• VLANs sollen über eine SD-RED 60 transportiert werden.

Standard/Split: Zentrale Netze durch den Tunnel

Bei Standard/Split bleibt die Sophos Firewall DHCP-Server und Standardgateway für das von der RED bereitgestellte Netz. Nur die unter Split networks eingetragenen Zielnetze laufen durch den Tunnel. Andere Ziele, typischerweise das Internet, verlassen den Standort über den lokalen WAN-Anschluss der RED.

Das entlastet den Tunnel und die Internetleitung der Zentrale. Der Preis dafür ist eine klare Sicherheitsgrenze: Sophos maskiert den lokalen Internettraffic an der RED, aber die zentrale Firewall kann diesen Verkehr nicht mit ihren Firewall-, Web- oder IPS-Regeln prüfen. Aus Sicht der Zentrale sieht dieser Datenpfad nicht wie normaler weitergeleiteter Internettraffic aus.

Für Split networks werden IP-Netze verwendet. FQDN-Hostobjekte sind an dieser Stelle nicht unterstützt. Bereits getaggte VLAN-Frames sind in Standard/Split ebenfalls nicht der richtige Datenpfad. Nur das direkt von der RED bereitgestellte DHCP-Netz erhält über diesen Modus lokalen Internetzugang.

Ein Beispiel für Split network: Die Filiale verwendet 10.20.30.0/24, das benötigte Servernetz der Zentrale 10.10.40.0/24. Nur das zentrale Zielnetz wird als Split-Netz eingetragen; es ist weder der DHCP-Bereich der Filiale noch ein FQDN-Host. Diese privaten Netze sind Beispiele und müssen durch die eigenen, nicht überlappenden Netze ersetzt werden. Danach werden ein Server in diesem Netz, ein lokales Ziel ausserhalb der Liste und ein Internetziel getrennt getestet. Nicht gelistete interne Ressourcen werden nicht automatisch über die Zentrale erreichbar: Sie folgen dem verbleibenden lokalen Pfad.

Auch Standard/Split ist kein allgemeines Fail-open-Design. Fällt der Tunnel aus, verlieren Clients im von der Firewall bereitgestellten Netz nach Sophos-Dokumentation sowohl die zentralen Ziele als auch den Internetzugang. Wer lokalen Internetbetrieb unabhängig vom Tunnel braucht, muss das Design anders planen und testen.

Wann Standard/Split passt

• Die Filiale braucht wenige klar definierte Netze in der Zentrale.
• Der lokale Internet-Breakout ist gewollt und darf ausserhalb der zentralen Sophos-Policies liegen.
• Das entfernte Netz kann von der Sophos Firewall per DHCP verwaltet werden.
• VLAN-Tagging über den RED-Tunnel ist nicht erforderlich.
• Der Ausfallpfad wurde getestet und wird nicht mit Manual/Split verwechselt.

Transparent/Split: RED im bestehenden Netz

Transparent/Split passt in Aussenstellen, in denen Router, DHCP, DNS und Standardgateway bereits vorhanden sind und bestehen bleiben sollen. Die RED arbeitet transparent im vorhandenen Layer-2-Netz. Nur die konfigurierten Split-Netze oder Split-Domänen werden durch den Tunnel zur Zentrale geleitet.

Dieser Modus vermeidet einen Gatewaywechsel für die Clients. Dafür wird die Fehlersuche anspruchsvoller: DHCP, DNS und der normale Internetpfad gehören weiterhin zum lokalen Netz, während ausgewählte Ziele über die RED umgelenkt werden. Der Test muss deshalb getrennt zeigen, welcher Pfad lokal bleibt und welcher tatsächlich im Tunnel landet.

Für interne Namen braucht Transparent/Split zusätzlich einen Split DNS server, also einen DNS-Server im zentralen Netz, den entfernte Clients für die betreffende interne Domäne abfragen können. Eine Split-Domäne ist nicht dasselbe wie ein FQDN-Host unter Split network. Beispielsweise muss für corp.example die Auflösung über den vorgesehenen internen DNS-Server funktionieren und dessen Netz durch den Tunnel erreichbar sein. corp.example ist ein Platzhalter für die eigene interne Domäne. Wenn die Server-IP erreichbar ist, der Name aber nicht, zuerst die tatsächliche DNS-Antwort, den verwendeten Resolver und den Pfad zu diesem Resolver prüfen, nicht die Firewall-Regel pauschal erweitern.

Transparent/Split überträgt keine bereits getaggten VLAN-Frames. Ein 3G/4G-Failover-Uplink steht in diesem Modus ebenfalls nicht zur Verfügung. Für ein WLAN-Modul muss der entfernte DHCP-Server die DHCP-Option 234 mit der IP-Adresse des RED-Interfaces am Firewall-Standort an den Access Point übergeben; gemeint ist weder die AP-Adresse noch eine Filialadresse oder die öffentliche Firewall-Adresse.

Wann Transparent/Split passt

• Der vorhandene Router soll DHCP, DNS und Standardgateway bleiben.
• Nur ausgewählte zentrale Netze oder Domänen sollen über die RED erreichbar sein.
• Die RED kann sauber inline in das bestehende Netz integriert werden.
• Der Standort braucht keine VLAN-Tags durch diesen RED-Datenpfad.
• Lokaler und getunnelter Traffic können mit Packet Capture und echten Zieltests getrennt geprüft werden.

Manual/Split: Lokales Gateway mit statischen Routen

Manual/Split beschreibt bei einer SD-RED vor allem ein bewusst manuell aufgebautes Netzdesign. WAN- und LAN-Seite der RED werden so in die vorhandene Standortinfrastruktur eingebunden, dass der bestehende Router das Standardgateway bleibt. Für die zentralen Netze erhält dieser Router statische Routen zur RED.

Der Vorteil ist die lokale Autonomie: Der normale Internetzugang kann auch dann weiterlaufen, wenn der RED-Tunnel oder die RED selbst ausfällt. Die Kehrseite ist zusätzlicher Planungsaufwand. Rückwege, statische Routen, ARP-Verhalten und die physische Verkabelung müssen exakt stimmen. Ein falsch gesetzter Next Hop kann Zentraltraffic am Tunnel vorbeileiten oder bei einem Ausfall in eine Sackgasse schicken.

Sophos beschreibt dafür eine manuelle physische Bereitstellung und eine RED-Konfiguration nach dem Standard/Unified-Grundschema, während das vorhandene Gateway und die statischen Routen den Split bestimmen. Die Bezeichnung sollte deshalb nicht wie ein unabhängiger, selbsterklärender Schalter behandelt werden.

Die physische Reihenfolge ist wichtig: Zuerst wird der WAN-Port der RED an denselben LAN-Switch angeschlossen, an dem auch die Standortclients hängen. Erst nachdem die RED ihre Standard/Unified-Konfiguration erhalten hat, wird ein RED-LAN-Port ebenfalls mit diesem Switch verbunden. Die RED steht dabei nicht inline vor dem gesamten Standort-LAN. Vor dem zweiten Anschluss müssen die vorhandene DHCP-Zuständigkeit, die RED-Adresse als Next Hop und die Switch-Portzuordnung geklärt sein; ein zusätzlicher, unkoordinierter DHCP-Server darf nicht die Clientkonfiguration übernehmen. Das ist ein geplantes Routingdesign, keine Empfehlung, bei einer beliebigen RED WAN und LAN zusammenzustecken.

Beispiel für den Routingplan: Das vorhandene Standortgateway 10.20.30.1 bleibt das Clientgateway, die geplante RED-LAN-Adresse 10.20.30.2 dient als Next Hop für das zentrale Netz 10.10.40.0/24. Alle Werte sind anpassbare Beispiele; Next Hop und Adressplan müssen zum tatsächlich bereitgestellten RED-Interface passen und dürfen nicht mit vorhandenen Geräten kollidieren. Die Zentrale braucht den Rückweg nach 10.20.30.0/24. Vor dem Rollout werden ARP-Auflösung zum Next Hop, ein zentrales Ziel und lokales Internet geprüft. Bei Tunnel- oder RED-Ausfall muss der Internetpfad über 10.20.30.1 bestehen bleiben, während das zentrale Ziel erwartungsgemäss ausfällt. Bei unerwartetem DHCP-, ARP- oder Routingverhalten den zuletzt hinzugefügten RED-LAN-Anschluss trennen und den dokumentierten Ausgangszustand von Verkabelung und Routen wiederherstellen.

Manual/Split gehört nur in ein dokumentiertes Design mit:

• alternativem lokalem Gateway
• statischen Routen für jedes zentrale Zielnetz
• geprüftem Rückweg von der Zentrale
• unabhängigem Managementzugang
• Test bei aktivem Tunnel, getrenntem Tunnel und ausgeschalteter RED

Layer-2- und Erweiterungsoptionen

Mehrere REDs als gemeinsames Bridge-Netz

Ein Bridged RED setup ist keine fünfte Betriebsart. Dabei fasst man auf der Sophos Firewall mindestens zwei bestehende RED-Interfaces in einer Bridge zusammen. Die entfernten RED-Netze verhalten sich dadurch wie ein gemeinsames LAN, während Firewall-Regeln den Verkehr zwischen den RED-Standorten weiterhin begrenzen können.

Der Aufbau erfolgt unter Network > Interfaces > Add interface > Add bridge. Dort werden ein eindeutiger Name, das Bridge-Interface und die gewünschten RED-Interfaces als Member interfaces mit ihren Zonen gewählt. Vorher müssen Adressplan, DHCP-Zuständigkeit und alle Bridge-Mitglieder zusammenpassen; mehrere unkoordinierte DHCP-Server oder versehentlich doppelte IP-Adressen wirken dann im selben Layer-2-Netz.

Wir empfehlen diesen Aufbau nur, wenn mehrere Filialen tatsächlich dieselbe Broadcast-Domain benötigen. Für normalerweise getrennte Standorte sind geroutete RED-Netze leichter einzugrenzen, zu überwachen und unabhängig zu ändern. Nach dem Speichern werden DHCP, ARP, Standort-zu-Standort-Traffic, die zuständige Firewall-Regel und ein absichtlich gesperrter Gegenverkehr geprüft. Ein grüner RED-Tunnel bestätigt die einzelnen Tunnel, aber noch nicht die Bridge und ihre Regeln.

Zweiter Uplink und zweite Firewall sind keine Betriebsarten

In der RED-Konfiguration können zusätzlich ein zweiter Firewall-Endpunkt und, je nach Modell und Modus, ein zweiter Uplink hinterlegt werden. Diese Optionen ergänzen den gewählten Datenpfad, sie ersetzen ihn nicht.

Ein zweiter Firewall-Endpunkt kann für Failover oder Load Balancing verwendet werden. Ein zweiter Uplink kann den Verbindungsaufbau absichern. Wenn beide Uplinks auf Static stehen, müssen sich die IP-Adressen ihrer DNS-Server unterscheiden; unterschiedliche DNS-Anbieter sind nicht erforderlich. Die RED prüft für die DNS-Auflösung den Routeneintrag des ersten Uplinks. Antwortet dessen Gateway nicht, behandelt sie die DNS-Server-IP als unerreichbar und versucht dieselbe IP-Adresse nicht erneut über den zweiten Uplink.

Für den zweiten Firewall-Endpunkt werden 2nd firewall IP/hostname und Use 2nd IP/hostname for gesetzt; für einen zweiten WAN-Anschluss sind 2nd uplink connection und 2nd uplink mode zuständig. Failover verwendet den zweiten Pfad bei Ausfall des ersten, Load balancing verteilt den Traffic auf beide. Load balancing ist deshalb kein Ersatz für einen getesteten Ausfallpfad. 3G/UMTS failover benötigt einen passenden USB-Dongle und die Mobilfunkparameter des Providers. RED-Firmware 2.0.018 unterstützt den D-Link DWM-222 nicht; eine geplante Mobilfunkreserve muss zur tatsächlichen Firmware und Hardware passen.

Mobilfunkreserve der RED: Providerwerte zuordnen

Wenn das eingesetzte RED-Modell, der Betriebsmodus, die RED-Firmware und der USB-Dongle diese Reserve unterstützen, bearbeitet man das betreffende RED-Interface unter Network > Interfaces und prüft dessen 3G/UMTS failover-Einstellungen. In Transparent/Split steht dieser Mobilfunk-Failover nicht zur Verfügung. Die folgende Zuordnung erklärt die RED-Parameter aus der API-Dokumentation für SFOS 22.0 und 23.0; sie ist weder ein ausführbares XML-Beispiel noch eine Zusage aktueller Mobilfunkunterstützung für SD-RED 20 oder 60. Alte Modellnamen und Mobilfunkoptionen im API-Beispiel ersetzen keine Kompatibilitätsprüfung für die konkrete Kombination.

• UMTS3GFailover: Aktivierung der RED-Mobilfunkreserve; die Dokumentation nennt Enable und Disable, mit Disable als Default. Erst nach der Kompatibilitätsprüfung aktivieren.
• Username und Password: Benutzername und Passwort für den Mobilfunkzugang gemäss Provider, nicht die Zugangsdaten des Firewall-Administrators. Nur vom Provider verlangte Zugangsdaten eintragen; keine erfundenen Standardwerte verwenden.
• Pin: PIN der eingesetzten SIM-Karte, falls dort eine PIN konfiguriert ist. Nicht mit dem RED-Unlock-Code verwechseln und bei unklarer PIN nicht durch wiederholtes Raten eine SIM-Sperre riskieren.
• MobileNetwork: Mobilfunknetztyp. Die dokumentierten Werte sind GSM und CDMA, mit GSM als Default; die Wahl muss zur tatsächlich unterstützten Provider-/Dongle-Kombination passen. Diese alten Auswahlwerte belegen keine heutige Netzverfügbarkeit.
• APN: Access Point Name des Providers für genau diese SIM beziehungsweise diesen Tarif. Er ist nicht die öffentliche Firewall-Adresse und wird nicht aus dem RED-Tunnelnamen abgeleitet.
• DialString: Einwahlzeichenfolge des Providers für die unterstützte Kombination. Den dokumentierten Beispiel-/Defaultwert nicht pauschal übernehmen: Es gibt hier keine universelle Einwahlzeichenfolge für alle Provider und Modems.

Diese Werte gehören zur RED am Aussenstandort: Im dokumentierten API-Beispiel stehen die Providerfelder unter UplinkSettings / FailOverSettings. Cellular WAN an der Sophos Firewall konfiguriert dagegen deren eigene Mobilfunkanbindung; gleichnamige Providerfelder dort richten keine RED-Reserve ein. Die Zuordnung ist eine Eingabehilfe, keine Empfehlung für einen ungeprüften API-Payload oder Serializer.

Vor einer Änderung den funktionierenden RED-Uplink, die bisherige Failover-Einstellung und einen unabhängigen Managementpfad sichern. Providerpasswort, SIM-PIN und Provisioning-Dateien nur geschützt und zugriffsbeschränkt aufbewahren; nicht in Screenshots, Tickets oder Konfigurationsbeispiele kopieren. Fehlt eine bestätigte Hardware-/Firmware-Kompatibilität oder ein Providerwert, die Reserve nicht durch Vermutungen aktivieren, sondern mit Provider beziehungsweise Sophos Support klären. Nach einer freigegebenen Änderung gelten die getrennten Uplink- und Pfadprüfungen unten; bei fehlgeschlagener Abnahme die vorherigen RED-Einstellungen wiederherstellen.

Entscheidend ist der getrennte Test:

1. Zuerst muss der gewählte RED-Modus über den primären Uplink korrekt funktionieren.
2. Danach wird ein kontrollierter Uplink-Failover getestet.
3. Anschliessend werden RED-Status, DHCP, zentrale Ziele und Internetpfad erneut geprüft.
4. In HA-Umgebungen kommt ein separater Firewall-Failover-Test hinzu; der RED-Tunnel braucht nach dem Rollenwechsel Zeit für den erneuten Aufbau.

Ein grüner Tunnelstatus allein beweist weder den richtigen Internetpfad noch funktionierende Security Policies.

VLANs und LAN-Portmodi bei SD-RED 60

Die SD-RED 60 kann VLANs über den Tunnel transportieren, aber nur in Standard/Unified. Zusätzlich wird pro LAN-Port festgelegt, wie die RED mit getaggten und ungetaggten Frames umgeht.

• Tagged: Nur die konfigurierten VLANs werden getaggt weitergegeben. Unkonfigurierte VLANs und ungetaggte Frames werden verworfen. Pro Port können bis zu 64 VLAN IDs eingetragen werden.
• Untagged, drop tagged: Ungetaggte Frames werden dem konfigurierten VLAN zugeordnet; bereits getaggte Frames werden verworfen. Das entspricht einem kontrollierten Access-Port.
• Disabled: Der LAN-Port verwirft den Traffic.
• Untagged: Ungetaggte Frames erhalten die konfigurierte VLAN-ID. Bereits getaggte Frames werden unverändert weitergeleitet. Pro Port ist nur eine VLAN-Konfiguration möglich. Das ist ein Hybrid-Port und kein frei konfigurierbarer Trunk; die erlaubten VLANs müssen weiterhin am angeschlossenen Switch und auf der Firewall kontrolliert werden.

Die obigen Zuordnungen beschreiben vor allem Frames, die am RED-LAN-Port eingehen. Für die Gegenrichtung beschreibt der LAN-Modus Untagged die Ausgabe der konfigurierten VLAN-ID ohne Tag, damit ein Endgerät ohne VLAN-Unterstützung angeschlossen werden kann. Unter LAN VID(s) ist dafür eine ID vorgesehen; bei Tagged werden mehrere IDs kommasepariert eingetragen, beispielsweise 10,20. Die Zahlen sind Beispiele für die eigenen VLANs und müssen mit Switch und Firewall übereinstimmen.

Die Beschreibungen der LAN-Modi sind nicht in jeder Richtung eindeutig: Die Verkehrstabelle beschreibt beim Access-Port das Verwerfen eingehender getaggter Frames, während der Text zu Untagged, drop tagged die Ausgabe passender VLAN-Frames widersprüchlich formuliert. Daraus wird hier keine garantierte Ausgangs- oder Isolationswirkung abgeleitet. Vor produktivem Einsatz werden auf dem tatsächlich eingesetzten Modell und Release erlaubte und nicht erlaubte VLANs sowie ungetaggte Frames in beiden Richtungen geprüft. Vorher Portmodus, LAN VID(s) und Switchkonfiguration sichern und einen unabhängigen Managementpfad vorsehen. Bei unerwartetem Forwarding den Testport aus dem Produktivnetz nehmen, die vorherigen Port- und VLAN-Einstellungen wiederherstellen und erneut prüfen; nicht durch eine pauschale VLAN-Freigabe improvisieren.

Soll ein Gast-VLAN hinter der RED lokal ins Internet, ist Standard/Split kein Ersatz für dieses VLAN-Design. Eine mögliche Architektur ist eine zusätzliche Sophos Firewall auf einer XGS Appliance der Desktop-Klasse am Standort, die diesen Traffic über das lokale Gateway routet und dort schützt. Das ist ein eigener Routing- und Security-Pfad und muss mit getrennten Regeln, Rückwegen und einem Gast-zu-intern-Negativtest geplant werden; die RED-Betriebsart allein liefert diese Trennung nicht.

Die Firewall braucht für jedes verwendete VLAN ein passendes VLAN-Interface auf dem RED-Interface. VLAN ID, IP-Netz, DHCP, RED-Portmodus und Switch-Konfiguration müssen exakt zusammenpassen. Der vollständige Firewall-Ablauf steht in Sophos Firewall VLAN einrichten und testen.

WLAN-Verhalten getrennt planen

Vor der Einrichtung eines WLAN-Moduls muss ein RED-Interface mit einer IP-Adresse vorhanden sein, und die DNS-Auflösung muss auf genau diesem Interface funktionieren. Ein optionales WLAN-Modul der SD-RED 20 oder 60 kann drei unterschiedliche Datenpfade verwenden:

• Separate zone: Der WLAN-Traffic läuft unabhängig vom RED-Betriebsmodus verschlüsselt über VXLAN zur Firewall. Auf der Sophos Firewall muss Separate-zone-Traffic für das RED-Interface ausdrücklich erlaubt sein; daraus folgt keine pauschale WAN-Freigabe.
• Bridge to AP LAN: Das WLAN wird mit dem lokalen LAN des Access Points verbunden.
• Bridge to VLAN: Das WLAN wird einem VLAN zugeordnet; das genaue Verhalten hängt vom RED-Modus und der VLAN-Konfiguration ab.

In Standard/Unified und Standard/Split muss ein passend konfigurierter DHCP-Server auf dem RED-Interface laufen. Im dokumentierten WLAN-Szenario mit Transparent/Split stellt das entfernte Netz DHCP und DNS bereit, und das RED-Interface muss seine IP-Adresse vom entfernten DHCP-Server beziehen. Dieser muss die Option 234 mit der IP-Adresse des RED-Interfaces am Firewall-Standort liefern. Ohne diese Option ist 1.2.3.4 als Fallback dokumentiert: Das ist ein Diagnosehinweis auf die fehlende Option, keine Adresse, die man für den Produktivbetrieb konfiguriert. WLAN, LAN-Portmodus und RED-Betriebsart sollten deshalb als ein gemeinsames Design und nicht als drei unabhängige Dropdowns abgenommen werden.

Bridge to VLAN macht einen Split-Modus nicht zum allgemeinen VLAN-Tunnel: In Standard/Split erreichen die WLAN-Clients gleich getaggte lokale Hosts und, falls auf dem RED-Interface vorhanden, das VLAN-Interface am Tunnelendpunkt. Die konfigurierten Split-Netze bleiben für diese Clients unerreichbar, weil RED sie nur für ungetaggte Pakete routet. In Transparent/Split reicht dasselbe VLAN lokal über die LAN-Ports 1–4 und den WAN-Port; auch hier sind die Split-Netze für diesen WLAN-Datenpfad nicht erreichbar.

Bei Bridge to AP LAN umfasst die lokale Bridge die LAN-Ports 1–4. WLAN-Clients können das RED-Tunnelendpunkt-Interface an der Firewall nur erreichen, wenn Traffic vom RED-Netz zu diesem Interface erlaubt ist. Bei Bridge to VLAN in Standard/Unified erhalten die WLAN-Clients die konfigurierte VLAN-ID und können entsprechend erlaubte Geräte derselben VLAN-ID an den LAN-Ports sowie das passende VLAN-Interface auf dem Firewall-Tunnelendpunkt erreichen. Ein erfolgreicher WLAN-Login bestätigt diese Ziele noch nicht; sie werden mit einem WLAN-Testclient einzeln geprüft.

Betriebsart konfigurieren und sicher testen

Vorbedingungen und exakte Felder

Zuerst wird unter System services > RED der RED-Service aktiviert. Danach wird die Appliance unter Network > Interfaces > Add interface > Add RED angelegt oder bearbeitet. Für RED-Hardware sind insbesondere RED ID, Unlock code, Firewall IP/hostname, Device deployment, Uplink connection, RED operation mode, RED IP, Zone, Configure DHCP, RED DHCP range und bei Split-Modi Split network relevant.

RED ID steht auf dem Gerät und der Verpackung; Tunnel ID muss auf beiden beteiligten Geräten frei sein. Firewall IP/hostname meint die erreichbare öffentliche Adresse beziehungsweise den öffentlichen Namen des Tunnelendpunkts, nicht eine beliebige interne Managementadresse. Bei der erstmaligen Registrierung bleibt Unlock code leer. Für eine bereits verwendete RED beziehungsweise den Wechsel auf eine andere Firewall muss der vorhandene Code gesichert und verwendet werden. Die Kontaktadresse unter System services > RED muss stimmen: Beim Löschen eines Interfaces wird der Code angezeigt und dorthin gesendet. Fehlt der Code, Sophos Support einbeziehen und nicht vorschnell das funktionierende Interface löschen.

Bei der automatischen Bereitstellung muss die RED mindestens einmal in einem Netz mit DHCP und Internetzugang starten, damit sie ihre Konfiguration vom Provisioning-Service laden kann. Statische Uplink-Adressierung setzt die manuelle Bereitstellung per USB-Stick voraus. Auf dem Pfad müssen TCP 3400, UDP 3410 und NTP 123 erlaubt sein: Die RED lädt die Konfiguration über TCP 3400, baut zuerst den Kontrollkanal über TCP 3400 und danach den Layer-2-Datentunnel über UDP 3410 auf. Eine fehlende WAN-DHCP-Adresse führt bei automatischer Bereitstellung zu wiederholten Neustarts.

Bei automatischer Bereitstellung speichert der Provisioning-Service die Firewall-Adresse, WAN- und Mobilfunkparameter, Betriebsart und den Unlock Code. Die RED löst red.astaro.com auf und lädt ihre Konfiguration vom Provisioning-Service. Eine funktionierende RED fragt diesen Dienst nicht dauerhaft ab; bei einer nicht funktionierenden Konfiguration sucht sie dort nach aktualisierten Anweisungen. Die Erreichbarkeit des Provisioning-Service und die Erreichbarkeit des eigentlichen Firewall-Tunnelendpunkts sind deshalb getrennte Prüfungen. Für USB-Bereitstellung unter Network > Interfaces das Menu des richtigen RED-Interfaces öffnen, Download provisioning file wählen und die aktuelle Datei ins Root-Verzeichnis des USB-Sticks kopieren. Die detaillierte Start- und Zeitprüfung steht im verlinkten Setup-Ablauf.

Wir empfehlen eine eigene Zone vom Typ LAN oder DMZ statt der allgemeinen LAN-Zone. So lassen sich Regeln für Filialnetze getrennt pflegen. Wird das RED-Interface durch eine Änderung von RED IP in ein Subnetz verschoben, das den vorhandenen RED DHCP range nicht mehr enthält, schaltet SFOS den RED-DHCP-Server aus. Das muss im Änderungsplan stehen, damit Clients nach dem Moduswechsel nicht unerwartet ihre DHCP-Versorgung verlieren.

Nach einer Änderung von RED IP unter Network > DHCP den bestehenden DHCP-Server anpassen oder einen neuen Server für das neue Netz anlegen. Nicht nur den dynamischen Bereich, sondern auch Dynamic IP lease, Static IP MAC mapping, Gateway, DNS und weitere Optionen prüfen. Ein Clienttest mit erneuerter Lease muss die tatsächlich neuen Werte zeigen, bevor die Filiale wieder freigegeben wird.

Routing, Firewall-Regeln und NAT passend zum Modus

Firewall-Regeln werden unter Rules and policies > Firewall rules zwischen der RED-Zone und den tatsächlich benötigten Zielzonen erstellt. Any für Netze und Dienste eignet sich höchstens für einen zeitlich begrenzten Funktionstest; für den Betrieb werden Quellnetze, Zielnetze und Dienste auf den realen Bedarf eingeschränkt. Eine Regel für RED-zu-LAN ersetzt keine RED-zu-WAN-Regel in Standard/Unified; für den zentralen Internetpfad muss ausserdem eine passende SNAT-Regel greifen.

In Standard/Split maskiert die RED den lokalen Internettraffic selbst mit ihrer öffentlichen Adresse. Dieser Pfad erscheint nicht an der zentralen Firewall und braucht dort keine WAN-SNAT-Regel. Zentral getunnelter Traffic benötigt dagegen korrekte Hin- und Rückrouten sowie passende Firewall-Regeln; vorhandene NAT-Regeln dürfen die Quell- oder Zielnetze nicht unbeabsichtigt verändern. Bei Manual/Split gehören die statischen Routen auf dem vorhandenen Standortgateway und der Rückweg in der Zentrale als zusammengehöriges Paar in die Prüfung.

Zusatzoptionen nicht als Moduskorrektur verwenden

MAC filtering type unterscheidet Allow list und Block list; die maximale Zahl der MAC-Adressen hängt vom Gerätemodell ab. MAC-Filter ersetzen keine Firewall-Regeln und reparieren kein falsches Routing. Unter PoE settings kann bei SD-RED 60 einer oder beide PoE-Ports aktiviert werden; PoE betrifft die Stromversorgung, nicht den Tunnelmodus.

Remote IP assignment unter Advanced settings weist der Bridge mit dem RED-Tunnel auf der WAN-Seite eine Adresse per DHCP oder Static zu. Diese Option ist nur für den Fall vorgesehen, dass Geräte hinter der RED nicht auf ARP-Anfragen antworten. Vor einer Änderung den ARP-Befund und den bisherigen Wert dokumentieren, danach genau denselben Zieltest wiederholen und bei ausbleibender Verbesserung den vorherigen Wert wiederherstellen.

Tunnel compression und MTU verändern ebenfalls nicht die Split-Auswahl. Kompression kann bei geeigneten Daten und langsamen Verbindungen helfen; MTU bezeichnet die maximale Paketgrösse in Bytes. Ohne Befund keinen pauschalen Wert übernehmen. Die kontrollierten Vorher-Nachher-Tests, Rückwege und die Empfehlung, 802.3az auf direkt angeschlossenen Switches zu deaktivieren, stehen in Sophos SD-RED einrichten und Fehler beheben.

Wechsel mit sauberem Rollback

Vor dem Wechsel werden die aktuelle RED-Konfiguration, RED IP, Zone, DHCP-Bereich und Optionen, Split-Netze, statischen Routen, Firewall- und NAT-Regeln, VLAN-Interfaces, LAN-Portmodi sowie ein unabhängiger Managementzugang dokumentiert. Zusätzlich wird die letzte funktionierende Konfiguration der beteiligten Router und Switchports gesichert. Dann wird jeweils nur eine Ebene geändert: zuerst Modus und RED-Netz, danach DHCP, Routing und Regeln, zuletzt VLAN oder WLAN.

Schlägt die Abnahme fehl, wird nicht mit weiteren Paralleländerungen improvisiert. Man setzt RED operation mode, RED IP, Zone, DHCP und Split-Netze auf die dokumentierten Werte zurück, stellt die vorherigen Routen und Regeln wieder her und lässt einen Testclient seine DHCP-Lease erneuern. Erst wenn Gateway, DNS, zentrales Ziel, Internetpfad und Regel-ID wieder dem Ausgangsstand entsprechen, ist das Rollback abgeschlossen. Bei Manual/Split muss auch die ursprüngliche physische Verkabelung wiederhergestellt werden.

Der praktische Setup-Ablauf mit Provisioning, LEDs, Regeln, Performance und Fehleranalyse steht in Sophos SD-RED einrichten und Fehler beheben. Für die Betriebsart braucht es zusätzlich eine Abnahme des tatsächlichen Pfads:

1. Ein Client erhält die erwartete IP-Adresse, DNS-Server und das richtige Gateway.
2. Ein definiertes Zielnetz in der Zentrale ist erreichbar.
3. Log Viewer oder Packet Capture zeigt die erwartete Firewall Rule ID und den RED-Pfad.
4. Ein Internettest zeigt den erwarteten öffentlichen Ausgang, zentral oder lokal.
5. Eine erlaubte und eine gesperrte Anwendung bestätigen, wo die Security Policy tatsächlich greift.
6. VLANs und WLANs werden einzeln statt nur über einen allgemeinen Ping geprüft.
7. Ein geplanter Tunnel- oder Uplink-Ausfall bestätigt das dokumentierte Ausfallverhalten.

Wenn der Tunnel grün ist, der Datenpfad aber unklar bleibt, hilft Packet Capture auf Sophos Firewall richtig einsetzen. Bei Produktivstandorten sollten Änderungen nicht gleichzeitig an Betriebsart, DHCP, VLANs und Firewall-Regeln vorgenommen werden. Sonst lässt sich ein Fehler kaum noch einer Ebene zuordnen.

Fehlersuche nach Datenpfad

• Die RED startet wiederholt neu oder baut keinen Tunnel auf: Zuerst WAN-DHCP, DNS und Internetzugang am RED-Standort prüfen. Danach TCP 3400, UDP 3410 und die Zeitsynchronisation über NTP 123 kontrollieren. Bei manueller Offline-Bereitstellung kann eine falsche Uhrzeit den TLS-Handshake verhindern.
• Der Tunnel ist grün, aber es fliesst kein Traffic: Im Log Viewer zuerst die erwartete Firewall Rule ID suchen und anschliessend Routen und NAT-Regeln für das konkrete Quell-/Zielpaar prüfen. In der Advanced Shell zeigt der von Sophos dokumentierte, nur lesende Mitschnitt tcpdump -ni any port 3410, ob am Firewall-Endpunkt RED-Datenverkehr ankommt. Der Befehl bestätigt weder eine erlaubende Regel noch den korrekten Nutzdatenpfad; danach folgt ein Packet Capture mit Client- und Zieladresse.
• Nur Split-Ziele schlagen fehl: Prüfen, ob das vollständige Zielnetz in Split network steht. FQDN-Hosts sind dort nicht unterstützt. In Transparent/Split zusätzlich den lokalen DNS- beziehungsweise Split-DNS-Pfad getrennt testen.
• Nur VLAN-Traffic schlägt fehl: Modus zuerst kontrollieren. VLAN-Transport durch den RED-Tunnel ist bei SD-RED 60 nur in Standard/Unified unterstützt. Danach VLAN ID, VLAN-Interface auf dem RED-Interface, LAN-Portmodus, Switch-Tagging, DHCP und VLAN-spezifische Firewall-Regel vergleichen.
• Ein HA-Failover wurde ausgelöst: Ein grüner Status ist nicht sofort zu erwarten. SFOS dokumentiert eine Wiederverbindungsverzögerung, deren Dauer von der Anzahl der Interfaces und weiteren Einstellungen abhängt. Deshalb auf den Tunnel-Neuaufbau warten und danach die vollständige Pfadprüfung wiederholen, statt gleichzeitig RED-Parameter zu ändern.

Typische Fehlannahmen

Split bedeutet nicht automatisch Internet bei Tunnelausfall

Standard/Split nutzt zwar lokalen Internet-Breakout, die Clients hängen aber weiterhin am von der Firewall bereitgestellten RED-Netz. Sophos dokumentiert bei einem Tunnelausfall auch dort den Verlust des Internetzugangs. Manual/Split ist das getrennte Design für ein bestehendes lokales Gateway.

Transparent bedeutet nicht beliebiges Layer-2-Passthrough

Transparent/Split integriert die RED in ein vorhandenes Netz, überträgt aber keine VLAN-getaggten Frames durch diesen Pfad. Auch DHCP, DNS und WLAN-Optionen müssen weiterhin bewusst geplant werden.

Ein grüner Tunnel beweist nicht die richtige Betriebsart

Der Tunnelstatus bestätigt die Verbindung zur Firewall. Erst DHCP-, Routing-, Internet-, Regel- und Ausfalltests zeigen, ob die gewählte Betriebsart zur Absicht passt.