Tuesday, January 6, 2026

HTTPS Freezes But Ping Works: The Silent MTU Problem

HTTPS Freezes But Ping Works: The Silent MTU Problem

HTTPS Freezes But Ping Works: The Silent MTU Problem

The Mystery:

A few weeks ago, I encountered a puzzling connectivity issue at a new site. The VPN tunnel was up and stable, ping responses were immediate and perfect, but something was seriously wrong. Web pages would only load halfway before freezing, HTTPS connections would hang mid-transfer, RDP sessions kept disconnecting randomly, and file uploads consistently failed at the same point every time.

Everything looked fine on the surface, but real applications just wouldn't work properly.

Initial Troubleshooting (That Didn't Work):

I went through all the usual suspects:

  • Checked the firewall → All rules clean, no blocks in the logs
  • Verified VPN status → UP and stable, no flapping
  • Suspected ISP issues → Called them, no problems reported
  • Restarted equipment → Router, switches, endpoints - no change
  • Ran connectivity tests → Ping worked perfectly, 0% packet loss
The Confusing Part: Small packets worked flawlessly while larger data transfers failed consistently. This pattern was the key clue I initially missed.

Root Cause:

It turned out to be a classic MTU (Maximum Transmission Unit) mismatch combined with blocked ICMP messages. Here's what was actually happening behind the scenes:

Packet Journey:

  1. PC sends a 1500-byte packet with DF (Don't Fragment) bit set
  2. Packet enters the IPsec VPN tunnel
  3. Encryption overhead adds extra bytes (ESP header, authentication, padding)
  4. Packet size now exceeds the path MTU
  5. Router drops the packet silently (because DF bit says "don't fragment me")

Why Ping Worked:

  • ICMP Echo packets are small (typically 64-100 bytes)
  • They easily pass through without hitting MTU limits
  • This is why ping is a terrible indicator of application-level connectivity

Why HTTPS/RDP Failed:

  • TCP uses larger packets and relies on Path MTU Discovery (PMTUD)
  • PMTUD requires ICMP "Fragmentation Needed" messages to work
  • These ICMP messages were blocked somewhere in the path
  • TCP kept retransmitting packets that would never fit through the tunnel
  • Result: Connection hangs or times out

The Solution:

Instead of changing VPN configuration, ISP settings, or reconfiguring every endpoint (which would be a nightmare), we adjusted TCP Maximum Segment Size (MSS) at the network edge.

Option 1: TCP MSS Adjustment (Recommended)

Router(config)# interface Tunnel0
Router(config-if)# ip tcp adjust-mss 1360

What this does: This command tells the router to rewrite TCP SYN packets, limiting the MSS value so TCP sessions start with smaller segments that fit within the tunnel MTU.

Option 2: Interface MTU Reduction

Router(config)# interface Tunnel0
Router(config-if)# ip mtu 1400

This reduces the MTU on the tunnel interface itself, forcing all traffic to use smaller packets.

Why Option 1 is Better:

  • Only affects TCP traffic (the problem traffic)
  • Doesn't impact UDP or other protocols unnecessarily
  • More efficient for mixed traffic environments
  • Doesn't require changes on endpoint devices

The Math:

Standard Ethernet MTU: 1500 bytes
IP header: 20 bytes
TCP header: 20 bytes
Available TCP payload: 1460 bytes

IPsec overhead (ESP): ~50-73 bytes (depending on encryption/authentication)

Safe MSS value: 1360 bytes (leaves room for all headers + encryption)

Immediate Results:

  • ✓ HTTPS connections loaded completely
  • ✓ RDP sessions remained stable for hours
  • ✓ File transfers completed successfully
  • ✓ Support tickets stopped coming in

Common Scenarios Where This Occurs:

  • IPsec VPN tunnels (GRE over IPsec, Site-to-Site VPN)
  • SD-WAN overlay networks (multiple encapsulation layers)
  • Cloud tunnels (AWS VPN, Azure VPN Gateway, GCP Cloud VPN)
  • PPPoE connections (already reduced MTU from 1500 to 1492)
  • MPLS networks with additional encapsulation
  • VxLAN overlays in data center environments

Prevention:

Always configure TCP MSS adjustment on tunnel interfaces or VPN endpoints to avoid this silent failure mode. Make it part of your standard VPN configuration template:

! For Cisco IOS/IOS-XE
interface TunnelX
 ip tcp adjust-mss 1360

! For Cisco ASA
sysopt connection tcpmss 1360

! For Palo Alto
set network interface tunnel units tunnel.X tcp-mss-adjustment ipv4 1360

Key Takeaway:

When connectivity tests pass but actual applications fail, think MTU. When small packets work but large ones don't, it's almost always MTU + PMTUD failure.

Don't rely on ping alone to validate connectivity. Test with actual application traffic or use ping with larger packet sizes:

# Windows
ping -f -l 1472 destination_ip

# Linux/Mac
ping -M do -s 1472 destination_ip

Note: 1472 bytes payload + 28 bytes headers = 1500 bytes total

Related Topics: Network Troubleshooting, VPN Configuration, IPsec, TCP/IP, Path MTU Discovery, Network Performance

No comments:

Post a Comment