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.

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.

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.

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.

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

Sophos verlangt für L2TP, dass VPN-Routen vor Static und SD-WAN Policy Routes ausgewertet werden. Zuerst wird die 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.
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.

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