That pattern, where small things work and big things hang, is almost always an MTU problem, and usually a specific one: a Path MTU Discovery black hole. In this post I'll build one in a lab, show exactly what it looks like in ping and in a packet capture, and test three ways of fixing it.

How Path MTU Discovery is meant to work

The MTU (maximum transmission unit) is the biggest IP packet a link will carry. On normal Ethernet that's 1500 bytes. Tunnels, PPPoE, VPNs and some WAN links have less room, often somewhere between 1400 and 1492.

Modern hosts send TCP traffic with the Don't Fragment (DF) bit set. So when a 1500-byte packet reaches a router whose next link only takes 1400, the router can't split it. It drops the packet and sends an ICMP message back to the sender: type 3, code 4, "fragmentation needed", which includes the MTU it can handle. The sender caches that value and resends smaller packets. That's Path MTU Discovery (PMTUD).

web01 (1500)      rtr02             1400 link              client01
  | -- 1500 bytes, DF --> |                                    |
  | <-- ICMP 3/4, mtu 1400 |                                    |
  | -- 1400 bytes, DF ----------------------------------------> |

It all hinges on that ICMP message getting back. If a firewall somewhere drops it, and plenty block ICMP wholesale, the sender never finds out. It keeps sending 1500-byte packets that keep vanishing. That's the black hole.

One detail matters for the lab: the narrow link has to be in the middle of the path. If it's on one of the end hosts, TCP's MSS negotiation during the handshake quietly works around it, and you never see a problem.

Lab setup

Same approach as my TCP handshake post: Linux network namespaces on one machine, no VMs. This time there are four of them in a line, with a 1400-byte link between the two routers:

Save this as mtu-lab.sh and run it with sudo bash mtu-lab.sh, or grab it, along with a cleanup script, from GitHub:

#!/bin/bash
# client01 -- rtr01 ==(1400 MTU link)== rtr02 -- web01
set -e
for ns in client01 rtr01 rtr02 web01; do
  ip netns add $ns
  ip netns exec $ns ip link set lo up
done

ip link add c0  type veth peer name r1a
ip link add r1b type veth peer name r2a
ip link add r2b type veth peer name w0
ip link set c0  netns client01
ip link set r1a netns rtr01
ip link set r1b netns rtr01
ip link set r2a netns rtr02
ip link set r2b netns rtr02
ip link set w0  netns web01

ip netns exec client01 ip addr add 198.51.100.10/24 dev c0
ip netns exec rtr01    ip addr add 198.51.100.1/24  dev r1a
ip netns exec rtr01    ip addr add 192.0.2.1/30     dev r1b
ip netns exec rtr02    ip addr add 192.0.2.2/30     dev r2a
ip netns exec rtr02    ip addr add 203.0.113.1/24   dev r2b
ip netns exec web01    ip addr add 203.0.113.10/24  dev w0

# the narrow link in the middle of the path
ip netns exec rtr01 ip link set r1b mtu 1400
ip netns exec rtr02 ip link set r2a mtu 1400

ip netns exec client01 ip link set c0  up
ip netns exec rtr01    ip link set r1a up
ip netns exec rtr01    ip link set r1b up
ip netns exec rtr02    ip link set r2a up
ip netns exec rtr02    ip link set r2b up
ip netns exec web01    ip link set w0  up

ip netns exec client01 ip route add default via 198.51.100.1
ip netns exec web01    ip route add default via 203.0.113.1
ip netns exec rtr01    ip route add 203.0.113.0/24 via 192.0.2.2
ip netns exec rtr02    ip route add 198.51.100.0/24 via 192.0.2.1
ip netns exec rtr01    sysctl -qw net.ipv4.ip_forward=1
ip netns exec rtr02    sysctl -qw net.ipv4.ip_forward=1

Then give web01 a small file and a 2 MB file to serve:

mkdir -p ~/mtu-www && cd ~/mtu-www
echo hello > small.txt
head -c 2000000 /dev/urandom > big.bin
sudo ip netns exec web01 python3 -m http.server 80 &

One thing worth doing before you capture anything: turn off segmentation offload on the two end hosts. Otherwise the kernel hands tcpdump huge "packets" of 7,000+ bytes before splitting them up, which makes an MTU post very confusing to read.

sudo apt install -y ethtool
sudo ip netns exec web01    ethtool -K w0 tso off gso off gro off
sudo ip netns exec client01 ethtool -K c0 tso off gso off gro off

When you're done, remove everything with:

for ns in client01 rtr01 rtr02 web01; do sudo ip netns del $ns; done

Healthy baseline

Before breaking anything, check that PMTUD works when ICMP is allowed. Both downloads should succeed:

sudo ip netns exec client01 curl -s -o /dev/null -m 10 -w "%{http_code} %{size_download} bytes\n" http://203.0.113.10/small.txt
sudo ip netns exec client01 curl -s -o /dev/null -m 10 -w "%{http_code} %{size_download} bytes\n" http://203.0.113.10/big.bin

Now send a full-size ping with DF set. -M do sets DF, and -s 1472 plus 28 bytes of IP and ICMP headers makes a 1500-byte packet:

sudo ip netns exec client01 ping -c1 -M do -s 1472 203.0.113.10

It doesn't get through, but it tells you why:

From 198.51.100.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)

That's rtr01 doing its job: it can't push 1500 bytes onto the 1400-byte link, so it says so. tracepath finds the same thing hop by hop:

sudo ip netns exec client01 tracepath -n 203.0.113.10

 1?: [LOCALHOST]                      pmtu 1500
 1:  198.51.100.1                     0.026ms
 2:  198.51.100.1                     0.004ms pmtu 1400
 2:  192.0.2.2                        0.010ms
 3:  203.0.113.10                     0.009ms reached
     Resume: pmtu 1400 hops 3 back 3

This is the behaviour you want on a real network: something tells you the path is smaller, and everything adjusts.

Break it

Now do what so many firewalls do by accident: drop the ICMP "fragmentation needed" messages. Add this on both routers:

sudo ip netns exec rtr01 iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP
sudo ip netns exec rtr02 iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP

Linux caches the path MTU it learned a minute ago, so clear that too, or the hosts will carry on using 1400 and hide the problem:

sudo ip netns exec client01 ip route flush cache
sudo ip netns exec web01    ip route flush cache

Run the two downloads again. The small file still works. The big one hangs, then curl gives up:

200 6 bytes
000 0 bytes

That's the symptom from the intro, reproduced. The connection opens fine, the request goes up fine, and then the download never arrives.

Diagnose it

Step 1: ping with different sizes

The quickest test needs nothing but ping. Try the full-size DF ping again:

sudo ip netns exec client01 ping -c1 -W1 -M do -s 1472 203.0.113.10

This time there's no "Frag needed" message. It just fails: 100% packet loss. Now try a smaller one:

sudo ip netns exec client01 ping -c1 -W1 -M do -s 1372 203.0.113.10

That works. 1372 plus 28 bytes of headers is exactly 1400. So small packets get through, full-size ones vanish without a word. On a real network you don't know the magic number, so you halve the gap between a size that works and one that fails until you find the largest one that gets through. That's your path MTU.

tracepath gives another hint. With the ICMP blocked, it never learns the smaller MTU, so its full-size probes die after the first router:

 1?: [LOCALHOST]                      pmtu 1500
 1:  198.51.100.1                     0.047ms
 2:  no reply
 3:  no reply
     Too many hops: pmtu 1500

Hop 1 still answers, but everything beyond the narrow link goes quiet, and it still believes the path is 1500. A path that "dies" at the same hop for big packets but not for a normal ping is a strong MTU signal.

Step 2: capture at both ends

This is where it clicks. Start a capture on each end host, then run the big download:

sudo ip netns exec client01 tcpdump -i c0 -w client.pcap tcp port 80 or icmp &
sudo ip netns exec web01    tcpdump -i w0 -w server.pcap tcp port 80 or icmp &
sudo ip netns exec client01 curl -s -o /dev/null -m 10 http://203.0.113.10/big.bin

Stop both captures afterwards with sudo pkill tcpdump.

The client sees a perfectly normal handshake, sends its GET, and receives the first small segment with the HTTP headers. Then nothing at all, until curl gives up 10 seconds later and closes the connection.

The server tells the real story. It's sending data in full-size 1,500-byte packets (1,448 bytes of TCP payload), getting no acknowledgement, and retransmitting the same segment with a growing gap: at about 0.2, 0.6, 1.5, 3.1 and then 6.6 seconds in my lab, roughly doubling each time.

Three Wireshark filters make this obvious on a busy capture:

Put together: the handshake works because SYN packets are tiny, the request works because it's small, and the response dies because it's the first thing big enough to hit the 1400-byte link. And since the ICMP message is being dropped, nobody is ever told.

Fix it

I tested three fixes. Between each one, undo the previous fix and run ip route flush cache on client01 and web01, so each test starts clean.

Fix 1: stop dropping the ICMP (the proper fix)

Remove the rule from both routers:

sudo ip netns exec rtr01 iptables -D OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP
sudo ip netns exec rtr02 iptables -D OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP

The big download now finishes in about 7 milliseconds. PMTUD does its job again.

On a real network, this means allowing ICMP type 3 code 4 through every firewall in the path, and ICMPv6 type 2 (Packet Too Big) if you run IPv6. Blocking all ICMP feels secure, but these messages are part of how IP works.

Fix 2: MSS clamping on the routers

Sometimes you can't fix the firewall that's dropping ICMP, because it isn't yours. MSS clamping works around it. The router rewrites the Maximum Segment Size (MSS) in the TCP handshake so neither end ever sends segments too big for the path:

sudo ip netns exec rtr01 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
sudo ip netns exec rtr02 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

With the ICMP still blocked, the big download works again, in about 8 milliseconds. You can see why in the capture: web01 offers an MSS of 1460, but the SYN-ACK that reaches client01 says 1360, which is 1400 minus 40 bytes of IP and TCP headers.

This is the standard fix on VPN, PPPoE and tunnel edges. Cisco IOS does the same with ip tcp adjust-mss on an interface, and FortiGate with set tcp-mss-sender and set tcp-mss-receiver on a firewall policy. The catch: it only helps TCP, and only for traffic passing through the device doing the clamping.

Fix 3: TCP MTU probing on the server

Linux can also find the path MTU without ICMP at all, by probing with different segment sizes and watching what gets acknowledged:

sudo ip netns exec web01 sysctl -w net.ipv4.tcp_mtu_probing=1

With ICMP still blocked and no clamping, the download does finish, but it took about 6.3 seconds in my lab, against 7 milliseconds with Fix 1. The server only starts probing after its normal retransmissions fail. It's a reasonable safety net on servers you control, not a fix.

Quick reference

Wrapping up

If small things work and big things hang, think MTU before anything else. Ping with DF set at a few sizes, capture at both ends, and look for big retransmitted packets with no "fragmentation needed" message anywhere. Then fix it properly by letting ICMP type 3 code 4 through, and use MSS clamping where you can't.

In this post I'll build a small lab, break the handshake in the three ways I see most often, and show what each one looks like in Wireshark. By the end you'll be able to look at a capture and say, within a minute, whether you're dealing with a closed port, a silent drop or a return-path problem.

Every capture in this post comes from a lab you can build on any Linux machine in about five minutes, with no VMs. The script is included, so you can reproduce each failure yourself.

The three-way handshake in 60 seconds

Every TCP connection starts with three packets:

1. SYN: the client asks to open a connection and sends its initial sequence number.

2. SYN-ACK: the server agrees, acknowledges the client's sequence number and sends its own.

3. ACK: the client acknowledges the server's sequence number. The connection is now established and data can flow.

Client                         Server
  | ---- SYN ------------------> |
  | <--- SYN-ACK --------------- |
  | ---- ACK ------------------> |
  |      (connection open)       |

A healthy handshake usually finishes within a few milliseconds on a LAN. When it doesn't finish, the packets that are there, and the ones that are missing, tell you where to look.

Lab setup

The lab is three Linux network namespaces on one machine, joined by virtual Ethernet (veth) pairs. Each namespace has its own interfaces, routing table and firewall, so it behaves like a separate host. It's quicker to build than VMs in EVE-NG or GNS3, and it runs anywhere.

Save this as lab.sh and run it with sudo bash lab.sh, or grab it, along with a cleanup script, from GitHub:

#!/bin/bash
# client01 (198.51.100.10) -- rtr01 -- web01 (203.0.113.10)
set -e
for ns in client01 rtr01 web01; do
  ip netns add $ns
  ip netns exec $ns ip link set lo up
done

ip link add c-eth0 type veth peer name r-eth0
ip link add r-eth1 type veth peer name w-eth0
ip link set c-eth0 netns client01
ip link set r-eth0 netns rtr01
ip link set r-eth1 netns rtr01
ip link set w-eth0 netns web01

ip netns exec client01 ip link set c-eth0 name eth0
ip netns exec rtr01    ip link set r-eth0 name eth0
ip netns exec rtr01    ip link set r-eth1 name eth1
ip netns exec web01    ip link set w-eth0 name eth0

ip netns exec client01 ip addr add 198.51.100.10/24 dev eth0
ip netns exec rtr01    ip addr add 198.51.100.1/24  dev eth0
ip netns exec rtr01    ip addr add 203.0.113.1/24   dev eth1
ip netns exec web01    ip addr add 203.0.113.10/24  dev eth0

ip netns exec client01 ip link set eth0 up
ip netns exec rtr01    ip link set eth0 up
ip netns exec rtr01    ip link set eth1 up
ip netns exec web01    ip link set eth0 up

ip netns exec client01 ip route add default via 198.51.100.1
ip netns exec web01    ip route add default via 203.0.113.1
ip netns exec rtr01    sysctl -qw net.ipv4.ip_forward=1

Start a web server on web01, then capture at both ends while the client connects:

sudo ip netns exec web01 python3 -m http.server 80 &

sudo ip netns exec client01 tcpdump -i eth0 -w client.pcap tcp port 80 &
sudo ip netns exec web01    tcpdump -i eth0 -w server.pcap tcp port 80 &

sudo ip netns exec client01 curl -m 10 http://203.0.113.10/

Capturing at both ends is the single most useful habit in handshake troubleshooting. It tells you which side of the path a packet disappeared on, and as you'll see in failure 3, sometimes it's the only way to tell two failures apart.

Open client.pcap in Wireshark and you'll see a healthy handshake. I've added the IP TTL as a column (right-click the TTL field in the packet details, then Apply as Column); it matters later.

When you're finished, remove the lab with:

for ns in client01 rtr01 web01; do sudo ip netns del $ns; done

Filters for finding failed handshakes fast

In a busy capture you won't spot a failed handshake by scrolling. These display filters do the work:

Wireshark also has a field called tcp.completeness, which scores each TCP conversation by the flags it has seen: SYN = 1, SYN-ACK = 2, ACK = 4, data = 8, FIN = 16, RST = 32. Recent versions show the same thing as letters in tcp.completeness.str. These are the values from my captures:

Note that the reset case is 37, not 33: the RST that answers a SYN also carries the ACK flag, which adds 4. So tcp.completeness == 1 finds every attempt that got no answer at all, and tcp.completeness.str contains "R" finds every conversation that was reset. If you use tshark rather than the GUI, add -2 (two-pass analysis), or early packets show only the flags seen so far.

Failure 1: SYN answered with RST

Reproduce it: stop the web server on web01 (fg, then Ctrl+C), then run the curl again. It fails instantly with Connection refused.

What Wireshark shows: two packets. The client's SYN, and an immediate RST, ACK coming back from 203.0.113.10, 45 microseconds later.

What it means: something answered on the server's behalf and said "no". Most often nothing is listening on that port: the service is stopped, crashed, or bound to a different port or address.

The catch: the reset isn't always from the server. Firewalls can be configured to reject with a reset, and they use the server's address as the source when they do it. To see this, start the web server again and add this rule on the router:

sudo ip netns exec rtr01 iptables -A FORWARD -p tcp --dport 80 -j REJECT --reject-with tcp-reset

The client capture looks almost identical, and the RST still claims to come from 203.0.113.10. The giveaway is the TTL:

• The RST from web01 left with a TTL of 64 and crossed one router, so it arrived with 63.

• The RST injected by rtr01 arrived with 64, because it never crossed a router at all.

There's a second clue if you captured at both ends: in the firewall case, web01's capture is empty. The SYN never reached the server, so the server can't have sent that reset.

In a real network, compare the reset's TTL with a normal SYN-ACK from the same server. If they differ, something in the path sent the reset, so look at firewalls and load balancers, not the application.

Next step: on the server, check what's listening with ss -tlnp | grep :80. If the service is up, work along the path looking for a reject rule.

Clear the rule before moving on: sudo ip netns exec rtr01 iptables -F.

Failure 2: SYN with no reply

Reproduce it: with the web server running, add a silent drop on web01's own firewall:

sudo ip netns exec web01 iptables -A INPUT -p tcp --dport 80 -j DROP

Run the curl again. This time it hangs, then gives up after 10 seconds with a timeout.

What the client capture shows: a SYN, then the same SYN retransmitted again and again. Wireshark marks the repeats as [TCP Retransmission].

Look at the Time column. I expected the gaps to double each time, as the textbooks describe. Instead, the first five retries came about one second apart, and only then did the gap grow, to two seconds. That's because recent Linux kernels (6.5 onwards) keep the first few SYN retries at a fixed one-second interval instead of doubling straight away, controlled by net.ipv4.tcp_syn_linear_timeouts. Older kernels and other operating systems back off differently, so don't read too much into the exact gaps. The pattern that matters is the same SYN, repeated, with nothing coming back.

What it means: the SYN was dropped somewhere, without any reply.

Where was it dropped? This is where the server-side capture earns its keep:

• The SYNs appear in the server capture: they reached the host, so the drop is on the host itself, usually its local firewall. That's what happens here: every SYN shows up in web01's capture, arriving with TTL 63. tcpdump sees packets before the host firewall does, which is why they still appear.

• The SYNs don't appear in the server capture: they were lost on the way. Check firewall policies, ACLs and routing between the two hosts, and capture at each hop until you find where they stop.

Next step: if the server never sees the SYN, check the path hop by hop. If it does, check the host firewall (iptables -L -n -v, nft list ruleset or Windows Defender Firewall) before touching the application.

Clear the rule before moving on: sudo ip netns exec web01 iptables -F.

Failure 3: SYN-ACK never acknowledged

Reproduce it: on the router, drop only the server's SYN-ACKs on their way back to the client:

sudo ip netns exec rtr01 iptables -A FORWARD -p tcp --sport 80 --tcp-flags SYN,ACK SYN,ACK -j DROP

Run the curl again. It hangs and times out, exactly like failure 2.

What the captures show: the client capture is indistinguishable from failure 2: a SYN and its retransmissions, nothing else. The server capture tells a completely different story:

The server is doing its job. It replies to the first SYN with a SYN-ACK, retransmits that SYN-ACK when no ACK arrives, and answers every one of the client's retransmitted SYNs with yet another SYN-ACK. None of them ever reach the client.

What it means: the forward path works but the return path doesn't. In real networks the usual causes are:

• Asymmetric routing through a stateful firewall: the SYN goes out one way, and the SYN-ACK comes back through a different firewall that never saw the SYN, so it drops the reply as out-of-state.

• Wrong default gateway or missing return route on the server: the SYN-ACK leaves by the wrong interface or next hop.

• NAT problems: the reply doesn't match a translation, so it's dropped or sent to the wrong place.

The lesson: a client-side capture alone can't tell failure 2 from failure 3. If you only take one thing from this post, take this: capture at both ends before you blame anything.

Next step: trace the return path from the server (ip route get 198.51.100.10, traceroute), and check the state tables or session logs on any firewall in the path.

Quick reference

Wrapping up

The handshake is the first thing to check whenever "the app is down". Three packets tell you whether the network is involved at all, and which side of the path to look at. Filter for SYNs, look at what comes back, check the TTL on any reset, and always capture at both ends.

In a future post I'll take this further into what happens after the handshake: zero windows, retransmissions in the data phase, and MTU problems that only show up once real traffic starts flowing.