VPN Ping Works, but Transfers Fail
Small packets can pass while larger packets fail. Conceptual illustration.
The VPN is connected and small pings succeed, yet file transfers stall. Start by testing packet size on the actual application path. This guide explains how to distinguish MTU-related failures from other causes, choose an MTU or TCP MSS adjustment, and verify the result.
KEY TAKEAWAYS
Test the real path. Vary packet size and test both directions.
Separate MTU from MSS. Account for VPN overhead; MSS clamping helps TCP, not UDP.
Verify one change at a time. Open new connections and repeat the failed transfer.
WHY LARGER PACKETS FAIL
A small ping does not prove that larger packets can cross the tunnel. RFC 2923 describes the characteristic pattern: ping and interactive connections work while bulk transfers stall when larger packets are sent.
MTU, as used here, is the maximum IP packet size a link can carry. Path MTU, or PMTU, is the smallest link MTU along the route. A packet that fits on the factory LAN may not fit after VPN encapsulation on the path to the remote gateway.
Encapsulation adds bytes. For example, IPsec NAT traversal can carry ESP inside UDP. The outer IP version, VPN protocol and any additional tunnels affect the overhead. A WAN MTU of 1500 therefore does not establish an inner tunnel MTU of 1500.
With classic IPv4 path MTU discovery, an oversized packet marked Don't Fragment (DF) is dropped by a router that cannot forward it, which returns an ICMP “fragmentation needed” message. The sender uses that feedback to reduce subsequent packet sizes.
IPv6 PMTUD instead uses ICMPv6 Packet Too Big messages; transit routers do not fragment IPv6 packets.
If the necessary feedback is filtered or mishandled, the sender may keep transmitting packets that cannot pass. In a VPN, check both whether outer-path feedback reaches the tunnel endpoint and how that endpoint handles the inner traffic. Looking only for ICMP on the PLC's LAN misses part of the process.
Packet size is not file size. A failed large-file transfer alone is not enough to diagnose an MTU problem. Failures tied to a particular file type, application action or elapsed time, without a repeatable packet-size boundary, call for investigation of other causes too.
TEST THE VPN PATH
Follow the application path through the VPN. Illustrative industrial scene.
Use controlled test hosts at each end of the VPN where possible. Their results help isolate the path, but final acceptance must return to the original PLC, HMI or application endpoint.
1. Record the Path
Record the router model, firmware, VPN protocol, inner and outer IP versions, WAN connection, source and destination addresses, and current MTU/MSS settings.
Confirm that the test traffic actually enters the intended tunnel. Pinging the router's public address, its tunnel address and a host behind it tests different paths.
Reproduce the original failure and record the direction, time and error before changing anything.
2. Test Packet Sizes
Start with a small packet that succeeds reliably, increase its size and narrow the interval where failures begin. Repeat each size: one timeout can be ordinary packet loss.
On a Linux test host using iputils ping, replace <remote-host-ip> with a controlled IPv4 host reached through the VPN:
ping -4 -M do -s 1200 -c 4 <remote-host-ip>
ping -4 -M do -s 1372 -c 4 <remote-host-ip>Example probes, not recommended MTU settings. According to the iputils ping manual, -s sets the data length and -M do sets DF while respecting the kernel's PMTU checks.
With a 20-byte IPv4 header and 8-byte ICMP header, 1372 data bytes produce a 1400-byte inner IP packet, before VPN overhead. Additional IP options change that calculation.
“Message too long”: the local kernel may have rejected the probe before transmission.
Timeout: this alone does not identify where the probe was lost.
Record the command, payload length and result. ICMP and application traffic may encounter different policies. These Linux commands are not router CLI instructions or IPv6 tests.
3. Inspect ICMP Feedback
Where access allows, capture traffic on the relevant inner and outer interfaces at both VPN endpoints. Look for the point where larger packets stop appearing, IPv4 fragmentation-needed or IPv6 Packet Too Big messages, and whether feedback reaches the correct endpoint.
For TCP, compare the handshake with subsequent data and retransmissions. Repeated retransmission of large segments is a clue described in RFC 2923, but retransmissions alone do not establish an MTU black hole.
Observation | Next check |
|---|---|
Relevant ICMP errors reach an endpoint, but traffic remains oversized | Check endpoint handling and the tunnel's effective MTU. |
Failures repeatedly begin near a particular packet size, but feedback is not visible | Add observations at other interfaces and investigate filtering or return-path handling. |
Failures have no consistent relationship to packet size | Investigate application behavior, device resources and link conditions alongside the MTU hypothesis. |
Not seeing ICMP at one capture point does not prove that no device generated it.
4. Retest Both Directions
Test site-to-remote transfers and remote-to-site transfers separately. Keep the source, destination and WAN path with each result. A controlled non-VPN comparison can help, but it is a different path and should be recorded separately.
Do not change MTU, MSS, keepalive and VPN protocol together. Even if the transfer recovers, that makes the effective change difficult to identify.
CHOOSE MTU OR MSS
If the encapsulated packet exceeds the outer path's capacity, check the VPN implementation's guidance for setting an effective tunnel MTU. If necessary ICMP feedback is blocked or mishandled, correct that handling.
Reducing packet size can restore service without resolving the underlying feedback problem; record that distinction.
MSS Controls TCP Data Size
TCP MSS specifies TCP data length, excluding IP and TCP headers. MSS clamping lowers the value advertised in TCP connection-establishment packets as they cross a policy point. This influences the peer's subsequent TCP segment sizes.
MSS clamping is specific to TCP. It differs from changing an interface MTU and does not directly resize UDP datagrams.
For an already established effective inner IP MTU of 1400 bytes, subtracting only fixed headers gives:
Inner IP version | Fixed IP + TCP headers | Illustrative MSS |
|---|---|---|
IPv4 | 20 + 20 bytes | 1360 bytes |
IPv6 | 40 + 20 bytes | 1340 bytes |
The 1400-byte MTU is an assumption for this calculation, not a universal setting. RFC 6691 also requires the sender to reduce actual TCP data length for IP or TCP options it includes. Do not substitute an outer-path MTU into this inner-packet calculation.
MSS is exchanged in SYN packets, including SYN-ACK, and each advertisement limits what the other endpoint should send, as specified in RFC 9293. After changing a clamp rule, establish new TCP connections and inspect both directions. An existing session is not sufficient evidence that the new rule has taken effect.
Keep Protocol Settings Separate
The OpenVPN 2.6 manual describes mssfix for TCP inside the tunnel and states that it makes sense when OpenVPN uses UDP to communicate with its peer. Its mtu argument changes the size accounting to include outer IP and UDP headers.
Do not treat tun-mtu, mssfix and fragment as interchangeable, or copy OpenVPN settings into WireGuard or IPsec configurations.
For failing UDP traffic, investigate application datagram sizes, encapsulation and the implementation's probing behavior separately. DPLPMTUD uses probes and delivery confirmation to discover usable packet sizes without requiring ICMP Packet Too Big feedback. Whether it is available depends on the application or protocol implementation.
VERIFY THE FIX
Repeat the original transfer over the same path. Check that it completes, verify file size and content where applicable, and test both directions with new connections. For multi-WAN installations, test each relevant WAN path separately: PMTU can change when the path changes.
Keep a short handover record containing the original symptom, test path, successful and failed packet sizes, feedback observed, before-and-after settings, transfer results and rollback procedure. If smaller packets restore service but the bottleneck is still unknown, record “service restored after packet-size adjustment; bottleneck not yet located.”
For Wavetel equipment, submit the model, firmware, VPN type, topology and test record through Technical Support. Confirm the model's actual MTU/MSS controls and capture facilities against its firmware documentation; a supported VPN protocol list does not establish those configuration details.
FAQ
Does a Successful Ping Rule Out MTU Issues?
No. It confirms that this probe size completed its round trip. Test larger packets and the actual application path, then check whether failures consistently follow packet size.
Should Every VPN Use MTU 1420?
No. The usable size depends on the path and encapsulation. A value that works on one connection may still be too large on another, or unnecessarily small. Use repeatable observations and the implementation's documentation.
Why Does Changing MSS Not Fix the Transfer?
Check that a new TCP connection was created, the rule handles the relevant direction, and the observed SYN/SYN-ACK values changed. UDP traffic and failures unrelated to packet size need separate investigation.
Can WireGuard Keepalive Fix Large Packets?
PersistentKeepalive maintains NAT or firewall mappings during idle periods. It does not change path capacity. It may be relevant to an idle tunnel that becomes unreachable, but not to a repeatable packet-size limit during active transfers.
Comments