BGP/EBGP from ISP to Fortigate HA A/P

[EM_Fortiuser]

I have been discussing if a Fortigate HA in A/P can work with BGP/EBGP from a single ISP.  So I wanted to see what exactly is possible.  The ISP was going to be providing the routing on their side with my firewalls accepting the connection.  I have put a logically diagram of what I am looking to build.

 

[Toshi_Esumi]

With a-p HA, those two FGTs in a cluster would become just one peer for those neighbors, instead of each unit acts as individual/separate peers. Because you can't configure differently for BGP. BGP config would be the same, or one configuration is shared/synced between them. Not only BGP but also almost all other parts of config.

Toshi

[EM_Fortiuser]

@Toshi_Esumi Thanks.  We were discussing OSPF behind the broder firewalls with 2 areas.  One with the Border and then the Internal firewalls in the a-p pair.

[Pittstate]

Is your ISP providing a single connection? Since it's a logical diagram it's hard to tell if there might be a dual-homed situation. Are these FGs geographically diverse or in the same data center?

[Toshi_Esumi]

I felt the same. The OP probably would post a new diagram if the change mentioned above doesn't work. The design and the intention of it are not clear.

Toshi

[EM_Fortiuser]

@Toshi_Esumi @Pittstate The firewalls will be geographically same city but in different locations with a single drop to each location.  The ISP hasnt been real clear what the backend would look like other than a single handoff at each location

[Pittstate · Accepted solution]

This sounds very similar to what I have just implemented, and is very doable. We went from a standalone to HA implementation so wasn't exactly sure what to expect as far as cluster behavior with the A-P. As Toshi said, the two FGs will be sync'd so they will have the exact same configuration. For instance, port 1 on the Active, will fail over with the exact same configuration on the Passive. Also, the interfaces on the Passive will show as link UP on any connected equipment, but it will not participate in any traffic related activity until it becomes the Active FG in a failover situation. So it is not participating in BGP sessions until it becomes the Active partner. When it becomes the Active it will make all connected interfaces fully active, bring L3 routing protocols up and start advertising routes on it's outside/ISP connected interface.

Like you, we are also single connected to our ISP at each location and each location has it's own /30 interface to the ISP's network. In our HA setup, FG1 (active) port 1, is connected to ISP router 1, and FG2 (passive) port 2 is connected to ISP router 2. This seemed to be the simplest way to solve the ISP connectivity problem without more fiber between sites, or implementing a router redundancy protocol. When things run normally, traffic routes out through FG1/ISP router 1. When things failover, traffic switches to FG2/ISP router 2. On failover, it does take a little bit to get the passive fully up on L3. In my lab it seemed like it took about 10-15s or so for the passive FG to come up and start advertising BGP routes, then an additional 90s or so for BGP timers to timeout and routes to appear where they should. We ended up targeting a 60s failover (from failure of Active to Passive up, full BGP routing advertisement, and traffic being routed correctly). Using BFD and tweaking BGP options/timeout values, and maybe some other FG magic, you can definitely bring that time down. I'm not a WAN guy, I'm sure there are better/quicker ways. This config and tolerances work for us.

[EM_Fortiuser]

This sounds like something we would have to do.  I am going to mark this as a solution.  Thanks for the help.

[Pittstate]

One last thing that was super helpful with policy configuration is enabling the "Multiple Interface Policies" in System>Feature Visibility. In our case, with two possible ports for outbound traffic to traverse, I just used the multiple interface option to select those ISP facing ports in the outbound policies. A single policy entry is now valid for both potential ISP facing ports no matter which one is currently active.