MTU & MSS Mismatches — 'Works in the Office, Broken Over VPN'

! The single most important test for MTU diagnosis:
! Send a large packet with DF bit set — if this fails but small ping succeeds, MTU is the problem

! From a Windows client:
ping <destination-ip> -f -l 1472
! -f = set Don't Fragment bit
! -l 1472 = 1472 bytes payload + 28 bytes IP/ICMP header = 1500 total
! If this succeeds: MTU is fine on this path
! If this fails: MTU problem confirmed

! Try smaller sizes to find the exact MTU ceiling:
ping <destination-ip> -f -l 1400
ping <destination-ip> -f -l 1300
ping <destination-ip> -f -l 1200
! The largest size that succeeds tells you the effective MTU

! From a Linux/macOS client:
ping -M do -s 1472 <destination-ip>
! -M do = set DF bit
! -s 1472 = payload size

! From Cisco IOS router:
ping <destination-ip> size 1500 df-bit repeat 5
! This is the router-originated version — tests the path from the router itself

! Check current MTU on all interfaces
show interfaces | include MTU|line protocol

! Check specific interface
show interface GigabitEthernet0/0 | include MTU

! Check MTU on subinterfaces (common mismatch point)
show interfaces | include Ethernet|MTU

! For tunnel interfaces — where the mismatch usually lives:
show interface Tunnel0
! Look for: MTU 1476 bytes (or whatever value is set)
! Compare this to physical interface MTU of 1500
! The tunnel MTU should be physical MTU minus tunnel overhead

! Check if ICMP unreachable messages are being generated
! (confirms fragmentation is happening or DF-drop is happening)
show ip interface | include Unreachables

! Debug IP ICMP to see fragmentation-needed messages:
debug ip icmp
! WARNING: Use on low-traffic interfaces only — very verbose
! Look for: "ICMP: dst (x.x.x.x) frag. needed and DF set, sending"
! This confirms the router is generating PMTUD responses

! Check if ICMP unreachables are disabled (blocks PMTUD response)
show running-config | include no ip unreachables

! If you see "no ip unreachables" on the interface — this blocks PMTUD
! Re-enable with: ip unreachables (on the outbound interface)

! Check MTU on the path end-to-end using traceroute with probe size
traceroute <destination> size 1500 df-bit

! On Cisco router — check tcp adjust-mss configuration
show running-config | include tcp adjust-mss

! Check active TCP sessions MSS negotiation:
! Capture packets and look at SYN and SYN-ACK for MSS option
! In Wireshark: tcp.flags.syn==1 → look at TCP Options → MSS value

! On PAN-OS — check MSS clamping in interface config
show interface ethernet1/1
! Look for: "MSS Adjustment" in the output

! On Linux — check interface MTU
ip link show
! Look for: mtu 1500 or whatever the value is
! Check effective MSS for a connection:
ss -ti dst <remote-ip>
! Shows: rcvmss, advmss, pmtu values

! Apply MSS clamping on the interface where packets exit to the problem path
! This modifies the MSS value in TCP SYN packets to prevent oversized segments

! On Cisco IOS — apply to the WAN or tunnel interface:
interface GigabitEthernet0/0
  ip tcp adjust-mss 1452
! This tells the router to rewrite any TCP MSS value above 1452 to 1452
! 1452 = 1500 (Ethernet) - 20 (IP) - 20 (TCP) - 8 (overhead buffer)

! For IPsec VPN tunnels — use a lower value:
interface Tunnel0
  ip tcp adjust-mss 1360
! IPsec ESP overhead: ~50-60 bytes
! 1500 - 60 (IPsec) - 20 (IP) - 20 (TCP) = approximately 1360-1400

! Verify the clamping is working:
! Run a packet capture on the tunnel interface
! Check SYN packets outbound — MSS should now show 1452 (or your set value)
! NOT the original 1460 that the client negotiated

! On PAN-OS — MSS adjustment in Network > Interfaces > Advanced tab
! Or via CLI:
set network interface ethernet ethernet1/1 adjust-tcp-mss enable yes
set network interface ethernet ethernet1/1 adjust-tcp-mss ipv4-mss-adjustment 40