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 current SFOS 22 help continues to document L2TP as a configurable remote access type. Sophos has not published a retirement notice for it. However, this does not guarantee support in a later major release. 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. PPTP is not a modern fallback: the protocol itself does not define encryption and should no longer be planned for new remote-access connections.

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.

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 the internal names. Set secondary DNS and WINS only when the environment actually requires them.

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 add the L2TP_Users group through Add members 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.

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. 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 under controlled conditions.

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.

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.

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. First save the actual initial state in the Device Console:

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, create a logged IPv4 rule. 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.

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

Keep the independent management path open during rollback. First restore the exact saved route precedence and test management, Static, SD-WAN, and VPN paths. Then disable the L2TP policy and use a pilot client to confirm that no production dependency remains.

Next remove the firewall rules and IPsec allowance if no other service depends on them. Only then remove users from Add members and turn off Enable L2TP. Do not blindly reset the preshared key to an earlier value; review all policies using the same WAN port and wildcard gateway together.

FAQ