A recent WireGuard handshake and a successful small ping do not prove that a VPN can carry a complete HTTPS session. When larger packets cannot cross the path, a site may start loading and then stall while smaller requests continue working.

MTU is one possible cause. Establish which traffic fails, verify its route and compare packet sizes before changing the tunnel. A useful diagnosis should survive a repeat test and include a way back to the original configuration.

What the handshake does and does not establish

WireGuard's protocol documentation describes a handshake that establishes keys for encrypted data exchange. That exchange is different from delivering an application's traffic through the tunnel and any networks beyond its peer.

MTU, or maximum transmission unit, limits the size of an IP packet on an interface. The path MTU is the smallest relevant link limit along a route. A tunnel carries an inner packet inside an outer packet, so the inner packet needs room for encapsulation. The interface MTU and the underlay path MTU are different measurements.

With IPv4 Path MTU Discovery, routers can report that a packet needs fragmentation when its Don't Fragment flag prevents that. RFC 1191 describes how the sender responds by reducing its packet size. If the required feedback is lost, repeated oversized transmissions can fail without giving the application a useful explanation.

For IPv6, RFC 8201 describes ICMPv6 Packet Too Big feedback. Review both address families: a successful IPv4 request says little about a separate IPv6 route.

Scope and safe starting conditions

The examples target an existing Linux WireGuard interface called wg0, using iproute2 and iputils. Configuration persistence below applies specifically to wg-quick. NetworkManager, systemd-networkd, routers and managed VPN clients have different configuration owners.

Work from a local client terminal or a console that does not depend on the tunnel being changed. Do not adjust the only path to a remote production server without independent access and a recovery plan. Keep the first test limited to one interface on one machine.

These commands are documentation-based examples, not results from tests on an IllusionCloud VPN. Replace the example addresses, interface and application URL with your own. The documentation addresses 203.0.113.20 and app.example.com are placeholders, not diagnostic services.

1. Rule out missing data connectivity

Inspect the interface and the relevant WireGuard runtime fields:

ip link show dev wg0
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer

The wg manual documents these read-only fields. Generate a small request to the intended destination, then check the counters again. A fresh handshake with no useful application traffic still leaves routing, peer configuration and firewall behavior to investigate.

Avoid sharing wg showconf or wg show ... dump output: configuration and dump formats can contain private or preshared keys. Even the selected fields above identify peers, so redact them before publishing diagnostics.

For the following examples, assume the remote peer has tunnel IPv4 address 10.66.0.1 and is configured to answer ICMP echo. Substitute the correct address:

ip -4 route get 10.66.0.1
ping -4 -n -c 3 -W 2 10.66.0.1

ip route get reports the kernel's selected route for the supplied lookup. For this simple setup, it should select wg0. Policy routing, marks and separate network namespaces may require a lookup matching the actual application context.

If small packets fail too, investigate basic reachability first. An ICMP-filtered peer is unsuitable for the size comparison below. Lack of an echo reply alone does not prove the VPN or its MTU is broken.

2. Separate name resolution from the transfer

Use the application hostname that actually fails:

getent ahosts app.example.com

getent queries the system's Name Service Switch, which may use DNS, local hosts files or cached information. Successful resolution establishes that an address was returned; it does not demonstrate that the application can reach it.

Check the route to the returned address as well. A split-tunnel VPN may carry the peer's private address while sending the website through another interface. Testing that website would not isolate this tunnel's data path.

For a repeatable HTTPS check, use a modest static file on an endpoint you control that is routed through the VPN:

curl --http1.1 -4 --noproxy '*' --connect-timeout 5 --max-time 20 -v -o /dev/null https://app.example.com/test-file.bin

Replace the hostname and file path. The curl manual documents the explicit IPv4, HTTP/1.1, timeout and proxy options. This example exercises HTTPS over TCP and avoids a configured HTTP proxy. It is not a test of QUIC or UDP game traffic. Verbose output helps distinguish resolution failure, connection failure, TLS negotiation and a transfer that begins but stalls.

Record which phase fails. If the service and VPN also support IPv6, repeat the application check with -6 instead of -4 and verify that address's route separately. A certificate error should be fixed as a certificate problem; disabling TLS verification would obscure the diagnosis.

3. Compare small and larger packets on the same path

For the IPv4 tunnel destination already verified above, compare a small payload with a larger one:

ping -4 -n -c 3 -W 2 -M do -s 1200 10.66.0.1
ping -4 -n -c 3 -W 2 -M do -s 1372 10.66.0.1

The iputils ping manual defines -s as data bytes, not total packet size. With ordinary IPv4 and ICMP headers, 1372 data bytes produce a 1400-byte inner IP packet. -M do requests Don't Fragment behavior and remains subject to the kernel's known PMTU checks.

A local message-too-long error means the local stack rejected that size. An explicit fragmentation-needed response is useful path feedback. Silent loss of only the larger probe is a clue, but filtering, loss and return-path behavior can also affect the result. Compare repeated observations rather than treating three packets as conclusive evidence.

These probes measure the inner path to 10.66.0.1. They do not directly measure the outer UDP path to the public WireGuard endpoint. Nor do successful peer-to-peer probes establish the MTU of a website beyond the peer.

An additional read-only clue is:

tracepath -4 -n 10.66.0.1

tracepath uses UDP probes and can report path-MTU information when intermediate devices provide suitable responses. Missing replies do not identify a particular broken hop. A trace to the public endpoint would examine a different path and may not receive responses at all.

4. Run one reversible MTU experiment

First record the current interface MTU, exposed through the kernel's network sysfs interface, in the same shell you will use for rollback:

original_mtu=$(cat /sys/class/net/wg0/mtu)
printf 'Original wg0 MTU: %s\n' "$original_mtu"

Confirm that this printed a valid number. Also write that value down so recovery does not depend on a shell variable surviving. If the current value is greater than 1380, a temporary trial is:

sudo ip link set dev wg0 mtu 1380
ip link show dev wg0

The ip-link manual documents changing a device's MTU. Here, 1380 is an example lower test value, not a recommended universal setting. If the current MTU is already 1380 or lower, skip this particular experiment rather than raising it accidentally.

Open a new application connection and repeat the same HTTPS transfer. Test more than once. A repeatable improvement supports investigating packet-size handling; it does not prove which device or direction caused the original failure. A client-side change may also leave problems in traffic sent by the remote peer or forwarded for other hosts.

Restore the original value after the comparison, especially if the result is unclear:

sudo ip link set dev wg0 mtu "$original_mtu"
ip link show dev wg0

Use the saved numeric value if you opened another shell. Check that the restore command succeeded. A runtime change can be replaced when the interface reconnects, the host reboots or its network manager reapplies configuration.

Do not keep lowering MTU without a diagnosis. RFC 8200 defines an IPv6 minimum link MTU of 1280 bytes. This procedure does not recommend configuring an IPv6-carrying interface below that limit.

5. Persist a verified value through the correct manager

Only persist a value after testing the affected application, required address families and any forwarded traffic. For a wg-quick interface, the usual file is /etc/wireguard/wg0.conf.

The wg-quick manual documents MTU under [Interface]; without it, the tool chooses an MTU using endpoint or default-route information. If 1380 was verified for your deployment, the relevant fragment is:

[Interface]
MTU = 1380

Merge that line into the existing section, retaining keys and other settings. Keep a protected backup. If SaveConfig = true, shutdown can overwrite file edits: take the interface down through its existing manager before editing, using independent console access. Reconnect through that manager during a maintenance window, then check the live MTU and application again.

For rollback, restore the previous MTU line, or remove the added line if automatic selection was previously used, and reconnect through the same manager. Restore the runtime value too if needed. Do not assume wg syncconf applies wg-quick-specific interface settings. For other network managers, change their connection profile instead.

Correct the underlying path where possible

A smaller tunnel MTU can accommodate a constrained underlay, but it should not conceal a firewall that drops required path-MTU feedback. Review relevant IPv4 fragmentation-needed and ICMPv6 Packet Too Big handling with the operator responsible for each firewall. Preserve filtering policy rather than broadly disabling a firewall.

TCP MSS adjustments affect TCP segment negotiation, not every protocol using the tunnel. Linux also has TCP-specific PMTU probing controls, documented in the kernel IP sysctl reference. Applying global TCP changes is a separate decision and does not demonstrate that UDP traffic has been repaired.

When asking a network or hosting operator for help, include the affected route, address family, original and trial MTUs, packet sizes and a redacted description of the repeatable application failure. State which probes were inside the tunnel and which targeted the public endpoint. That evidence is more actionable than a screenshot showing only a successful handshake.

For adjacent troubleshooting, see our Linux system administration guide and Docker/UFW exposure audit. The latter covers a different firewall failure mode; verify the actual packet path before choosing a remedy.