L2TP Remote Access op Sophos Firewall instellen en testen

L2TP Remote Access is nog steeds beschikbaar op Sophos Firewall, maar zou niet automatisch de eerste keuze moeten zijn voor nieuwe beheerde endpoints. Sophos Connect met IPsec of SSL VPN is centraler te beheren en biedt het completere Sophos-clientpad. L2TP blijft nuttig wanneer een besturingssysteem zijn ingebouwde VPN-client moet gebruiken of wanneer een bestaande compatibele omgeving gecontroleerd moet worden voortgezet.

Beoordeling voor nieuwe omgevingen: De vergeleken helppagina’s voor SFOS 22 en 23 vermelden L2TP als een configureerbaar type externe toegang. Dit bevestigt de gedocumenteerde functionaliteit, niet de beschikbaarheid op elke build of een toezegging voor latere hoofdversies. Avanet raadt L2TP niet aan als nieuwe standaard voor beheerde clients. Implementeer geen nieuwe L2TP-toegang zonder een concrete legacy- of compatibiliteitsvereiste.

L2TP op zichzelf definieert de tunnel, niet de vereiste beveiliging. Op Sophos Firewall beschermt een IPsec-policy de verbinding. Het IPsec-profiel, de authenticatie, de preshared key of het certificaat en de clientconfiguratie moeten daarom op elkaar aansluiten. Een groene Active-status betekent bovendien alleen dat de policy is ingeschakeld; pas de Connection-status en werkelijk verkeer bevestigen de tunnel.

⚠️ De Route Precedence die Sophos voor L2TP vereist, plaatst vpn op de hele firewall vóór Static en SD-WAN Policy Routes. Een nieuwe L2TP-policy met een wildcard-peer kan ook bestaande preshared keys beïnvloeden. Documenteer daarom vóór de wijziging de huidige volgorde, een onafhankelijk beheerpad en alle andere VPN-, Static- en SD-WAN-paden.

L2TP in acht stappen

1. Controleren of L2TP werkelijk nodig is en of client, IPsec-profiel en authenticatie bij elkaar passen.
2. Een niet-overlappende private lease-range, interne DNS-servers en een beperkte gebruikersgroep plannen.
3. Onder Remote access VPN > L2TP > L2TP global settings L2TP inschakelen en gebruikers toevoegen.
4. Een L2TP-policy maken met het passende IPsec-profiel, de WAN-poort, authenticatie en NAT Traversal.
5. Onder Administration > Device access de service IPsec voor de noodzakelijke WAN-bereikbaarheid toestaan.
6. De huidige Route Precedence vastleggen en vpn gecontroleerd op de eerste plaats zetten.
7. Een beperkte firewallregel met logging maken van de zone VPN naar de interne doelen die werkelijk nodig zijn.
8. Met een externe pilotclient authenticatie, lease-adres, DNS, regel, retourpad en een negatieve test valideren.

Wanneer L2TP past

L2TP kan nuttig zijn voor ingebouwde clients van een besturingssysteem of bestaande apparaten waarop Sophos Connect niet is voorzien. Het is ook een begrijpelijke keuze wanneer een kleine, al gedocumenteerde L2TP-omgeving zonder extra clientsoftware moet blijven functioneren.

Voor een nieuwe standaarduitrol is Sophos Connect met IPsec of SSL VPN meestal geschikter. Profieldistributie, clientdiagnose en het Sophos-specifieke supportpad zijn daar duidelijker. Voor afzonderlijke toepassingen kan Clientless SSL VPN browsergebaseerde toegang bieden zonder een volwaardige netwerktunnel. PPTP is geen modern alternatief: het protocol definieert zelf noch versleuteling noch authenticatie; selecteerbare aanmeldingsmethoden maken het niet tot een veilige nieuwe doelarchitectuur.

Vóór de configuratie moeten drie grenzen duidelijk zijn:

• L2TP gebruikt op Sophos Firewall één gedeelde globale adrespool en gemeenschappelijke DNS-instellingen voor alle L2TP-policies.
• Groepen die uit Active Directory of Microsoft Entra ID zijn geïmporteerd, worden niet automatisch voor L2TP ingeschakeld. Ze moeten expliciet via Add members worden toegevoegd.
• L2TP en PPTP houden bij de evaluatie van groepslidmaatschappen alleen rekening met de relevante Main Group. Een aanvullend groepslidmaatschap bewijst daarom op zichzelf nog geen autorisatie. Gebruikersgroepen en Main Group correct beheren legt de achtergrond uit.

Voorbeeld en voorbereiding

In het voorbeeld maakt een externe client verbinding met een intern applicatienetwerk. De waarden zijn bewust documentatiewaarden en moeten aan de eigen omgeving worden aangepast:

• L2TP-pool: 10.250.30.10 tot 10.250.30.100 binnen 10.250.30.0/24
• interne DNS-server: 10.10.10.10
• toegestane groep: L2TP_Users
• policynaam: L2TP_Remote_Access
• IPsec-profiel: DefaultL2TP als uitgangspunt voor de compatibiliteitstest
• intern doelnetwerk: 10.10.10.0/24
• voorbeeldservice: HTTPS

De range 10.250.30.0/24 is alleen een privaat voorbeeldnetwerk. Deze mag niet overlappen met LAN-, VLAN-, Site-to-Site- of thuisnetwerken en evenmin met lease-ranges van Remote Access IPsec, SSL VPN of PPTP. Sophos staat voor Assign IP from maximaal 254 adressen binnen een /24 of kleiner subnet toe.

Controleer vóór de start ook het volgende:

• Een passend IPsec-profiel is afgestemd op de instellingen die de ingebouwde client ondersteunt.
• Het publieke adres of de FQDN van de geselecteerde WAN-poort is vanaf de client bereikbaar.
• Systeemtijd, DNS en de certificaatketen zijn correct wanneer een certificaat wordt gebruikt.
• De gebruiker of groep bestaat en de juiste authenticatiemethode staat onder Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• De huidige uitvoer van system route_precedence show en een bijbehorend rollbackcommando zijn gedocumenteerd.
• WebAdmin of de console blijft via een onafhankelijk beheerpad bereikbaar.

De authenticatiebron en de client moeten dezelfde methode ondersteunen: SFOS vermeldt PAP, CHAP of MSCHAPv2 voor Local en RADIUS, alleen PAP voor Active Directory en LDAP, en PAP of CHAP voor TACACS+. Controleer vóór de uitrol welke methode de bron en de ingebouwde client beide ondersteunen. De buitenste IPsec-beveiliging blijft voor L2TP verplicht; deze compatibiliteitsmatrix is geen aanbeveling voor PPTP of voor onbeveiligd gebruik van PAP.

Versie- en clientgrenzen

Deze handleiding is bedoeld voor SFOS 22.0 MR2 Build 546 en de interface die in de online-help voor 22.0 wordt beschreven. L2TP is in deze versie beschikbaar. De Avanet-upgradecontrole voor SFOS 22 bundelt actuele upgradeblokkades en ondersteunde paden; vergelijk daar vóór elke migratie de concrete bronbuild met de doelbuild. Er bestaat geen volledige compatibiliteitsmatrix voor ingebouwde L2TP-clients. De 22.0-handleiding noemt alleen Windows 10 als concreet clientvoorbeeld. Dat bewijst geen compatibiliteit met andere of latere versies van besturingssystemen.

De volledige L2TP-helppagina’s voor SFOS 22 en 23 beschrijven dezelfde globale instellingen, policyvelden en configuratiestappen. Deze documentatievergelijking is geen appliance- of clienttest en maakt van het SFOS 22-voorbeeld geen geteste SFOS 23-configuratie. De platformmatrix voor Sophos Connect, IPsec en SSL VPN in de Remote Access-FAQ is evenmin een L2TP-compatibiliteitsmatrix; volg voor een overstap de hierboven gelinkte clientvergelijking en de bijbehorende IPsec- of SSL VPN-procedure.

Test daarom elke werkelijk gebruikte OS-versie afzonderlijk met het bedoelde IPsec-profiel, de authenticatieserver en het ID-type. Het maximum van 254 pooladressen is alleen een adreslimiet en geen toezegging voor evenveel gelijktijdige sessies. De openbare 22.0-help noemt geen algemeen geldende limiet voor L2TP-sessies. Valideer capaciteit en stabiliteit op het daadwerkelijke firewallmodel met de verwachte gelijktijdigheid.

De huidige help beschrijft de selecteerbare waarden, maar noemt voor Gateway type, Authentication type, Allow NAT traversal en Disconnect when tunnel is idle geen universele standaardwaarde voor bestaande of gemigreerde configuraties. Leg deze velden vóór en na een upgrade vast in plaats van ze vanuit een veronderstelde default te reconstrueren.

De ingebouwde Windows-client configureren en controleren

Maak in Windows de verbinding via Instellingen > Netwerk en internet > VPN > VPN toevoegen. Selecteer Windows (ingebouwd) als VPN-provider, voer de publieke FQDN of het WAN-adres van de firewall in als Servernaam of -adres en kies als VPN-type L2TP/IPsec met vooraf gedeelde sleutel of de certificaatoptie die bij het firewallprofiel past. De vooraf gedeelde sleutel moet overeenkomen met de PSK van de L2TP-policy. Gebruik als aanmeldingsgegevens de gebruikersnaam en het wachtwoord van een account dat onder Add members is toegestaan; documenteer VPN-type, aanmeldingsmethode, ID’s en clientversie samen.

Voer de eerste test uit vanaf een extern netwerk. Controleer na het verbinden met ipconfig /all het adres uit de L2TP-pool en de bedoelde DNS-servers en test vervolgens interne naamomzetting en de toegestane HTTPS-toegang. Als het opbouwen van de tunnel zelf mislukt, vergelijk dan eerst servernaam, PSK- of certificaatmodus, aanmeldingsmethode en het afgestemde IPsec-profiel en correleer daarna het tijdstip met l2tpd.log en de IPsec-logs. Elke gebruikte Windows-versie blijft een afzonderlijk te valideren clientcombinatie.

Globale L2TP-instellingen configureren

Schakel onder Remote access VPN > L2TP > L2TP global settings de optie Enable L2TP in. Voer in dit voorbeeld bij Assign IP from 10.250.30.10 tot 10.250.30.100 in. Selecteer 10.10.10.10 als Primary DNS server wanneer deze server de interne namen kan omzetten. DNS is een optioneel veld: selecteer de server uit de lijst of voer het adres in via Other. Stel Secondary DNS server, Primary WINS server en Secondary WINS server alleen in wanneer de omgeving die werkelijk nodig heeft; WINS vervangt DNS niet.

De optie Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client is alleen zinvol wanneer de RADIUS-server betrouwbaar een geschikt adres levert. Als deze geen adres retourneert, gebruikt de firewall eerst een statisch adres dat voor de gebruiker is geconfigureerd, of daarna de globale pool. Zowel RADIUS-toewijzing als het fallbackpad moeten daarom zonder overlap worden gepland. RADIUS op Sophos Firewall instellen beschrijft de serverconfiguratie.

Selecteer vervolgens via Add members de groep L2TP_Users, voeg deze toe met Add en controleer deze met Show members. Voor een directorygebruiker is een geslaagde groepsimport alleen niet voldoende. Een pilotgebruiker moet werkelijk lid zijn van de toegestane groep, en die groep moet bij de L2TP-evaluatie als hoofdgroep worden gebruikt.

Klik na wijzigingen aan de globale instellingen en leden op Apply. Controleer daarna opnieuw de opgeslagen globale waarden en Show members. Save voor de L2TP-policy is een afzonderlijke, latere stap.

Grenzen van automatisering via de XML-API

De stappen in de interface vormen geen kant-en-klaar XML-API-verzoek. De vergeleken API-pagina’s voor SFOS 22 en 23 scheiden onder L2TPConfiguration de globale waarden in L2TPSettings van de leden in L2TPMembers met UserName. Anders dan de interface markeert de tabel PrimaryDNSServer als een verplicht veld met een IPv4-adres. Het optionele DNS-veld in de interface bewijst daarom niet dat deze API-parameter mag worden weggelaten. L2TPGeneralSettings en LeaseIPFromRadiusServer staan daar als optioneel vermeld, met Disable als gedocumenteerde standaardwaarde; daaruit volgt geen getest gedrag bij weglating. Voordat u automatiseert, moet het API-contract van de geïnstalleerde build duidelijk zijn, zonder een lege DNS-codering te raden. Lees daarna de bedoelde globale waarden en het lidmaatschap opnieuw uit; de hierboven beschreven interfaceprocedure en het RADIUS-fallbackproces blijven daarvan gescheiden.

Voor de hieronder beschreven opgeslagen policy toont het API-voorbeeld L2TPConnection met Configuration; daarnaast staan de besturingstakken Connection, DisConnection, Active en DeActive, elk met Name. Opslaan, verbinden, verbreken en activeren verwijzen dus niet naar dezelfde identiteit of actie. De pictogrammen in de interface tonen geen uitvoerbaar API-verzoek aan. Bovendien spreken het voorbeeld en de veldtabel elkaar tegen: RemoteHost bevat in het voorbeeld een hostnaam of IP-adres, terwijl de tabel IPv4 of * toestaat; AliasLocalWANPort staat in het voorbeeld alleen voor een WAN-alias, maar is in de tabel verplicht. Voor DisconnectOnIdleInterval noemt de tabel een standaardwaarde van 0, maar tegelijk een bereik van 120 tot 999; 600 is alleen de voorbeeldwaarde. Leid hieruit noch een betekenis voor nul noch veilige vervangende waarden af. Verduidelijk deze punten voor de specifieke build voordat u API-wijzigingen doorvoert en controleer het onafhankelijke beheerpad en de gevolgen voor gedeelde wildcard-PSK’s zoals hierboven beschreven.

Ook bij latere ontmanteling moet het verwijderen van een opgeslagen verbinding worden onderscheiden van het deactiveren ervan en het globaal uitschakelen van L2TP. Inventariseer eerst de bestaande configuratie, deactiveer de bedoelde verbinding en controleer afhankelijkheden. Delete L2TP Connection vereist de exacte opgeslagen Name (eerste letter A-Za-z, daarna A-Za-z0-9_, maximaal 50 tekens); de pagina geeft geen verzoekvoorbeeld. De statustoewijzingen 200/L2TPDeleteSuccess, 203/L2TPConnInUse en 500/L2TPDeleteFail verwijzen naar niet-opgeloste Message-identificatoren, niet naar bevestigde meldingsteksten of een HTTP-classificatie. Tel met name 203 niet als een generiek succesvol verwijderresultaat uit de 2xx-klasse. Zodra het verwijderverzoek is opgehelderd, controleert u opnieuw de exacte doelnaam en bevestigt u dat de nog benodigde productietoegang behouden is; raad geen envelopstructuur voor het verwijderverzoek of automatische vervolgopschoning.

Statisch gebruikersadres en bestaande PPTP-afhankelijkheden

De gebruikersgebonden leasevelden staan onder Authentication > Users > [Gebruiker] in het gedeelte met instellingen voor externe toegang. L2TP staat L2TP-toegang toe en bevat een veld voor het IP-adres dat aan de externe gebruiker moet worden geleased. PPTP heeft een eigen schakelaar en een apart invoerveld voor het te leasen IP-adres. Dit zijn twee afzonderlijke accountinstellingen, niet de globale pool en geen IP-toewijzing voor SSL VPN. Beheer de lokale gebruiker en diens wachtwoord volgens Lokale gebruikers op Sophos Firewall aanmaken. Plan alleen voor een gerechtvaardigde bestaande toegang een uniek, conflictvrij adres, sla het op met Save en controleer bij de volgende externe verbindingsopbouw het daadwerkelijk toegewezen adres en het retourpad. Bij RADIUS-leasing blijft het gebruikersadres de hierboven beschreven fallback wanneer RADIUS geen adres levert; een accountschakelaar vervangt noch de toestemming via Add members noch de firewallregel.

Eerste aanmelding vóór de tunnel: De Add-user-help voor SFOS 22 en 23 vereist dat policyleden na het inschakelen van L2TP of PPTP eerst bij het VPN portal inloggen en een wachtwoord aanmaken voordat ze verbinding maken. Controleer deze gedocumenteerde eerste toegang met een pilotaccount voor de gebruikte build en authenticatieserver. Reset bestaande wachtwoorden niet op goed geluk en schakel een werkende directoryaanmelding niet zonder meer over op lokale wachtwoorden. Controleer de bereikbaarheid van het portal en VPN portal authentication methods afzonderlijk van de tunnelmethode; hiervoor hoeft WebAdmin niet vanaf WAN toegankelijk te worden gemaakt.

Voor de inventarisatie van een reeds bestaande PPTP-toegang vindt u onder Remote access VPN > PPTP de opties Enable PPTP, Assign IP from, de gedeelde RADIUS-leasingoptie, de primaire DNS-server en optionele secundaire DNS-/WINS-servers. De lease geldt voor de duur van de verbinding; het private adresbereik ligt binnen een /24 of kleiner subnet en bevat maximaal 254 adressen. Het mag niet overlappen met de adresbereiken voor Remote Access IPsec en SSL VPN. De help beschrijft Apply voor globale waarden en Add members en Show members voor het toestaan van gebruikers; ook hier geeft een AD- of Entra ID-groepsimport niet automatisch toegang. Lees deze velden voor migratie en probleemoplossing alleen uit de bestaande configuratie af; dit is geen aanbeveling om PPTP in te schakelen. De gedocumenteerde methoden PAP, CHAP en MS-CHAPv2 bieden geen moderne beveiligingsstandaard; plan de vervanging met IPsec, SSL VPN of toepassingsgerichte toegang.

De L2TP-policy maken

Gebruik onder Remote access VPN > L2TP de knop Add om de policy L2TP_Remote_Access te maken.

Profiel en opstartgedrag

Selecteer onder Profile het IPsec-profiel dat bij de clients past. In het voorbeeld dient het bestaande profiel DefaultL2TP als uitgangspunt voor de compatibiliteitstest. De algoritmen en lifetimes moeten nog steeds worden vergeleken met de ondersteunde clientwaarden; een naam met Default is geen blijvende beveiligingsgarantie. De twee waarden van Gateway type hebben verschillende operationele gevolgen:

• Respond only houdt de policy na een herstart gereed zodat deze inkomende aanvragen kan beantwoorden.
• Disable laat de policy inactief totdat deze handmatig via de Active-status wordt ingeschakeld.

Voor een productieve Remote Access-service is Respond only meestal het begrijpelijke uitgangspunt. Controleer deze keuze expliciet na een herstart van firewall of service, zodat activering en verbindingsstatus niet met elkaar worden verward.

Authenticatie en preshared key

De beschikbare waarden voor Authentication type zijn Preshared key en Digital certificate. Digital certificate authenticeert de eindpunten door lokaal ondertekende of door een certificeringsinstantie uitgegeven certificaten uit te wisselen. Certificaten vermijden een gedeelde PSK, maar vereisen een volledig geplande vertrouwensketen en passende clientondersteuning. Een PSK moet lang en willekeurig zijn, via een apart kanaal worden overgebracht en regelmatig gecontroleerd worden vernieuwd.

Sophos gebruikt de laatst geconfigureerde PSK voor alle verbindingen met dezelfde luisterinterface en dezelfde remote peer. Bij Remote Access staat Remote host doorgaans op *. Een nieuwe of gewijzigde wildcard-policy kan daardoor de PSK van bestaande Remote Access-configuraties vervangen. Controleer vóór het opslaan alle policies die dezelfde WAN-poort en wildcard-gateway gebruiken.

Definieer bij een PSK overeenkomende waarden voor Local ID en Remote ID. Het ID-type DER ASN1DN (X.509) wordt niet geaccepteerd voor PSK. De ID’s moeten overeenkomen met de ingebouwde client en mogen niet voor het gemak op willekeurige waarden worden ingesteld.

WAN-poort, peer en selectors

Selecteer onder Local WAN port de WAN-poort die werkelijk bereikbaar is. Stel Remote host voor clients met wisselende adressen in op de wildcardwaarde *. Schakel Allow NAT traversal in wanneer clients zich achter NAT bevinden, wat normaal is op thuis-, mobiele en hotelnetwerken.

Voor de gebruikelijke Remote Access-workflow gebruikt het Sophos-voorbeeld Remote subnet: Any, Local port: 1701 en Remote port: *. 1701 is de L2TP-poort op de firewall; de clientpoort kan variëren. Deze waarden zijn tunnelselectors en vervangen geen firewallregel. De latere toegang blijft beperkt tot concrete zones, doelen en services.

Remote host kan voor een vaste peer ook een IP-adres of hostnaam bevatten. Remote subnet beschrijft de externe netwerken; controleer de waarde aan de hand van het concrete clientontwerp. De veldhelp staat voor Local port en Remote port TCP-/UDP-poorten of de wildcardwaarde * toe; het voorbeeld met lokale poort 1701 is geen algemene vereiste voor elk selectorontwerp. De policyhelp noemt dit gedeelte afwijkend QuickHA mode, terwijl de configuratiehandleiding over Quick Mode-selectors spreekt. Uit deze kop mag geen HA-functie worden afgeleid: de twee poortvelden en de op elkaar afgestemde IPsec-selectors zijn bepalend.

Met Disconnect when tunnel is idle kan de firewall inactieve clients na de onder Idle session time interval opgegeven periode verbreken. Pas de waarde aan het werkelijke werkpatroon aan en test deze met realistische pauzes. Een te korte periode veroorzaakt onnodige nieuwe verbindingen; zonder limiet kunnen vergeten sessies langer actief blijven. Idle session time interval wordt in seconden opgegeven.

Schakel na Save de policy in via het rode pictogram in de kolom Active. Groen onder Active betekent nog niet dat een client verbonden is. De afzonderlijke Connection-status toont of de tunnel daadwerkelijk is opgebouwd; de help beschrijft de verbindingsactie via het bijbehorende statuspictogram. Voor een externe client blijft diens verbindingspoging vanaf een extern netwerk bepalend. Logs op de L2TP-pagina opent de L2TP-logboeken. Wanneer Active is uitgeschakeld, is de policy inactief, ongeacht een eerdere tunnelstatus.

Bij meerdere lokale en externe subnetten ontstaat één tunnel per lokaal/extern subnetpaar. Connection kan een gedeeltelijke status tonen: de configuratie is actief, maar minstens één tunnel is niet opgebouwd. Test elk vereist subnetpaar en de bijbehorende gegevensstroom afzonderlijk; ingeschakeld Active bevestigt niet alle tunnels.

Bereikbaarheid, routing en firewallregel

IPsec op WAN toestaan

Onder Administration > Device access moet IPsec voor de noodzakelijke WAN-bereikbaarheid zijn toegestaan. Voer deze toestemming zo beperkt uit als de topologie toelaat. Een sterke PSK of een certificaat rechtvaardigt geen onnodig brede toegang tot WebAdmin, User Portal of SSH. Device Access en Local Service ACL legt de scheiding tussen servicebereikbaarheid en gebruikersautorisatie uit.

Route Precedence gecontroleerd instellen

De door Sophos gedocumenteerde standaardvolgorde is Static, SD-WAN Policy Routes en daarna VPN. Voor L2TP moeten VPN-routes juist eerst worden geëvalueerd; Static en SD-WAN mogen daarna in willekeurige volgorde volgen. Meld u aan bij de firewall-CLI en selecteer 4. Device Console. Leg daar eerst de werkelijke uitgangssituatie vast:

system route_precedence show

Stel vervolgens de gedocumenteerde L2TP-volgorde in en controleer deze opnieuw:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Deze wijziging geldt op de hele firewall en vormt geen afzonderlijke schakelaar voor de nieuwe L2TP-policy. Test vóór en na de wijziging overlappende Static-, SD-WAN- en VPN-paden, evenals de beheertoegang. Route Precedence op Sophos Firewall aanpassen legt de werking en veilige rollback uit.

Toegang tot interne doelen toestaan

Maak onder Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule een regel met logging en sla deze vervolgens op met Save. Geef een herkenbare Rule name op, bijvoorbeeld VPN-LAN. Het Sophos-voorbeeld met Any voor bron, bestemming en service is eenvoudig voor een eerste functionele controle, maar geen goede permanente beveiligingsstandaard. Dit voorbeeld is beperkter:

• Source zone: VPN
• Source network: de L2TP-pool 10.250.30.0/24 of een passend IP host-object
• Destination zone: de zone met het applicatienetwerk
• Destination network: 10.10.10.0/24 of bij voorkeur de benodigde servers
• Services: HTTPS of alleen de werkelijk benodigde services
• Log firewall traffic: ingeschakeld

Internetverkeer via de firewall vereist een afzonderlijke regel van VPN naar WAN en een bewust NAT- en beveiligingsontwerp. Deze toegang wordt niet automatisch aangemaakt alleen omdat de L2TP-tunnel actief is.

De verbinding valideren

Voer de validatie uit vanaf een werkelijk extern netwerk. Een test vanuit hetzelfde LAN of via een bestaand VPN-pad kan problemen met routing, NAT en publieke bereikbaarheid verhullen.

1. Verbinding maken met een bevoegde pilotgebruiker en de gedocumenteerde clientconfiguratie.
2. Onder Remote access VPN > L2TP de Active- en Connection-status afzonderlijk controleren. Bij meerdere lokale en externe subnetten ontstaat één tunnel per lokaal/extern subnetpaar. Connection kan een gedeeltelijke status tonen: de configuratie is actief, maar minstens één tunnel is niet opgebouwd. Test elk vereist subnetpaar en de bijbehorende gegevensstroom afzonderlijk; ingeschakeld Active bevestigt niet alle tunnels.
3. Controleren of de client een adres van 10.250.30.10 tot 10.250.30.100 en de bedoelde DNS-servers ontvangt.
4. Een interne naam omzetten en via HTTPS een expliciet toegestaan doel bereiken.
5. In Log Viewer de verwachte Firewall Rule ID, het bron-IP uit de L2TP-pool, doel, service en action controleren.
6. Het retourpad van het doelnetwerk naar de L2TP-pool controleren en dezelfde toegang na een nieuwe verbinding herhalen.
7. Een negatieve test uitvoeren met een gebruiker die niet is toegevoegd; deze mag geen bruikbare tunnel krijgen.
8. Idle-gedrag, verbreken, opnieuw verbinden en bij HA een gecontroleerde failover met een nieuwe aanmelding testen.

Geslaagde authenticatie bewijst nog geen werkend datapad. Een groene tunnel bewijst evenmin dat DNS, regel, NAT en retourpad kloppen. Sophos Firewall-regels testen legt uit hoe bewijs uit Log Viewer en Packet Capture van elkaar wordt gescheiden.

Problemen systematisch oplossen

De policy is actief, maar de tunnel blijft down

Vergelijk eerst WAN-poort, publieke bereikbaarheid, IPsec onder Device Access, NAT Traversal, clientadres, PSK of certificaat, Local/Remote ID en IPsec-profiel. Controleer daarna of een recenter opgeslagen wildcard-policy de verwachte PSK heeft vervangen.

Gebruik voor de eerste scheiding l2tpd.log voor L2TP en strongswan.log of charon.log voor de IPsec-onderhandeling. Sophos Firewall-services en logbestanden bevat de volledige toewijzing. Correleer logs met het exacte tijdstip, de gebruiker, het publieke client-IP en de policynaam; een serviceherstart is niet de eerste diagnosestap.

Aanmelding mislukt of de gebruiker krijgt geen toegang

Controleer onder Authentication > Services de methode voor VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Controleer daarna of gebruiker of groep onder Add members staat en welke groep in het gebruikersobject als Main Group wordt weergegeven. Controleer bij RADIUS authenticatie en optionele leasetoewijzing bovendien afzonderlijk.

De tunnel is up, maar interne doelen zijn onbereikbaar

Controleer achtereenvolgens lease-adres, Route Precedence, Firewall Rule ID, doelroute en retourpad. Een brede SD-WAN-route of concurrerende Static Route kan het pad wijzigen. De L2TP-pool moet vanuit het interne netwerk bereikbaar zijn zonder dat een tweede identieke route of overlappend netwerk het retourpad overneemt.

Als Log Viewer Rule 0, een onverwachte Rule ID of geen passend item toont, bepaal dan eerst welke regel werkelijk matcht voordat iets naar Any wordt verruimd. Wanneer het uitgaande pakket zichtbaar is maar geen antwoord terugkomt, gaat de volgende controle naar de doelhost, diens gateway, lokale firewall of retourroute.

De verbinding is traag of instabiel

Controleer latency, packet loss, MTU of fragmentatie, WAN-wisselingen en CPU-belasting tijdens een reproduceerbare test. Eén SMB-overdracht is geen zuivere VPN-doorvoertest. Meerdere gecontroleerde TCP-streams in beide richtingen helpen tunnel, transport en applicatie van elkaar te onderscheiden.

Wanneer alleen L2TP-verbindingen instabiel zijn, vergelijk dan tijdstempels in l2tpd.log, de IPsec-logs, WAN-events en het clientlog. Wijzig profiel, MTU of idle time alleen afzonderlijk en in een onderhoudsvenster nadat een concreet verband is aangetoond.

Neem bij de overstap naar Sophos Connect geen L2TP-regels over

De Remote Access-FAQ behandelt IPsec en SSL VPN, niet een aanvullende toestemming voor L2TP-clients. De platformtabel vermeldt voor Windows .pro of .scx voor IPsec en .pro of .ovpn voor SSL VPN; dezelfde bestandstypen worden genoemd voor macOS met Sophos Connect vanaf 2.1. macOS met Connect 2.0 gebruikt respectievelijk .scx en .ovpn; vóór 2.0 gebruikt IPsec Sophos Connect met .scx, terwijl SSL VPN een client van derden met .ovpn gebruikt. Android gebruikt clients van derden met .tgb voor IPsec of .ovpn voor SSL VPN; iOS heeft voor IPsec geen extra client nodig en downloadt de configuratie van het VPN portal, maar gebruikt voor SSL VPN een client van derden met .ovpn. Controleer vóór de vervanging de concrete actuele client-/OS-combinatie. Controleer de versleuteling voor IPsec onder Remote access VPN > IPsec > IPsec profiles > Encryption algorithm en voor SSL VPN onder Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings. De algemene FAQ-uitspraak over een versleutelde verbinding voor externe toegang mag niet worden toegepast op PPTP zonder eigen protocolbeveiliging.

Bij Sophos Connect Provisioning dienen de gateways in .pro alleen om de configuratie via het portal op te halen, niet om de tunnel te selecteren: IPsec gebruikt de geconfigureerde interface, SSL VPN de interfaces uit .ovpn die onder Network > Interfaces aanwezig zijn en via Local Service ACL zijn toegestaan. Override hostname stelt het gewenste publieke SSL VPN-adres in; achter een router moet diens publieke FQDN of WAN-IP in .pro staan, moet op de router een passende DNAT-doorsturing worden ingesteld en moet voor IPsec diens WAN-IP als gateway in .scx staan. Het private standaardcertificaat voor WebAdmin en VPN Portal kan bij provisioning een vertrouwensfout veroorzaken; corrigeer de certificaatketen in plaats van de controle uit te schakelen. De firewallconfiguratie voor Sophos Connect en de SSL VPN-procedure vervangen hier de L2TP-configuratie.

De FAQ vereist bij IPsec-wijzigingen Edit connection > Update policy en het opnieuw ophalen van de configuratie via het portal; bij SSL VPN betreffen handmatige updates vooral poort, protocol, gateway en SSL-servercertificaat. .pro haalt sommige SSL VPN-wijzigingen automatisch op; een nieuwe import kan beide configuraties opnieuw ophalen. Volg SSL VPN-profiel opnieuw downloaden om onderscheid te maken tussen een profielupdate en een downloadfout. Sophos Connect gebruikt de SSL VPN-gateways uit .ovpn in omgekeerde prioriteitsvolgorde, niet noodzakelijk in de volgorde van .pro. SSL VPN verdeelt de pool over CPU-afhankelijke instanties met eigen tun0-subnetten: adresbereiken kleiner dan /24 verminderen de leasecapaciteit; bij /27 en acht instanties vermeldt de FAQ slechts één resterend leaseadres. Dit is geen L2TP-poollimiet. Ontbrekende .ovpn-downloads kunnen ook samenhangen met gebruikers-ID’s boven de gezamenlijke gebruikers-/groeps-ID-limiet van 65535; Gebruikers-ID-limiet veilig controleren beschrijft gecontroleerd opschonen in plaats van zonder onderscheid verwijderen.

Plan MFA voor het vervangende toegangspad onder Authentication > Multi-factor authentication met de benodigde selectievakjes User portal, SSL VPN remote access en IPsec remote access. Het afzonderlijke OTP-veld vereist bij IPsec Prompt users for 2FA token en Apply, of bij provisioning otp: true en 2fa: 1. Sophos Connect verstuurt wachtwoord en OTP gecombineerd als passwordotp en ondersteunt volgens de FAQ geen OTP-challengeprocedure; bel-/pushmethoden worden ondersteund en WebAdmin ondersteunt daarnaast challenge-MFA. Controleer dit verschil tijdens de provisioningpilot en pas het niet toe op een ingebouwde L2TP-client. De FAQ beperkt Remote Access IPsec bovendien tot één WAN-interface; daaruit volgt noch dezelfde beperking voor L2TP noch een toezegging voor multi-WAN op het vervangende toegangspad.

Naar SFOS 22 migreren

Plan een firmwaremigratie afzonderlijk van een wijziging aan de L2TP-configuratie. Inventariseer vóór de upgrade de exacte firmware en het platform, globale L2TP-instellingen, toegestane gebruikers en Main Groups, elke L2TP-policy inclusief profiel, ID’s en authenticatie, Device Access, Route Precedence en de bijbehorende firewall- en NAT-regels. Bereid ook een versleutelde back-up en een onafhankelijk beheerpad voor. Gebruik de upgradecontrole voor SFOS 22 om de concrete bronbuild met de actuele upgradetabel te vergelijken; de algemene verklaring dat configuraties naar 22.0 GA kunnen worden gemigreerd, vervangt deze padcontrole niet.

Verwar L2TP niet met Remote Access IPsec (legacy): L2TP blijft beschikbaar in SFOS 22.0 MR2, terwijl de verouderde IPsec-variant in 22.0 MR1 is uitgefaseerd. Een firewall met deze verouderde configuratie kan niet naar 22.0 MR1 of hoger worden geüpgraded. Bovendien ondersteunen SFOS 22.0 GA en latere versies geen XG- of SG-hardware-appliances. Het platform en bestaande typen externe toegang zijn dus echte stopvoorwaarden en niet alleen inventarisgegevens.

SFOS 22.0 MR1 Build 490 verhielp NC-162171, waarbij de NAS-Identifier niet werd ingevoegd voor L2TP-verbindingen met MS-CHAPv2 of MS-CHAP. Als RADIUS-regels van de NAS-Identifier afhangen en de firewall van een oudere build komt, controleer dan na de upgrade niet alleen een aanmelding, maar ook de ontvangen RADIUS-request en de RADIUS-policy die werkelijk matcht. Deze correctie bewijst niet dat elke combinatie van client en authenticatie automatisch compatibel is.

Vergelijk na de herstart de firmwareversie en alle geïnventariseerde velden. Voer vervolgens de volledige validatie uit vanaf een extern netwerk, inclusief de negatieve test, DNS, het datapad, idle-gedrag en een nieuwe aanmelding na een HA-failover. Houd de oude toegangsmethode als gecontroleerd terugvalpad beschikbaar totdat deze controles slagen.

Een firmwarerollback is meer dan L2TP uitschakelen. De actieve en vorige firmware staan met hun respectieve configuratiestatus op afzonderlijke partities. Bij het starten van de vorige firmware wordt ook de eerdere configuratiestatus actief; wijzigingen sinds de upgrade maken na de rollback dus geen deel uit van de actieve configuratie. Bewaar vóór deze stap vereiste latere wijzigingen afzonderlijk, controleer de ondersteunde doelversie en bevestig het onderhoudsvenster voor de herstart.

De L2TP-configuratie veilig terugrollen

Rollback betekent dat alleen de tijdens deze procedure gewijzigde toestanden worden teruggebracht naar de gedocumenteerde uitgangssituatie, niet dat een bestaande L2TP-omgeving wordt ontmanteld. Leg daarom vóór de eerste wijziging de globale L2TP-waarden vast, inclusief Enable L2TP, de Active-status van elke betrokken policy, de volledige lijst onder Add members, gebruikersrechten, firewallregels en de IPsec-toestemming onder Administration > Device access; noteer nieuwe elementen en wijzigingen aan bestaande elementen afzonderlijk. Als uitgangswaarden ontbreken of er geen bevestigde methode is om de toestand exact te herstellen op de geïnstalleerde build, voer de betreffende wijziging dan niet uit; stem dit eerst af met Sophos Support. Een gedocumenteerde standaardwaarde vervangt geen uitgelezen uitgangswaarde.

Houd tijdens de rollback het onafhankelijke beheerpad open. Zet eerst een tijdens deze procedure gewijzigde Route Precedence exact terug naar de eerder vastgelegde volgorde, lees deze opnieuw uit met system route_precedence show en controleer het beheerpad en de Static-, SD-WAN- en VPN-paden. Als de volgorde al ongewijzigd was, blijft deze behouden.

Herstel bij een bestaande configuratie alleen de gewijzigde waarden, policystatussen, lidmaatschappen en rechten exact. Reeds bestaande policies, leden, regels en toestemmingen blijven in hun oorspronkelijke toestand behouden; een eerder ingeschakelde Enable L2TP blijft ingeschakeld. Het terugdraaien van één Device Console-wijziging is geen aanleiding om deze toegang te verwijderen of L2TP globaal uit te schakelen.

Het ontmantelen van een implementatie die uitsluitend tijdens deze procedure nieuw is aangemaakt, staat hier los van: controleer vóór elke deactivering of verwijdering de afhankelijkheden en bevestig dat geen nog benodigde productietoegang wordt geraakt. Deactiveer alleen dan de nieuw aangemaakte L2TP-policy en controleer de gevolgen met een pilotclient. Trek vervolgens uitsluitend nieuw aangemaakte, niet meer benodigde firewallregels en IPsec-toestemmingen in en verwijder alleen de tijdens deze procedure toegevoegde leden uit Add members. Schakel Enable L2TP alleen uit als deze optie vóór deze procedure uitgeschakeld was en er geen nog benodigde afhankelijkheid bestaat. Verwijder bestaande gedeelde elementen niet als onderdeel van de opschoning.

Vergelijk na het terugdraaien de opgeslagen globale waarden, Show members, policystatus, gebruikersrechten, regels en Device Access met de gedocumenteerde uitgangssituatie. Bevestig met een externe pilotclient dat de eerder benodigde productietoegang nog steeds werkt en dat ingetrokken testtoestemmingen geen toegang meer verlenen. Zet de Preshared Key niet blind terug naar een eerdere waarde; controleer alle policies met dezelfde WAN-poort en wildcard-gateway gezamenlijk.

FAQ