Use global VPN settings on Sophos Firewall safely

The Sophos Firewall Device Console provides global settings under set vpn for VPN failover, IPsec processing, and the legacy L2TP and PPTP protocols. They don’t only affect the connection currently being investigated. An unfocused test can influence other tunnels, remove existing sessions, or weaken a protection function.

Not a general performance recipe: Don’t preemptively set ipsec-max-workqueue-items, the anti-replay window, or use-resolved-ip-address to larger values or enable. Sophos describes these as advanced settings to use for a specific network requirement or on advice from Sophos Support.

For ordinary tunnel issues, start with IPsec VPN troubleshooting. It checks IKE, the Child SA, routing, NAT, rules, and the actual packet flow. The global switches in this article only become relevant when the symptom precisely matches their purpose.

Record the baseline before every change

Run the commands under 4. Device Console. Before setting a value, record the SFOS version and build, time, affected tunnels, expected test flow, and an independent management path. Also create a current configuration backup. The SFOS 22 CLI help documents only set vpn for these values, not a read command. Existing change records and backups are supporting evidence, but don’t prove the current runtime value. Have Sophos Support confirm a method for reading the exact value on the installed build, record its output, and prepare the matching set vpn rollback command. If Support can’t confirm a read method or the current value can’t be established, stop: don’t change the global setting.

The SFOS 22 help only states defaults for the L2TP MTU, anti-replay window, cookie threshold, and resolved peer address. Even these defaults don’t prove that the specific appliance still has an unchanged configuration.

For a custom configuration, rollback always means the baseline established safely beforehand. The documented syntax has no universal default parameter. The default commands shown below are only appropriate when the change explicitly intends to return to the documented SFOS 22 default; they must not overwrite an intentionally different baseline.

Sessions during tunnel and WAN transitions

conn-remove-tunnel-up controls whether existing connections are removed when an IPsec tunnel comes up. This can matter when a flow started over another path and remains pinned to the wrong path after the tunnel is established. Removing it can also interrupt productive sessions. The SFOS 22 help doesn’t state a default for this switch, so restore the value established safely beforehand.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover controls global cleanup during failover and failback. all affects all connections, while non-tcp limits cleanup to non-TCP traffic such as UDP or ICMP. The correct value is therefore not only a VPN decision: observe VoIP, video conferencing, DNS, and other UDP applications in the same test window.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

The SFOS 22 help doesn’t state a default for conn-remove-on-failover either. To roll back, run exactly set vpn conn-remove-on-failover all or set vpn conn-remove-on-failover non-tcp, according to the recorded baseline.

In HA, test each protocol separately. According to the SFOS 22 HA help, route-based, policy-based, and remote access IPsec tunnels are restored during failover. For traffic inside an IPsec tunnel, HA session failover supports stateless protocols such as UDP and ICMP, but not stateful protocols such as TCP. The two conn-remove-* switches therefore replace neither the HA design nor tests with one existing TCP and UDP flow each.

Keep similarly named settings in the correct scope

Not every global or VPN-adjacent option belongs to set vpn. Match the path to the symptom before making a change:

• IPsec profile: Under System > Profiles > IPsec profiles, Use strict profile and Pass data in compressed format apply to connections using that profile. The profile help says strict profile can prevent handshake issues caused by packet fragmentation, while compression compresses the payload before encryption. Neither is a global fragmentation or performance switch.
• SSL VPN: Remote access VPN > SSL VPN > SSL VPN global settings applies to all remote access SSL VPN policies and becomes part of the .ovpn file. Only there does Disconnect dead peer after default to 180 seconds for TCP and 100 seconds for UDP; the SSL VPN help allows 60 to 110 for UDP. Disconnect idle peer after is in minutes, but this help page doesn’t state a default. Don’t apply these values to IPsec or L2TP.
• L2TP web admin: Remote access VPN > L2TP > L2TP global settings applies to all L2TP policies. It controls enablement, lease range, RADIUS leasing, DNS, WINS, and members. The documented pool must be private, belong to a /24 or smaller subnet, and contain no more than 254 addresses. Sophos states that the L2TP and PPTP address ranges must not overlap remote access IPsec or SSL VPN configurations; it doesn’t state on this page that the L2TP and PPTP ranges must not overlap each other. The CLI authentication and MTU below remain L2TP-specific.
• Firewall-wide values: set advanced-firewall tcp-est-idle-timeout, udp-timeout, udp-timeout-stream, and fragmented-traffic aren’t VPN settings. The SFOS 22 CLI help gives 2700-432000 seconds for established TCP sessions, 30-3600 seconds for each UDP timeout, and allow as the fragmented-traffic default. Don’t change firewall-wide values to repair a single tunnel.

IPsec performance and protection controls

The ipsec-performance group contains four very different functions. Its name can encourage tuning experiments even though only one function directly defines a workqueue size.

Change the workqueue only for a proven bottleneck

ipsec-max-workqueue-items accepts values from 1024 to 10240. The queue holds work for IPsec processing. A larger value doesn’t guarantee higher throughput and doesn’t fix packet loss, MTU problems, weak single-stream results, or a saturated WAN circuit.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

A change only makes sense when a reproducible load test, system utilization, and Sophos diagnostics point to this exact bottleneck. First check MTU and MSS, latency, packet loss, the encryption profile, IPsec acceleration, and parallel test streams separately. Restore the recorded baseline when the test doesn’t improve.

Sophos doesn’t document a default for ipsec-max-workqueue-items. Roll back with set vpn ipsec-performance ipsec-max-workqueue-items <recorded-baseline>.

The anti-replay window is a security control

IPsec records which packets it has already seen during decryption within the replay window. It can therefore detect and discard replayed packets. SFOS 22 accepts 0, 32, 64, 128, 256, 512, 1024, 2048, and 4096; the documented default is 1024.

set vpn ipsec-performance anti-replay window-size <value>

A larger window can be relevant when packets are heavily reordered across parallel paths. It isn’t a general throughput switch. The value 0 removes anti-replay protection and isn’t recommended as a fix. Such a test belongs in an isolated maintenance window with explicit Sophos Support guidance and an immediately available rollback.

set vpn ipsec-performance anti-replay window-size 1024 returns to the documented default. If the baseline was custom, restore that exact value instead.

The IKEv2 cookie threshold protects half-open SAs

According to Sophos, cookie validation is always active and is only available for IKEv2. cookie_threshold doesn’t turn it on or off. When the number of simultaneous half-open IKE SAs exceeds the threshold, the responder requests a cookie from the initiator. This protects the setup state against DoS load. The documented default is 30.

set vpn ipsec-performance cookie_threshold <number>

Choose a lower or higher value only from real IKE load and support diagnostics. It doesn’t repair missing Child SAs, mismatched proposals, or authentication failures. During validation, observe new IKEv2 connections, strongswan.log, CPU load, and legitimate simultaneous dial-ins.

set vpn ipsec-performance cookie_threshold 30 returns to the documented default. Restore a recorded custom threshold with the same syntax.

Use the resolved peer address only for the documented Charon case

use-resolved-ip-address is intended for many site-to-site IPsec tunnels with FQDN peers and slow DNS resolution. According to Sophos, precisely this combination can cause a blocked charon thread. With enable, the firewall uses the already resolved address instead of initiating the tunnel with another lookup of the remote FQDN.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

The FQDN must already have resolved successfully. The documented default is Off; set vpn ipsec-performance use-resolved-ip-address disable restores it. If enable was the recorded baseline, use that as the custom rollback instead. The option doesn’t replace working DNS or reachable resolvers. Before enabling it, correlate resolution time, resolved peer address, tunnel count, and charon.log. After a DNS or provider transition, confirm that the firewall uses the new peer address within the expected time.

Strict IPsec policy checking in the SFOS 23 help

The SFOS 23 CLI help documents ipsec-strict-policy-check as a separate option under set vpn, not part of ipsec-performance. Security Associations (SAs) provide the security context associated with protected IPsec traffic. With enable, Sophos Firewall validates the subnet pair against its associated SA; incoming IPsec traffic that doesn’t match the expected SA may be dropped. This is not Use strict profile under System > Profiles > IPsec profiles, which concerns profile-scoped handshake issues caused by fragmentation.

Consider disable only for the documented compatibility case: a third-party peer uses shared SAs across multiple subnet pairs in site-to-site IPsec tunnels. This turns off strict association checking. Arbitrary tunnel, routing, or authentication failures are not a reason to do so; first establish that this exact shared-SA case applies.

Before setting the value: Require an independent management path, a current backup, and a method for reading the runtime value confirmed by Sophos Support for the installed build. Record the output, current value, and exact rollback to that baseline beforehand. Without a reliable read method or a safely established current value, leave the control unchanged.

The documented syntax for 4. Device Console is:

set vpn ipsec-strict-policy-check [enable | disable]

The brackets indicate alternatives: substitute only the justified target value, enable or disable. The SFOS 23 help supplies neither a default nor a getter/read command for this option. No default, reset, or invented read command is provided here. Its absence from the compared SFOS 22 help establishes neither introduction in SFOS 23 nor lack of support in SFOS 22.

Change only this global value in a controlled maintenance window. Before and after the change, test the affected subnet pairs and previously unaffected tunnels with existing and new flows in both directions. Controlled negative traffic tests must also confirm that disallowed traffic remains blocked; investigate SA associations and drop reasons with the IPsec and packet-capture checks in the testing and rollback section below. Read back the target value using the Support-confirmed method. If improvement is absent or regressions occur, restore exactly the recorded baseline with the same syntax and read it back, then recheck tunnels and user traffic. The four SFOS 22 default commands below are not a rollback for this control.

L2TP compatibility, MTU, and PPTP

set vpn also contains authentication protocols for L2TP and PPTP and the global L2TP MTU. That doesn’t make PPTP suitable for new environments. PPTP is obsolete and shouldn’t be newly deployed. L2TP remote access also remains a controlled compatibility solution, not the preferred standard for new managed clients.

L2TP and PPTP offer ANY, CHAP, MS_CHAPv2, and PAP:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

Don’t choose the value by the strongest-sounding name alone. The client, authentication server, and VPN method configured under Authentication > Services must support the same protocol. With Active Directory in particular, the supported combination can differ from a RADIUS path. ANY isn’t a security upgrade. It broadens the accepted methods and therefore requires an explicit risk decision.

Sophos doesn’t state a default for either CLI value. Roll back with the recorded token using the same syntax, for example set vpn l2tp authentication MS_CHAPv2 if that was the baseline.

The L2TP MTU can be set from 576 to 1460; the documented default is 1410:

set vpn l2tp mtu <576-1460>

The L2TP MTU doesn’t change a route-based or policy-based site-to-site IPsec interface. Adjust it step by step only for a reproducible L2TP fragmentation issue. Large and small transfers, DNS, authentication, and reconnection must still work afterward.

set vpn l2tp mtu 1410 returns to the documented default. Restore the recorded value instead if the baseline MTU was intentionally customized.

Test and roll back in a controlled way

These commands return the four settings for which SFOS 22 explicitly documents defaults:

set vpn ipsec-performance anti-replay window-size 1024
set vpn ipsec-performance cookie_threshold 30
set vpn ipsec-performance use-resolved-ip-address disable
set vpn l2tp mtu 1410

Sophos doesn’t state defaults for conn-remove-*, ipsec-max-workqueue-items, or either authentication value. Always restore a custom configuration with the value recorded before the test and the same set vpn syntax.

Change exactly one global value per maintenance window. Use the same tunnels, test flow, and WAN or HA transition before and after the change. For IPsec, record Current activities > IPsec connections, Child SA, byte counters, CPU, and packet loss. Remote access SSL VPN users appear under Current activities > Remote users. The official log reference maps IPsec to strongswan.log, ipsec_monitor.log, and charon.log, SSL VPN to sslvpn.log, and L2TP to l2tpd.log. For session cleanup, include VoIP, DNS, and other UDP flows.

A successful ping isn’t a complete acceptance test. Check at least one existing flow, one new connection, both traffic directions, and a controlled negative test. Under Diagnostics > Packet capture, SFOS shows the ingress and egress interfaces, Rule ID, status, and drop reason; use a narrow filter for the anonymized test endpoints to avoid collecting unrelated data. Use the Support-confirmed read method to verify the target value after the change. Command acceptance and observed traffic alone don’t prove which global value is active.

If the expected improvement doesn’t occur or new interruptions appear, set exactly the value recorded before the test. Recheck tunnel state and user traffic afterward. Don’t perform a set vpn change without a known baseline, an independent management path, and a defensible symptom.

FAQ