Alternative IKEv2 VPN Configuration: PMTUD-Friendly Network Setup

For users experiencing issues with disabled PMTU Discovery, this configuration takes a more conservative approach by enabling PMTUD and using MSS clamping instead.

Why This Approach?

Rather than blindly disabling PMTUD, this configuration:

• Keeps PMTU Discovery enabled so the system can adapt to different MTU sizes
• Uses iptables MSS clamping to ensure VPN packets fit within the tunnel
• Includes hardware offloading checks to prevent packet handling issues
• Includes diagnostics for non-standard MTU configurations

Step 1: Diagnose Your Network MTU

First, check your actual network MTU size:

# Check your primary network interface MTU
ip link show

# Test MTU by pinging with different sizes
ping -M do -s 1472 8.8.8.8  # 1472 + 28 bytes ICMP header = 1500
ping -M do -s 1448 8.8.8.8  # Conservative test

What to look for:

• Most networks use MTU 1500 (standard Ethernet)
• Some networks use 1492 (PPPoE), 1480 (GRE), or even smaller
• If ping works at 1472 but fails at 1500, your MTU is non-standard

Step 2: Check Hardware Offloading

Hardware offloading can interfere with MTU handling. Check what’s enabled:

# View current offloading settings (replace eth0 with your NIC)
ethtool -k eth0 | grep offload

# View TSO, GSO, GRO settings
ethtool -k eth0 | grep -E "(tso|gso|gro)"

Common offloading options:

• tcp-segmentation-offload (tso): NIC breaks large TCP packets
• generic-segmentation-offload (gso): Kernel handles it if NIC can’t
• generic-receive-offload (gro): NIC combines small packets into larger ones
• rx-vlan-offload: VLAN packet handling

If you’re experiencing issues, try disabling them:

# Disable potentially problematic offloading
ethtool -K eth0 tso off gso off gro off

# Make it permanent (add to /etc/rc.local or create systemd service)
cat > /etc/systemd/system-sleep/ethtool-offload.sh << 'EOF'
#!/bin/bash
if [ "$1" = "post" ]; then
    ethtool -K eth0 tso off gso off gro off
fi
EOF
chmod +x /etc/systemd/system-sleep/ethtool-offload.sh

Step 3: Alternative IP Configuration (Replace Step 6)

Instead of disabling PMTU Discovery entirely, use this configuration:

nano /etc/sysctl.conf

Replace the networking section with:

# IPv4 networking - PMTUD-friendly approach
net.ipv4.ip_forward = 1

# KEEP PMTU DISCOVERY ENABLED
# Set minimum MTU for ICMP fragmentation needed messages
net.ipv4.ipfragmentlow = 18000
net.ipv4.ipfragmenthigh = 20000

# Use MSS clamping via iptables instead
# (configured in next step)

# Security settings (same as before)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1

# IPv6 networking
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.send_redirects = 0

# Optional: If you have jumbo frames (MTU > 1500)
# net.ipv4.tcp_mtu_probing = 1  # Enable TCP MTU probing

Apply changes:

sysctl -p

Step 4: Configure MSS Clamping with iptables

Instead of disabling PMTUD, use iptables MSS clamping to automatically adjust packet sizes:

# For IPv4 - Clamp MSS to account for IPsec overhead (typically 1380-1400)
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

# For IPv6 - Same approach
ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

What this does:

• Automatically adjusts TCP MSS based on actual path MTU
• Works dynamically without manual size calculation
• Preserves PMTU discovery functionality

Make this persistent via UFW:

nano /etc/ufw/before.rules

Add after the NAT section:

# MSS Clamping for IPsec VPN
-A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

COMMIT

And for IPv6:

nano /etc/ufw/before6.rules

Add:

# MSS Clamping for IPsec VPN IPv6
-A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

COMMIT

Step 5: Update strongSwan Configuration (Optional Enhancement)

In your /etc/ipsec.conf, you can also add fragmentation hints:

conn roadwarrior
  # ... existing config ...
  
  # Fragmentation handling
  fragmentation=yes
  forceencaps=yes
  
  # Optional: Adjust IKE and ESP fragment sizes if you have issues
  # These values depend on your actual MTU
  # Default IKE fragment size: 2048, ESP: 1280
  # If problems persist, try:
  # ikelifetime=28800s
  # lifetime=3600s

Step 6: Diagnostic Commands for Troubleshooting

Test your configuration with these commands:

# Check if PMTU discovery is working
tracepath -m 30 8.8.8.8

# Test VPN tunnel with different packet sizes
# (from a connected VPN client)
ping -M do -s 1300 8.8.8.8  # Should work through VPN
ping -M do -s 1400 8.8.8.8  # Test larger packet
ping -M do -s 1472 8.8.8.8  # Test near-max

# Monitor for fragmentation
netstat -s | grep -i "fragments\|reassembled"

# Check current TCP MSS values in use
ss -tni | grep -i mss

# Monitor ICMP fragmentation needed messages
tcpdump -ni any 'icmp[icmptype] == icmp-unreach and icmp[icmpcode] == frag-needed'

Step 7: If You Have Non-Standard MTU

If your network uses a custom MTU (e.g., 1492 for PPPoE):

# Set interface MTU
ip link set dev eth0 mtu 1492

# Make it permanent in netplan (Ubuntu 20.04+)
nano /etc/netplan/00-installer-config.yaml

Add to the interface:

  eth0:
    dhcp4: true
    mtu: 1492  # Your custom MTU

Then apply:

netplan apply

Summary: Key Differences from Main Guide

When to Use Each Approach

Use the Main Guide if:

• Your network is standard Ethernet (MTU 1500)
• You want the simplest possible configuration
• You’re not experiencing packet fragmentation issues
• You have a straightforward network topology

Use This Alternative if:

• You’re experiencing mysterious connection drops
• Your network has non-standard MTU sizes (PPPoE, GRE, etc.)
• You have jumbo frames enabled
• You want a more adaptive, less strict configuration
• You need better troubleshooting capabilities