Hub-Spoke With Redundant Tunnels

[JGaiser]

I am working on designing a solution that requires a 'spoke' network to communicate with other 'spoke' networks without the other spoke networks being able to communicate with each other.

There is a remote operations center, 2 datacenters (these will be hubs), and then 60+ remote networks.  The ROC needs to communicate with every remote site.  The remote sites all need to communicate with the datacenters and possibly an additional remote site (ie spoke) with strict source/destination and services rules.  These will also need to communicate via primary and secondary ISP connections.

I am looking at the ADVPN/BGP solution from Fortigate documentation, but it appears there might be a couple ways to do this and am not sure what the best method is.  What would be the case for OSPF vs BGP?

[DPadula]

Hi JGaiser,

Fortinet recommend iBGP instead of OSPF. Here are some links that might be helpful. I believe the first one is the most appropriate for your case. 

• Multiple datacenters (primary/secondary gateways) 
• Basic SD-WAN/ADVPN design

[JGaiser]

This isn't quite getting me to where I need.

I have a lab network with 4 firewalls.  1 is a hub, 3 are spokes.

I have used the Wizard to setup hub and spoke setup between the 4 devices per this documentation: IPsec VPN wizard hub-and-spoke ADVPN support | FortiGate / FortiOS 6.2.0 | Fortinet Document Library

All of the tunnels are showing as up, however these problems remain:

-No traffic is flowing between the spokes and the hub at all.  I would only like 2 of the spokes to be able to communicate with each other and the hub, while the 3rd spoke should only communicate with the hub.  What additional settings that are not in the documentation need to be configured to allow this to happen?

-I am not able to find a way to configure SD-WAN as the outgoing interface on the spokes.  The hub has 1 ISP connection.  All of the spokes have 2.  The test needs to conclude that the hub-and-spoke connections are able to use SD-WAN for high-availability.

[JGaiser]

It looks like the lab hub is not advertising routes to the lab spokes.  After following the wizard setup as mentioned above, what could be causing the routes not to be advertised?

[brunoleao]

Hey @JGaiser with you are using HUB/Spoke configuration setup from VPN, You need to use same local-as and remote for hub and spokes. After that you need to put the networks or use the buttons for connected/static in BGP gui configuration and etc.

For best practicies i recommend you to use IPs on the VPN interface, i.e.

HUB link1 = 10.10.1.1 gateway 10.10.1.254/24 (Use the last ip from network)
HUB link2 10.10.2.1 gateway 10.10.2.254/24 (same as HUB1 but using another network)

Remote1 link1 10.10.1.2 gateway 10.10.1.1/24
Remote1 link2 10.10.2.2 gateway 10.10.2.1/24

Still speaking of good practice, the ideal for several routers is to create a neighbor group for each VPN, i.e.
10.10.1.0/24 neighborgroup1
10.10.2.0/24 neighborgroup2

This way you will be able to connect multiple spokes without having to configure them one by one on the HUB.

One more thing: you can put this interfaces on SD-WAN if you want to. Make sure this interfaces are off from policies and another references.

[Toshi_Esumi]

Based on your original description of requirements, I don't think that's a good idea implementing access control by routing (L3 level). They (the requirements) would easily change and you might need to go back and redesign it from scratch again.

What I would do in your situation is just make all locations, remotes, HUBs, ROC routable/reachable each others at L3 using whatever the routing method you choose, such as ADVPN(iBGP), eBGP, OSPF or even static routing, which doesn't matter, then control the accessability by policies at the source and/or desitnation end(s) of FGT. 
Just make sure IPsec VPN's phase2 selectors are all 0/0<->0/0. Otherwise, every time you need to add accessibility from one location to the other, you have to adjust/add phase2 selectors matching the new src/dst combination on the path.

Toshi