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.

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.

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:

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.

Test packet size with the DF bit

An ICMP test with the Don’t Fragment bit set can help narrow down the usable packet size of a path. The test is not a complete application proof, but it often shows quickly whether large packets are fragmented or dropped along the way.

Important: The specified packet size is normally the ICMP payload. With IPv4, 20 bytes of IP header and 8 bytes of ICMP header are added. A payload of 1472 therefore roughly corresponds to an IPv4 packet of 1500 bytes.

Examples:

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

ping -M do -s 1472 <target-ip>

If the test fails with 1472, reduce the payload step by step, for example to 1464, 1452, 1412, or lower. The important point is not one perfect value, but the difference between working and non-working sizes on exactly the same path.

These tests can be distorted by ICMP filters, providers, cloud gateways, or peers. They should therefore always be combined with Packet Capture, Log Viewer, and a real application test.

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

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.