Route-Based IPsec VPN Up but Bulk Transfers Stall
An SRX340 at headquarters and an SRX300 at a branch office build a route-based IPsec VPN. IKEv2 phase 1 and phase 2 are up; st0.0 is in the VPN zone; static routes point 10.2.0.0/16 at st0.0. The HQ subnet is 10.1.0.0/16 and the branch subnet is 10.2.0.0/16. Small pings from 10.1.1.10 to 10.2.1.10 succeed, and the branch server SSH banner appears, but the SSH session freezes when output scrolls. HTTPS downloads from the branch server stall after a few kilobytes. A packet capture on the HQ st0.0 shows large TCP segments leaving HQ but no matching replies. The branch server has MTU 1500 and its default gateway is the branch SRX. The WAN path MTU is 1500. There is no MSS clamping configured. The security policy permits junos-ssh and junos-https over the tunnel.
1. What is the most likely cause, and how would you confirm it without changing production?
Read the worked answer
This is a classic IPsec MTU/MSS black hole. The tunnel adds ESP overhead; with a 1500-byte WAN path, a 1500-byte TCP segment with DF set cannot fit and is dropped. Small packets, the TCP handshake, and the SSH banner pass, which makes the tunnel look healthy. Bulk transfers use the full 1460-byte MSS and stall. Confirm with ping 10.2.1.10 size 1400 do-not-fragment and increase the size until it fails; also check show interfaces st0.0 for MTU and show security ipsec statistics for errors. A packet capture on st0.0 showing large outbound segments with no replies supports the diagnosis. show security flow session will show long-lived sessions with bytes in one direction only. Do not assume IKE or the policy is the problem when phase 1 and phase 2 are up.
2. What is the correct remediation, and why is it better than clearing the DF bit?
Read the worked answer
Clamp TCP MSS on the tunnel so the endpoints negotiate a segment size that fits after IPsec overhead. For example, set set interfaces st0 unit 0 family inet tcp-mss 1350 or use the global set security flow tcp-mss all-tcp mss 1350, and optionally set the st0 MTU to 1400. The SYN and SYN-ACK are rewritten before the data flows, so neither side sends oversized segments. Clearing the DF bit or letting the SRX fragment works around the symptom but increases fragmentation, CPU load, and latency, and it can still fail if fragments are filtered. MSS clamping is the cleaner fix. Verify with a large SSH transfer and show interfaces st0.0 detail; a capture should show segments at or below the clamped MSS.
3. Why not simply lower the branch server MTU to 1400?
Read the worked answer
Lowering the server MTU only affects packets that the server originates. Traffic from HQ clients to the server, and traffic from other sites, can still arrive at the tunnel with a 1500-byte MTU and a 1460-byte MSS. Path MTU discovery may also be blocked by ICMP filters, so the sender never learns the lower size. The tunnel is the shared bottleneck, so the fix belongs on the tunnel interface or in the TCP MSS policy on the SRX. Also, changing a server MTU can cause unexpected behavior for local traffic and is harder to audit across many servers. Use MSS clamping at the tunnel and document the value.