Technical Tip: How to avoid Bidirectional Forwarding Detection (BFD) invalidating static routes when configured on a FortiGate VPN tunnel interface

FortiGate supports configuring BFD neighborships across IPsec VPN tunnels, with the tunnel interface's IP address being used as the BFD source. Notably, one major requirements is to configure the Remote IP/Netmask on the FortiGate-side tunnel interface so that it uses a /32 subnet mask.

The BFD neighborship will still come online when using a subnet mask with another value, but it will automatically invalidate the static route (i.e. put it into an inactive state) once it is attached to the route. As a result, the route will not be installed into the routing table. Consider the following example topology:

In the above topology, FW_A has a VPN tunnel to_FWB with a tunnel interface IP address of 192.168.100.1. FW_B has a tunnel interface IP address of 192.168.100.2, as well as a LAN subnet of 192.168.40.0/24 that FW_A can reach via a static route across the tunnel.

On FW_A, the to_FWB tunnel interface has BFD enabled, and the remote-ip setting has a /24 subnet mask currently configured. FW_A also has a static route to 192.168.40.0/24 with BFD enabled:

FW_A # show system interface to_FWB
config system interface
    edit "to_FWB"
        set vdom "root"
        set ip 192.168.100.1 255.255.255.255
        set allowaccess ping
        set bfd enable
        set type tunnel
        set remote-ip 192.168.100.2 255.255.255.0
        set snmp-index 15
        set interface "port3"
    next
end

FW_A # show router static 2
config router static
    edit 2
        set dst 192.168.40.0 255.255.255.0
        set device "to_FWB"
        set bfd enable
    next
end

When checking get router info bfd neighbor, FW_B is reporting as up/active, but the static route associated with this BFD neighbor shows as inactive when checked in the routing table:

FW_A # get router info bfd neighbor

OurAddress       NeighAddress    State    Interface    LDesc/RDesc
192.168.100.1    192.168.100.2   UP       to_FWB       1/1

FW_A # get router info routing-table database | grep 192.168.40.0
S 192.168.40.0/24 [10/0] via to_FWB tunnel 10.0.1.2 inactive, [1/0]
B *> 192.168.40.0/24 [20/0] via 10.0.1.2 (recursive is directly connected, port3), 4d23h50m, [1/0]

To resolve the issue, the tunnel interface remote IP subnet mask must be changed to /32:

FW_A # config system interface

FW_A (interface) # edit to_FWB

FW_A (to_FWB) # set remote-ip 192.168.100.2/32

FW_A (to_FWB) # show

config system interface
    edit "to_FWB"
        set vdom "root"
        set ip 192.168.100.1 255.255.255.255
        set allowaccess ping
        set bfd enable
        set type tunnel
        set remote-ip 192.168.100.2 255.255.255.255
        set snmp-index 15
        set interface "port3"
    next
end

Rechecking the routing table shows that the static route is now valid and successfully installed to the routing table:

FW_A # get router info routing-table database | grep 192.168.40.0
S *> 192.168.40.0/24 [10/0] via to_FWB tunnel 10.0.1.2, [1/0]
B 192.168.40.0/24 [20/0] via 10.0.1.2 (recursive is directly connected, port3), 5d00h00m, [1/0]

Related documents:

• Technical Tip: Configuring Bidirectional Forwarding Detection (BFD) for static routes
• BFD