Fortinet Tutorial: Public Cloud Four Site ADVPN Mesh (Using the Fabric Overlay Orchestrator)

As part of a series on deploying ADVPN across three Major Public Cloud Providers (GCP, Azure and AWS) this is the fourth video we hook everything together using the new Fabric Overlay Orchestrator found in FortiOS 7.2.4+ and 7.4.x. If you watch previous videos this is an A-Z guide on how to set up absolutely everything and at the end of the video all sites have a security fabric created between them with policy synchronization and can speak to each other. For smaller organisations, this can be a more cost-effective way of creating a mesh without needing FortiManager.
PT1: • SDWAN/ADVPN Series: Vi...
PT2: • SDWAN/ADVPN Series: Vi...
PT3: • SDWAN/ADVPN Series: Vi...
// Timestamps //
0:00 - Video Intro / Recap
0:37 - Cost so far
1:42 - Quick overview of the design
2:20 - Creating the security fabric
6:08 - Creating the VPN Fabric
10:14 - Required configuration amendments to spokes
11:02 - Quick overview of the design (Including IP Allocations)
12:13 - Ping Tests between all three sites
12:47 - ADVPN Shortcuts
14:33 - Explaining via topology diagram
15:04 - Logging into spoke devices using SSO
15:36 - Video wrap-up & what's next!
// Chris SOCIAL //
/ chris-eddisford-5b676462
// Keywords //
Fortinet
Virtual FortiGate
Security Fabric Configuration
Fortigate Firewall Configuration
Amazon Web Services (AWS)
SDWAN
ADVPN
Fortinet how to
Fortinet guide
Fortinet network security
Cybersecurity
// HashTags //
#cybersecurity
#networking
#fortinet

[@FortiBytes]

I'm aware that some of the content loops between 5:40 and 6:30 just ignore it I promise I haven't travelled back in-time 🤣

[@anonyoutube4619]

Great video again! I tried to understand what the loopback interfaces are for. But I just can't wrap my head around it. I know it's like a virtual interface. But why would you need it? When you can create sub interfaces under a real interface. Can you explain this to me like i'm 8 years old.

[@FortiBytes]

Morning, loopback interfaces are used for lots of things. They are a virtual interface that does not have any dependency on a physical interface, so unless you disable it manually it should always remain up, because if it’s nature it’s often used to form bgp relationships so your not dependent on a physical link. In the video its use-case is both for bgp and also testing. It allowed me to create a virtual test bed to prove connectivity between sites by using the configured loopback without having to get a host machine on the LAN side. Think of it this way if I used a sub interface under let’s say port 2 and it went down then I wouldn’t be able to use that interface anymore this is one of the reasons you use them. When it comes to bgp you use them again to untangle away from a physical interface opening the opportunity to create a virtual interface that’s potentiality routable and can be peered against via several different paths. Just to be clear also it’s not just bgp many other routing protocols use this method.

[@pko492001]

Hello, I would like to ask three questions
1. Is there an architecture diagram of this video, including all IP addresses?
2. Is there any pre-configuration that needs to be completed at the beginning of this video, such as IPSEC VPN SDWAN, and then set up after the VPN is established?
3. Regarding FAZ IP, I don’t know much about it here. Are the FAZ IPs of HUB and SPOKE the same? If so, do all the points need to be connected to the same FAZ in the front end?

[@FortiBytes]

Hi thanks for reaching out answers below
1. I’m afraid there isn’t an architecture diagram, I’ll look at doing this for future videos.
2. This is part of a video series please watch the videos prior to this one.
3. All FortiGate devices should point to the same FAZ unit. This will then be distributed via the security fabric.

[@piotrczopik2905]

Hi, great video. Can we specify an address of a local gateway ? In your video you had to manually change an address of the remote gateway for both spokes (since there was a private IP of your Azure FG). I can see that after reboot it will change again (I assume that this address is being pushed by the orchestrator). How can we make that change permanent? Can we somehow specify that address in Orchestrator config (f.e. to use secondary IP of a given interface)? Best regards.

[@FortiBytes]

Hi great question. The correct method of deployment specifically for the hub is to ensure that its public ip address is reserved. Once I did my manual change it wasn’t overrided on reboot. Alternately something like dyndns could be used however you don’t want the public ip specifically for the hubs changing being honest for spokes it does not matter as they are the ones that do the dialling. If the hubs where standard on-prem deployments then the orchestrator would have got the configuration right and there wouldn’t be a requirement to make a change as I suspect it just takes the IP address from internal1 for the built in automation.