Troubleshooting BGP Routing on Fortigate

Introduction

Setting up VPN connections between distant locations comes with its own set of challenges. Apart from distance, limitations of available internet service providers, latency, and jitter can also play a significant role. Therefore, it is essential to prepare as much redundancy as possible, both in terms of devices and connections.

As the number of devices and connections increases, more attention is required to ensure the configurations remain aligned with the standards in use. One way to guarantee this is by utilizing dynamic routing, such as the BGP protocol.

This article aims to assist in troubleshooting BGP routing configurations on Fortigate devices.

Prerequisites

The following items are required:

IP addresses of the relevant Fortigate devices, along with their SSH or Web UI ports if needed;
Credentials for accessing each device.

Procedure

The first step is to confirm whether the BGP route is active.

To check routing using the UI, navigate to Dashboard → Routing Monitor. For easier access, you can directly input the destination IP in the search bar, which will display a list of matching active routes.

Generally, the route selection process considers two factors:

Routes with more specific subnets;
Routes with the lowest Administrative Distance.

Based on these criteria, the image above shows that the Fortigate Hub uses the BGP route to the 10.10.2.0/24 network, as it is more specific than 10.10.0.0/16, even though its administrative distance is higher. Since there are four identical routes, all four are considered active.

Confirm Existing Routes

Ensure that the Spoke Fortigate has the appropriate return routes in the Routing Monitor menu.

Another way to directly check active routes is through the Fortigate CLI with the following command:

get router info routing-table details <REMOTE_NETWORK>

Also confirm that the routes from the Spoke Fortigate to the Hub subnet exist and use the correct paths. If the expected routes are missing, there are several checks to perform:

Confirm Neighbor Connectivity

First, verify the connectivity between neighbors to ensure they can communicate with each other. Note that neighbors must be connected via point-to-point IP addresses.

To view connected neighbors, use the following CLI command:

get router info bgp summary

Ensure the interface IPs connecting the Hub and Spoke Fortigate are visible to each other (Hub IP visible on Spoke, and vice versa).

If they do not appear, recheck the BGP configuration on each device. View the BGP configuration using the following CLI command:

show router bgp

Key aspects to verify:

Ensure the neighbor IP addresses and remote-as values are correct;
Confirm other configurations meet the requirements.

Check if traffic is following the correct path by using logs. Perform a ping from a local device or the Spoke and Hub Fortigate towards each other, then check the traffic logs on both Fortigates. Ensure the destination interface is correct, even if the status shows as blocked or denied.

To view logs, navigate to Log & Reports → Forward Traffic on each firewall.

If the destination interface is correct but traffic is denied, review the policy configuration under Policy & Objects → Firewall Policy and make necessary adjustments.

If all configurations are correct but the route remains incorrect, as a last resort, clear active routes or restart the route advertisement process using the following commands:

execute router clear bgp as <AS_NUMBER>
execute router restart

Conclusion

In summary, the following checks are essential:

IPSec connections are active;
Fortigate devices can see each other’s neighbors;
The active BGP configuration meets the required setup.

ndkprd's notes