Sophos Firewall L2TP Remote Access einrichten und testen

L2TP Remote Access ist auf Sophos Firewall weiterhin verfügbar, sollte für neue verwaltete Endgeräte aber nicht automatisch die erste Wahl sein. Sophos Connect mit IPsec oder SSL VPN lässt sich zentraler betreiben und bietet den vollständigeren Sophos-Clientpfad. L2TP bleibt sinnvoll, wenn ein Betriebssystem seinen nativen VPN-Client verwenden muss oder eine bestehende kompatible Umgebung kontrolliert weitergeführt wird.

Einordnung für neue Umgebungen: Die aktuelle SFOS-22-Hilfe führt L2TP weiterhin als konfigurierbaren Remote-Access-Typ. Sophos hat dafür keine öffentliche Abkündigung veröffentlicht. Daraus folgt jedoch keine Zusage für eine spätere Major-Version. Avanet empfiehlt L2TP nicht als neuen Standard für verwaltete Clients. Ohne konkrete Legacy- oder Kompatibilitätsanforderung sollte kein neuer L2TP-Zugang aufgebaut werden.

L2TP allein beschreibt den Tunnel, nicht die gewünschte Sicherheit. Auf Sophos Firewall wird die Verbindung durch eine IPsec-Policy geschützt. IPsec-Profil, Authentifizierung, Preshared Key oder Zertifikat und die Clientkonfiguration müssen deshalb zusammenpassen. Ein grüner Active-Status bedeutet zudem nur, dass die Policy aktiviert ist; erst der Connection-Status und ein echter Datenfluss bestätigen den Tunnel.

⚠️ Die von Sophos für L2TP verlangte Route Precedence stellt vpn global vor Static und SD-WAN Policy Routes. Auch eine neue L2TP-Policy mit Wildcard-Gegenstelle kann bestehende Preshared Keys beeinflussen. Vor der Änderung müssen deshalb die aktuelle Reihenfolge, ein unabhängiger Managementzugang und alle anderen VPN-, Static- und SD-WAN-Pfade dokumentiert sein.

L2TP in acht Schritten

1. Prüfen, ob L2TP wirklich benötigt wird und Client, IPsec-Profil sowie Authentifizierung zusammenpassen.
2. Einen nicht überlappenden privaten Lease-Bereich, interne DNS-Server und eine enge Benutzergruppe planen.
3. Unter Remote access VPN > L2TP > L2TP global settings L2TP aktivieren und Benutzer hinzufügen.
4. Eine L2TP-Policy mit passendem IPsec-Profil, WAN-Port, Authentifizierung und NAT Traversal erstellen.
5. Unter Administration > Device access den Dienst IPsec für die benötigte WAN-Erreichbarkeit freigeben.
6. Die aktuelle Route Precedence sichern und vpn kontrolliert an die erste Stelle setzen.
7. Eine enge, geloggte Firewall-Regel von der Zone VPN zu den tatsächlich benötigten internen Zielen erstellen.
8. Mit einem externen Pilotclient Anmeldung, Lease-Adresse, DNS, Regel, Rückweg und Negativtest abnehmen.

Wann L2TP passt

L2TP kann bei nativen Betriebssystem-Clients oder bestehenden Geräten nützlich sein, auf denen Sophos Connect nicht vorgesehen ist. Es ist auch nachvollziehbar, wenn eine kleine, bereits dokumentierte L2TP-Umgebung ohne zusätzliche Clientsoftware weiterbetrieben werden soll.

Für einen neuen Standard-Rollout ist meist Sophos Connect mit IPsec oder SSL VPN geeigneter. Dort sind Profilverteilung, Clientdiagnose und der Sophos-spezifische Supportpfad klarer. PPTP ist keine moderne Ausweichlösung: Das Protokoll definiert selbst keine Verschlüsselung und sollte für neue Remote-Access-Zugänge nicht mehr eingeplant werden.

Vor der Konfiguration sollten drei Grenzen klar sein:

• L2TP verwendet auf der Sophos Firewall einen gemeinsamen globalen Adresspool und gemeinsame DNS-Einstellungen für alle L2TP-Policies.
• Importierte Gruppen aus Active Directory oder Microsoft Entra ID werden nicht automatisch für L2TP freigeschaltet. Sie müssen unter Add members ausdrücklich hinzugefügt werden.
• L2TP und PPTP berücksichtigen bei Gruppenmitgliedschaften nur die relevante Hauptgruppe. Eine zusätzliche Gruppenmitgliedschaft allein beweist deshalb noch keine Berechtigung. Die Hintergründe erklärt Benutzergruppen und Main Group richtig verwalten.

Beispiel und Vorbereitung

Das Beispiel verbindet einen externen Client mit einem internen Applikationsnetz. Die Werte sind bewusst als Dokumentationswerte gewählt und müssen zur eigenen Umgebung passen:

• L2TP-Pool: 10.250.30.10 bis 10.250.30.100 innerhalb von 10.250.30.0/24
• interner DNS-Server: 10.10.10.10
• erlaubte Gruppe: L2TP_Users
• Policy-Name: L2TP_Remote_Access
• IPsec-Profil: DefaultL2TP als Ausgangspunkt für den Kompatibilitätstest
• internes Zielnetz: 10.10.10.0/24
• Beispielservice: HTTPS

Der Bereich 10.250.30.0/24 ist nur ein privates Beispielnetz. Er darf weder mit LAN-, VLAN-, Site-to-Site- oder Heimnetzen noch mit den Lease-Bereichen von Remote Access IPsec, SSL VPN oder PPTP überlappen. Sophos erlaubt für Assign IP from höchstens 254 Adressen innerhalb eines /24 oder kleineren Subnetzes.

Vor dem Start werden zusätzlich geprüft:

• Ein passendes IPsec-Profil ist mit den unterstützten Einstellungen des nativen Clients abgestimmt.
• Die öffentliche Adresse beziehungsweise der FQDN des ausgewählten WAN-Ports ist vom Client erreichbar.
• Systemzeit, DNS und Zertifikatskette stimmen, falls ein Zertifikat verwendet wird.
• Der Benutzer oder die Gruppe existiert und die richtige Authentifizierungsmethode ist unter Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods eingetragen.
• Die aktuelle Ausgabe von system route_precedence show und ein dazu passender Rollback-Befehl sind dokumentiert.
• WebAdmin oder Konsole bleibt über einen unabhängigen Managementpfad erreichbar.

Authentifizierungsquelle und Client müssen dasselbe Verfahren unterstützen: Für Local und RADIUS nennt SFOS PAP, CHAP oder MSCHAPv2, für Active Directory und LDAP nur PAP, für TACACS+ PAP oder CHAP. Vor dem Rollout wird die gemeinsame Schnittmenge mit dem nativen Client geprüft. Die äussere IPsec-Absicherung bleibt bei L2TP zwingend; diese Kompatibilitätsmatrix ist keine Empfehlung für PPTP oder ungeschützte PAP-Nutzung.

Versions- und Clientgrenzen

Diese Anleitung ist für SFOS 22.0 MR2 Build 546 und die Bedienoberfläche der 22.0-Onlinehilfe ausgelegt. L2TP ist in diesem Stand verfügbar. Aktuelle Upgrade-Sperren und unterstützte Pfade hält der Avanet SFOS 22 Upgrade-Check zusammen; vor jeder Migration wird dort der konkrete Quell-Build gegen den Ziel-Build geprüft. Für native L2TP-Clients gibt es keine vollständige Kompatibilitätsmatrix. Die 22.0-Anleitung nennt als konkretes Clientbeispiel nur Windows 10. Das ist kein Kompatibilitätsnachweis für andere oder spätere Betriebssystemversionen.

Deshalb wird jede tatsächlich eingesetzte OS-Version mit dem vorgesehenen IPsec-Profil, dem Authentifizierungsserver und dem ID-Typ als eigene Kombination getestet. Die Obergrenze von 254 Pooladressen ist nur eine Adressgrenze; sie ist keine Zusage für ebenso viele gleichzeitige Sitzungen. Eine belastbare pauschale L2TP-Sitzungsgrenze nennt die öffentliche 22.0-Hilfe nicht. Kapazität und Stabilität werden daher auf dem konkreten Firewall-Modell mit der erwarteten Parallelität abgenommen.

Die aktuelle Hilfe beschreibt die auswählbaren Werte, kennzeichnet für Gateway type, Authentication type, Allow NAT traversal und Disconnect when tunnel is idle aber keinen allgemeinen Standardwert für bestehende oder migrierte Konfigurationen. Diese Felder werden deshalb vor und nach einem Upgrade abgelesen und nicht aus einem vermuteten Default rekonstruiert.

Nativen Windows-Client konfigurieren und prüfen

Unter Windows wird die Verbindung über Einstellungen > Netzwerk und Internet > VPN > VPN hinzufügen angelegt. Als VPN-Anbieter wird Windows (integriert) gewählt, als Servername oder -adresse der öffentliche FQDN beziehungsweise die WAN-Adresse der Firewall und als VPN-Typ L2TP/IPsec mit vorinstalliertem Schlüssel oder die zum Firewall-Profil passende Zertifikatsvariante. Der vorinstallierte Schlüssel muss dem PSK der L2TP-Policy entsprechen. Als Anmeldeinformation dienen Benutzername und Kennwort eines unter Add members freigegebenen Kontos; VPN-Typ, Anmeldeverfahren und IDs werden zusammen mit der Clientversion dokumentiert.

Der erste Test erfolgt aus einem externen Netz. Nach dem Verbinden werden mit ipconfig /all die Adresse aus dem L2TP-Pool und die vorgesehenen DNS-Server kontrolliert, danach interne Namensauflösung und der freigegebene HTTPS-Zugriff geprüft. Schlägt bereits der Aufbau fehl, werden zuerst Servername, PSK- oder Zertifikatsmodus, Anmeldeverfahren und das abgestimmte IPsec-Profil verglichen und der Zeitstempel mit l2tpd.log sowie den IPsec-Logs korreliert. Jede eingesetzte Windows-Version bleibt eine separat abzunehmende Clientkombination.

Globale L2TP-Einstellungen konfigurieren

Unter Remote access VPN > L2TP > L2TP global settings wird Enable L2TP aktiviert. Unter Assign IP from trägt man im Beispiel 10.250.30.10 bis 10.250.30.100 ein. Als Primary DNS server wird 10.10.10.10 gewählt, wenn dieser Server die internen Namen auflösen kann. Secondary DNS und WINS werden nur gesetzt, wenn sie in der Umgebung tatsächlich gebraucht werden.

Die Option Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client ist nur sinnvoll, wenn der RADIUS-Server zuverlässig eine passende Adresse liefert. Liefert er keine Adresse, verwendet die Firewall zuerst eine statisch am Benutzer konfigurierte Adresse oder anschliessend den globalen Pool. RADIUS-Zuweisung und Rückfallpfad müssen daher beide ohne Überlappung geplant werden. Die Serverkonfiguration erklärt RADIUS auf Sophos Firewall einrichten.

Anschliessend wird über Add members die Gruppe L2TP_Users hinzugefügt und mit Show members kontrolliert. Bei einem Verzeichnisbenutzer reicht der erfolgreiche Gruppenimport allein nicht. Ein Pilotbenutzer muss wirklich Mitglied der freigegebenen Gruppe sein, und diese Gruppe muss für die L2TP-Auswertung als Hauptgruppe greifen.

Nach den Änderungen an globalen Einstellungen und Mitgliedern Apply anklicken. Anschliessend die gespeicherten globalen Werte und Show members erneut prüfen. Das spätere Save der L2TP-Policy ist ein separater Schritt.

L2TP-Policy erstellen

Unter Remote access VPN > L2TP wird mit Add die Policy L2TP_Remote_Access angelegt.

Profil und Startverhalten

Unter Profile wird das mit den Clients abgestimmte IPsec-Profil gewählt. Im Beispiel dient das vorhandene Profil DefaultL2TP als Ausgangspunkt für den Kompatibilitätstest. Die enthaltenen Algorithmen und Lifetimes werden trotzdem gegen die unterstützten Clientwerte geprüft; ein Name mit Default ist keine zeitlose Sicherheitsgarantie. Die beiden Werte für Gateway type haben unterschiedliche Betriebsfolgen:

• Respond only hält die Policy nach einem Neustart bereit, damit sie eingehende Anfragen beantworten kann.
• Disable lässt sie inaktiv, bis sie manuell über den Active-Status eingeschaltet wird.

Für einen produktiven Remote-Access-Dienst ist Respond only gewöhnlich der nachvollziehbare Ausgangspunkt. Die Wahl wird nach einem Firewall- oder Dienstneustart ausdrücklich geprüft, damit Aktivierung und Verbindungsstatus nicht verwechselt werden.

Authentifizierung und Preshared Key

Als Authentication type stehen Preshared key und Digital certificate zur Verfügung. Zertifikate vermeiden einen gemeinsam geteilten PSK, benötigen aber eine vollständig geplante Vertrauenskette und passende Clientunterstützung. Ein PSK muss lang, zufällig, getrennt übermittelt und regelmässig kontrolliert erneuert werden.

Sophos verwendet den zuletzt konfigurierten PSK für alle Verbindungen mit derselben Listening-Schnittstelle und derselben Remote-Gegenstelle. Bei Remote Access steht Remote host typischerweise auf *. Eine neue oder geänderte Wildcard-Policy kann dadurch den PSK bestehender Remote-Access-Konfigurationen ersetzen. Vor dem Speichern müssen alle Policies mit demselben WAN-Port und Wildcard-Gateway geprüft werden.

Bei einem PSK wird ausserdem eine passende Local ID und Remote ID definiert. Der ID-Typ DER ASN1DN (X.509) wird für PSK nicht akzeptiert. IDs müssen mit dem nativen Client übereinstimmen; sie werden nicht aus Bequemlichkeit auf beliebige Werte gesetzt.

WAN-Port, Gegenstelle und Selektoren

Unter Local WAN port wird der wirklich erreichbare WAN-Port ausgewählt. Remote host erhält für wechselnde Clientadressen den Wildcard-Wert *. Allow NAT traversal wird aktiviert, wenn Clients hinter NAT arbeiten, was bei Heim-, Mobilfunk- und Hotelnetzen der Normalfall ist.

Für den typischen Remote-Access-Ablauf verwendet das Sophos-Beispiel Remote subnet: Any, Local port: 1701 und Remote port: *. 1701 ist der L2TP-Port auf der Firewall; der Clientport kann variieren. Diese Werte sind Teil der Tunnel-Selektoren und ersetzen keine Firewall-Regel. Der spätere Zugriff wird weiterhin auf konkrete Zonen, Ziele und Services begrenzt.

Mit Disconnect when tunnel is idle kann die Firewall inaktive Clients nach dem unter Idle session time interval angegebenen Zeitraum trennen. Der Wert wird an die Arbeitsweise angepasst und mit realen Pausen getestet. Eine zu kurze Zeit erzeugt unnötige Neuverbindungen; ohne Begrenzung können vergessene Sitzungen länger bestehen bleiben. Idle session time interval wird in Sekunden angegeben.

Nach Save wird die Policy über das rote Symbol in der Spalte Active eingeschaltet. Grün bei Active bedeutet noch nicht, dass ein Client verbunden ist. Der separate Connection-Status zeigt, ob der Tunnel tatsächlich aufgebaut wurde.

Bei mehreren lokalen und entfernten Subnetzen entsteht je lokalem/entferntem Subnetzpaar ein Tunnel. Die Connection-Anzeige kann einen Teilzustand zeigen: Die Konfiguration ist aktiv, aber mindestens ein Tunnel ist nicht aufgebaut. Deshalb jedes erforderliche Subnetzpaar und den zugehörigen Datenfluss einzeln testen; ein aktiviertes Active bestätigt nicht alle Tunnel.

Erreichbarkeit, Routing und Firewall-Regel

IPsec am WAN zulassen

Unter Administration > Device access muss IPsec für die benötigte WAN-Erreichbarkeit zugelassen sein. Diese Freigabe wird so eng wie die konkrete Topologie erlaubt umgesetzt. Ein starker PSK oder ein Zertifikat rechtfertigt keine unnötig breite WebAdmin-, User-Portal- oder SSH-Freigabe. Die Trennung zwischen Dienst-Erreichbarkeit und Benutzerberechtigung erklärt Device Access und Local Service ACL.

Route Precedence kontrolliert setzen

Die von Sophos dokumentierte Standardreihenfolge lautet Static, SD-WAN Policy Routes, VPN. Für L2TP müssen dagegen VPN-Routen zuerst ausgewertet werden; Static und SD-WAN dürfen danach in beliebiger Reihenfolge folgen. Zuerst wird die tatsächliche Ausgangslage in der Device Console gesichert:

system route_precedence show

Danach wird die dokumentierte L2TP-Reihenfolge gesetzt und erneut geprüft:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Diese Änderung gilt global und ist kein isolierter Schalter für die neue L2TP-Policy. Vorher und nachher müssen deshalb überlappende Static-, SD-WAN- und VPN-Pfade sowie der Managementzugang getestet werden. Die Wirkung und sichere Rücknahme beschreibt Route Precedence auf Sophos Firewall anpassen.

Zugriff auf interne Ziele erlauben

Unter Rules and policies > Firewall rules wird eine geloggte IPv4-Regel erstellt. Das Sophos-Beispiel mit Any für Quelle, Ziel und Service ist für einen ersten Funktionsnachweis einfach, aber kein guter dauerhafter Sicherheitsstandard. Im Beispiel wird enger gearbeitet:

• Source zone: VPN
• Source network: der L2TP-Pool 10.250.30.0/24 oder ein passend definiertes Hostobjekt
• Destination zone: die Zone des Applikationsnetzes
• Destination network: 10.10.10.0/24 oder noch enger die benötigten Server
• Services: HTTPS beziehungsweise nur die tatsächlich benötigten Dienste
• Log firewall traffic: aktiviert

Internetverkehr durch die Firewall benötigt eine separate Regel von VPN nach WAN und ein bewusstes NAT- und Security-Design. Diese Freigabe wird nicht automatisch angelegt, nur weil der L2TP-Tunnel steht.

Verbindung abnehmen

Die Abnahme erfolgt aus einem echten externen Netz. Ein Test aus demselben LAN oder über einen bereits bestehenden VPN-Pfad kann Routing, NAT und öffentliche Erreichbarkeit verdecken.

1. Mit einem berechtigten Pilotbenutzer und der dokumentierten Clientkonfiguration verbinden.
2. Unter Remote access VPN > L2TP Active- und Connection-Status getrennt prüfen. Bei mehreren lokalen und entfernten Subnetzen entsteht je lokalem/entferntem Subnetzpaar ein Tunnel. Die Connection-Anzeige kann einen Teilzustand zeigen: Die Konfiguration ist aktiv, aber mindestens ein Tunnel ist nicht aufgebaut. Deshalb jedes erforderliche Subnetzpaar und den zugehörigen Datenfluss einzeln testen; ein aktiviertes Active bestätigt nicht alle Tunnel.
3. Kontrollieren, ob der Client eine Adresse aus 10.250.30.10 bis 10.250.30.100 sowie die vorgesehenen DNS-Server erhält.
4. Einen internen Namen auflösen und ein ausdrücklich freigegebenes Ziel über HTTPS erreichen.
5. Im Log Viewer die erwartete Firewall Rule ID, Source-IP aus dem L2TP-Pool, Ziel, Service und Action prüfen.
6. Rückweg vom Zielnetz zum L2TP-Pool kontrollieren und denselben Zugriff nach einer neuen Verbindung wiederholen.
7. Mit einem nicht hinzugefügten Benutzer einen Negativtest durchführen; er darf keinen nutzbaren Tunnel erhalten.
8. Idle-Verhalten, Trennen, Neuverbinden und bei HA einen kontrollierten Failover mit einer neuen Anmeldung testen.

Eine erfolgreiche Authentifizierung beweist noch keinen Datenpfad. Ebenso beweist ein grüner Tunnel nicht, dass DNS, Regel, NAT und Rückweg stimmen. Die praktische Trennung von Log Viewer und Packet Capture erklärt Sophos Firewall Regeln testen.

Fehler systematisch eingrenzen

Policy ist aktiv, aber der Tunnel bleibt down

Zuerst WAN-Port, öffentliche Erreichbarkeit, IPsec unter Device Access, NAT Traversal, Clientadresse, PSK oder Zertifikat, Local/Remote ID und IPsec-Profil vergleichen. Danach prüfen, ob eine zuletzt gespeicherte Wildcard-Policy den erwarteten PSK ersetzt hat.

Für die erste Trennung helfen l2tpd.log für L2TP und strongswan.log beziehungsweise charon.log für die IPsec-Aushandlung. Die vollständige Zuordnung steht in Sophos Firewall Service- und Logdateien. Logs werden mit genauer Uhrzeit, Benutzer, öffentlicher Client-IP und Policy-Name korreliert; ein Service-Restart gehört nicht zum ersten Diagnoseschritt.

Anmeldung schlägt fehl oder der Benutzer erhält keinen Zugriff

Unter Authentication > Services die Methode für VPN (IPsec/dial-in/L2TP/PPTP) authentication methods prüfen. Danach kontrollieren, ob Benutzer oder Gruppe unter Add members eingetragen sind und welche Gruppe im Benutzerobjekt als Hauptgruppe erscheint. Bei RADIUS zusätzlich prüfen, ob Authentifizierung und optionale Lease-Zuweisung getrennt funktionieren.

Tunnel steht, aber interne Ziele sind nicht erreichbar

Lease-Adresse, Route Precedence, Firewall Rule ID, Zielroute und Rückweg nacheinander prüfen. Eine breite SD-WAN Route oder eine konkurrierende Static Route kann den Pfad verändern. Der L2TP-Pool muss im internen Netz erreichbar sein, ohne dass eine zweite gleichlautende Route oder ein überlappendes Netz den Rückweg übernimmt.

Zeigt der Log Viewer Rule 0, eine unerwartete Rule ID oder keinen passenden Eintrag, wird die konkrete Regelzuordnung vor jeder Erweiterung mit Any geklärt. Sieht man den Hinweg, aber keine Antwort, liegt der nächste Prüfpunkt am Zielhost, dessen Gateway, lokaler Firewall oder Rückroute.

Verbindung ist langsam oder instabil

Latenz, Packet Loss, MTU beziehungsweise Fragmentierung, WAN-Wechsel und CPU-Auslastung während eines reproduzierbaren Tests prüfen. Ein einzelner SMB-Transfer ist kein sauberer VPN-Durchsatztest. Mehrere kontrollierte TCP-Streams und beide Richtungen helfen, Tunnel, Transport und Anwendung zu unterscheiden.

Werden nur L2TP-Verbindungen instabil, Zeitstempel in l2tpd.log, IPsec-Logs, WAN-Ereignissen und Clientlog vergleichen. Erst wenn ein konkreter Zusammenhang belegt ist, werden Profil, MTU oder Idle-Zeit einzeln im Wartungsfenster verändert.

Nach SFOS 22 migrieren

Eine Firmwaremigration wird getrennt von einer Änderung der L2TP-Konfiguration geplant. Vor dem Upgrade werden die genaue Firmware und Plattform, globale L2TP-Einstellungen, erlaubte Benutzer und Hauptgruppen, jede L2TP-Policy samt Profil, IDs und Authentifizierung, Device Access, Route Precedence sowie die zugehörigen Firewall- und NAT-Regeln inventarisiert. Zusätzlich werden ein verschlüsseltes Backup und ein unabhängiger Managementzugang vorbereitet. Im SFOS 22 Upgrade-Check wird der konkrete Quell-Build gegen die aktuelle Upgrade-Tabelle geprüft; die pauschale Aussage, dass Konfigurationen zu 22.0 GA migriert werden können, ersetzt diese Pfadprüfung nicht.

Dabei darf L2TP nicht mit Remote Access IPsec (legacy) verwechselt werden: L2TP bleibt in SFOS 22.0 MR2 verfügbar, die Legacy-IPsec-Variante ist dagegen seit 22.0 MR1 ausser Betrieb. Eine Firewall mit dieser Legacy-Konfiguration lässt sich nicht auf 22.0 MR1 oder neuer aktualisieren. Zudem unterstützen SFOS 22.0 GA und neuer keine XG- oder SG-Hardware-Appliances. Plattform und bestehende Remote-Access-Typen sind deshalb echte Stop-Bedingungen und nicht nur Inventarpunkte.

SFOS 22.0 MR1 Build 490 behebt mit NC-162171, dass der NAS-Identifier bei L2TP-Verbindungen mit MS-CHAPv2 oder MS-CHAP nicht eingefügt wurde. Wer RADIUS-Regeln vom NAS-Identifier abhängig macht und von einem älteren Build kommt, prüft nach dem Upgrade deshalb nicht nur eine Anmeldung, sondern auch den empfangenen RADIUS-Request und die tatsächlich treffende RADIUS-Policy. Die Korrektur ist kein Beleg dafür, dass jede Client- und Authentifizierungskombination automatisch kompatibel ist.

Nach dem Neustart werden Firmwareversion und alle inventarisierten Felder verglichen. Danach folgt die vollständige Abnahme aus einem externen Netz, einschliesslich Negativtest, DNS, Datenpfad, Idle-Verhalten und einer neuen Anmeldung nach einem HA-Failover. Bis diese Prüfungen bestanden sind, bleibt die alte Zugriffsmethode als kontrollierter Rückweg verfügbar.

Ein Firmware-Rollback ist mehr als das Deaktivieren von L2TP. Aktive und vorherige Firmware liegen mitsamt ihrem jeweiligen Konfigurationsstand in getrennten Partitionen. Beim Booten der vorherigen Firmware wird deshalb auch deren früherer Konfigurationsstand wieder aktiv; Änderungen seit dem Upgrade sind danach nicht Teil der laufenden Konfiguration. Vor diesem Schritt werden benötigte Nachänderungen separat gesichert, die unterstützte Zielversion geprüft und das Wartungsfenster für den Neustart bestätigt.

L2TP-Konfiguration sicher zurückrollen

Beim Rollback bleibt der unabhängige Managementzugang geöffnet. Zuerst wird die zuvor gesicherte Route Precedence exakt wiederhergestellt und der Management-, Static-, SD-WAN- sowie VPN-Pfad geprüft. Danach wird die L2TP-Policy deaktiviert und mit einem Pilotclient bestätigt, dass keine produktive Abhängigkeit mehr besteht.

Anschliessend können die Firewall-Regeln und die IPsec-Freigabe zurückgenommen werden, sofern kein anderer Dienst davon abhängt. Erst danach werden Benutzer aus Add members entfernt und Enable L2TP deaktiviert. Der Preshared Key wird nicht blind auf einen früheren Wert gesetzt; alle Policies mit demselben WAN-Port und Wildcard-Gateway werden gemeinsam geprüft.

FAQ