Check Sophos Firewall MTU and MSS for VPN Issues

When a VPN connection is established but individual applications still hang, the first thought often goes to firewall rules, DNS, or the remote site. This is correct but not complete. For large packets, IPsec overhead, PPPoE, SD-WAN, or route-based VPNs, MTU and MSS can also be the cause.

A typical error pattern does not look like a clear block: Ping works, small websites load, but file transfers break off, RDP freezes, HTTPS logins stall, or VoIP becomes unstable. This article places MTU and MSS issues in the context of Sophos Firewall without blindly changing values or creating dangerous shell workarounds.

For the basics on interfaces, zones, and XFRM, first see Configure Sophos Firewall Zones and Interfaces. If an IPsec tunnel does not establish at all or no Security Association is installed, Sophos Firewall IPsec VPN Troubleshooting is a better starting point.

MTU and MSS Explained Briefly

The MTU describes how large a packet can be on an interface or path. If a packet is larger than the path allows, it must be fragmented or discarded. This is particularly relevant for VPNs because IPsec adds additional headers.

The MSS concerns TCP and describes how large the payload of a TCP segment should be. If the MSS remains too high, even though the actual path is smaller due to VPN, PPPoE, or other overlays, typical TCP problems arise: retransmits, stalls, slow connections, or disconnections with larger data volumes.

Important: MTU and MSS are not tuning values that you randomly set smaller until it somehow works. Both values belong to the path. Before making a change, it should be clear which interface, direction, protocol, and tunnel are affected.

When to Suspect MTU or MSS

MTU and MSS issues often only appear with certain applications or packet sizes.

Typical indications:

VPN tunnel is connected, but larger downloads or uploads hang.
RDP, SMB, HTTPS, backup, ERP, or cloud applications only partially work.
Small ICMP tests work, larger data transfers do not.
VoIP or conferencing applications are only unstable over certain VPN or SD-WAN paths.
The issue only affects PPPoE, a specific WAN, a route-based IPsec path, or an XFRM interface.
iPerf shows many retransmits or highly fluctuating TCP throughput.
A new error pattern suddenly appears after a provider change, firmware upgrade, SD-WAN rebuild, or VPN migration.

Such symptoms do not yet prove an MTU problem. Nevertheless, they are a good reason to include MTU and MSS in the analysis.

Do Not Confuse with Rule, NAT, or DNS Issues

MTU/MSS is usually not the first checkpoint. First, it should be clear that the traffic is fundamentally taking the expected path. Otherwise, packet sizes are adjusted when actually a rule, NAT, DNS, or the return path is incorrect.

Observation	More likely than MTU/MSS initially
No traffic appears in the Log Viewer	Logging, client gateway, VLAN, route, or incorrect test flow
The wrong firewall rule ID applies	Rule order, zone, source, destination, service, or user matching
NAT rule ID does not match	NAT order, original fields, MASQ/SNAT/DNAT, or wrong direction
Name resolves to an unexpected IP	DNS, split DNS, FQDN object, CDN, or IPv6
Small and large tests fail equally	Rule, routing, NAT, target system, or remote site
Only large transfers hang	Check MTU/MSS, fragmentation, path MTU discovery, or VPN overhead

For this preliminary check, Check Causes When Sophos Firewall Rule Does Not Match, Use Packet Capture in WebAdmin, and Understand NAT on Sophos Firewall are suitable. Only when rule, NAT, routing, and DNS are plausible does the MTU/MSS trail really make sense.

Typical Areas on Sophos Firewall

On Sophos Firewall, several areas can be relevant. Usually, not the entire firewall is affected, but a specific path.

Area	Why relevant
WAN interface	Provider, PPPoE, VLAN, or router in front can reduce usable packet size
XFRM interface	Route-based IPsec generates additional overhead and requires appropriate tunnel MTU
SD-WAN route	A path may run over a different WAN, MPLS, or VPN than expected
Firewall rule	Security features or logging help narrow down but are not the MTU itself
Remote site	The other firewall, cloud VPN, or provider side must handle the same path cleanly
Wi-Fi interface	Since SFOS 22.0 MR1, Sophos also mentions MTU/MSS adjustments for Wi-Fi interfaces via CLI

For route-based IPsec, Sophos Firewall creates XFRM interfaces. XFRM MTU values are calculated based on the physical interface and the maximum IPsec overhead and can be adjusted if necessary. This is helpful but does not replace a clean check of the actual path.

Prove the Path First

Before any change, the affected data flow should be clearly described. Otherwise, you quickly optimise the wrong interface.

Practical questions:

Which source IP and destination IP are affected?
Does the traffic run over LAN, VLAN, WAN, XFRM, RED, SD-WAN, or Remote Access VPN?
Is only one direction affected or both?
Does it affect TCP, UDP, or both?
Do small packets work, but larger transfers do not?
Does the expected firewall rule really apply?
Is there NAT, MASQ, TLS Inspection, IPS, or Application Control on the path?
Does the remote site have a suitable return route?

For rule and path checking, Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture is helpful. For NAT or MASQ, additionally check Understand NAT on Sophos Firewall.

Diagnosis with Log Viewer, Packet Capture, and iPerf

The Log Viewer shows whether traffic is allowed or dropped. However, it does not alone prove whether a packet is too large. For this, you need Packet Capture, reproducible tests, and clear interpretation.

Log Viewer

First check in the Log viewer:

Select module Firewall or the affected security module.
Filter by source IP, destination IP, and service.
Check which firewall rule matches.
Ensure no drop rule, wrong zone, or wrong NAT rule is the actual problem.

If no traffic is visible at all, the problem often lies before the firewall, at the client gateway, VLAN, routing, or on the remote site.

Packet Capture

Under Diagnostics > Tools > Packet capture, you can narrow down the test. A filter on exactly the affected source and destination is useful. Then a single test is reproduced, such as an HTTPS call, a file transfer, or an application start.

Interpretation is important:

Observation	Meaning
Packets do not arrive at the firewall	Check client, gateway, VLAN, or local routing
Packets go into the tunnel, responses are missing	Check remote site, return route, or remote firewall
Many retransmits with TCP	Check packet loss, MTU/MSS, WAN quality, or overload
Small tests work, large transfers hang	Check MTU/MSS or path MTU discovery

For using the tool, see Use Packet Capture Tool in WebAdmin.

iPerf

iPerf is helpful when you can reproducibly measure a route. An own iPerf server on the remote side is significantly more meaningful than a public iPerf server. If TCP throughput is low and many retransmits are visible, MTU/MSS should be checked along with WAN quality, CPU, remote site, and security features.

The procedure is described in Sophos Firewall Troubleshooting with iPerf and Speedtest.

Change Values Only Deliberately

If the suspicion is substantiated, changes should remain small, documented, and reversible.

Before a change:

document the current value
note the affected interface and tunnel
choose a maintenance window or controlled test time
change only one value per test
conduct a before/after test with the same application
inform the remote site if a site-to-site VPN is affected

For route-based VPNs, the XFRM interface and the associated IPsec connection should be checked first. For PPPoE or provider overlays, the WAN interface or provider path is often the crucial point. For SD-WAN, it must also be clear which gateway or VPN path is actually used. The article SD-WAN Routing for Reply Packets and System Traffic helps in classifying SD-WAN paths.

⚠️ Do not use permanent shell hacks. Direct packet manipulation via Advanced Shell, undocumented startup scripts, or spontaneous packet filter rules are not a clean solution for productive firewalls. Supported Sophos Firewall functions should be checked first.

What to Avoid

These patterns cause more harm than good in practice:

Setting MSS extremely low for all networks.
Changing MTU values without before/after testing.
Testing only one direction and concluding for the entire VPN path.
Using shell workarounds instead of WebAdmin or documented device console functions.
Ignoring the remote site, even though the return path or their MSS clamping may be involved.
Assuming MTU/MSS as the cause, although firewall rule, NAT, routing, or DNS have not been checked.
Letting debug logs or packet captures run for a long time and fill up storage space.

If local scripts or packet manipulations already exist, first read Sophos Firewall Scripts Without Cronjob: Risks and Alternatives and cleanly document the legacy.

Troubleshooting Table

Symptom	More Likely Area	Next Check
VPN green, large transfers hang	MTU/MSS, return path, security feature	Packet Capture and iPerf with the same path
Only PPPoE WAN affected	Provider path or WAN MTU	Check WAN interface, gateway, and provider details
Route-based VPN unstable with large packets	XFRM MTU or SD-WAN path	Check XFRM interface, IPsec connection, and route
VoIP over VPN only partially stable	SD-WAN, return path, packet loss, MTU	Check SIP/RTP path, SD-WAN route, and capture
TCP very slow, UDP normal	MSS, retransmits, TCP window, packet loss	Test iPerf TCP/UDP separately
Small packets work, large do not	Path MTU discovery or fragmentation	Test packet sizes consciously and check remote site

Checklist

Check immediately:

Documented affected source, destination, service, and direction.
Confirmed firewall rule and NAT rule in Log Viewer.
Conducted Packet Capture with a narrow filter.
Checked IPsec status and byte counter if a VPN is involved.
Checked remote site and return path.

If MTU/MSS is likely:

Identified affected interface or XFRM location.
Documented current MTU/MSS value.
Planned only one change per test.
Set test application and comparison value.
Coordinated change with remote site if site-to-site VPN is affected.

After the change:

Test the same application again.
Compare Log Viewer, Packet Capture, or iPerf.
Document new values and justification.
Check monitoring in the coming days.

FAQ

Is MTU the same as MSS?

No. MTU concerns the maximum packet size on an interface or path. MSS concerns the TCP payload per segment. They are related but not the same.

Why does Ping work but HTTPS or RDP does not?

Small tests can work even though larger TCP segments later cause problems. Therefore, a simple ping is not enough to prove that the entire path is healthy.

Do you need to change the MTU for every VPN?

No. Many VPNs work cleanly with the default values. A change only makes sense if the affected path and error pattern suggest it.

What is special about XFRM interfaces?

XFRM interfaces belong to route-based IPsec VPNs. Sophos Firewall automatically creates them in the context of the IPsec connection. For route-based VPNs, routes, firewall rules, and the XFRM interface together determine where traffic flows.

Should MSS be enforced via Shell?

For normal operation, no. Shell-based packet manipulation is hard to maintain and can unexpectedly disappear or malfunction after updates, restore, or HA failover. Supported firewall functions are preferable.