Skip to content
Avanet

Check Sophos Firewall MTU and MSS for VPN Issues

Sophos Firewall

A typical MTU or MSS issue does not look like an obvious block: the VPN tunnel is connected and ping works, but downloads fail, RDP freezes, or HTTPS sign-ins stall. The cause may be a smaller usable path due to IPsec, PPPoE, XFRM, or SD-WAN.

If the tunnel does not establish at all or no Security Association exists, start with Sophos Firewall IPsec VPN Troubleshooting. For interface types and XFRM, see Configure Sophos Firewall Zones and Interfaces.

Quick diagnosis: Confirm an MTU or MSS issue

  1. In Log Viewer, confirm the expected Firewall Rule ID and, if NAT is part of the path, the NAT Rule ID. If no traffic appears or the wrong rules match, correct the routing, zone, NAT, or DNS issue first.
  2. Record the source, destination, service, direction, TCP/UDP, and actual path through LAN, VLAN, WAN, XFRM, RED, SD-WAN, or Remote Access VPN.
  3. Display and document the current MTU and MSS on the affected interface.
  4. Run a DF test, a narrowly filtered Packet Capture, and the same real application test.
  5. Change a value only when there is a reproducible difference between small and large packets. Then repeat exactly the same test.

Test a Firewall Rule with Log Viewer, Policy Test, and Packet Capture explains the general rule check. If the NAT Rule ID differs from the expected value, see Understand NAT on Sophos Firewall.

Test packet size with the DF bit

With IPv4, add 20 bytes for the IP header and 8 bytes for the ICMP header to the ICMP payload. A payload of 1472 therefore corresponds to a packet of approximately 1500 bytes.

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

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

If 1472 fails, reduce the payload step by step to 1464, 1452, 1412, or lower. Document both a working and a failing size. ICMP filters, providers, cloud gateways, or the remote endpoint can distort the result, so a DF test does not replace Packet Capture or an application test.

Classify MTU, MSS, and the affected path

The MTU is the maximum packet size of an interface or path. Larger packets are fragmented or dropped. The MSS limits the TCP payload per segment. If it remains too high despite VPN or provider overhead, retransmissions, stalls, and failures with larger data volumes can occur.

MTU and MSS are not general tuning values. The specific path matters:

  • WAN, PPPoE, or VLAN: The provider, router, or an additional header can reduce the usable packet size.
  • XFRM: Route-based IPsec adds overhead; routes, rules, and the XFRM interface jointly determine the path.
  • SD-WAN: A flow may use a different WAN, MPLS, or VPN path than expected. SD-WAN Routing for Reply Packets and System Traffic explains path selection.
  • Remote endpoint: The return route, remote firewall, cloud VPN, and MSS clamping must match the tested direction.
  • Wi-Fi: Since SFOS 22.0 MR1, the documented CLI commands can change MTU and MSS on existing Wi-Fi interfaces.

Large downloads or uploads, RDP, SMB, HTTPS, backups, ERP, cloud and conferencing applications, or VoIP that fail only over a specific VPN or SD-WAN path are suspicious. Many iPerf retransmissions, strongly fluctuating TCP throughput, or an issue that starts directly after a provider change, firmware upgrade, SD-WAN redesign, or VPN migration also fit this pattern. If small and large tests fail in the same way, a rule, NAT, routing, DNS, target system, or return-path issue is more likely.

Check the traffic flow with Log Viewer, Packet Capture, and iPerf

Rule out rule, NAT, and DNS issues

  • No traffic in Log Viewer: Check the client gateway, VLAN, route, logging, and test flow.
  • Wrong Firewall Rule ID: Check order, zone, source, destination, service, and user matching. Sophos Firewall Rule Does Not Match lists further causes.
  • Wrong NAT Rule ID: Check order, original fields, MASQ, SNAT, DNAT, and direction.
  • Unexpected destination IP: Check DNS, split DNS, the FQDN object, CDN, and IPv6.

If a VPN is involved, also check the tunnel status and byte counters. Document TLS Inspection, IPS, and Application Control so that before-and-after tests genuinely compare the same path and Security Features.

Evaluate Packet Capture

Under Diagnostics > Tools > Packet capture, filter for the affected source and destination and reproduce exactly one HTTPS request, transfer, or application start:

  • If packets do not arrive, the issue is usually with the client, gateway, VLAN, or local routing.
  • If packets enter the tunnel but no replies return, check the remote endpoint and return route.
  • Many TCP retransmissions indicate packet loss, MTU/MSS, WAN quality, or congestion.
  • If small tests work but large transfers fail, check Path MTU Discovery and fragmentation.

Use Packet Capture in WebAdmin explains the tool. Run captures and enabled debug logs only as long as necessary so that they do not consume unnecessary storage.

Compare iPerf with an application test

A dedicated iPerf server at the remote endpoint is more meaningful than a public server. Test TCP and UDP separately, and assess low TCP throughput or retransmissions together with WAN quality, CPU, the remote endpoint, and Security Features. Sophos Firewall Troubleshooting with iPerf and Speedtest provides the complete procedure.

Display or change MTU and MSS

WebAdmin and XFRM

Under Network > Interfaces, edit the affected interface and open Advanced settings > Interface settings. The MTU and Override MSS settings are shown there. XFRM interfaces appear under their physical listening interface.

Sophos Firewall calculates the XFRM MTU from the listening interface MTU and the maximum IPsec overhead by default. If the XFRM MTU is changed manually, it must be at least 113 bytes lower than the listening interface MTU. With 1400 bytes on the listening interface, the XFRM MTU must be no higher than 1287 bytes. This margin prevents packet loss during FastPath offload when SSL/TLS decryption is applied to IPsec traffic.

Check values in Device Console

Sign in over SSH, select 4. Device Console from the main menu, and enter the interface ID:

show mtu-mss Port2

Sophos documents the following change syntax for physical interfaces:

set network mtu-mss <PortID> mtu <number|default> mss <number|default>

Calculation example: If the confirmed IPv4 path MTU is 1492 bytes, the TCP MSS without additional options is 1452 bytes (1492 - 20 - 20). This is neither a general SFOS default nor a blanket recommendation for the physical PPPoE interface.

⚠️ A change affects live traffic and can interrupt the SSH or WebAdmin connection. Do not make it through the only management connection on the affected interface. A local or out-of-band fallback must be available. Port2 is only an example and must be replaced with the interface ID that was actually verified.

Save the displayed values first. default applies the Sophos-documented product defaults of MTU 1500 and MSS 1460:

set network mtu-mss Port2 mtu default mss default

This is a rollback only if those values were active before the change. Otherwise, explicitly restore the original values documented with show mtu-mss.

Validate the change

  • Document the affected interface, tunnel, and original values.
  • Choose a maintenance window or controlled test time.
  • Make only one change per test.
  • Inform the remote endpoint for a site-to-site VPN.
  • After both the change and rollback, use show mtu-mss Port2 to confirm that the expected values are active.
  • Repeat the same DF, capture, iPerf, and application tests.
  • Document the new values, reason, and result.
  • Check monitoring over the following days.

⚠️ Do not use permanent Advanced Shell hacks, startup scripts, or improvised packet-filter rules. They are difficult to maintain and may behave incorrectly or disappear after an update, restore, or HA failover. If such legacy changes exist, see Sophos Firewall Scripts without Cronjob: Risks and Alternatives.

Do not substantially reduce MSS across all networks, test in only one direction, or ignore the remote endpoint. If a controlled test does not improve the issue, restore the documented original value.

Troubleshooting by symptom

  • VPN is up, large transfers stall: Check MTU/MSS, the return path, or a Security Feature with Packet Capture and iPerf on the same path.
  • Only the PPPoE WAN is affected: Check the WAN interface, gateway, provider specifications, and usable packet size.
  • Route-based VPN is unstable with large packets: Check the XFRM interface, IPsec connection, route, and 113-byte rule.
  • VoIP over VPN is unstable: Check the SIP/RTP path, SD-WAN route, return path, packet loss, and capture.
  • TCP is very slow, UDP is normal: Check MSS, retransmissions, the TCP window, and packet loss with separate iPerf tests.
  • Small packets work, large packets do not: Document the DF test and check Path MTU Discovery, fragmentation, and the remote endpoint.

FAQ

Why does ping work while HTTPS or RDP does not?

A normal ping uses small packets. Larger TCP segments may still be fragmented or dropped. This is why DF tests with documented sizes and a real application test are required.

Must MTU or MSS be changed for every VPN?

No. Default values work in many environments. A change is useful only when the path, packet sizes, and reproducible tests demonstrate an MTU or MSS issue.