Technical Tip: Understanding unexpected Next-Hop behavior in FortiGate ADVPN with BGP

[shahrukh_khan]

Description	This article describes that in FortiGate Auto-Discovery VPN (ADVPN) setups using BGP, an 'unexpected' next-hop behavior can be observed where the next-hop IP in received routes does not match the advertising neighbor (typically the hub). Instead, it remains the IP of the originating spoke.
Scope	FortiGate.
Solution	In a hub-and-spoke ADVPN topology with BGP (often iBGP in the same AS), hubs commonly act as route reflectors (RRs) to propagate routes between spokes without requiring a full-mesh peering. By default, when a hub reflects a route from one spoke to another, it preserves the original next-hop IP (the originating spoke's tunnel IP) rather than rewriting it to its own IP. This is intentional in ADVPN to enable spoke-to-spoke shortcuts: Traffic initially flows through the hub, but upon detection, a direct IPsec tunnel forms between spokes, bypassing the hub. This preservation can appear 'unexpected' if it anticipates hub-centric routing, where the hub's IP should always be the next-hop. In iBGP, next-hops are not automatically changed (unlike eBGP), and standard next-hop-self does not apply to reflected routes, only to local or eBGP-learned ones. As a result, commands like get router info bgp neighbors received-routes may show next-hops as spoke IPs, even though the routes are advertised by the hub. In this diagram: The hub reflects routes between Spoke1 and Spoke2, preserving the next-hop (e.g., Spoke1's route to Spoke2 uses 10.1.1.3 as next-hop). Once traffic flows, ADVPN triggers a direct shortcut tunnel between spokes. Configuration Steps Leading to the Issue. On the hub: Step 1: Set Up IPsec Tunnels for ADVPN. config vpn ipsec phase1-interface     edit "ADVPN-Hub"         set interface "port1" <----- WAN interface.         set peertype any         set proposal aes256-sha256         set psksecret <secret>         set auto-discovery-sender enable # <----- Enables shortcut triggering.     next end config vpn ipsec phase2-interface     edit "ADVPN-Hub"         set phase1name "ADVPN-Hub"         set proposal aes256-sha256     next end On spokes (e.g., Spoke1 and Spoke2), use similar configs with auto-discovery-receiver enabled. Step 2: Configure BGP on the Hub as a Route Reflector. config router bgp     set as 65001         config neighbor             edit "10.1.1.2" # Spoke1 tunnel IP                 set remote-as 65001                 set next-hop-self enable <----- Affects local/eBGP routes only.                 set route-reflector-client enable <----- Enables reflection.             next                 edit "10.1.1.3" # Spoke2                 set remote-as 65001                 set next-hop-self enable                 set route-reflector-client enable             next         end         config network             edit 1                 set prefix 192.168.1.0 255.255.255.0 <----- Hub's local network.             next         end end Step 3: Configure BGP on Spokes config router bgp     set as 65001         config neighbor             edit "10.1.1.1" <----- Hub tunnel IP.                 set remote-as 65001             next         end         config network             edit 1                 set prefix 172.16.1.0 255.255.255.0 <----- Spoke local network.             next         end end Verification: This default config leads to the behavior, as 'next-hop-self' does not modify reflected iBGP routes. Use 'get router info bgp network' on spokes to observe preserved next-hops (e.g., Spoke1 sees Spoke2's route with Spoke2's IP as next-hop, advertised via hub). To modify this default behavior, refer to the following article: Technical Tip: Explanation of 'set next-hop-self-rr enable'