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. Query the existing values separately:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance shows the workqueue and replay values, among others. show vpn configuration is relevant to the current L2TP and PPTP configuration. If a value doesn’t appear in the output of the installed build, don’t infer it from an assumed default. Include a configuration backup and Sophos Support in the change before modifying a global advanced setting.

The rollback is always the actual value read from the appliance. default isn’t a universally documented rollback for these VPN commands and must not be used on assumption.

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. New configurations have used disable by default since SFOS 19.0, while migrated systems can retain an older value.

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

Sophos changed these defaults in SFOS 19.0 for new configurations to reduce non-TCP connection flapping when IPsec tunnels come up or go down. The change was deliberately not applied globally during upgrades and migrations. On SFOS 22, the current appliance output therefore matters, not the assumed factory value.

In HA, also remember that Sophos Firewall doesn’t hand VPN and non-TCP sessions to the peer like ordinary forwarded TCP sessions. The two conn-remove-* switches replace neither the HA design nor a controlled failover test.

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.

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.

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.

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. The option therefore doesn’t replace working DNS, appropriate TTLs, or reachable resolvers. Before enabling it, correlate resolution time, current A and AAAA answers, tunnel count, and charon.log. After a DNS or provider transition, confirm that the firewall uses the new peer address within the expected time. Leave the option disabled without the described Charon case.

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.

First read the current configuration with show vpn configuration. 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.

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.

Test and roll back in a controlled way

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 tunnel state, Child SA, byte counters, strongswan.log, charon.log, CPU, and packet loss. 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. Then read the target state again with the appropriate show vpn ... command.

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