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 verglichenen Hilfeseiten für SFOS 22 und 23 führen L2TP als konfigurierbaren Remote-Access-Typ. Das belegt den dokumentierten Funktionsumfang, nicht die Verfügbarkeit auf jedem Build oder eine Zusage für spätere Major-Versionen. 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. Für einzelne Anwendungen kann Clientless SSL VPN den browserbasierten Zugriff ohne vollwertigen Netzwerktunnel abdecken. PPTP ist keine moderne Ausweichlösung: Das Protokoll definiert selbst weder Verschlüsselung noch Authentifizierung; auswählbare Anmeldeverfahren machen es nicht zu einer sicheren neuen Zielarchitektur.

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.

Die vollständigen L2TP-Hilfeseiten für SFOS 22 und 23 beschreiben dieselben globalen Einstellungen, Policy-Felder und Einrichtungsschritte. Dieser Dokumentationsvergleich ist kein Appliance- oder Clienttest und macht aus dem SFOS-22-Beispiel keine geprüfte SFOS-23-Konfiguration. Die Plattformmatrix für Sophos Connect, IPsec und SSL VPN in der Remote-Access-FAQ ist ebenfalls keine L2TP-Kompatibilitätsmatrix; für einen Wechsel folgt man dem oben verlinkten Clientvergleich und dem jeweiligen IPsec- oder SSL-VPN-Ablauf.

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. DNS ist ein optionales Feld: Den Server aus der Liste wählen oder über Other seine Adresse eingeben. Secondary DNS server, Primary WINS server und Secondary WINS server werden nur gesetzt, wenn sie in der Umgebung tatsächlich gebraucht werden; WINS ersetzt DNS nicht.

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 ausgewählt, mit Add übernommen 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.

Grenzen bei XML-API-Automation

Die UI-Schritte sind kein fertiger XML-API-Auftrag. Die verglichenen API-Seiten für SFOS 22 und 23 trennen unter L2TPConfiguration die globalen Werte in L2TPSettings von den Mitgliedern in L2TPMembers mit UserName. Anders als die UI kennzeichnet die Tabelle PrimaryDNSServer als Pflichtfeld mit einer IPv4-Adresse. Das optionale DNS-Feld in der Oberfläche beweist deshalb nicht, dass dieser API-Parameter entfallen darf. L2TPGeneralSettings und LeaseIPFromRadiusServer sind dort optional und mit Disable als dokumentiertem Default aufgeführt; daraus folgt keine geprüfte Wirkung beim Weglassen. Vor Automation muss der API-Vertrag des installierten Builds geklärt sein, ohne eine leere DNS-Kodierung zu erraten. Danach die beabsichtigten globalen Werte und die Mitgliedschaft erneut auslesen; der oben beschriebene UI- und RADIUS-Rückfallablauf bleibt davon getrennt.

Für die unten beschriebene gespeicherte Policy zeigt das API-Beispiel L2TPConnection mit Configuration; daneben stehen die Steuerzweige Connection, DisConnection, Active und DeActive, jeweils mit Name. Speichern, Verbinden, Trennen und Aktivieren sind somit nicht dieselbe Identität oder Aktion. Die UI-Symbole belegen keinen ausführbaren API-Auftrag. Zudem widersprechen sich Beispiel und Feldtabelle: RemoteHost enthält im Beispiel einen Hostnamen oder eine IP-Adresse, die Tabelle erlaubt IPv4 oder *; AliasLocalWANPort steht im Beispiel nur für einen WAN-Alias, ist in der Tabelle aber Pflicht. Für DisconnectOnIdleInterval nennt die Tabelle Default 0, zugleich jedoch den Bereich 120 bis 999; 600 ist nur der Beispielwert. Daraus weder eine Bedeutung für Null noch sichere Ersatzwerte ableiten. Vor API-Änderungen diese Punkte build-spezifisch klären und den unabhängigen Managementzugang sowie die Auswirkungen auf gemeinsame Wildcard-PSKs wie oben prüfen.

Auch beim späteren Rückbau ist das Löschen einer gespeicherten Verbindung von deren Deaktivierung und vom globalen Abschalten von L2TP zu unterscheiden. Zuerst den Bestand erfassen, die vorgesehene Verbindung deaktivieren und Abhängigkeiten prüfen. Delete L2TP Connection verlangt den exakten gespeicherten Name (erster Buchstabe A-Za-z, danach A-Za-z0-9_, höchstens 50 Zeichen); die Seite liefert kein Request-Beispiel. Ihre Statuszuordnungen 200/L2TPDeleteSuccess, 203/L2TPConnInUse und 500/L2TPDeleteFail verweisen auf nicht aufgelöste Message-Bezeichner, nicht auf bestätigte Meldungstexte oder eine HTTP-Klassifikation. Insbesondere 203 nicht als allgemeinen 2xx-Löscherfolg zählen. Nach einem geklärten Löschauftrag den exakten Zielnamen erneut prüfen und bestätigen, dass die weiterhin benötigten produktiven Zugänge erhalten sind; keinen Löschumschlag oder eine automatische Folgebereinigung erraten.

Statische Benutzeradresse und bestehende PPTP-Abhängigkeiten

Die benutzerbezogenen Lease-Felder stehen unter Authentication > Users > [Benutzer] im Bereich der Remote-Access-Einstellungen. L2TP erlaubt den L2TP-Zugang und nimmt eine IP-Adresse auf, die dem Remote-Benutzer geleast werden soll. PPTP besitzt einen eigenen Schalter und eine eigene Eingabe für die zu leasende IP-Adresse. Das sind zwei getrennte Kontoeinstellungen, nicht der globale Pool und keine SSL-VPN-IP-Zuweisung. Den lokalen Benutzer und dessen Passwort verwaltet man nach Lokale Benutzer auf Sophos Firewall anlegen. Nur für einen begründeten bestehenden Zugang eine eindeutige, konfliktfreie Adresse planen, mit Save speichern und beim nächsten externen Verbindungsaufbau die tatsächlich zugewiesene Adresse sowie den Rückweg prüfen. Bei RADIUS-Leasing bleibt die Benutzeradresse der oben beschriebene Rückfall, wenn RADIUS keine Adresse liefert; ein Kontoschalter ersetzt weder die Freigabe über Add members noch die Firewall-Regel.

Erste Anmeldung vor dem Tunnel: Die Add-user-Hilfe für SFOS 22 und 23 verlangt nach dem Einschalten von L2TP oder PPTP, dass Policy-Mitglieder sich zuerst am VPN portal anmelden und ein Passwort erstellen, bevor sie sich verbinden. Diesen dokumentierten Erstzugang mit einem Pilotkonto für den eingesetzten Build und Authentifizierungsserver prüfen. Bestehende Kennwörter nicht auf Verdacht zurücksetzen und eine funktionierende Verzeichnisanmeldung nicht pauschal auf lokale Passwörter umstellen. Portal-Erreichbarkeit und VPN portal authentication methods sind separat von der Tunnelmethode zu prüfen; WebAdmin muss dafür nicht aus dem WAN geöffnet werden.

Für die Inventur eines bereits vorhandenen PPTP-Zugangs findet man unter Remote access VPN > PPTP Enable PPTP, Assign IP from, die gemeinsame RADIUS-Leasing-Option sowie den primären DNS-Server und optionale sekundäre DNS-/WINS-Server. Die Lease gilt für die Dauer der Verbindung; der private Bereich liegt in einem /24 oder kleineren Subnetz und enthält höchstens 254 Adressen. Er darf die Remote-Access-IPsec- und SSL-VPN-Bereiche nicht überlappen. Die Hilfe beschreibt Apply für globale Werte sowie Add members und Show members für die Benutzerfreigabe; auch hier schaltet ein AD- oder Entra-ID-Gruppenimport den Zugriff nicht automatisch frei. Diese Felder werden für Migration und Fehlersuche nur am bestehenden Stand abgelesen, nicht als Empfehlung zum Einschalten von PPTP. Die dokumentierten Verfahren PAP, CHAP und MS-CHAPv2 liefern keinen modernen Sicherheitsstandard; der Ersatz wird mit IPsec, SSL VPN oder anwendungsbezogenem Zugriff geplant.

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. Digital certificate authentifiziert die Endpunkte durch den Austausch lokal signierter oder von einer Zertifizierungsstelle ausgestellter Zertifikate. 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.

Remote host kann für eine feste Gegenstelle auch eine IP-Adresse oder einen Hostnamen enthalten. Remote subnet beschreibt die entfernten Netze; den Wert gegen das konkrete Clientdesign prüfen. Die Feldhilfe erlaubt für Local port und Remote port TCP-/UDP-Ports oder den Wildcard-Wert *; das Beispiel mit lokalem Port 1701 ist keine allgemeine Vorgabe für jedes Selektordesign. Die Policy-Hilfe nennt diesen Abschnitt abweichend QuickHA mode, während die Einrichtungsanleitung von Quick-Mode-Selektoren spricht. Aus dieser Überschrift darf keine HA-Funktion abgeleitet werden: Entscheidend sind die beiden Portfelder und die abgestimmten IPsec-Selektoren.

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; über dessen Statussymbol beschreibt die Hilfe die Verbindungsaktion. Für einen Remote-Client bleibt dessen externer Verbindungsversuch massgeblich. Logs auf der L2TP-Seite öffnet die L2TP-Protokolle. Bei deaktiviertem Active ist die Policy inaktiv, unabhängig von einem früheren Tunnelzustand.

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. An der Firewall-CLI anmelden und 4. Device Console wählen. Zuerst wird dort die tatsächliche Ausgangslage 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 > IPv4 > Add firewall rule > New firewall rule wird eine geloggte Regel erstellt und anschliessend mit Save gespeichert. Einen nachvollziehbaren Rule name, beispielsweise VPN-LAN, vergeben. 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.

Beim Wechsel zu Sophos Connect nicht L2TP-Regeln übertragen

Die Remote-Access-FAQ behandelt IPsec und SSL VPN, nicht eine zusätzliche L2TP-Clientfreigabe. Ihre Plattformtabelle nennt für Windows .pro oder .scx für IPsec sowie .pro oder .ovpn für SSL VPN; dieselben Dateitypen nennt sie für macOS mit Sophos Connect ab 2.1. macOS mit Connect 2.0 verwendet .scx beziehungsweise .ovpn; vor 2.0 bleibt IPsec bei Sophos Connect mit .scx, SSL VPN hingegen bei einem Drittclient mit .ovpn. Android verwendet Drittclients mit .tgb für IPsec oder .ovpn für SSL VPN; iOS benötigt für IPsec keinen zusätzlichen Client und lädt die Konfiguration vom VPN portal, für SSL VPN einen Drittclient mit .ovpn. Die konkrete aktuelle Client-/OS-Kombination vor der Ablösung prüfen. Verschlüsselung wird für IPsec unter Remote access VPN > IPsec > IPsec profiles > Encryption algorithm und für SSL VPN unter Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings geprüft. Die pauschale FAQ-Aussage zur verschlüsselten Remote-Access-Verbindung darf nicht auf PPTP ohne eigene Protokollabsicherung übertragen werden.

Bei Sophos Connect Provisioning dienen die Gateways in .pro nur zum Portalabruf, nicht zur Tunnelwahl: IPsec verwendet die konfigurierte Schnittstelle, SSL VPN die in Network > Interfaces vorhandenen und per Local Service ACL freigegebenen Interfaces aus .ovpn. Override hostname setzt die gewünschte öffentliche SSL-VPN-Adresse; hinter einem Router gehören dessen öffentlicher FQDN oder WAN-IP in .pro, eine passende DNAT-Weiterleitung auf den Router und für IPsec dessen WAN-IP als Gateway in .scx. Das private Standardzertifikat für WebAdmin und VPN Portal kann beim Provisioning einen Vertrauensfehler verursachen; die Zertifikatskette korrigieren, nicht die Prüfung deaktivieren. Die Firewall-Konfiguration für Sophos Connect und der SSL-VPN-Ablauf ersetzen hier die L2TP-Einrichtung.

Die FAQ verlangt bei IPsec-Änderungen Edit connection > Update policy und den erneuten Portalabruf; bei SSL VPN betreffen manuelle Updates insbesondere Port, Protokoll, Gateway und SSL-Serverzertifikat. .pro ruft einige SSL-VPN-Änderungen automatisch ab; ein erneuter Import kann beide Konfigurationen neu beziehen. Für die Abgrenzung zwischen Profilupdate und Downloadfehler folgt man SSL-VPN-Profil erneut herunterladen. Sophos Connect verwendet die SSL-VPN-Gateways aus .ovpn in umgekehrter Prioritätsreihenfolge, nicht zwingend in .pro-Reihenfolge. SSL VPN verteilt den Pool auf CPU-abhängige Instanzen mit eigenen tun0-Subnetzen: kleinere Bereiche als /24 verkleinern die Lease-Kapazität; bei /27 und acht Instanzen nennt die FAQ nur eine verbleibende Lease-Adresse. Das ist kein L2TP-Poollimit. Fehlende .ovpn-Downloads können auch mit Benutzer-IDs oberhalb der gemeinsamen Benutzer-/Gruppen-ID-Grenze von 65535 zusammenhängen; User-ID-Limit sicher prüfen beschreibt die kontrollierte Bereinigung statt pauschalen Löschens.

MFA für den Ersatzpfad wird unter Authentication > Multi-factor authentication mit den benötigten Auswahlfeldern User portal, SSL VPN remote access und IPsec remote access geplant. Das separate OTP-Feld erfordert bei IPsec Prompt users for 2FA token und Apply beziehungsweise im Provisioning otp: true und 2fa: 1. Sophos Connect sendet Passwort und OTP kombiniert als passwordotp und unterstützt laut FAQ keinen OTP-Challenge-Ablauf; Call-/Push-Verfahren werden unterstützt, WebAdmin zusätzlich Challenge-MFA. Diesen Unterschied im Provisioning-Pilot prüfen, nicht auf einen nativen L2TP-Client übertragen. Die FAQ beschränkt Remote-Access-IPsec ausserdem auf eine WAN-Schnittstelle; daraus folgt weder dieselbe L2TP-Grenze noch ein Multi-WAN-Versprechen für den Ersatzpfad.

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

Rollback bedeutet, nur die während dieses Verfahrens geänderten Zustände auf die dokumentierte Ausgangslage zurückzuführen, nicht eine bestehende L2TP-Umgebung abzubauen. Vor der ersten Änderung werden deshalb die globalen L2TP-Werte einschliesslich Enable L2TP, der Active-Status jeder betroffenen Policy, die vollständige Liste unter Add members, Benutzerberechtigungen, Firewall-Regeln und die IPsec-Freigabe unter Administration > Device access festgehalten; neue Elemente und Änderungen am Bestand werden getrennt notiert. Fehlen Ausgangswerte oder ein bestätigter Weg zur exakten Wiederherstellung auf dem installierten Build, wird die betreffende Änderung nicht ausgeführt; zuerst mit Sophos Support klären. Ein dokumentierter Default ersetzt keinen abgelesenen Ausgangswert.

Beim Rollback bleibt der unabhängige Managementzugang geöffnet. Zuerst wird eine während dieses Verfahrens geänderte Route Precedence exakt auf die zuvor gesicherte Reihenfolge zurückgesetzt, mit system route_precedence show erneut abgelesen und der Management-, Static-, SD-WAN- sowie VPN-Pfad geprüft. War die Reihenfolge bereits unverändert, bleibt sie erhalten.

Bei einer bestehenden Konfiguration werden nur die geänderten Werte, Policy-Zustände, Mitgliedschaften und Berechtigungen exakt wiederhergestellt. Bereits vorhandene Policies, Mitglieder, Regeln und Freigaben bleiben mit ihrem ursprünglichen Zustand erhalten; ein zuvor aktiviertes Enable L2TP bleibt aktiviert. Das Zurücknehmen einer einzelnen Device-Console-Änderung ist kein Anlass, diese Zugänge zu entfernen oder L2TP global abzuschalten.

Der Rückbau einer ausschliesslich während dieses Verfahrens neu angelegten Bereitstellung ist davon getrennt: Vor jeder Deaktivierung oder Entfernung werden die Abhängigkeiten geprüft und bestätigt, dass kein weiterhin benötigter produktiver Zugang betroffen ist. Nur dann die neu angelegte L2TP-Policy deaktivieren und mit einem Pilotclient die Auswirkungen kontrollieren. Anschliessend ausschliesslich neu angelegte, nicht mehr benötigte Firewall-Regeln und IPsec-Freigaben zurücknehmen und nur die während dieses Verfahrens hinzugefügten Mitglieder aus Add members entfernen. Enable L2TP nur deaktivieren, wenn es vor diesem Verfahren deaktiviert war und keine weiterhin benötigte Abhängigkeit besteht. Bestehende gemeinsam genutzte Elemente werden nicht als Bereinigung gelöscht.

Nach der Rücknahme die gespeicherten globalen Werte, Show members, Policy-Status, Benutzerberechtigungen, Regeln und Device Access mit der dokumentierten Ausgangslage vergleichen. Mit einem externen Pilotclient bestätigen, dass die zuvor benötigten produktiven Zugänge weiterhin funktionieren und zurückgenommene Testfreigaben keinen Zugriff mehr erlauben. 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