PMTUD black holes can make a working VPN appear broken only when a website sends larger packets. Login screens may open, while uploads or page content stall. Small pings can succeed throughout the failure.
This guide focuses on missing packet-size feedback, not general VPN speed or interface mismatch. The goal is to prove a size-dependent failure, locate the feedback gap, and choose a targeted repair.
Recognize a Packet-Size Failure Before Changing Settings
A successful VPN login proves that the tunnel established. It does not prove that every packet size can cross it.
Look for a repeatable pattern:
- Small requests work, but larger responses stop progressing.
- A website connects, then stalls during encrypted negotiation or content delivery.
- Uploads hang while short messages succeed.
- The same destination works through another approved network path.
- Failures follow a tunnel, internet circuit, or firewall change.
These clues suggest a packet-size problem, but they do not establish the cause. Filtering, server faults, and congestion can produce similar symptoms.
First confirm that the hostname resolves and the connection reaches the intended server. Use the VPN hostname resolution checklist when names fail before connections begin.
If all traffic moves slowly regardless of size, start with broader VPN performance checks. Here, the key distinction is a connection that works initially and then stops moving data.
Understand MTU, MSS, and Tunnel Overhead
The maximum transmission unit, or MTU, sets the largest IP packet a link can carry without fragmentation. The path MTU is the smallest limit along the route.
A VPN adds headers around the original packet. Encryption, outer IP headers, and tunnel transport consume space. That leaves less room for the inner packet.
For example, an outer link with a 1,500-byte MTU cannot necessarily carry a 1,500-byte inner packet. The combined packet must also fit the tunnel headers. Exact overhead depends on the protocol, address family, encryption choices, and encapsulation.
TCP, the reliable transport used by many websites, also uses a maximum segment size, or MSS. Each endpoint advertises the TCP payload size it can receive during connection setup.
MTU and MSS are related, but they are not interchangeable. With basic IPv4 and TCP headers, a 1,500-byte MTU commonly corresponds to a 1,460-byte MSS. Basic IPv6 and TCP headers leave 1,440 bytes. Options and encapsulation complicate actual packet sizing.
Do not copy those values into a firewall rule without measuring the relevant path.
How Path MTU Discovery Creates Black Holes
Path MTU discovery, or PMTUD, lets a sender learn when packets exceed a route’s limit. Network devices return control messages through the Internet Control Message Protocol, or ICMP.
For IPv4, a router can fragment a packet when the packet permits it. Fragmentation splits the packet into pieces that the destination must reassemble.
When the IPv4 Don’t Fragment flag is set, the router instead drops an oversized packet. It should return an ICMP “fragmentation needed” message with useful size information.
IPv6 routers do not fragment packets in transit. They return ICMPv6 “Packet Too Big” messages. The source must adjust its packet sizing or use source fragmentation where appropriate.
PMTUD black holes occur when oversized packets disappear and the sender never receives usable size feedback. A firewall might block the message. Tunnel handling or an incorrect advertised limit can also interfere.
The sender may keep retrying data that cannot cross the path. Small connection-opening packets still fit, which explains the misleading partial success.
Some transports use packetization-layer discovery to probe sizes without relying solely on ICMP. Support and recovery behavior vary, so do not assume every application will recover.
Build a Safe, Repeatable MTU Test
Choose one affected client and a destination you control or have permission to test. Record the address family, VPN state, destination address, and failure time.
Use a small number of probes. Avoid flood options, broad scans, and tests against unrelated public systems.
Compare Small and Larger IPv4 Probes
On Windows, these commands send four IPv4 echo requests:
ping -4 -n 4 -f -l 1200 DESTINATION_IP
ping -4 -n 4 -f -l 1400 DESTINATION_IPOn Linux with an iputils-compatible ping, the approximate equivalents are:
ping -4 -c 4 -M do -s 1200 DESTINATION_IP
ping -4 -c 4 -M do -s 1400 DESTINATION_IPReplace the placeholder with the approved target. Verify available options on your operating system before running them.
These sizes describe echo payload, not total IP packet size. For basic IPv4 headers, add 28 bytes for IP and ICMP overhead.
If a smaller probe succeeds and a larger one fails, narrow the boundary with a few intermediate sizes. Record explicit size errors separately from silent timeouts.
A destination may block echo requests altogether. In that case, ping cannot establish the size threshold. Also, an echo test does not guarantee the same route or treatment as web traffic.
Confirm the Finding With Application Traffic
Repeat the actual failing request using a test account and nonsensitive data. Compare the same destination with and without the VPN, if policy permits.
Keep other variables stable. A network change may also change DNS answers, server selection, or routing.
Test IPv4 and IPv6 separately where practical. A successful IPv4 probe says nothing conclusive about an IPv6 connection.
With approval, temporarily reduce the affected client’s tunnel MTU. Record the original setting and prepare a rollback first. Reopen the application connection after the change.
If the transaction then succeeds, the result supports a size-dependent diagnosis. It does not identify which device lost the feedback.
Stop if the change threatens remote management access. A test should not leave the technician disconnected from the only recovery path.
Trace the Missing PMTUD Feedback
Packet captures can distinguish a size problem from an application that simply stopped responding. Capture only authorized traffic, limit duration, and protect the resulting files.
Where possible, observe the client, the tunnel’s inner interface, and its outer interface. Compare both directions.
- Look for repeated TCP data transmissions without progress.
- Check for IPv4 fragmentation-needed or ICMPv6 Packet Too Big messages.
- Inspect the size information those messages report.
- Determine whether feedback reaches the tunnel endpoint and original sender.
- Compare the advertised MSS in both directions during connection setup.
Repeated transmissions alone do not prove an MTU fault. Pair them with a size threshold, relevant feedback, or a controlled change.
Network offload features can make host captures show packets larger than those actually sent on the wire. Account for that before drawing conclusions from packet length.
Review firewall counters and logs for the necessary ICMP messages. Do not disable the entire firewall as a test. Prefer narrowly scoped policy changes with documented rollback.
Use MSS Clamping Without Hiding the Wrong Problem
MSS clamping lets a router or firewall lower the MSS advertised in TCP connection-opening packets. Endpoints then send smaller TCP payloads.
This can help TCP traffic fit through a tunnel when reliable path-size feedback is unavailable. However, placement matters. The clamp must affect the appropriate forwarded connection-opening packets and directions.
Check whether the device derives its clamp from a known path MTU or requires an explicit value. A route-based calculation may fail if that route still reports an unsuitable MTU.
Clamping does not directly fix UDP, the transport used by many real-time applications and HTTP/3. It also does not repair the underlying ICMP feedback path.
Existing TCP sessions usually retain their negotiated MSS. Open fresh connections when validating a change.
For OpenVPN deployments, consult the official reference for MTU-related options. Confirm behavior for your installed version and transport before editing settings.
Prefer restoring correct feedback when feasible. Use a measured tunnel MTU or scoped clamp where the architecture requires it. Avoid a global low value that conceals the fault and reduces efficiency everywhere.
Verify the Repair Across Real Business Tasks
A successful ping is not the finish line. Retest the affected website, a representative upload, and a download over fresh connections.
Check both traffic directions and relevant address families. If the business uses UDP applications, test those separately from TCP websites.
Document the original limit, measured threshold, change location, and rollback steps. Include packet evidence showing whether feedback now arrives or smaller packets avoid the failing boundary.
Monitor for recurrence after routing changes or internet failover. A different path may have a different usable packet size.
Resolving PMTUD black holes requires more than finding a smaller number that works. The lasting fix explains where the size limit lives and how senders learn about it.
Professional remote assistance may help when packet captures, firewall policy, or tunnel settings require coordinated changes. Tech Rescue Ops LLC provides network diagnostic support when teams need evidence-led testing with a clear recovery plan.