Set up and test L2TP remote access on Sophos Firewall

L2TP remote access remains available on Sophos Firewall, but it should not automatically be the first choice for new managed endpoints. Sophos Connect with IPsec or SSL VPN is easier to operate centrally and provides the more complete Sophos client path. L2TP remains useful when an operating system must use its native VPN client or when an existing compatible environment needs to be continued in a controlled manner.

Position for new deployments: The SFOS 22 and 23 help pages compared here list L2TP as a configurable remote-access type. This establishes the documented feature set, not availability on every build or a commitment for later major releases. Avanet does not recommend L2TP as a new standard for managed clients. Do not deploy a new L2TP service without a specific legacy or compatibility requirement.

L2TP alone defines the tunnel, not the required security. On Sophos Firewall, an IPsec policy protects the connection. The IPsec profile, authentication, preshared key or certificate, and client configuration must therefore match. A green Active status also means only that the policy is enabled; only the Connection status and actual traffic confirm the tunnel.

⚠️ The route precedence required by Sophos for L2TP places vpn globally ahead of Static and SD-WAN Policy Routes. A new L2TP policy with a wildcard peer can also affect existing preshared keys. Before making the change, document the current order, an independent management path, and all other VPN, Static, and SD-WAN paths.

L2TP in eight steps

1. Confirm that L2TP is actually required and that the client, IPsec profile, and authentication are compatible.
2. Plan a non-overlapping private lease range, internal DNS servers, and a narrowly scoped user group.
3. Under Remote access VPN > L2TP > L2TP global settings, enable L2TP and add users.
4. Create an L2TP policy with the matching IPsec profile, WAN port, authentication, and NAT traversal.
5. Under Administration > Device access, allow the IPsec service for the required WAN reachability.
6. Save the current route precedence and place vpn first in a controlled change.
7. Create a narrow, logged firewall rule from the VPN zone to the internal destinations that are actually required.
8. With an external pilot client, validate authentication, lease address, DNS, rule, return path, and a negative test.

When L2TP fits

L2TP can be useful for native operating-system clients or existing devices on which Sophos Connect is not intended. It is also a reasonable choice when a small, already documented L2TP environment needs to continue without additional client software.

For a new standard rollout, Sophos Connect with IPsec or SSL VPN is usually more suitable. Profile distribution, client diagnostics, and the Sophos-specific support path are clearer there. For individual applications, Clientless SSL VPN can provide browser-based access without a full network tunnel. PPTP is not a modern fallback: the protocol itself defines neither encryption nor authentication; selectable sign-in methods do not make it a secure new target architecture.

Three boundaries should be clear before configuration:

• On Sophos Firewall, L2TP uses one shared global address pool and shared DNS settings for all L2TP policies.
• Groups imported from Active Directory or Microsoft Entra ID are not automatically enabled for L2TP. They must be added explicitly under Add members.
• L2TP and PPTP consider only the relevant main group when evaluating group membership. An additional group membership alone therefore does not prove authorization. Manage user groups and the main group correctly explains the background.

Example and preparation

The example connects an external client to an internal application network. The values are deliberately documentation values and must be adapted to the local environment:

• L2TP pool: 10.250.30.10 to 10.250.30.100 within 10.250.30.0/24
• internal DNS server: 10.10.10.10
• permitted group: L2TP_Users
• policy name: L2TP_Remote_Access
• IPsec profile: DefaultL2TP as the starting point for the compatibility test
• internal destination network: 10.10.10.0/24
• example service: HTTPS

The range 10.250.30.0/24 is only a private example network. It must not overlap LAN, VLAN, site-to-site, or home networks, nor the lease ranges used by remote access IPsec, SSL VPN, or PPTP. Sophos allows no more than 254 addresses for Assign IP from, within a /24 or smaller subnet.

Before starting, also verify the following:

• A matching IPsec profile is aligned with the settings supported by the native client.
• The public address or FQDN of the selected WAN port is reachable from the client.
• System time, DNS, and the certificate chain are correct when a certificate is used.
• The user or group exists, and the correct authentication method is entered under Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• The current output of system route_precedence show and a matching rollback command are documented.
• WebAdmin or the console remains reachable through an independent management path.

The authentication source and client must support the same method: SFOS lists PAP, CHAP, or MSCHAPv2 for Local and RADIUS, only PAP for Active Directory and LDAP, and PAP or CHAP for TACACS+. Before rollout, verify the common method with the native client. The outer IPsec protection remains mandatory for L2TP; this compatibility matrix is not a recommendation for PPTP or unprotected PAP use.

Version and client boundaries

This guide is designed for SFOS 22.0 MR2 Build 546 and the interface described in the 22.0 online help. L2TP is available in this release. The Avanet SFOS 22 upgrade check tracks current upgrade blockers and supported paths; before every migration, check the specific source build against the target build there. There is no complete compatibility matrix for native L2TP clients. The 22.0 guide names only Windows 10 as a specific client example. That is not evidence of compatibility for other or later operating-system versions.

The complete L2TP help pages for SFOS 22 and 23 describe the same global settings, policy fields, and setup steps. This documentation comparison is not an appliance or client test and does not make the SFOS 22 example a validated SFOS 23 configuration. The platform matrix for Sophos Connect, IPsec, and SSL VPN in the remote-access FAQ is not an L2TP compatibility matrix either; when switching, follow the client comparison linked above and the relevant IPsec or SSL VPN procedure.

Therefore, test every OS version actually in use with the intended IPsec profile, authentication server, and ID type as a separate combination. The maximum of 254 pool addresses is only an address limit; it is not a promise of the same number of concurrent sessions. The public 22.0 help does not state a generally applicable L2TP session limit. Validate capacity and stability on the actual firewall model at the expected concurrency.

The current help describes the selectable values but does not identify a universal default for Gateway type, Authentication type, Allow NAT traversal, or Disconnect when tunnel is idle in existing or migrated configurations. Record these fields before and after an upgrade instead of reconstructing them from an assumed default.

Configure and verify the native Windows client

In Windows, create the connection under Settings > Network & internet > VPN > Add VPN. Select Windows (built-in) as the VPN provider, enter the firewall’s public FQDN or WAN address as the Server name or address, and choose L2TP/IPsec with pre-shared key or the certificate option that matches the firewall profile as the VPN type. The pre-shared key must match the L2TP policy’s PSK. Use the username and password of an account permitted under Add members as the sign-in information; document the VPN type, sign-in method, IDs, and client version together.

Run the first test from an external network. After connecting, use ipconfig /all to verify the address from the L2TP pool and the intended DNS servers, then test internal name resolution and the permitted HTTPS access. If tunnel establishment itself fails, first compare the server name, PSK or certificate mode, sign-in method, and agreed IPsec profile, then correlate the timestamp with l2tpd.log and the IPsec logs. Treat every Windows version in use as a separate client combination that requires validation.

Configure global L2TP settings

Under Remote access VPN > L2TP > L2TP global settings, turn on Enable L2TP. For Assign IP from, enter 10.250.30.10 to 10.250.30.100 in this example. Select 10.10.10.10 as the Primary DNS server if this server can resolve internal names. DNS is an optional field: select the server from the list or enter its address through Other. Set Secondary DNS server, Primary WINS server, and Secondary WINS server only when the environment actually requires them; WINS does not replace DNS.

The option Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client is useful only when the RADIUS server reliably supplies a suitable address. If it does not return an address, the firewall first uses a static address configured for the user or then the global pool. RADIUS assignment and the fallback path must therefore both be planned without overlaps. Set up RADIUS on Sophos Firewall explains the server configuration.

Then select the L2TP_Users group through Add members, add it with Add, and verify it with Show members. For a directory user, a successful group import alone is not enough. A pilot user must actually belong to the permitted group, and that group must be the main group used for the L2TP evaluation.

After changing the global settings and members, click Apply. Read back the saved global values and Show members. The later Save action for the L2TP policy is a separate step.

Limits of XML API automation

The UI steps are not a ready-made XML API request. The API pages compared for SFOS 22 and 23 separate the global values in L2TPSettings from the members in L2TPMembers with UserName, under L2TPConfiguration. Unlike the UI, the table marks PrimaryDNSServer as a required field containing an IPv4 address. The optional DNS field in the interface therefore does not prove that this API parameter may be omitted. L2TPGeneralSettings and LeaseIPFromRadiusServer are listed there as optional, with Disable as the documented default; do not infer preservation or default application when omitting them. Before automation, clarify the API contract for the installed build without guessing an empty DNS encoding. Afterwards, read back the intended global values and membership; the UI procedure and RADIUS fallback process described above remain separate.

For the saved policy described below, the API example shows L2TPConnection with Configuration; alongside it are the control branches Connection, DisConnection, Active and DeActive, each with Name. Saving, connecting, disconnecting and activating therefore do not refer to the same identity or action. The UI icons do not establish an executable API request. The example and field table also contradict each other: RemoteHost contains a hostname or an IP address in the example, while the table allows IPv4 or *; AliasLocalWANPort represents only a WAN alias in the example, but is required in the table. For DisconnectOnIdleInterval, the table gives a default of 0, yet also specifies a range of 120 to 999; 600 is only the example value. Do not infer either a meaning for zero or safe replacement values from this. Before making API changes, clarify these points for the specific build and check the independent management path and the effects on shared wildcard PSKs as described above.

During later decommissioning, deleting a saved connection must also be distinguished from deactivating it and from globally switching off L2TP. First inventory the existing configuration, deactivate the intended connection and check dependencies. Delete L2TP Connection requires the exact saved Name (first letter A-Za-z, followed by A-Za-z0-9_, no more than 50 characters); the page provides no request example. Its status mappings 200/L2TPDeleteSuccess, 203/L2TPConnInUse and 500/L2TPDeleteFail refer to unresolved Message identifiers, not confirmed message texts or an HTTP classification. In particular, do not count 203 as a generic 2xx deletion success. Once the deletion request has been clarified, check the exact target name again and confirm that production access still required has been preserved; do not guess a deletion request envelope or automatic follow-up cleanup.

Static user address and existing PPTP dependencies

The per-user lease fields are under Authentication > Users > [User] in the remote-access settings section. L2TP permits L2TP access and accepts an IP address to lease to the remote user. PPTP has its own switch and a separate field for the IP address to lease. These are two separate account settings, not the global pool or an SSL VPN IP assignment. Manage the local user and password as described in Create local users on Sophos Firewall. Only assign a unique, conflict-free address for an existing access requirement with a valid justification, save it with Save, and verify the address actually assigned and the return path on the next external connection. With RADIUS leasing, the user address remains the fallback described above if RADIUS does not supply an address; an account switch replaces neither authorization through Add members nor the firewall rule.

First sign-in before the tunnel: After L2TP or PPTP is enabled, the add-user help for SFOS 22 and 23 requires policy members to sign in to the VPN portal first and create a password before connecting. Verify this documented first-access procedure with a pilot account for the build and authentication server in use. Do not reset existing passwords speculatively or indiscriminately replace working directory authentication with local passwords. Check portal reachability and VPN portal authentication methods separately from the tunnel authentication method; this does not require opening WebAdmin access from the WAN.

When inventorying an existing PPTP service, Remote access VPN > PPTP contains Enable PPTP, Assign IP from, the shared RADIUS leasing option, the primary DNS server, and optional secondary DNS/WINS servers. The lease lasts for the duration of the connection; the private range must be within a /24 or smaller subnet and contain no more than 254 addresses. It must not overlap the remote-access IPsec or SSL VPN ranges. The help describes Apply for global values and Add members and Show members for user authorization; here too, importing an AD or Entra ID group does not automatically enable access. For migration and troubleshooting, read these fields from the existing configuration only; this is not a recommendation to enable PPTP. The documented PAP, CHAP, and MS-CHAPv2 methods do not provide a modern security standard; plan a replacement using IPsec, SSL VPN, or application-specific access.

Create the L2TP policy

Under Remote access VPN > L2TP, use Add to create the L2TP_Remote_Access policy.

Profile and startup behavior

Under Profile, select the IPsec profile that matches the clients. In the example, the existing DefaultL2TP profile is the starting point for the compatibility test. Its algorithms and lifetimes must still be checked against the client values; a name containing Default is not a permanent security guarantee. The two Gateway type values have different operating consequences:

• Respond only keeps the policy ready after a restart so that it can answer incoming requests.
• Disable leaves it inactive until it is switched on manually through the Active status.

For a production remote-access service, Respond only is usually the understandable starting point. Verify this choice explicitly after a firewall or service restart so that activation and connection status are not confused.

Authentication and preshared key

The available Authentication type values are Preshared key and Digital certificate. Digital certificate authenticates the endpoints by exchanging locally signed certificates or certificates issued by a certification authority. Certificates avoid a shared PSK but require a fully planned trust chain and suitable client support. A PSK must be long, random, transmitted separately, and renewed regularly in a controlled manner.

Sophos uses the most recently configured PSK for all connections with the same listening interface and remote peer. For remote access, Remote host is typically set to *. A new or changed wildcard policy can therefore replace the PSK of existing remote-access configurations. Before saving, review every policy that uses the same WAN port and wildcard gateway.

For a PSK, define matching Local ID and Remote ID values. The ID type DER ASN1DN (X.509) is not accepted for PSK. The IDs must match the native client; they should not be set to arbitrary values for convenience.

WAN port, peer, and selectors

Under Local WAN port, select the WAN port that is actually reachable. For clients with changing addresses, set Remote host to the wildcard value *. Enable Allow NAT traversal when clients are behind NAT, which is normal on home, mobile, and hotel networks.

For the typical remote-access workflow, the Sophos example uses Remote subnet: Any, Local port: 1701, and Remote port: *. 1701 is the L2TP port on the firewall; the client port can vary. These values are tunnel selectors and do not replace a firewall rule. Subsequent access remains restricted to specific zones, destinations, and services.

Remote host can also contain an IP address or hostname for a fixed peer. Remote subnet describes the remote networks; check the value against the specific client design. The field help allows TCP/UDP ports or the wildcard value * for Local port and Remote port; the example using local port 1701 is not a universal requirement for every selector design. The policy help labels this section QuickHA mode, whereas the setup guide refers to Quick Mode selectors. Do not infer an HA feature from this heading: what matters is the two port fields and the matching IPsec selectors.

With Disconnect when tunnel is idle, the firewall can disconnect inactive clients after the period specified under Idle session time interval. Adapt the value to the actual working pattern and test it with realistic pauses. A value that is too short causes unnecessary reconnections; without a limit, forgotten sessions can remain established for longer. Idle session time interval is specified in seconds.

After Save, switch on the policy through the red icon in the Active column. Green under Active does not yet mean that a client is connected. The separate Connection status shows whether the tunnel has actually been established; the help describes using its status icon to initiate the connection action. For a remote client, its external connection attempt remains the decisive check. Logs on the L2TP page opens the L2TP logs. When Active is disabled, the policy is inactive regardless of any previous tunnel state.

With multiple local and remote subnets, one tunnel is created for each local/remote subnet pair. Connection status can show a partial state: the configuration is active, but at least one tunnel is not established. Test every required subnet pair and its data flow separately; an enabled Active state does not confirm all tunnels.

Reachability, routing, and firewall rule

Allow IPsec on WAN

Under Administration > Device access, IPsec must be allowed for the required WAN reachability. Implement this allowance as narrowly as the topology permits. A strong PSK or a certificate does not justify unnecessarily broad WebAdmin, User Portal, or SSH access. Device Access and Local Service ACL explains the separation between service reachability and user authorization.

Set route precedence in a controlled change

The default order documented by Sophos is Static, SD-WAN Policy Routes, then VPN. For L2TP, VPN routes must instead be evaluated first; Static and SD-WAN may follow in either order. Sign in to the firewall CLI and select 4. Device Console. First save the actual initial state there:

system route_precedence show

Then set the documented L2TP order and check it again:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

This change is global and is not an isolated switch for the new L2TP policy. Before and after the change, test overlapping Static, SD-WAN, and VPN paths as well as management access. Adjust route precedence on Sophos Firewall explains the effect and safe rollback.

Allow access to internal destinations

Under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, create a logged rule and then save it with Save. Assign a descriptive Rule name, such as VPN-LAN. The Sophos example using Any for source, destination, and service is simple for an initial functional check, but it is not a good permanent security standard. The example here is narrower:

• Source zone: VPN
• Source network: the L2TP pool 10.250.30.0/24 or a matching IP host object
• Destination zone: the zone containing the application network
• Destination network: 10.10.10.0/24 or, preferably, the required servers
• Services: HTTPS or only the services actually required
• Log firewall traffic: enabled

Internet traffic through the firewall requires a separate rule from VPN to WAN and a deliberate NAT and security design. This access is not created automatically merely because the L2TP tunnel is established.

Validate the connection

Perform validation from a real external network. A test from the same LAN or through an existing VPN path can hide routing, NAT, and public-reachability problems.

1. Connect with an authorized pilot user and the documented client configuration.
2. Under Remote access VPN > L2TP, check Active and Connection status separately. With multiple local and remote subnets, one tunnel is created for each local/remote subnet pair. Connection status can show a partial state: the configuration is active, but at least one tunnel is not established. Test every required subnet pair and its data flow separately; an enabled Active state does not confirm all tunnels.
3. Verify that the client receives an address from 10.250.30.10 to 10.250.30.100 and the intended DNS servers.
4. Resolve an internal name and reach an explicitly permitted destination over HTTPS.
5. In Log Viewer, verify the expected Firewall Rule ID, source IP from the L2TP pool, destination, service, and action.
6. Verify the return path from the destination network to the L2TP pool and repeat the same access after reconnecting.
7. Run a negative test with a user who has not been added; this user must not receive a usable tunnel.
8. Test idle behavior, disconnect, reconnect, and, in HA, a controlled failover with a new sign-in.

Successful authentication does not prove the data path. Likewise, a green tunnel does not prove that DNS, the rule, NAT, and the return path are correct. Test Sophos Firewall rules explains how to separate Log Viewer and Packet Capture evidence.

Troubleshoot systematically

The policy is active, but the tunnel remains down

First compare the WAN port, public reachability, IPsec under Device Access, NAT traversal, client address, PSK or certificate, Local/Remote ID, and IPsec profile. Then check whether a wildcard policy saved more recently replaced the expected PSK.

For the first separation, use l2tpd.log for L2TP and strongswan.log or charon.log for the IPsec negotiation. Sophos Firewall service and log files provides the complete mapping. Correlate logs with the exact time, user, public client IP, and policy name; a service restart is not the first diagnostic step.

Sign-in fails or the user receives no access

Under Authentication > Services, check the method for VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Then verify whether the user or group is listed under Add members and which group appears as the main group in the user object. With RADIUS, additionally verify authentication and optional lease assignment separately.

The tunnel is up, but internal destinations are unreachable

Check the lease address, route precedence, Firewall Rule ID, destination route, and return path in that order. A broad SD-WAN route or a competing Static Route can change the path. The L2TP pool must be reachable from the internal network without a second identical route or an overlapping network taking over the return path.

If Log Viewer shows Rule 0, an unexpected Rule ID, or no matching entry, identify the actual rule match before widening anything to Any. If the outbound packet is visible but no response returns, continue at the destination host, its gateway, local firewall, or return route.

The connection is slow or unstable

Check latency, packet loss, MTU or fragmentation, WAN changes, and CPU usage during a reproducible test. A single SMB transfer is not a clean VPN throughput test. Several controlled TCP streams in both directions help separate the tunnel, transport, and application.

If only L2TP connections are unstable, compare timestamps in l2tpd.log, the IPsec logs, WAN events, and the client log. Change the profile, MTU, or idle time individually in a maintenance window only after a concrete relationship has been established.

Do not carry over L2TP rules when switching to Sophos Connect

The remote-access FAQ covers IPsec and SSL VPN, not additional L2TP client support. Its platform table lists .pro or .scx for IPsec and .pro or .ovpn for SSL VPN on Windows; it lists the same file types for macOS with Sophos Connect 2.1 or later. macOS with Connect 2.0 uses .scx and .ovpn, respectively; before 2.0, IPsec uses Sophos Connect with .scx, while SSL VPN uses a third-party client with .ovpn. Android uses third-party clients with .tgb for IPsec or .ovpn for SSL VPN; iOS requires no additional client for IPsec and downloads the configuration from the VPN portal, while SSL VPN requires a third-party client with .ovpn. Check the specific current client/OS combination before replacing the existing solution. Check encryption for IPsec under Remote access VPN > IPsec > IPsec profiles > Encryption algorithm and for SSL VPN under Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings. The FAQ’s general statement about encrypted remote-access connections must not be applied to PPTP, which has no protection built into the protocol itself.

With Sophos Connect provisioning, the gateways in .pro are used only to retrieve the configuration from the portal, not to select the tunnel: IPsec uses the configured interface, while SSL VPN uses the interfaces listed in .ovpn that exist under Network > Interfaces and are permitted by the Local Service ACL. Override hostname sets the desired public SSL VPN address; when the firewall is behind a router, put the router’s public FQDN or WAN IP in .pro, configure appropriate DNAT forwarding on the router, and use its WAN IP as the IPsec gateway in .scx. The private default certificate for WebAdmin and VPN Portal can cause a trust error during provisioning; correct the certificate chain rather than disabling validation. The firewall configuration for Sophos Connect and the SSL VPN procedure replace the L2TP setup procedure here.

For IPsec changes, the FAQ requires Edit connection > Update policy and retrieving the configuration from the portal again; for SSL VPN, manual updates particularly concern the port, protocol, gateway, and SSL server certificate. .pro retrieves some SSL VPN changes automatically; importing it again can retrieve both configurations anew. To distinguish a profile update from a download failure, follow Download the SSL VPN profile again. Sophos Connect uses the SSL VPN gateways from .ovpn in reverse priority order, not necessarily in .pro order. SSL VPN distributes the pool across CPU-dependent instances with their own tun0 subnets: ranges smaller than /24 reduce lease capacity; for /27 with eight instances, the FAQ states that only one lease address remains. This is not an L2TP pool limit. Missing .ovpn downloads can also be related to user IDs above the shared user/group ID limit of 65535; Check the user ID limit safely describes controlled cleanup rather than indiscriminate deletion.

Plan MFA for the replacement path under Authentication > Multi-factor authentication using the required selection fields User portal, SSL VPN remote access, and IPsec remote access. For IPsec, the separate OTP field requires Prompt users for 2FA token and Apply, or otp: true and 2fa: 1 in provisioning. Sophos Connect sends the password and OTP combined as passwordotp and, according to the FAQ, does not support an OTP challenge flow; call/push methods are supported, and WebAdmin additionally supports challenge-based MFA. Verify this distinction in the provisioning pilot; do not apply it to a native L2TP client. The FAQ also limits remote-access IPsec to one WAN interface; this implies neither the same limit for L2TP nor a multi-WAN guarantee for the replacement path.

Migrate to SFOS 22

Plan a firmware migration separately from a change to the L2TP configuration. Before upgrading, inventory the exact firmware and platform, global L2TP settings, permitted users and main groups, every L2TP policy including its profile, IDs, and authentication, Device Access, route precedence, and the associated firewall and NAT rules. Also prepare an encrypted backup and an independent management path. Use the SFOS 22 upgrade check to compare the specific source build with the current upgrade table; the broad statement that configurations can migrate to 22.0 GA does not replace this path check.

Do not confuse L2TP with remote access IPsec (legacy): L2TP remains available in SFOS 22.0 MR2, whereas the legacy IPsec option was retired in 22.0 MR1. A firewall containing that legacy configuration cannot be upgraded to 22.0 MR1 or later. In addition, SFOS 22.0 GA and later do not support XG or SG hardware appliances. The platform and existing remote-access types are therefore actual stop conditions, not merely inventory items.

SFOS 22.0 MR1 Build 490 fixed NC-162171, in which the NAS-Identifier was not inserted for L2TP connections using MS-CHAPv2 or MS-CHAP. If RADIUS rules depend on the NAS-Identifier and the firewall is moving from an older build, verify not only a sign-in after the upgrade but also the received RADIUS request and the RADIUS policy that actually matches. This fix is not evidence that every client and authentication combination is automatically compatible.

After the restart, compare the firmware version and every inventoried field. Then perform the full validation from an external network, including the negative test, DNS, data path, idle behavior, and a new sign-in after an HA failover. Keep the old access method available as a controlled fallback until these checks pass.

A firmware rollback is more than disabling L2TP. The active and previous firmware reside in separate partitions together with their respective configuration states. Booting the previous firmware therefore also makes its previous configuration state active, so changes made since the upgrade are not part of the running configuration after rollback. Before doing this, separately preserve required post-upgrade changes, verify the supported target version, and confirm the restart maintenance window.

Roll back the L2TP configuration safely

Rollback means restoring only the states changed during this procedure to the documented baseline, not decommissioning an existing L2TP environment. Before the first change, therefore, record the global L2TP values, including Enable L2TP, the Active status of each affected policy, the complete list under Add members, user permissions, firewall rules and the IPsec allowance under Administration > Device access; record new elements separately from changes to existing ones. If baseline values are missing or a method for exact restoration on the installed build has not been confirmed, do not make the affected change; clarify this with Sophos Support first. A documented default is not a substitute for a baseline value read from the actual configuration.

Keep the independent management path open during rollback. First, if route precedence was changed during this procedure, restore the exact order saved beforehand, read it back with system route_precedence show and check the management, Static, SD-WAN and VPN paths. If the order was already unchanged, leave it as it is.

For an existing configuration, restore only the changed values, policy states, memberships and permissions exactly. Preserve existing policies, members, rules and allowances in their original states; Enable L2TP must remain enabled if it was enabled beforehand. Reversing a single Device Console change is not a reason to remove this access or disable L2TP globally.

Decommissioning a deployment created entirely during this procedure is a separate process: before any deactivation or removal, check dependencies and confirm that no production access still required will be affected. Only then deactivate the newly created L2TP policy and check the effects with a pilot client. Next, revoke only newly created firewall rules and IPsec allowances that are no longer required, and remove only the members added under Add members during this procedure. Disable Enable L2TP only if it was disabled before this procedure and no dependency still required remains. Do not delete existing shared elements as part of cleanup.

After rollback, compare the saved global values, Show members, policy status, user permissions, rules and Device Access with the documented baseline. Use an external pilot client to confirm that previously required production access still works and that revoked test allowances no longer permit access. Do not blindly reset the preshared key to an earlier value; review all policies using the same WAN port and wildcard gateway together.

FAQ