ADVPN hub first then shortcut

Lessons · FortiGate IPsec S2S · ADVPN overlay

Hero · hub is the parent, shortcut is the child

Why spokes still hairpin

The day-one ticket is always the same: “IPsec is up, so spoke-to-spoke should be direct.” Wrong. A green parent SA to the hub only proves the overlay underlay. Direct spoke-to-spoke is a different SA, created after three other things are true: the hub is allowed to send shortcut offers, the spoke is allowed to receive them, and overlay routing still lists the remote spoke overlay IP as BGP next-hop so the kernel has something to resolve via the new child.

Three hairpin-forever states look identical in IPsec Monitor (parent up, no child):

• Hub missing auto-discovery-sender enable — IKE never sends a shortcut-offer, even when spoke-to-spoke traffic transits.
• Spoke missing auto-discovery-receiver enable — offer arrives, spoke ignores it.
• Hub iBGP next-hop-self enable — spokes learn 10.22.0.0/24 via 10.10.100.254 (the hub). Recursive lookup never points at Spoke2. Shortcut, if it even forms, is unused.

Concept — hub-spoke overlay

ADVPN is a hub-and-spoke IPsec fabric that can later shortcut. Every spoke has one (or more) parent tunnels to the hub. The hub phase1 is type dynamic so N spokes share one object. Overlay addresses live on the tunnel interfaces. Dynamic routing — lab is iBGP — advertises each site LAN across that overlay. That is the control plane. The data plane for spoke-to-spoke starts as a hairpin and only then becomes a shortcut.

Overlay routing is the steering plane

IKE does not install spoke LAN routes. Fortinet is explicit: ADVPN requires a dynamic routing protocol. Lab is iBGP on the overlay, one AS, hub as route reflector. Each spoke advertises its LAN. The hub reflects those prefixes to the other spokes and leaves the BGP next-hop as the originating spoke’s overlay IP.

That next-hop is the whole trick. Spoke1 learns 10.22.0.0/24 via 10.10.100.2. Until a shortcut exists, 10.10.100.2 recursively resolves via the parent tunnel to the hub. After the shortcut comes up, IKE injects a /32 (or a dedicated shortcut interface) to 10.10.100.2 via the child SA. Same BGP prefix. Better recursive resolution. Traffic leaves the hairpin without a BGP reconvergence.

Path — first packet, then IKE offer

Journey · hub tunnel, overlay, offer, then direct

Order is the whole job. A shortcut cannot form before the parent, and it will not be used if overlay routing still points at the hub.

1. Spoke1 and Spoke2 bring up parent IKE/IPsec to 203.0.113.1.
2. iBGP establishes over the overlay. Hub RR reflects 10.22.0.0/24 to Spoke1 with NH 10.10.100.2.
3. Host in 10.11.0.0/24 sends to 10.22.0.0/24. Spoke1 encapsulates toward the hub (only current resolution of that NH).
4. Hub forwards the packet to Spoke2 and, because sender is enabled, emits an IKE shortcut-offer toward Spoke1 containing Spoke2’s public IP 198.51.100.22.
5. Spoke1 (receiver) initiates a child SA to Spoke2. On success, IKE installs a path to 10.10.100.2 via the child. Subsequent packets skip the hub.

Hub vs spoke knobs

The GUI will let you build a dial-up IPsec named like ADVPN. It will not set the flags that make ADVPN. Fortinet admin guide: GUI does not support auto-discovery-sender, auto-discovery-receiver, auto-discovery-forwarder, or iBGP neighbor-group. Finish those in CLI.

Do — Side A / B / C

Lab: hub WAN 203.0.113.1, Spoke1 198.51.100.11, Spoke2 198.51.100.22, overlay 10.10.100.0/24, iBGP AS 65001. One underlay. No SD-WAN members in this lesson.

Side A — underlay / reachability

1. Hub and spokes can UDP/500 and UDP/4500

   From Spoke1, 203.0.113.1 answers IKE. NAT-T on. If a spoke sits behind NAT, the hub still sees it as a dynamic peer; spoke-to-spoke IKE then depends on at least one side being reachable on 500/4500. Two NAT-hidden spokes with no hairpin mapping is a shortcut that will never complete — parent stays up.

2. Do not publish LAN routes on the WAN

   Underlay is only the three WAN addresses. Overlay IPs stay on the tunnel interfaces. If 10.11.0.0/24 is already in the WAN VRF, you do not have an ADVPN problem — you have a leak.

Side B — product (IPsec, overlay, BGP, policy)

1. Hub phase1 + phase2

   VPN > IPsec Tunnels can create the dial-up object. Then CLI — the GUI will not set sender. Source: FortiOS admin guide “ADVPN and shortcut paths” / “ADVPN with BGP as the routing protocol”.

config vpn ipsec phase1-interface
    edit "advpn-hub"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set add-route disable
        set auto-discovery-sender enable
        set psksecret <lab-psk>
    next
end
config vpn ipsec phase2-interface
    edit "advpn-hub"
        set phase1name "advpn-hub"
        set auto-negotiate enable
    next
end
config system interface
    edit "advpn-hub"
        set ip 10.10.100.254 255.255.255.255
        set remote-ip 10.10.100.253 255.255.255.0
        set allowaccess ping
    next
end

config vpn ipsec phase1-interface
    edit "spoke1"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device enable
        set add-route disable
        set auto-discovery-receiver enable
        set remote-gw 203.0.113.1
        set psksecret <lab-psk>
    next
end
config vpn ipsec phase2-interface
    edit "spoke1"
        set phase1name "spoke1"
        set auto-negotiate enable
    next
end
config system interface
    edit "spoke1"
        set ip 10.10.100.1 255.255.255.255
        set remote-ip 10.10.100.254 255.255.255.255
        set allowaccess ping
    next
end

1. Overlay iBGP — hub RR, original next-hop

   Network > BGP can set AS and a neighbor. Neighbor-group, neighbor-range, and RR client are CLI. Do not enable next-hop-self on the hub group.

config router bgp
    set as 65001
    set router-id 10.10.100.254
    config neighbor-group
        edit "advpn"
            set remote-as 65001
            set route-reflector-client enable
            set link-down-failover enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.100.0 255.255.255.0
            set neighbor-group "advpn"
        next
    end
    config network
        edit 1
            set prefix 10.1.0.0 255.255.255.0
        next
    end
end

config router bgp
    set as 65001
    set router-id 10.10.100.1
    config neighbor
        edit "10.10.100.254"
            set remote-as 65001
            set update-source "spoke1"
            set link-down-failover enable
        next
    end
    config network
        edit 1
            set prefix 10.11.0.0 255.255.255.0
        next
    end
end

1. Firewall policy that forwards the first hairpin

   Hub: overlay-to-overlay (tunnel interface or a zone that contains advpn-hub) accept, NAT disabled, for spoke LANs. If this policy drops, the hub never forwards stage 3 and IKE never offers. Spokes: LAN to tunnel accept, NAT disabled. Source: same ADVPN BGP guide plus ordinary FortiOS policy lookup.

Side C — proof

1. Parent identity

   diagnose vpn tunnel list — parent advpn-hub / spoke1 up. get router info bgp neighbors — Established to 10.10.100.254 / .1 / .2.

2. NH is the remote spoke, not the hub

   On Spoke1: get router info routing-table bgp shows 10.22.0.0/24 via 10.10.100.2. If you see via 10.10.100.254, stop and remove next-hop-self. Do not ping yet expecting a shortcut.

3. Generate spoke-to-spoke, then re-list tunnels

   From a host in 10.11.0.0/24 (or sourced ping on Spoke1): traffic to 10.22.0.1. Re-run diagnose vpn tunnel list. You want a child (spoke1_0 or similar) with remote 198.51.100.22. Then the same BGP prefix recursively via that child. IKE debug if the child never appears: diagnose debug application ike -1 and look for shortcut-offer / SHORTCUT-QUERY.

One flow after go-live

After the parent overlay is up:

1. PC in 10.11.0.0/24 sends to 10.22.0.1. Spoke1 looks up BGP, NH 10.10.100.2, currently via parent to hub.
2. Hub policy accepts overlay-to-overlay, forwards to Spoke2, IKE sender emits shortcut-offer to Spoke1 with 198.51.100.22.
3. Spoke1 receiver starts child IKE. Child SA up. Kernel path to 10.10.100.2 now via the shortcut interface / tunnel-id.
4. Same BGP prefix. New recursive resolution. Packets skip the hub until the shortcut idles out (if idle-timeout is set) and the process repeats.

Traps + proof

Proof · child tunnel in the list, not a green parent

diagnose vpn tunnel list
get router info bgp neighbors
get router info routing-table bgp
# expect: B 10.22.0.0/24 via 10.10.100.2

# after spoke-to-spoke traffic
diagnose vpn tunnel list | grep -A2 spoke1
# child remote = 198.51.100.22

diagnose debug reset
diagnose debug application ike -1
diagnose debug enable
# generate traffic; look for shortcut-offer / SHORTCUT-QUERY
diagnose debug disable

Sources

• FortiOS admin guide — ADVPN with BGP as the routing protocol (hub net-device disable, add-route disable, auto-discovery-sender; spoke net-device enable, auto-discovery-receiver; iBGP neighbor-group / RR)
• FortiOS admin guide — ADVPN and shortcut paths (GUI does not support auto-discovery flags or IBGP neighbor-group)
• FortiOS SD-WAN architecture — ADVPN support with BGP RR (preserve original next-hop; recursive resolution via shortcut)
• FortiOS 7.0 handbook / older ADVPN example — IKE shortcut-offer / SHORTCUT-QUERY; dynamic routing required; IKE does not handle routing
• Fortinet Community — Technical Tip: disable shortcut creation (sender/receiver disable; net-device note)
• Fortinet Community — auto-discovery-crossover (7.2.5+, multi-overlay; out of this lab’s single underlay)
• FortiOS 7.6 — Dynamic BGP / ADVPN 2.0 is a different neighbor-group (RR off, shortcut-triggered spoke-spoke BGP). Do not mix with this RR lab.

Related: IPsec site-to-site · SD-WAN SLA · SD-WAN SLA rules · FortiGate interview