Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren
Mit SFOS 22.0 MR1 hat Sophos das Legacy Remote Access IPsec VPN endgültig aus dem unterstützten Upgradepfad genommen. Firewalls, auf denen diese alte Remote-Access-IPsec-Konfiguration noch vorhanden ist, können nicht auf SFOS 22.0 MR1 oder neuere Versionen aktualisiert werden.
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.
Ein wichtiger Restore-Fall wird leicht übersehen: Backups oder importierte Konfigurationen können Legacy Remote Access IPsec enthalten, diese Legacy-Konfiguration wird aber nicht automatisch migriert. Nach Restore, Hardwaretausch oder Konfigurationsimport sollte man den Punkt deshalb erneut prüfen, auch wenn die Firewall vorher bereits bereinigt wirkte.
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:
- Remote access VPN > IPsec (legacy) öffnen, falls der Menüpunkt in der installierten SFOS-Version sichtbar ist.
- Prüfen, ob Legacy Remote Access IPsec aktiviert ist oder noch Konfigurationsobjekte vorhanden sind.
- Remote access VPN > IPsec öffnen und die aktuelle Remote-Access-IPsec-Konfiguration getrennt dokumentieren.
- Authentication > Users und Benutzergruppen prüfen, wenn statische IP-Adressen, lokale Benutzer oder alte Gruppenzuordnungen verwendet wurden.
- Rules and policies > Firewall rules nach Regeln aus der Zone
VPNzuLAN,DMZoderWANdurchsuchen. - Administration > Device access prüfen, ob IPsec, VPN Portal, DNS oder Ping aus den nötigen Zonen erreichbar sind.
- 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:
| Bereich | Was geprüft werden sollte |
|---|---|
| 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 aktuelle Sophos Connect Profile 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 hauptsächlich mit Windows oder macOS arbeiten
- IPsec im bisherigen Einsatz stabil war
- interne Netze über klassische Firewall-Regeln erreichbar sein sollen
Die bestehende Anleitung Sophos Connect Client auf der Sophos Firewall konfigurieren kann als Grundlage dienen, muss aber mit aktuellen SFOS-Versionen und dem eigenen Authentifizierungsdesign abgeglichen werden.
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.
Der bestehende Artikel Sophos ZTNA Gateway Connector ist dafür ein guter Einstiegspunkt. Für einfache Webzugriffe kann auch Clientless Access relevant sein, wenn die Anforderungen dazu passen.
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.
Empfohlener Ablauf:
- Zielvariante festlegen: aktuelles Remote Access IPsec, SSL VPN, ZTNA oder Kombination.
- Neuen IP-Pool wählen und auf Überschneidungen prüfen.
- Authentifizierungsquelle und MFA festlegen.
- Benötigte Benutzer oder Gruppen zuordnen.
- DNS-Server und interne Domains definieren.
- Firewall-Regeln für die neuen VPN-Quellen erstellen.
- Testprofil für wenige Benutzer erzeugen.
- Verbindung auf mindestens zwei verschiedenen Netzanschlüssen testen.
- Erst danach Benutzerkommunikation und 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:
| Punkt | Empfehlung |
|---|---|
| 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 Profilname, damit Benutzer alte und neue Verbindung 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?
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:
- Frisches Backup erstellen.
- Aktive Benutzer über das Wartungsfenster informieren.
- Neue Remote-Access-Konfiguration aktiv lassen.
- Legacy Remote Access IPsec im WebAdmin entfernen.
- Nicht mehr benötigte alte Profile, IP-Pools und Regeln prüfen.
- Firmware-Seite erneut öffnen und kontrollieren, ob der Upgrade-Blocker verschwunden ist.
- 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 die Firewall neu laden beziehungsweise den Firmwarebereich erneut öffnen. Danach prüfen, ob wirklich alle Legacy-Remote-Access-Objekte entfernt wurden. Wenn unklar bleibt, welches Objekt blockiert, sollte ein Sophos Support Case mit Screenshot der Upgrade-Meldung 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 für IPsec, VPN Portal, DNS und Ping geprüft
- 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