Fortinet FCSS NST study materials
Fortinet FCSS NST study resources

Branch OSPF over IPsec: MTU, ECMP, and SaaS Breakout

Fortinet FCSS NST · Put your knowledge to work in context.

All case studies

Branch OSPF over IPsec: MTU, ECMP, and SaaS Breakout

A FortiGate 200G connects a 300-user branch to HQ over a route-based IPsec tunnel. OSPF runs over the tunnel in area 0, and the branch has a local ISP breakout for SaaS. After a recent change, users can reach HQ servers but large file transfers stall, the OSPF adjacency flaps every 20-30 minutes, and some SaaS traffic goes through HQ instead of the local breakout. The tunnel interface MTU is 1500 and MSS clamping is not configured. The branch has two equal-cost routes for 10.20.0.0/16: one over the tunnel and one over a backup wireless link. HQ advertises a summarized 10.0.0.0/8 over OSPF and a more specific 10.20.0.0/16 via eBGP. The branch has a policy route that sends TCP 80/443 to the local ISP; other traffic follows the OSPF default from HQ. No SD-WAN is configured at the branch.

1. Diagnose the file-transfer stalls and OSPF flaps. What MTU/MSS and routing evidence would you collect?

Read the worked answer

IPsec adds ESP overhead, so a 1500-byte tunnel MTU will black-hole large packets when DF is set and MSS is not clamped. Small pings and OSPF hellos may pass while file transfers stall. Collect diagnose vpn tunnel list, diagnose netlink interface list, and execute ping-options df with increasing sizes. Look for ICMP 'fragmentation needed' messages and retransmissions. OSPF adjacency flaps every 20-30 minutes can be caused by MTU mismatch during database exchange, unstable equal-cost links, or the wireless backup flapping. Check get router info ospf neighbor and OSPF logs; if the adjacency drops during large LSAs, MTU is a strong suspect. Set the tunnel interface MTU to a tested value (for example 1400) and clamp TCP MSS on the tunnel (for example 1360) so TCP negotiates below the path MTU. Verify both directions, because the branch and HQ must agree.

2. Which route will the branch choose for 10.20.0.0/16 and for SaaS traffic, and why? How should the design be corrected?

Read the worked answer

For 10.20.0.0/16, the branch will prefer the eBGP route (administrative distance 20) over OSPF (110), even if the OSPF path looks equal-cost; longest prefix also beats the /8 summary. If both an eBGP path and an OSPF path are installed, you can get asymmetric forwarding. For SaaS, the policy route for TCP 80/443 sends web traffic to the local ISP, but non-web or non-standard-port SaaS traffic follows the OSPF default from HQ, which explains the mix. The correction is to stop relying on a default learned over the tunnel for general internet traffic. Keep the local ISP as the explicit default for breakout, use policy routes or SD-WAN for the SaaS destinations, and filter the OSPF default at the branch if it is not wanted. For HQ prefixes, prefer one path with OSPF cost or BGP local preference and remove the equal-cost wireless path unless it is a tested backup.

3. Design a clean branch routing and MTU plan and describe how you would validate it.

Read the worked answer

Design: IPsec tunnel MTU/MSS explicitly; OSPF on the tunnel with a cost that makes the wireless link strictly backup; BGP for the specific HQ prefix or a single OSPF area with controlled summarization; local internet breakout as the only default for SaaS, with policy routes/SD-WAN for exceptions. Do not advertise a default from HQ unless the branch is meant to backhaul all internet traffic. Add link monitoring for the wireless backup and a route preference that prevents ECMP. Validate with get router info routing-table, get router info ospf neighbor, diagnose sys sdwan if used, and large-file tests. Confirm that a 10.20.0.0/16 flow uses the tunnel in both directions and that SaaS flows use the local ISP with the correct source NAT.