Fortigate and BGP

Last week I attended an event at Fortinet’s offices in London which are on the 26th floor of a building in the City. With a view like this you’d be forgiven for spending a lot of time looking out of the window

Today, I’d like to tinker with BGP on Fortigates. (I have to declare an interest I got a couple of pens, a nice writing pad and a wirless charger at said event – although I had determined to do this post before getting the bag of swag)

The lab is a pair of Fortis in a single multi-homed set-up which basically means we’re connected to two ISPs with a default route to the Internet; we prefer one route out but can fail over to the other.

I started this lab a while ago and realised I’d forgotten the sources I’d referenced but I (re)encountered this link…

https://yurisk.info/assets/Fortigate-BGP-cookbook-of-example-configuration-and-debug-commands.pdf

…and noticed the ASNs and addressing were the same as I’d used so assume this was my starting point though ultimately I think these derive from a Forti Cookbook! Nonetheless, this looks a much more comprehensive treatment than mine so you may be better reading the link above.

Well, if you’re still with me, I’m using 7.0.5 FortiOS images. I tried 7.2.1 but it limits the number of interfaces you can use and insists on a cloud connection. (The cloud connectivity thing is hugely annoying. I recently upgraded a Fortimanager which demanded I sign into the cloud mid-upgrade. Did I have the client’s details? No. Why remove the ‘later’ button option? Rant over)

So to the topology which I should explain. The ISPs would probably be running routers rather than Fortigate firewalls themselves but I was a little lazy in only wanting to configure one type of device and am mainly interested interested in the customer Fortigates FG3 and FG4 which are in a HA pair. (The truncated connections are just management)

We have the HA pair of FG3 and FG4 and the primary in the HA pair, FG3, forms BGP peerings with ISP1 on FG1 and ISP2 on FG2.

What you see on the Forti’s BGP GUI settings varies from version to version but in 7.0.5 you do get most of the config (which I will paste in full at the bottom anyway).

So on FG3, on the GUI in Network/BGP editing the peer connecton to FG1 defined by its ip address, 12.12.12.12, we see the following:

The remote BGP ASN is defined, two prefix lists controlling which prefixes we allow in and out and the setting soft reconfiguration and route refresh which allow a soft reset of the peer and give us more functionality in displaying advertised and received routes. (Generally a good idea to set unless there are lots and lots of peers as there’s a memory hit)

The other peer, FG2, is defined thusly:

Similar in most respects save for a route map being defined which we will touch on later.

FG1 and FG2 have the following configuration

All BGP configs are redistributing static and connected routes.

The ‘internet’ in the lab is represented by a loopback on R1 addressed with that familiar ip address: 8.8.8.8

On FG1 (and FG2) we have the following default route defined.

Although it’s a blackhole route – it’s presence means we can advertise it to FG3 / FG4 and when the traffic from these devices reaches FG1 (or FG2) using this route it can pick up more specific routes. On FG1 and FG2, I actually used BGP to learn 8..8.8.0/24 from R1 so could have shared this directly with FG3. However, if FG1/FG2 were ISP routers they might have thousands of routes and in reality the customer would much rather learn one default route than clogging their device with thousands of the ISP’s routes.

Prefix Lists

OK so – on FG3 I only want to accept the default route from the BGP and the applied prefix list achieves this. This is how it’s defined:

config router prefix-list
edit “accept-default”
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next

The ‘ge’ and ‘le’ we’ll get into later but the fact they’re unset means we only accept that prefix exactly – as in no subnets it contains (which is a bit of nonsense with 0.0.0.0 but for instance if it were 192.168.100.0 255.255.255.0 – we would not accept 192.168.100.0 255.255.255.224)

So what about the other way? With advertised routes out of FG3 we have the following prefix list controlling what we allow out:

config router prefix-list
edit “advertise-own-routes”
config rule
edit 3
set prefix 10.16.0.0 255.255.0.0
unset ge
set le 32
next

And the ‘set le 32’ means all bits in the subnet mask should be considered and thus all subnets of 10.16.0.0/16 will be advertised. As I have these loopbacks defined on FG3,

These should all be distributed into BGP and picked up by FG1 (and FG2) which they are:

A good explanation of prefix-lists can be found here:

https://packetlife.net/blog/2010/feb/1/understanding-ip-prefix-lists/

Another thing we want to do is favour the path to ISP1 as we may well want to do in a real-world environment. In BGP, one way of doing this is to increase the path length through ISP2 and this is generally done by pre-pending our own ASN bo the BGP path so it will be longer. This is achieved on FG3/4 using those route map on our neighbor defintiion to FG2:

These are defined on the CLI as follows. This is a a mechanism of increasing the BGP path length for routes advertised from FG2:

config router route-map
edit “prepend-out”
config rule
edit 1
set set-aspath “1680 1680”
next
end

Thus checking the BGP paths advertised to FG2 (peer 13.13.13.6)

We see the pre-pending with the extra 1680 ASN hops making the routes have a longer path than that to FG1 (peer 12.12.12.12) show below:

And after appliying a route map which is doing similar pre-pending on FG2 (but pre-pending using its own ASN of 222) we see the received routes favour FG1 too:

Routes recieved from FG1

Routes received from FG2

You may have noticed, as I did, that we’re receving 8.8.8.0/24 when our prefix list should be keeping this out… I checked on the BGP routes on the GUI and there was no sign of it…

For some reason, I couldn’t / can’t find reference to this particular command in Forit docs but I surmised the CLI command above is before filtering and the one below which just uses ‘routes’ is after filtering…

OK, so can we ping from PC1? We can.

Are we going through FG1? We are, though admittedly I could have posted output this from the other firewall.

But.. and there’s a ‘but’. If I shut down FG1 it takes 2 minutes 50 seconds for the traffic to be routed through FG2. Clearly, not good enough. So in my next post I’ll see what can be done about that. In the meantime, here are the configs from this exercise: