Retail ADVPN Overlay with a CGNAT LTE Underlay
Northline Retail runs 80 stores on FortiGate 60F appliances, managed by FortiManager. Each store has a 100/100 Mbps fiber circuit and a 20/10 Mbps LTE circuit; the LTE provider uses CGNAT and hands the FortiGate a private WAN address. Two FortiGate 200F hubs sit in separate data centers, each with 1 Gbps internet and static public addresses. The business wants an ADVPN overlay so stores can reach the data center and, for voice and click-and-collect, reach each other directly. The current design builds one IPsec tunnel per store to each hub with static routes. A pilot store shows that when its fiber fails, traffic moves to LTE but branch-to-branch voice still goes through the hub and latency rises from 40 ms to 170 ms. The CIO also wants a 200 ms failover target and no oversubscription of the hubs.
1. Which links should terminate the ADVPN overlay, and how would you configure the hub and spoke roles? Explain the effect of the LTE CGNAT circuit on direct spoke-to-spoke shortcuts.
Read the worked answer
Both hubs should terminate ADVPN. Each store should build tunnels to both hubs over each ISP, so at least one tunnel per ISP per hub, and preferably four overlays per store. On the hubs, enable the ADVPN discovery/sender role so spokes learn other spokes' public addresses. On the spokes, enable the receiver role so they can be told about a shortcut. The LTE circuit is CGNAT: the FortiGate WAN address is private and the provider does not forward inbound IKE, so another spoke cannot initiate a direct IPsec shortcut to it. The store can still use LTE as an underlay to the hubs because the store initiates those tunnels outbound. The practical design is to keep fiber as the preferred member for voice, use LTE as backup for hub-routed traffic, and accept that any shortcut to or from a CGNAT store falls back to the hub path. If direct voice between two stores is mandatory, put a public or port-forwarded circuit on at least one end, or use a hub as relay and budget the latency.
2. Propose a BGP design for the overlay, including route advertisement, next-hop handling, and how you prevent a store from becoming transit between hubs.
Read the worked answer
Use a private AS per store with iBGP inside the overlay, or eBGP with the hubs. The hubs should be route reflectors and advertise a summary for the data center; each store advertises only its own /24. Do not let stores advertise a default or hub routes back into the overlay. For ADVPN, preserve the remote spoke next-hop for spoke routes so the receiving spoke can identify the peer and trigger a shortcut; if the hub rewrites next-hop to itself, traffic stays hub-routed. Apply route maps: outbound from a spoke permit only its LAN, inbound to a spoke deny prefixes learned from other stores that would create transit. Set a maximum-prefix limit and prefer the fiber path with local preference or SD-WAN priority. The hub should not install a route from one store to another store's LAN as a transit path; it should forward the first packet and let the ADVPN shortcut take over.
3. The CIO asks for 200 ms failover for voice. Which SD-WAN and IPsec settings do you use, and what will you tell them about the CGNAT link?
Read the worked answer
Use an SD-WAN health check per underlay with a short interval, around 500 ms, and an SLA that tracks latency, jitter, and packet loss. The voice rule should be top-of-list, match the voice destination or internet service, use SLA mode, and order fiber above LTE. The 200 ms target is achievable only for fiber paths. The hub-routed path over LTE measured 170 ms before queuing, so do not promise 200 ms for branch-to-branch voice when fiber is down. For the CGNAT link, configure tunnels to the hubs only, disable shortcut expectations, and use IPsec DPD plus SD-WAN SLA to fail over. Verify with diagnose sys sdwan health-check status and diagnose sys sdwan service. Test a fiber failure and confirm that voice either stays hub-routed within budget or is blocked rather than degraded.