Description
This article describes that with BGP configured on a VPN tunnel, if loopback is used as an update source in BGP configuration, the routes received from the BGP peer are not installed into the routing table and give an error in debugs as 'denied due to non-connected next-hop'.
Scope
FortiGate.
Solution
Explanation.
BGP is configured as follows to use the loopback interface as the update source.
config router bgp
set as 65101
set router-id 1.1.1.1
config neighbor
edit "10.20.16.1"
set soft-reconfiguration enable
set remote-as 65102
set update-source "Loopback_bgp"
next
end
config network
edit 1
set prefix 172.17.8.0 255.255.255.0
next
end
end
Loopback Interface configuration.
config system interface
edit "Loopback_bgp"
set vdom "root"
set ip 10.20.16.2 255.255.255.255
set allowaccess ping
set type loopback
set role lan
set snmp-index 15
next
end
Tunnel Interface configuration.
config system interface
edit "VPN-BGP"
set vdom "root"
set ip 10.20.16.4 255.255.255.255
set allowaccess ping https http
set type tunnel
set remote-ip 10.20.16.1 255.255.255.255
set role lan
set snmp-index 4
set interface "wan1"
next
end
Running debugs.
diagnose ip router bgp level info
diagnose ip router bgp all enable
diagnose debug enable
Disabling BGP debugs:
diagnose ip router bgp level none
diagnose ip router bgp all disable
diagnose debug disable
Note:
Starting from v7.2.0 GA, it is now possible to filter 'BGP debug' to a single BGP neighbor with the following command line added to the above BGP debug:
diagnose ip router bgp set-filter neighbor <neighbor address>
In the debugs, it shows that the route is denied and hence is not being installed in the routing table.
BGP: 10.20.16.1-Outgoing [RIB] Update: Prefix 172.17.8.0/24 path_id 0 denied due to non-connected next-hop
Solution.
Even though the IPsec tunnel provides reachability between the loopback addresses, FortiGate’s BGP process still performs the strict eBGP next-hop check, it
treats the peer as non-directly connected. By default, eBGP enforces a "directly connected" check for the next-hop. This behavior is standards-based (RFC 4271) but catches many administrators off guard in VPN scenarios.
Without explicit multihop permission, any route whose BGP next-hop is not on a directly connected subnet of the peering interface is discarded.
To fix this issue, the following needs to be added to the BGP config.
config router bgp
config neighbor
edit "10.20.16.1"
set soft-reconfiguration enable
set remote-as 65102
set update-source "Loopback_bgp"
set ebgp-enforce-multihop enable
next
end
Since the update source is configured as Loopback, FortiGate considers the interface to be not directly connected; therefore, it is necessary to introduce the command 'set ebgp-enforce-multihop enable'.
