Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren

Mit SFOS 22.0 MR1 hat Sophos Legacy Remote Access IPsec VPN ausser Betrieb genommen. Bereits eine auf der Firewall vorhandene Legacy-Konfiguration blockiert das Upgrade auf SFOS 22.0 MR1 und spätere Versionen. Sie muss vor dem Upgrade gelöscht werden, auch wenn aktuell niemand mehr darüber verbunden ist.

Der Artikel beschreibt, wie man die alte Konfiguration vor einem Firmware-Upgrade erkennt, sauber dokumentiert, durch eine aktuelle Remote-Access-Lösung ersetzt und erst danach entfernt. Für den allgemeinen Upgrade-Check passt zusätzlich Sophos Firewall vor SFOS 22 Upgrade prüfen.

Worum es bei Legacy Remote Access IPsec geht

Sophos hat über die Jahre mehrere Remote-Access-Wege unterstützt. Dadurch ist in vielen Umgebungen nicht sofort klar, ob eine aktuelle IPsec-Konfiguration, ein alter Legacy-Eintrag, SSL VPN oder Sophos Connect gemeint ist.

Für das SFOS-22-MR1-Upgrade ist vor allem entscheidend:

• Legacy Remote Access IPsec ist der alte Konfigurationstyp, der das Upgrade blockieren kann.
• Aktuelles Remote Access IPsec ist der Zielpfad, wenn IPsec weiter genutzt werden soll.
• SSL VPN kann eine Alternative sein, wenn IPsec in Hotels, Gastnetzen oder Mobilfunkumgebungen regelmässig blockiert wird.
• ZTNA kann sinnvoll sein, wenn nicht mehr ein komplettes Client-VPN, sondern Zugriff auf einzelne Anwendungen benötigt wird.

Der Unterschied ist operativ wichtig. Ein grüner VPN-Status oder ein funktionierender Sophos Connect Client beweist nicht automatisch, dass keine Legacy-Konfiguration mehr auf der Firewall vorhanden ist.

Auch die Clientdateien helfen bei der Einordnung:

• Bei einer Legacy-Verbindung wurde aus einem heruntergeladenen .tar-Archiv eine .tgb-Datei extrahiert und in einen Drittanbieter-VPN-Client importiert.
• Die aktuelle Remote-Access-IPsec-Konfiguration kann eine .scx-Datei für Sophos Connect exportieren. Sie enthält neben den allgemeinen auch die erweiterten Einstellungen.
• Eine heutige .tgb-Datei allein beweist noch keine Legacy-Konfiguration, weil die aktuelle IPsec-Seite sie weiterhin für Drittanbieter-Clients exportieren kann. Massgebend ist der Eintrag unter Remote access VPN > IPsec (legacy).

Ein wichtiger Restore-Fall wird leicht übersehen: Backups oder importierte Konfigurationen können Legacy Remote Access IPsec enthalten. Sophos stellt diese Konfiguration zwar wieder her beziehungsweise importiert sie, migriert sie aber nicht in das aktuelle Remote-Access-IPsec-Modell. Nach Restore, Hardwaretausch oder Konfigurationsimport muss der Upgradeblocker deshalb erneut geprüft werden.

Wann man migrieren sollte

Die Migration sollte vor dem geplanten SFOS-22-MR1-Upgrade abgeschlossen sein. Dieser Wechsel sollte nicht erst im Wartungsfenster für das Firmware-Update erledigt werden, weil Remote Access oft Benutzer, Zertifikate, MFA, DNS, Firewall-Regeln und Client-Konfigurationen betrifft.

Typische Auslöser:

• Sophos Firewall soll auf SFOS 22.0 MR1 oder neuer aktualisiert werden.
• Die Firmware-Seite oder Sophos-Dokumentation weist auf Legacy Remote Access IPsec hin.
• In der Umgebung gibt es alte Sophos Connect Profile, die seit Jahren nicht mehr geprüft wurden.
• Benutzer melden wiederkehrende Remote-Access-Probleme nach Profil- oder Clientwechseln.
• Remote Access soll ohnehin mit MFA, Entra ID SSO, SSL VPN oder ZTNA neu bewertet werden.

Wenn Remote Access geschäftskritisch ist, sollte die Migration als eigenes Change-Projekt behandelt werden. Ein Firmware-Upgrade ist dann nur der Anlass, nicht der ganze Arbeitsumfang.

Vor der Migration dokumentieren

Zuerst wird der Ist-Zustand dokumentiert. Dieser Schritt ist wichtiger als er aussieht, weil viele VPN-Konfigurationen nicht nur aus einem Tunnelprofil bestehen. Häufig hängen Benutzergruppen, IP-Pools, DNS-Einstellungen, Firewall-Regeln, NAT-Ausnahmen und Clientdateien daran.

Legacy-Konfiguration im WebAdmin prüfen

Vor der Zielplanung sollte man sauber feststellen, ob wirklich Legacy Remote Access IPsec betroffen ist. Der Check gehört nicht nur vor das Firmware-Upgrade, sondern auch nach Restore, Hardwaretausch oder Konfigurationsimport.

Praktischer Ablauf:

1. Remote access VPN > IPsec (legacy) auf der noch unterstützten Ausgangsversion öffnen.
2. Prüfen, ob dort eine Legacy-Verbindung vorhanden ist. Für den Upgradeblocker ist nicht entscheidend, ob sie gerade aktiv genutzt wird.
3. Remote access VPN > IPsec öffnen und die aktuelle Remote-Access-IPsec-Konfiguration getrennt dokumentieren.
4. Authentication > Users und Benutzergruppen prüfen, wenn statische IP-Adressen, lokale Benutzer oder alte Gruppenzuordnungen verwendet wurden.
5. Rules and policies > Firewall rules nach Regeln aus der Zone VPN zu LAN, DMZ oder WAN durchsuchen.
6. Administration > Device access prüfen, ob IPsec, VPN Portal, DNS oder Ping aus den nötigen Zonen erreichbar sind.
7. Die Firmware-Seite erneut öffnen und kontrollieren, ob weiterhin ein Upgrade-Blocker angezeigt wird.

Wenn der Legacy-Bereich nicht mehr sichtbar ist, aber das Upgrade weiterhin blockiert wird, sollte man nicht auf Verdacht Objekte löschen. Dann sind Screenshot der Meldung, aktuelles Backup und eine nachvollziehbare Objektliste wichtiger als hektisches Aufräumen im Wartungsfenster.

Zu dokumentieren sind mindestens:

• Benutzer und Gruppen: Welche Benutzer dürfen Remote Access verwenden? Werden lokale Benutzer, AD, RADIUS oder Entra ID verwendet?
• Authentifizierung: Passwort, MFA, Zertifikat, Preshared Key oder SSO-Abhängigkeiten.
• IP-Pool: Welche Adressen bekommen VPN-Clients? Gibt es Konflikte mit LAN, WLAN, VLAN oder anderen VPNs?
• DNS: Welche DNS-Server und Domains werden an Clients verteilt?
• Zugriff: Welche internen Netze, Server und Dienste müssen erreichbar sein?
• Firewall-Regeln: Welche Regeln erlauben Traffic von VPN nach LAN, DMZ oder WAN?
• Clientverteilung: Wo liegen alte .tgb-Dateien, aktuelle Sophos-Connect-Profile (.scx oder .pro) oder SSL-VPN-Konfigurationen?
• Betrieb: Wer kann Benutzer informieren, Profile verteilen und Fehler entgegennehmen?

Wenn es bereits Probleme mit Routing oder Traffic durch den Tunnel gibt, sollte man sie nicht ungeprüft in die neue Konfiguration übernehmen. Für die Analyse hilft Sophos Firewall IPsec VPN Troubleshooting.

Zielpfad auswählen

Es gibt nicht den einen richtigen Ersatz für Legacy Remote Access IPsec. Die Wahl hängt davon ab, was die Benutzer wirklich brauchen und wie die Umgebung betrieben wird.

Aktuelles Remote Access IPsec

Aktuelles Remote Access IPsec ist naheliegend, wenn weiterhin Sophos Connect mit IPsec genutzt werden soll und die Umgebung damit grundsätzlich gut funktioniert. IPsec ist oft performant, kann aber in restriktiven Fremdnetzen durch blockierte UDP-Ports oder NAT-Sonderfälle auffallen.

Dieser Weg passt gut, wenn:

• Sophos Connect bereits verteilt ist
• Benutzer mit Windows 10/11 oder macOS 13 und neuer arbeiten
• IPsec im bisherigen Einsatz stabil war
• interne Netze über klassische Firewall-Regeln erreichbar sein sollen

Sophos Connect selbst unterstützt aktuelles Remote Access IPsec auf diesen Windows- und macOS-Versionen. Für Linux und andere mobile Plattformen braucht es einen passenden Drittanbieter-Client; iOS kann ein eigenes IPsec-Profil aus dem VPN Portal installieren. Die bestehende Anleitung Sophos Connect Client auf der Sophos Firewall konfigurieren beschreibt den vollständigen Aufbau.

SSL VPN

SSL VPN ist sinnvoll, wenn Remote Access möglichst robust durch unterschiedliche Fremdnetze funktionieren soll. Je nach Umgebung kann SSL VPN einfacher sein, erzeugt aber andere Performance- und Clientfragen. Für Windows gibt es die Anleitung Sophos Connect SSL VPN Client installieren.

Dieser Weg passt gut, wenn:

• Benutzer häufig in Hotels, Gast-WLANs oder fremden Firmennetzen arbeiten
• IPsec-Verbindungen immer wieder an Netzrestriktionen scheitern
• bestehende SSL-VPN-Prozesse bereits etabliert sind
• mobile Plattformen oder Drittanbieter-OpenVPN-Clients eine Rolle spielen

ZTNA oder Clientless Access

Wenn Benutzer nur einzelne interne Webanwendungen oder definierte Applikationen brauchen, sollte man prüfen, ob ein klassisches Volltunnel-VPN überhaupt noch die richtige Lösung ist. ZTNA ist kein direkter Ersatz für jedes VPN-Szenario, kann aber in sauber abgegrenzten Anwendungsfällen die bessere Architektur sein.

Für die Entscheidung hilft zuerst Was ist Zero Trust Network Access? Grundlagen, Vorteile und Grenzen. Wenn Sophos ZTNA eingesetzt werden soll, beschreibt Sophos ZTNA Gateway Connector die konkrete Komponente. Clientless SSL VPN für RDP und SSH ist nur für passende browserbasierte Ziele eine Alternative und ersetzt keinen allgemeinen Netzwerkzugriff.

Neue Remote-Access-Konfiguration aufbauen

Die neue Konfiguration sollte parallel vorbereitet werden, bevor die alte entfernt wird. Ziel ist nicht, alle Benutzer gleichzeitig in ein ungetestetes Setup zu verschieben.

Für aktuelles Remote Access IPsec reicht es nicht, nur einen neuen Profilnamen anzulegen. Der Migrationsablauf sollte die entscheidenden Einstellungen bewusst übernehmen oder neu festlegen:

1. Zielvariante festlegen: aktuelles Remote Access IPsec, SSL VPN, ZTNA oder Kombination.
2. Unter Remote access VPN > IPsec Remote Access aktivieren und die externe Interface auswählen.
3. Ein passendes IPsec profile verwenden. Remote Access akzeptiert IKEv1-Profile, bei denen Dead Peer Detection deaktiviert oder auf Disconnect gesetzt ist.
4. Authentication type, lokale und entfernte ID sowie Allowed users and groups festlegen.
5. Unter Assign IP from einen privaten Bereich aus mindestens einem /24-Subnetz wählen. Er darf sich nicht mit SSL VPN, L2TP, PPTP, LAN, WLAN oder Site-to-Site-Netzen überschneiden.
6. DNS server 1 und optional DNS server 2 sowie die benötigten internen Ressourcen festlegen.
7. Split Tunnel oder Use as default gateway bewusst entscheiden und Prompt users for 2FA token passend zum MFA-Verfahren konfigurieren.
8. Unter Authentication > Groups prüfen, ob Remote Access IPsec für die tatsächlich wirksame Benutzergruppe erlaubt ist. Bei importierten AD-Gruppen und migrierten Gruppen ist dies nicht automatisch aktiv.
9. Unter Administration > Device access IPsec aus der WAN-Zone erlauben. Das VPN Portal wird nur benötigt, wenn Clients oder Provisionierung darüber zugreifen; DNS und Ping werden nur für das konkrete Design freigegeben.
10. Getrennte und klar benannte Firewall-Regeln für eingehenden und ausgehenden VPN-Traffic erstellen und Logging aktivieren.
11. Mit Export connection eine .scx-Datei für Sophos Connect erzeugen oder eine vorhandene .pro-Provisionierung aktualisieren.
12. Testprofil an wenige Pilotbenutzer verteilen, auf mindestens zwei verschiedenen Netzanschlüssen testen und erst danach den Rollout planen.

MFA sollte bei Remote Access nicht als optionales Detail behandelt werden. Wenn das VPN weltweit erreichbar ist, gehören MFA, saubere Benutzergruppen, Logging und ein Review der Device-Access-Einstellungen zusammen. Der Artikel Sophos Firewall MFA einrichten deckt die Grundlagen ab.

Koexistenz und Rückfallweg planen

Die neue Remote-Access-Lösung sollte zuerst neben der alten Konfiguration getestet werden. Dadurch kann man Benutzer schrittweise migrieren und bei Fehlern gezielt zurückgehen, ohne im gleichen Wartungsfenster Remote Access, Firewall-Regeln, DNS, MFA und Clientverteilung gleichzeitig zu ändern.

Wichtig ist aber, dass Koexistenz sauber geplant wird. Die neue Konfiguration sollte nicht denselben IP-Pool, dieselben unklar benannten Firewall-Regeln oder dieselben Profilnamen verwenden wie die alte Legacy-Konfiguration. Sonst ist im Log Viewer später nicht mehr erkennbar, welcher Zugang einen Benutzer tatsächlich verbunden hat.

Vor dem Pilot sollten diese Punkte feststehen:

• Pilotgruppe: wenige technisch erreichbare Benutzer mit verschiedenen Geräten und Netzen.
• IP-Pool: eigener Bereich ohne Überschneidung mit LAN, WLAN, Site-to-Site VPN oder altem Remote Access.
• Firewall-Regeln: eigene, klar benannte Regeln für den neuen VPN-Pool.
• Clientprofile: neuer Verbindungsname, damit Benutzer Legacy- und Zielverbindung unterscheiden können.
• Rückfallkriterium: vorher definieren, wann auf die alte Verbindung zurückgegangen wird.
• Supportfenster: Helpdesk oder Admin muss während des Pilots erreichbar sein.

Ein Rückfallweg bedeutet nicht, die Legacy-Konfiguration dauerhaft weiterzubetreiben. Er dient nur dazu, den Pilot kontrolliert abzubrechen, falls Anmeldung, MFA, DNS, Routing oder zentrale Anwendungen nicht funktionieren. Sobald die neue Lösung stabil ist, sollte die alte Konfiguration entfernt und der Upgrade-Blocker erneut geprüft werden.

Tests vor dem Entfernen der Legacy-Konfiguration

Die alte Konfiguration sollte erst entfernt werden, wenn der Ersatz getestet wurde. Sonst ist zwar das Upgrade-Problem gelöst, aber der Remote Access kann produktiv ausfallen.

Funktionstest

Mindestens prüfen:

• Anmeldung mit Testbenutzer funktioniert
• MFA oder SSO wird wie erwartet abgefragt
• Client erhält eine passende VPN-IP
• interne DNS-Namen werden aufgelöst
• zentrale Server sind erreichbar
• Internetverhalten entspricht dem Design: Split Tunnel oder Full Tunnel
• Abmeldung und erneute Anmeldung funktionieren

Firewall- und Routing-Test

Im Log Viewer prüfen, ob Traffic von der VPN-Zone die erwarteten Regeln trifft. Wenn Traffic verworfen wird, sollte man nicht nur die VPN-Konfiguration prüfen, sondern auch Firewall-Regel, NAT, Route Precedence und Rückweg. Für einzelne Verbindungen ist der Artikel Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture hilfreich.

Client-Test

Bei Sophos Connect sollten bestehende Profile nicht stillschweigend überschrieben werden. Besser ist ein kleiner Pilot mit klarer Rückmeldung:

• Importiert der Client die neue Konfiguration?
• Wird die alte Verbindung für Benutzer verständlich ersetzt?
• Funktioniert der Verbindungsaufbau nach Neustart?
• Sind DNS-Suffixe, Routen und gespeicherte Verbindungen korrekt?
• Gibt es Unterschiede zwischen Windows und macOS?

Bei .scx-Verteilung muss eine spätere Änderung erneut exportiert und importiert werden. Eine bereits eingerichtete .pro-Provisionierung kann spätere Änderungen automatisch abrufen, solange Gateway-Adresse und VPN-Portal-Port erreichbar und unverändert sind.

Vor einem breiten Rollout sollte auch die eingesetzte Clientversion geprüft werden. Dafür passt Sophos Connect Client Version prüfen und sicher aktualisieren.

Legacy-Konfiguration entfernen

Wenn die neue Lösung produktiv getestet ist, kann die Legacy-Konfiguration entfernt werden. Vorher sollte noch einmal ein aktuelles Backup erstellt werden. Das ist besonders wichtig, wenn im gleichen Change auch Firewall-Regeln, Benutzergruppen oder Authentifizierungsserver angepasst werden.

Praktischer Ablauf:

1. Frisches Backup erstellen.
2. Aktive Benutzer über das Wartungsfenster informieren.
3. Neue Remote-Access-Konfiguration aktiv lassen.
4. Legacy Remote Access IPsec im WebAdmin entfernen.
5. Nicht mehr benötigte alte Profile, IP-Pools und Regeln auf Abhängigkeiten prüfen.
6. Firmware-Seite erneut öffnen und kontrollieren, ob der Upgrade-Blocker verschwunden ist.
7. Ergebnis dokumentieren.

Nicht sofort alles löschen, was alt aussieht. Alte Firewall-Regeln, Hosts oder Gruppen können auch für Site-to-Site-VPN, SSL VPN oder andere Zwecke verwendet werden. Zuerst Abhängigkeiten prüfen, dann bereinigen.

Nach einem Restore oder Konfigurationsimport sollte die Kontrolle wiederholt werden. Ein Backup kann alte Legacy-Objekte enthalten, ohne dass daraus automatisch eine aktuelle Remote-Access-IPsec-Konfiguration entsteht. Für Betrieb und Dokumentation ist deshalb entscheidend, ob die produktive Zielkonfiguration wirklich neu aufgebaut, getestet und verteilt wurde.

Troubleshooting

Upgrade bleibt weiterhin blockiert

Wenn das Upgrade weiterhin blockiert wird, obwohl die sichtbare Legacy-Konfiguration entfernt wurde, zuerst den Firmwarebereich neu öffnen und Remote access VPN > IPsec (legacy) erneut prüfen. Nicht auf Verdacht Hosts, Gruppen oder aktuelle IPsec-Profile löschen. Wenn unklar bleibt, welche Legacy-Konfiguration erkannt wird, sollte ein Sophos Support Case mit Screenshot der Upgrade-Meldung, Ausgangsversion und aktuellem Backup vorbereitet werden.

Nach Restore taucht die Legacy-Frage wieder auf

Nach Restore, Hardwaretausch oder Import einer alten Konfiguration sollte man Remote Access erneut prüfen. Entscheidend ist nicht, ob der frühere Change einmal abgeschlossen war, sondern was in der aktuell laufenden Konfiguration vorhanden ist. Alte Backups können historische Remote-Access-Objekte zurückbringen oder eine neue Prüfung des Upgradepfads auslösen.

Benutzer können sich nicht anmelden

Bei Anmeldeproblemen zuerst Authentifizierung, MFA, Benutzergruppe und VPN-Policy prüfen. Wenn RADIUS, AD oder Entra ID beteiligt ist, sollte man die Serververbindung getrennt vom VPN testen. Ein VPN-Problem ist nicht immer ein IPsec-Problem.

Verbindung steht, aber interne Systeme sind nicht erreichbar

Dann liegt die Ursache oft bei Firewall-Regeln, NAT, DNS oder Routing. Prüfen, ob der Client eine passende VPN-IP erhält, ob interne Namen korrekt aufgelöst werden und ob der Traffic im Log Viewer die erwartete Regel trifft.

Einzelne Netze funktionieren, andere nicht

In diesem Fall sind häufig Split-Tunnel-Netze, IPsec-Routen, statische Routen oder fehlende Rückrouten beteiligt. Bei IPsec-Szenarien ist IPsec Route auf Sophos Firewall ein sinnvoller Anschlussartikel.

Checkliste

Vor dem Rollout

• Legacy Remote Access IPsec identifiziert
• Benutzer, Gruppen, IP-Pool, DNS und Firewall-Regeln dokumentiert
• Zielpfad gewählt: aktuelles IPsec, SSL VPN, ZTNA oder Kombination
• MFA und Authentifizierung geprüft
• Device Access bedarfsgerecht geprüft: IPsec auf WAN, VPN Portal für Verteilung oder Provisionierung, DNS und Ping nur wenn benötigt
• Koexistenz und Rückfallkriterium definiert
• Testbenutzer definiert
• Backup erstellt

Während des Rollouts

• Neue Konfiguration mit Pilotbenutzern getestet
• Clientprofile verteilt
• Log Viewer und betroffene Firewall-Regeln geprüft
• Rückfallweg kommuniziert
• Benutzerfeedback gesammelt

Nach der Migration

• Legacy-Konfiguration entfernt
• Upgrade-Blocker erneut geprüft
• Restore- und Import-Szenario dokumentiert
• Alte Profile und Regeln auf Abhängigkeiten geprüft
• Dokumentation aktualisiert
• Firmware-Upgrade erst danach geplant

FAQ