NSE7 Part 11: Advanced IPsec: Multihub, Multiregion, and Large Deployments

The IPsec Deep Dive series covers ESP/AH, IKE phase 1 and phase 2, and NAT-T at the protocol level, and Beyond PSK covers moving a Fortinet SD-WAN IPsec design from pre-shared keys to a real PKI. This post assumes both and is built entirely around what “Advanced IPsec” means at the scale the blueprint actually tests: this is the single heaviest-weighted domain on the exam alongside routing, 25-35%, and it earns that weight because a hub-and-spoke or dual-hub IPsec design touches nearly every other domain in this series at once.

Mastering IPsec Topology Design

IKEv2 (the blueprint specifies IKE version 2 explicitly, over the older IKEv1 that Part 1 of the IPsec Deep Dive covers alongside v2) is the assumed baseline for enterprise SD-WAN IPsec design at this exam’s level, largely for its improved rekey behavior and native support for the MOBIKE extension relevant to some resilience scenarios. Topology design at the “advanced” level this domain tests is less about phase 1/phase 2 parameter selection, which is NSE4 territory, and more about the structural decisions covered in the rest of this post: how many hubs, how tunnels aggregate, and how routing self-heals when a hub or a path fails.

Dead Peer Detection Modes

DPD (set dpd under config vpn ipsec phase1-interface) detects a peer that’s gone silent without a clean tunnel teardown. FortiOS offers three modes, and best practice is choosing deliberately rather than leaving the default unexamined:

• on-demand: DPD probes are sent only when there’s outbound traffic queued with no recent inbound traffic to confirm the peer is alive, minimizing probe overhead at the cost of slower detection for genuinely idle tunnels.
• on-idle: probes fire on a fixed interval regardless of traffic, giving consistent, traffic-independent failure detection at the cost of constant background probe overhead across every configured tunnel.
• disable: no DPD at all, relying entirely on IKE’s own rekey timers to eventually notice a dead peer, which is slow enough that it’s rarely the right choice for any tunnel a design actually depends on for redundancy.

The design-relevant choice is on-demand versus on-idle: a tunnel carrying constant background traffic gets adequate failure detection from on-demand alone with lower overhead, while a tunnel that’s genuinely bursty or often idle, but still needs fast failover the moment it’s needed, is better served by on-idle’s constant probing despite the overhead.

Outbound NAT for IPsec Interfaces with No IP Address

A route-based IPsec tunnel interface commonly has no IP address of its own (set ip 0.0.0.0 0.0.0.0 or simply unnumbered), relying entirely on the tunnel’s routing rather than interface addressing. This creates a specific, non-obvious problem for outbound NAT: a firewall policy performing NAT that would ordinarily use “use outgoing interface address” as its NAT source has no address to actually use on an unnumbered tunnel interface. The fix is an explicit IP pool bound to the policy rather than interface-based NAT, or, where the design genuinely needs the tunnel interface to carry an address (some dual-hub and loopback-adjacent designs benefit from this anyway), assigning one deliberately rather than leaving it unnumbered and discovering the NAT gap during testing.

OpenSSL for IPsec VPNs

FortiOS’s IPsec implementation is built on OpenSSL for its cryptographic primitives, and the practical, exam-relevant consequence is that IKE/IPsec cipher and Diffie-Hellman group support tracks what the underlying FortiOS OpenSSL build actually supports for a given firmware version, which is why cipher suite and DH group availability can differ between FortiOS versions in ways that aren’t always obvious from the VPN configuration GUI alone, and why a design specifying a particular cipher suite for compliance reasons needs to confirm actual support against the specific FortiOS version in use rather than assuming universal availability across the platform line.

IPsec Aggregate for Redundancy and Load Balancing

An IPsec aggregate interface (config system ipsec-aggregate) bundles multiple individual IPsec tunnel interfaces into one logical interface, distributing traffic across the member tunnels similarly in concept to a physical link aggregate, but for tunnels rather than physical links. This gives both redundancy (a member tunnel failing doesn’t take the whole aggregate down, just reduces its available capacity) and load balancing (traffic spreads across all member tunnels rather than concentrating on one), and is a distinct mechanism from SD-WAN zones containing multiple tunnel members, though the two are frequently used together, with an IPsec aggregate as a single SD-WAN zone member representing several underlying redundant tunnels as one unit to SD-WAN’s own rule logic.

Overlapping Routes in Remote VPNs

A specific, recurring problem in any design aggregating VPN connectivity from multiple independently-administered remote sites (an MSSP scenario, or an enterprise absorbing an acquired company’s network): two remote sites may present overlapping or identical private address ranges, since neither was necessarily designed with awareness of the other. FortiOS’s answer at the routing layer is VRF or VDOM-based isolation (keeping overlapping-range sites in genuinely separate routing contexts rather than a shared table where the overlap would be unresolvable), or, where the sites must actually communicate, NAT applied specifically at the point where the overlapping ranges would otherwise collide. This is a design problem the exam expects to be recognized from a described scenario (two acquired sites both using 10.0.0.0/24 internally) rather than treated as an edge case unlikely to come up.

MTU, MSS, and IPsec Fragmentation

IPsec’s ESP encapsulation adds overhead (IV, ESP header/trailer, and, for tunnel mode, an additional IP header) that reduces the effective MTU available to the original payload compared to the underlying physical link’s MTU. Left unaddressed, TCP sessions across the tunnel negotiate an MSS based on the physical interface’s full MTU, produce packets that then need fragmentation to fit through the tunnel’s actual reduced MTU, and fragmentation, especially post-encryption fragmentation, is expensive and, across many real-world paths, unreliable if any hop along the way drops fragmented traffic.

The standard fix is TCP MSS clamping on the tunnel interface (set tcp-mss-sender / set tcp-mss-receiver under the phase1-interface, or the equivalent firewall policy setting), which rewrites the MSS value in the TCP handshake itself so that TCP sessions negotiate a payload size that fits within the tunnel’s actual available MTU from the start, avoiding fragmentation entirely for TCP traffic rather than relying on IP-layer fragmentation to paper over an MTU mismatch after the fact. Container Networking Part 4 covers the identical MTU-overhead problem for VXLAN encapsulation, worth reading as the same underlying issue in a different tunneling context.

Hardware Offload: Encryption, FEC, and the NPU-Flag Field

On NP-equipped platforms, IPsec encryption and decryption can be offloaded to hardware, a major factor in whether a given platform can sustain its rated throughput under real IPsec load rather than just its clear-text forwarding throughput. diagnose vpn ipsec status and session-level inspection via diagnose sys session list (filtered to a specific session) reveal the session’s NPU-Flag field, whose value indicates whether that session’s IPsec processing is genuinely NPU-offloaded (npu) or falling back to the CPU (absent or a different flag value), which is the direct diagnostic answer to “is this tunnel’s traffic actually hardware-accelerated” rather than inferring it from throughput numbers alone.

Forward Error Correction (FEC) is a newer FortiOS SD-WAN feature that proactively adds redundant data to an IPsec-tunneled stream, allowing the receiving end to reconstruct a bounded amount of lost data without retransmission, valuable specifically for latency-sensitive traffic (voice, video) over lossy WAN paths where waiting for TCP-style retransmission would itself introduce unacceptable additional latency. FEC has a genuine bandwidth cost (the redundant data itself consumes capacity), which makes it a deliberate per-application-class choice rather than a blanket setting, consistent with the same cost-versus-benefit framing that ran through the security profiles domain in Part 7.

Dual-Hub Topologies

A single-hub design has an obvious structural weakness: the hub is a single point of failure for every spoke’s connectivity to every other spoke and to any centrally-hosted resource. Dual-hub topologies address this by giving every spoke tunnels to two independent hubs rather than one, and the design work is almost entirely about how routing behaves once a spoke genuinely has two viable paths to the rest of the network rather than one.

SD-WAN with Dual-Hub Topologies, and Dual-Hub Options in the Overlay Template

Part 6’s SD-WAN overlay template is where dual-hub topology gets expressed at the FortiManager level: the overlay template’s dual-hub options generate both spoke-to-hub-A and spoke-to-hub-B tunnels, plus the underlying SD-WAN zone and BGP configuration for both, from a single template rather than requiring the design to be built twice by hand. Configuration specifics for large topologies at this point become largely a Part 6 concern again: metadata variables and neighbor-groups from Part 9 are what make a dual-hub, fifty-spoke design operationally tractable rather than fifty hand-built spoke configurations.

BGP Routing and Self-Healing in Dual-Hub Designs

BGP advanced options for SD-WAN and routing options for dual-hub topologies are, in practice, the same question asked twice: how does a spoke’s routing know to prefer hub A under normal conditions but genuinely fail over to hub B if hub A (or the path to it) degrades, without manual intervention. This is SD-WAN self-healing, and it’s built from pieces already covered across this series rather than being a separate mechanism: BGP-learned routes via both hubs (Part 9), an SD-WAN rule using a Lowest Cost (SLA) or Best Quality strategy across both hub-facing zones (Part 10), and BFD bound to both BGP sessions (Part 9) for fast failure detection. What makes it “self-healing” specifically is that no single piece is new, the design property emerges from BGP, BFD, and SD-WAN rule strategy all pointed at the same dual-hub topology correctly, which is exactly why this is tested as a scenario-integration question rather than a single feature to memorize.

Multiregion Topologies and Large Deployments

Extending dual-hub design across multiple geographic regions, each with its own regional hub pair, adds a further routing question: how does a spoke in Region A reach a resource behind Region B’s hubs. Routing specifics for multiregion topologies typically resolve this via BGP route propagation between regional hub pairs (the hubs themselves running BGP to each other, redistributing what they learn from their own spokes), so that inter-region reachability is a property of the hub-to-hub BGP relationship rather than requiring every spoke to have a direct relationship with every other region’s infrastructure. Hub Placement Part 3 and the Cloud On-Ramp series both cover adjacent multiregion and multicloud hub-placement decisions worth reading alongside this section.

Common MSSP Deployments with SD-WAN

An MSSP running SD-WAN as a managed service for multiple independent customers layers customer isolation (VDOMs, per Part 4) on top of the dual-hub/multiregion topology this post has been building: shared hub infrastructure serving multiple customer VDOMs, each with its own spoke fleet, its own BGP AS or route-distinguisher scheme, and its own SD-WAN rule sets, all riding shared physical hub hardware without customer traffic or routing information leaking across the VDOM boundary.

VRF-Aware Overlays

VRF-aware overlays are the mechanism that makes genuine multi-tenant routing isolation possible on shared tunnel infrastructure without requiring a fully separate VDOM (and its associated licensing cost) per tenant: IPsec tunnels and the SD-WAN configuration riding on them can be bound to a specific VRF, so that a single physical hub can maintain multiple independent, non-overlapping routing contexts for different tenants or business units over what is, at the physical and even the IPsec-tunnel-interface level, shared infrastructure. This is the lighter-weight alternative to full VDOM-based MSSP isolation from Part 4, appropriate where the isolation requirement is genuinely about routing-table separation rather than the deeper administrative and security-profile-level separation VDOMs provide.

Where Part 12 Picks This Up

Everything in this post assumes IPsec tunnels are statically provisioned, spoke to hub, hub to hub, however many of them a design calls for. Part 12 removes that assumption entirely: ADVPN builds tunnels on demand, between spokes that were never explicitly configured to peer with each other at all, and the routing design underneath it (which this post has been building toward) is what makes that possible.