Task 1: Azure Virtual WAN

Azure Virtual WAN

Azure Virtual WAN is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. Some of the main features include:

• Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE).
• Site-to-site VPN connectivity.
• Remote user VPN connectivity (point-to-site).
• Private connectivity (ExpressRoute).
• Intra-cloud connectivity (transitive connectivity for virtual networks).
• VPN ExpressRoute inter-connectivity.
• Routing, Azure Firewall, and encryption for private connectivity.

You don’t have to have all of these use cases to start using Virtual WAN. You can get started with just one use case, and then adjust your network as it evolves.

The Virtual WAN architecture is a hub and spoke architecture with scale and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2 clients), ExpressRoute circuits, and virtual networks. It enables a global transit network architecture, where the cloud hosted network ‘hub’ enables transitive connectivity between endpoints that might be distributed across different types of ‘spokes’.

Virtual WAN offers the following advantages:

• Integrated connectivity solutions in hub and spoke: Automate site-to-site configuration and connectivity between on-premises sites and an Azure hub.
• Automated spoke setup and configuration: Connect your virtual networks and workloads to the Azure hub seamlessly.
• Intuitive troubleshooting: You can see the end-to-end flow within Azure, and then use this information to take required actions.

In this course, the vWAN has already been deployed for the student.

Continue to Chapter 2 - Task 2: Azure vWAN resources

Task 2: Azure vWAN Resources

Azure vWAN Resources

To configure an end-to-end virtual WAN, you create the following resources:

• Virtual WAN: The virtual WAN resource represents a virtual overlay of your Azure network and is a collection of multiple resources. It contains links to all your virtual hubs that you would like to have within the virtual WAN. Virtual WANs are isolated from each other and can’t contain a common hub. Virtual hubs in different virtual WANs don’t communicate with each other.

• Hub: A virtual hub is a Microsoft-managed virtual network. The hub contains various service endpoints to enable connectivity. From your on-premises network (vpnsite), you can connect to a VPN gateway inside the virtual hub, connect ExpressRoute circuits to a virtual hub, or even connect mobile users to a point-to-site gateway in the virtual hub. The hub is the core of your network in a region. Multiple virtual hubs can be created in the same region.

A hub gateway isn’t the same as a virtual network gateway that you use for ExpressRoute and VPN Gateway. For example, when using Virtual WAN, you don’t create a site-to-site connection from your on-premises site directly to your VNet. Instead, you create a site-to-site connection to the hub. The traffic always goes through the hub gateway. This means that your VNets don’t need their own virtual network gateway. Virtual WAN lets your VNets take advantage of scaling easily through the virtual hub and the virtual hub gateway.

• Hub virtual network connection: The hub virtual network connection resource is used to connect the hub seamlessly to your virtual network. One virtual network can be connected to only one virtual hub.

• Hub-to-hub connection: Hubs are all connected to each other in a virtual WAN. This implies that a branch, user, or VNet connected to a local hub can communicate with another branch or VNet using the full mesh architecture of the connected hubs. You can also connect VNets within a hub transiting through the virtual hub, as well as VNets across hub, using the hub-to-hub connected framework.

• Hub route table: You can create a virtual hub route and apply the route to the virtual hub route table. You can apply multiple routes to the virtual hub route table.

In this workshop the student will use these resources to help create network traffic and route to the FortiGate NVAs.

Continue to Chapter 2 - Task 3: FortiGate NVA Support for vWAN

Task 3: FortiGate NVA Support for vWAN

Microsoft Azure supports virtual WAN (vWAN), and partners with third-party solution providers, such as Fortinet, to deploy network virtual appliances (NVAs) to a vWAN hub.

FortiGate NVA

By combining stateful inspection with a comprehensive suite of powerful security features, FortiGate next generation firewall technology delivers complete content and network protection. This solution is available for deployment in the Microsoft Azure vWAN managed service.

In addition to advanced features such as an extreme threat database, vulnerability management, and flow-based inspection, features including application control, firewall, antivirus, IPS, web filter, and VPN work in concert to identify and mitigate the latest complex security threats.

FortiGate NVAs are deployed in an active/active high availability (HA) configuration with FortiGate-native FGSP synchronization between the NVAs.

Order Types

You can choose one of the following scale unit values when deploying FortiGate NVAs. Higher scale units are available for increased bandwidth requirements. A specific FortiGate virtual machine license is recommended for each scale unit value.

NGFW Deployment

SD-WAN NGFW Deployment

Deployment Requirements

Deployment requires the following:

• Two full FortiGate licenses if using bring your own license (BYOL) or FortiFlex. Alternatively, you can select pay as you go (PAYG) during deployment.
• One fully licensed FortiManager instance (PAYG or BYOL)

Continue to Chapter 3 - Getting Started

Task 1: Course Enrollment

Public Cloud - 202 - Secured Azure FortiGate Integrated vWAN Hub

Enroll in this workshop

Continue to Chapter 3 - Task 2: User Credentials

Task 2: User Credentials

These are the credentials that are used throughout the session. It is recommended you open this page in a new tab for quick reference.

Azure Portal Login

• U: vwanXX@fortinetcloud.onmicrosoft.com (User Specific)
• P: FortinetXperts2024!

Linux host username and passwords

• U: fortixperts
• P: Fortixperts2024!

FortiGates

• U: fortixperts
• P: Fortixperts2024!

Continue to Chapter 3 - Task 3: Azure Portal - Lab Access

Task 3: Azure Portal - Lab Access

Azure Portal & Resources

The work for this session takes place in Azure and on FortiGates deployed into the Azure Virtual WAN Hub. The first step is to logon to the Azure Portal.

Login to Azure Portal and Review Existing Resources

1. Navigate to Azure Portal

2. Login with provided credentials

   

3. Click “Yes” to “Stay singed in?”

   

4. Click “Cancel” on the “Welcome to Microsoft Azure” page (if displayed)

   

5. Click “Resource groups”

   

6. Click your Resource Group named vwanXX-training. XX is the number of your allocated environment.

   Tip

   In an Azure environment there can be many Resource Groups, use the search field to find your Resource Group.

   

7. View the already deployed resources already deployed

   Info

   The assigned Resource Group has already been deployed along with the key resources for this session.

   • Review and make sure all the following resources are deployed in your resource group.

     • Virtual WAN (VWAN)

       • vwanXX-training_VWAN
       • Virtual Hub (vhub) - This resource is visible in the vwanXX-training_VWAN page. Navigate to Connectivity then Hubs on the left side of the page.
         • vwanXX-eastus-vHub1_VHUB

     • Virtual Networks (VNETs)

       • Spoke1-vHub1_VNET
       • Spoke2-vHub1_VNET

     • Virtual Machines (VMs) with disk and network interface

       • Linux-Spoke1-VM
       • Linux-Spoke2-VM

Continue to Chapter 4 - Securing the Azure vWAN

Task 1: FortiGate NVA Deployment

In task one, you will deploy a FortiGate NVA into the vWAN hub that you have been assigned.

1. Click on VWAN vwanXX-training_VWAN in your Resource Group. XX is your assigned number.

   

2. Click on “Hubs” in the “Connectivity” section of the left-hand navigation. A hub in EastUS has already been deployed.

   

3. Click on your assigned hub

4. View information about Hub

   • Name
   • Location (Region)
   • Private Address Space

5. Confirm the status of the following:

   • Hub status: Succeeded
   • Routing status: Provisioned

   

   Warning

   Only move on to the next step if Hub and Routing status have green checks.

6. Click on “Network Virtual Appliance in the “Third party providers” section of the left-hand navigation.

7. Click the button “Create network virtual appliance”

8. Select fortinet-sdwan-and-ngfw

9. Click “Create” - proceed to leave site to redirect to Marketplace.

   

   Info

   If a warning is displayed about “Leaving” the site, select the Leave page button.

   

10. Click “Create” on the Marketplace listing for “Azure Virtual WAN Secured by FortiGate”

    

11. Click on “Yes, continue” on the Continue creating this plan? screen.

    

12. On the “Create Azure Virtual WAN Secured by FortiGate” window, enter the following values in the Basics tab:

    • Select - Resource Group - vwanXX-training – Be sure to select your assigned Resource Group
    • Select - Region - East US – May already be defaulted to the correct region
    • Enter - FortiGate administrative username - fortixperts
    • Enter - password - Fortixperts2024!
    • Confirm - password - Fortixperts2024!
    • Enter - FortiGate Name Prefix - vwanXX – Enter your assigned lab number for XX.
    • Select - FortiGate License Type - “Pay As you Go (PAYG)”
    • Select - FortiGate Image Version - “7.4.X” – Be sure to select the highest 7.4 version.
    • Select - Azure vWan deployment type - “SDWAN + NGFW (Hybrid)”
    • Enter - Application Name - vwanXX – Enter your assigned lab number for XX.
    • Update - Managed Resource Group - Append “_vwanXX” to the provided name – Enter your assigned lab number for XX.
    • Click - “Next”

    

13. On the FortiGate in Virtual WAN Specific Parameters tab, enter the following values:

    • Select Virtual WAN Hub - select vwanXX-eastus-vHub1_VHUB – Be sure to enter your assigned lab number for XX.
    • Leave all other items as is
    • Click “Next”

    

14. On the PublicIP Verification tab, select “Next”.

    • No screenshot included in the step

15. On the Tags tab, select “Next”.

    • No screenshot included in this step

16. On the Review + create tab, select the following:

    • Scroll down to agree to the terms and conditions
    • Click “Create”

    

    Info

    The FortiGate NVAs take about 15 minutes to deploy. Grab a refreshment and relax! You will see the screen belows when the deployment is in progress and when complete.

    

17. Click on your assigned Resource Group to return to your Resource Group and prepare for the next task.

    

Continue to Chapter 4 - Task 2: Configure FGSP

Task 2: Configure FGSP

After the FortiGate NVA deployments are complete, the next step is to configure FortiGate Session Life Support FGSP on both FortiGates to enable session sync to support the Active-Active architecture.

1. To access the CLI on your FortiGate NVAs, following these steps:

   1. From your assigned Resource Group “vwanxx-training”, navigate to your vWAN “vwanxx-training_VWAN” and then your hub “vwanXX-eastus-vHub1_VHUB”

   2. Click Network Virtual Appliance in the left-hand navigation

   3. Click “Click here” link under “Instances info” in the right-hand “Network Virtual Appliances” pane

   4. Note FortiGate Public IP and Private IP addresses

   5. Open a browser tab to each FortiGate using the Public IP address of each FortiGate

      

2. Configure FGSP

   1. Open a CLI session on each FortiGate

   2. Enter the blocks of CLI commands on each FortiGate.

   3. On FortiGate ending with _0 configure the peerip address with the port2 private IP address of the FortiGate ending with _1.

      Warning

      If the IP address of port2 on FortiGate ending _1 is not 10.1.112.6 replace the peerip below with the port2 private IP address of the FortiGate ending with _1
      Copy these CLI commands to notepad or similar tool to update the peerip address, if required.

      config system standalone-cluster
          config cluster-peer
              edit 1
                  set peerip 10.1.112.6
              next
          end
          set standalone-group-id 1
          set group-member-id 1
      end

   4. Answer “y” to the “Do you want to continue? (y/n)” prompt

      Changing standalone-group-id or group-member-id will potentially affect FGSP traffic.
      Please first make sure the member is isolated from FGSP cluster properly.
      Do you want to continue? (y/n)
      

      config system ha
          set session-pickup enable
          set session-pickup-nat enable
          set session-pickup-connectionless enable
          set override disable
      end

   5. On FortiGate ending with _1 configure the peerip address with the port2 private IP address of the FortiGate ending with _1.

      Warning

      If the IP address of port2 on FortiGate ending _0 is not 10.1.112.5 replace the peerip below with the port2 private IP address of the FortiGate ending with _0
      Copy these CLI commands to notepad or similar tool to update the peerip address, if required.

      Warning

      Notice that the group-member-id is 2 in the CLI commands below

      config system standalone-cluster
          config cluster-peer
              edit 1
                  set peerip 10.1.112.5
              next
          end
          set standalone-group-id 1
          set group-member-id 2
      end

   6. Answer “y” to the “Do you want to continue? (y/n)” prompt

      Changing standalone-group-id or group-member-id will potentially affect FGSP traffic.
      Please first make sure the member is isolated from FGSP cluster properly.
      Do you want to continue? (y/n)
      

      config system ha
          set session-pickup enable
          set session-pickup-nat enable
          set session-pickup-connectionless enable
          set override disable
      end

FGSP is now configured and the FortiGates will share session information.

Continue to Chapter 4 - Task 3: VNET-to-VNET Traffic

Task 3: VNET-to-VNET Traffic

To be part of an Azure Virtual WAN, Azure VNETs need to be peered to the Azure vWAN hub. Prior to VNETs being peered to a vWAN hub, virtual machines in the VNET will route their traffic based on Azure default routing services such as user defined routing (UDR) or routes advertised by an Azure Route Server.

Two spoke VNETs have been deployed in your assigned resource group, each with a Linux virtual machine (VM). The spoke VNETs are just stand-alone VNETs which means the Linux VMs in one spoke cannot communicate with Linux VMs in the other spoke without setting up VNET peering with the hub and configuring routing.

In this task, the student will confirm that each Linux VM cannot communicate between VNETs and the Internet.

1. View the assigned VNET address space, navigate from your assigned resource group to each VNET

   • “Spoke1-vHub1_VNET”

   • “Spoke2-vHub1_VNET”.

     

2. VNET assigned address space can be determined by clicking on a VNET and viewing the “Address space” value on the right side of the “Overview” pane.

   VNET Spoke1-vHub1_VNET is shown below.

3. Repeat the above steps to determine the “Address space” for Spoke2-vHub1_VNET.

4. View the private IP addresses of the spoke VNET Linux VMs, navigate from your assigned resource group to each Linux VM - “Linux-Spoke1_VM” and “Linux-Spoke2_VM”.

   

   Linux-Spoke1_VM	Linux-Spoke2_VM

5. Access the serial console on the Linux-Spoke1_VM.

   • Scroll to the bottom of the left-hand navigation on the Linux-Spoke1_VM resource page
   • Expand the “Help” section (if not already expanded)
   • Click “Serial console”. A serial console session will start in the right-hand pane.

6. Login to Linux-Spoke1_VM:

   • username fortixperts
   • password Fortixperts2024!

7. Ping Linux-Spoke2_VM:

   • ping 192.168.2.4

     

8. Ping Linux-Spoke1_VM from Linux-Spoke2_VM:

   • Repeat previous steps to access the serial console of Linux-Spoke2_VM

9. Ping an Internet resource from both Linux VMs:

   • ping 8.8.8.8

   Both ping tests will fail, these resources are unable to access each other and resources on the Internet.

Continue to Chapter 4 - Task 4: BGP & Routing Intent

Task 4: BGP & Routing Intent

In task four, the student will configure BGP on the FortiGates and enable Routing Intent from the Azure hub portal.

Configure BGP

1. Confirm the private address space of the vWAN hub

   The private address space of the vWAN hub is needed to create a summary route from the private address range to the secondary interfaces of the FortiGate NVAs to establish BGP peering.

   The FortiGates are deployed with BGP peers already configured and ready to go online after the static route is enabled.

   • Navigate to your assigned hub vwanXX-eastus-vHub1_VHUB

   • View hub address space

     

2. View FortiGate BGP peer status

   • Open each FortiGate in a browser tab/window

   • Open FortiGate CLI

   • Run CLI command get router info bgp summary to view BGP Peer status

     

3. Determine FortiGate NVA port2 Gateway

   Static routes are needed on the FortiGates to enable BGP, a component required to setup the static route is the gateway address of the FortiGate’s port2 interface.

   Every subnet in Azure uses the first address in the subnet as the gateway. For example, in the subnet 10.1.1.0/24 Azure uses 10.1.1.1 as the subnet gateway.

   • Click on Network
   • Click on Interfaces
   • View the assigned address of port2 and determine the gateway

   In the screenshot below, the port2 IP address is 10.1.112.5/255.255.255.128 (/25)

   • Network address is 10.1.112.0

   • Gateway address is 10.1.112.1

     

4. Configure Static Routes on each FortiGate

   Two static routes are required on each FortiGate

   • A static route to the virtual hub routers through the gateway of port2

   • A Static route for the internal Azure load balancer probes

   • Click Network

   • Click Static Routes

   • Click Create New

     

5. Create a static route

   • Enter Destination - 10.1.0.0/16

   • Enter Gateway Address - 10.1.112.1

   • Select Interface - port2

   • Click “OK”

     

6. Repeat the process to add a static route for the Azure internal load balancer health probe

   Refer to the overall for the internal load balancer placement. Health probes enable the Azure load balancer to know if a FortiGate is in a state to forward traffic.

   The static route destination below is the default Azure load balancer health probe destination.

   • Enter Destination: 168.63.129.16/32
   • Enter Gateway Address: 10.1.112.1
   • Select Interface: port2
   • Enter Administrative Distance: 5
   • Click “OK”

7. Repeat the commands on the other FortiGate

   When completed the static routes of each FortiGate should look similar to the screenshot below.

   

8. Verify BGP communication between FortiGate NVAs

   After configuring the static routes on both FortiGates BGP peers are reachable.

   • Verify BGP communication between FortiGate NVAs in the CLI.

   • Open FortiGate CLI

   • Run CLI command get router info bgp summary

     

   More information about FortiGate static routes and BGP can be found in Fortinet documents.

Enable Routing Intent

Routing Intent and Routing Policies allow you to configure the Virtual WAN hub to forward Internet-bound and Private (Point-to-site VPN, Site-to-site VPN, ExpressRoute, Virtual Network and Network Virtual Appliance) traffic to an Azure Firewall, Next-Generation Firewall Network Virtual Appliance (NGFW-NVA) or security software-as-a-service (SaaS) solution deployed in the virtual hub.

1. Enable Routing Intent

   • Navigate - to your Hub - vwanXX-eastus-vHub1_VHUB
   • Click - “Routing Intent and Routing Policies” on the left under “Routing”
   • Select - for “Internet traffic” - Network Virtual Appliance
   • Select - for “Private traffic” - Network Virtual Appliance
   • Select - for both “Next Hop Resources” - your cluster name (the only selection in the dropdown)
   • Click - “Save” to update Routing Intent

   

Continue to Chapter 4 - Task 5: VNET Peering and Verifying Routing

Task 5: VNET Peering and Verifying Routing

In this task, the student will setup peering between the spokes/VNETs and the vWAN hub. Then second part of this task it to verify routing by viewing the routing tables on the FortiGate NVAs, the hub, and effective routes on the Linux hosts.

Peer Spoke VNETS to Hub

1. Peer Spoke1-vHub1_VNET to hub

   • Navigate to your Virtual Wan - vwanXX-training_VWAN

   • Click “Virtual network connections” on the left under “Connectivity”.

   • Click “+ Add connection”

   • Enter - “Connection name” - Spoke1

   • Select - “Hubs” - your assigned hub -vwanXX-eastus-vHub1_VHUB

   • Select - “Resource group” - your resource group - vwanXX-training

   • Select - “Virtual Network” - Spoke1 VNET - Spoke1-vHub1_VNET

   • Click - “Create”

   

2. Peer Spoke2-vHub1_VNET

   • Navigate to your Virtual Wan - vwanXX-training_VWAN

   • Click “Virtual network connections” on the left under “Connectivity”.

   • Click “+ Add connection”

   • Enter - “Connection name” - Spoke2

   • Select - “Hubs” - your assigned hub -vwanXX-eastus-vHub1_VHUB

   • Select - “Resource group” - your resource group - vwanXX-training

   • Select - “Virtual Network” - Spoke2 VNET - Spoke2-vHub1_VNET

   • Click - “Create”

     

     Info

     VNET Peering takes a few minutes to complete. The Connectivity Status can be reviewed by Clicking Refresh

     

Verify Routing

Routes and routing are the key for users to access workloads in an Azure VNET and for those workloads to be able to access resources outside of their VNET. At this point routes and routing should be set within the Azure environment and in the FortiGate NVAs.

From the perspective of the FortiGate, a decision will be made to send traffic to a specific port based on FortiGate policy. Once the traffic leaves the FortiGate’s port, it is up to Azure to forward the traffic.

Where traffic will be sent in Azure can be determined by viewing the effective routes associated to a particular networking service.

• What routes do the FortiGates know about?
• What are the effective routes of the hub?
• What are the effective routes of the Linux VMs in the Spoke VNETs?

1. View each FortiGate’s route table

   • Open each FortiGate in a browser tab/window

   • Open FortiGate CLI

   • Run CLI command get router info routing-table all

     

   The output shows that BGP routes have been learned for the two Spoke VNETs that were peered to the Hub

2. View the hub effective routes in the default route table

   • Navigate to your vWAN hub - vwanXX-eastus-vHub1_VHUB

   • On the left side, expand “Routing” and then “Effective Routes”

   • Select - “Route Tables” under “Choose resource type”

   • Select - “Default” under “Resource”

     All effective routes should have the FortiGate NVA group as next hop.

     

3. View the effective routes on the spoke Linux VMs

   • Navigate to your Linux VM Linux-Spoke1-VM

   • Click - “Network settings” located under “Networking” on the left side of the page

   • Click - “Linux-Spoke1-VM_nic1 (primary) / ipconfig (primary)

   • One the next page, navigate to Help on the bottom left and Click - “Effective Routes”

   • Repeat for Linux-Spoke2-VM

     

   The effective route’s next hop IP is the IP address of internal load balancer that is deployed in the vWAN hub with the FortiGate NVAs.

The diagram below is a visual representation of what you have deployed and configured. Congrats!

Continue to Chapter 5 - Network Traffic Management

Task 1: East-West Network Traffic

In this task, the student will create FortiGate firewall policies to allow east-west network traffic.

Spoke to Spoke traffic (East-West)

1. Ping between Linux Spoke VMs.

   • Open a serial console connections to each Linux Spoke VM and ping the other Spoke VM

     • Linux-Spoke1-VM - ping 192.168.2.4
     • Linux-Spoke2-VM - ping 192.168.1.4

     Linux-Spoke1_VM	Linux-Spoke2_VM

   Neither ping will be successful because the FortiGate is not allowing traffic from port2 to port2, even though port2 would be considered trusted since the traffic is all internal. This is the FortiGate’s ability to micro-segment the traffic.

   However, the traffic from each VM does reach the FortiGate, but it is dropped. Firewall Policies are required to allow traffic to pass from port2 to port2.

2. View ping traffic from Spoke VMs reaching the FortiGates

   • Open each FortiGate in a browser tab/window
   • Open FortiGate CLI
   • Run CLI command diagnose sniffer packet port2 'icmp' 4 0 a
     • 4 - means: print header of packets with interface name
     • 0 - means: continuous output
     • a - means: absolute UTC time, yyyy-mm-dd hh:mm:ss.ms

       FortiGate 0	FortiGate 1

   The ping traffic is only on one FortiGate, this is because the internal load balancer sends traffic from the Spokes to one of the FortiGates for inspection.

3. Create Firewall policies on both FortiGates to allow traffic to pass from port2 to port2 (Spoke to Spoke)

   NOTE: The FortiGates can be setup to sync configuration information. If one of the FortiGates was designated as the primary configuration supplier and the other as a secondary, any changes made to the primary would be replicated to the secondary.

   Configuration Synchronization was not enabled on the FortiGates as part of this course.

   • Navigate to “Policy & Objects”

   • Click Firewall Policy

   • Click Create new

     Attribute	Value
     Name	port2_to_port2
     Incoming interface	port2
     Outgoing interface	port2
     Source	all
     Destination	all
     Schedule	always
     Service	ALL
     NAT	enabled
     IP pool configuration	Use Outgoing Interface Address
     Enable this policy	enabled

   • Click “OK”

     

4. Ping between Linux Spoke VMs and confirm connectivity.

   • Linux-Spoke1-VM - ping 192.168.2.4
   • Linux-Spoke2-VM - ping 192.168.1.4

     Linux-Spoke1_VM	Linux-Spoke2_VM

     FortiGate 0	FortiGate 1

Continue to Chapter 5 - Task 2: North-South Network Traffic

Task 2: North-South Network Traffic

In this task, the student will create FortiGate firewall policies to allow North-South (Spoke to Internet) network traffic.

1. Ping from the Linux Spoke VMs to the Internet

   • Open a serial console connections to each Linux Spoke VM and ping the other Spoke VM

     • Linux-Spoke1-VM - ping 8.8.8.8
     • Linux-Spoke2-VM - ping 8.8.8.8

     Neither ping will be successful because the FortiGate is not allowing traffic from port2 to port1.

     Linux-Spoke1_VM	Linux-Spoke2_VM

   However, the traffic from each VM does reach the FortiGate, but it is dropped. Firewall Policies are required to allow traffic to pass from port2 to port1, and then return back to the VM that originated the ping.

2. View ping traffic from Spoke VMs reaching the FortiGates

   • Open each FortiGate in a browser tab/window
   • Open FortiGate CLI
   • Run CLI command diagnose sniffer packet port2 'icmp' 4 0 a

     • 4 - means: print header of packets with interface name

     • 0 - means: continuous output

     • a - means: absolute UTC time, yyyy-mm-dd hh:mm:ss.ms

       In the screenshots notice how this time the ping traffic appeared on FortiGate 1

       FortiGate 0	FortiGate 1

   The ping traffic is only on one FortiGate, this is because the internal load balancer sends traffic from the Spokes to one of the FortiGates for inspection.

3. Create Firewall policies on both FortiGates to allow traffic to pass from port2 to port1 (Spoke to Internet)

   The FortiGates can be setup to sync configuration information. If one of the FortiGates was designated as the primary configuration supplier and the other as a secondary, any changes made to the primary would be replicated to the secondary.

   Configuration Synchronization was not enabled on the FortiGates as part of this course.

   • Navigate to “Policy & Objects”

   • Click Firewall Policy

   • Click Create new

     Attribute	Value
     Name	port2_to_port1
     Incoming interface	port2
     Outgoing interface	port1
     Source	all
     Destination	all
     Schedule	always
     Service	ALL
     NAT	enabled
     IP pool configuration	Use Outgoing Interface Address
     Enable this policy	enabled

   • Click “OK”

     

4. Ping from the Linux Spoke VMs to the Internet and confirm the pings are successful

   • Linux-Spoke1-VM - ping 8.8.8.8
   • Linux-Spoke2-VM - ping 8.8.8.8

     Linux-Spoke1_VM	Linux-Spoke2_VM

     FortiGate 0	FortiGate 1

Continue to Chapter 6 - Two vWAN Hubs

Task 1: Deploy a second VWAN Hub

In this task, the student will deploy a second vWAN hub.

Deploy a VWAN Hub

The initial vWAN hub setup was already done for you before the session. Now you will deploy a second hub in another Azure region. The hub will eventually have a Virtual Network (VNET) peered to it, with a Linux VM deployed in the VNET as well.

1. Add a VWAN Hub.

   • Navigate to your assigned vWAN vwanXX-eastus_VWAN

   • On the left under “Connectivity” select “Hubs”.

   • Click - “+ New Hub” button

   • Select - Region “West US”

   • Enter - Name vwanXX-westus-vHub2_VHUB <– Where XX is your assigned number.

   • Enter - Hub private address space “10.2.0.0/16”

   • Select - Virtual hub capacity “2 Routing Infrastructure Units, 3 Gbps Router, Supports 2000 VMs”

   • Select - Hub routing preference “AS Path”

   • Click - “Next: Site to Site” button

     

   • Click - “Next: Point to Site” button

   • Click - “Next: ExpressRoute” button

   • Click - “Next: Tags” button

   • Click - “Next: Review + create” button

   • Click - “Next: Create” button

     

     Tip

     A deployment progress screen will be shown followed by a deployment completion screen. Hub deployment can take up to 30 minutes. Leave this browser tab open until you confirm the deployment has completed. Open the Azure portal in another browser tab and continue with the next task.

     

Continue to Chapter 6 - Task 2: Deploy a VNET

Task 2: Deploy a VNET

Deploy a VNET

Azure Virtual Networks (VNET) can be peered to a vWAN hub. Once a VNET is peered to a vWAN hub, workloads in the VNET can communicate with workloads in other VNETs connected to other vWAN hubs that are part of the same vWAN.

1. Add a VNET

   • Navigate to your Resource Group vwanXX-training

   • Click - The Portal Menu button in the upper-left corner, sometime referred to as the hamburger button

   • Select - Virtual Networks in the left-hand navigation

   • Click - “+ Create” button

     

   • Select - your Resource Group vwanXX-training

   • Enter - Virtual network name Spoke3-vHub2_VNET

   • Select - Region “(US) West US”

   • Click - “Next” button

     

   • Click - “Next” button on “Security” tab

     

   • Enter - Address Space 192.168.3.0

   • Select - Netmask /24

   • Click - “Pencil” button to edit subnet configuration

   • Enter - Name Subnet1-Spoke3_SUBNET

   • Enter - Starting address 192.168.3.0

   • Click - “Save” button

     

     • Click - “Next” button

     

     • Click - “Next” button

     

     • Click - “Create” button

     

     • Click - your resource group name when the deployment is complete and confirm the new “Spoke3-vHUB2_VNET”.

     

Continue to Chapter 6 - Task 3: Deploy a Linux VM

Task 3: Deploy a Linux VM

Deploy a Linux VM

Now that you have the Spoke3-vHub2_VNET deployed, you are going to deploy a Linux VM in Spoke3-vHub2_VNET. This VM will be used to test hub to hub connectivity between spokes peered to different hubs.

Steps to create a Linux VM

1. Navigate into your assigned Resource Group and click on the + Create located at the top left of the tool bar.

   

   You will be redirected to the Azure Marketplace.

2. Enter - ubuntu 24.10 - in the Marketplace search bar, then press enter. Navigate to the Ubuntu 24.10 - all plans offering from Canonical and select Create and Ubuntu Server 24.10.

   

   You will be redirected to the Create a virtual machine template.

3. Under the Basics tab, update the following fields:

   (Leave the default entry for the other fields not listed here)

   • Resource group: Confirm “vwanXX-training”
   • Virtual machine name: “Linux-Spoke3-VM”
   • Region: “(US) West US”
   • Availability options: “No infrastructure redundancy required”
   • Security type: “Standard”
   • Authentication type: “Password”
   • Username: “fortixperts”
   • Password: “Fortixperts2024!”
   • Confirm password: “Fortixperts2024!”

4. Confirm the changes and the other fields default entries match the following diagram.

   

5. Click Next: Disks > - no changes are needed

6. Click Next: Networking >

   Feel free to read through the available disk services that can be changed/enabled.

7. Update the following fields on the Networking tab: (Leave the default entry of the other fields not listed here)

   • Virtual network: “Spoke3-vHub2_VNET”
   • Subnet: “Subnet1-Spoke3_SUBNET (192.168.3.0/24)”
   • Public IP: Select None
   • NIC network security group: Select None

8. Confirm the changes and the other fields default entries match the following diagram

   

9. Click Review + create >

   Feel free to read through the Management, Monitoring, Advanced, and Tags tabs for additional services that can be changed/enabled.

10. Confirm the template validation has passed

11. Click Create

    

    Info

    The Deployment is in progress notice is displayed and then the Your deployment is complete notice is displayed.

    

12. Click on the vwanXX-training link to be re-directed to your resource group.

13. Verify the new Linux-Spoke3-VM and the associated components are listed in your Resource Group.

Continue to Chapter 6 - Task 4: VNET Peering to the Second Hub

Task 4: VNET Peering to the Second Hub

In this task, the student will setup peering between the Spoke3-vHub2_VNET and the vwanxx-westus-vHub2_VHUB. Then you will view route tables on the FortiGate NVAs, hubs, and the Linux-Spoke3-VM.

1. Peer Spoke3-vHub2_VNET to vwan12-westus-vHub2_VHUB

   • Navigate to your Virtual Wan - vwanXX-training_VWAN

   • Click “Virtual network connections” on the left under “Connectivity”.

   • Click “+ Add connection”

   • Enter - “Connection name” - Spoke3

   • Select - “Hubs” - your second hub -vwanXX-westus-vHub2_VHUB

   • Select - “Resource group” - your resource group - vwanXX-training

   • Select - “Virtual Network” - Spoke3 VNET - Spoke3-vHub2_VNET

   • Click - “Create”

     

     Info

     VNET Peering takes a few minutes to complete. The Connectivity Status can be updated by Clicking Refresh

     

Verify Route Tables

Now that the Spoke3-vHub2_VNET has been peered to your second hub vwanXX-westus-vHub2_VHUB and both hubs are part of the Azure vWAN, lets take a closer look at the learned routes in each resource.

• What routes do the FortiGates know about?
• What are the effective routes of both hubs?
• What are the effective routes of the Linux-Spoke3-VM?

1. View each FortiGate’s route table

   • Open each FortiGate in a browser tab/window

   • Open FortiGate CLI

   • Run CLI command get router info routing-table all

     

   The output shows that BGP learned routes for the new Spoke3-vHub2_VNET peered to the new vwanXX-westus-vHub2_VHUB.

2. View the effective routes of the default route table, in both hubs.

   vHub1

   • Navigate to your vWAN hub - vwanXX-eastus-vHub1_VHUB

   • On the left side, expand “Routing” and then “Effective Routes”

   • Select - “Route Tables” under “Choose resource type”

   • Select - “Default” under “Resource”

     All effective routes should have the FortiGate NVA group as next hop. Note that nothing has changed in your vwanXX-eastus-vHub1_VHUB route table.

     

   vHub2

   • Navigate to your vWAN hub - vwanXX-westus-vHub2_VHUB

   • On the left side, expand “Routing” and then “Effective Routes”

   • Select - “Route Tables” under “Choose resource type”

   • Select - “Default” under “Resource”

     Note the three spoke VNETs learned by vHub2.

     

3. View the effective routes on the “Linux-Spoke3-VM”

   • Navigate to your Linux VM Linux-Spoke3-VM
   • Click - “Network settings” located under “Networking” on the left side of the page
   • Click - “Linux-Spoke3-VM_nic1 (primary) / ipconfig (primary)
   • One the next page, navigate to Help on the bottom left and Click - “Effective Routes”

   Effective routes for Linux-Spoke3-VM

   The effective route’s next hop IP is the IP address of internal load balancer that is deployed in vHub2.

The diagram below is a visual representation of what you have deployed and configured. Congrats!

Continue to Chapter 6 - Task 5: Manage Network Traffic Between Hubs

Task 5: Manage Network Traffic Between Hubs

In this task, the student will create FortiGate firewall policies to allow or deny selective east-west network traffic between spokes in different vWAN hubs.

Create the following addresses and firewall policies on both FortiGates.

1. Create firewall addresses for Spoke1-vHub1_VNET, Spoke2-vHub1_VNET, and Spoke3-vHub2_VNET.

   • Login to both FortiGate NVAs
   • Navigate to “Policy & Objects”
   • Select “Addresses” and “+ Create new” at the top of the Address page.
   • Name Spoke1-vHub1_VNET
   • Interface: port2
   • IP/Netmask: 192.168.1.0/24
   • Click OK

   

2. Follow the above steps to create addresses for Spoke2-vHub1_VNET (192.168.2.0/24) and Spoke3-vHub2_VNET (192.168.3.0/24), both on interface port2.

   

3. Create a firewall policy to allow traffic to pass from spoke1 to spoke3. Be sure to do this on both FortiGates.

   NOTE: Delete the existing port2_to_port2 policy first!

   • Click Firewall Policy

   • Click Create new

     Attribute	Value
     Name	Spoke1_to_Spoke3
     Incoming interface	port2
     Outgoing interface	port2
     Source	Spoke1-vHub1_VNET
     Destination	Spoke3-vHub2_VNET
     Schedule	always
     Service	ALL
     NAT	disabled
     Enable this policy	enabled

   • Click “OK”

   

4. Follow the above steps to create a firewall policy to deny traffic from spoke2 to spoke3 and another firewall policy to allow traffic from spoke3 to both spoke1 and spoke2. Be sure to do this on both FortiGates.

5. Test connectivity between Linux spoke VMs.

   • Open serial console connections on each Linux VM and ping the other spoke VMs
     • Linux-Spoke1-VM - ping 192.168.3.4
     • Linux-Spoke2-VM - ping 192.168.3.4
     • Linux-Spoke3-VM - ping 192.168.1.4
     • Linux-Spoke3-VM - ping 192.168.2.4

Did you get the results you expected? If you did, great job!. You are done with the course.

If you did not, here are some helpful troubleshooting hints:

• Did you enter the addresses and firewall policies on both FortiGates?
• Double check your firewall policies. Make sure NAT is disabled.
• Make sure the address names have the correct IP addresses/subnet.
• Check your route table on the FortiGates. Do you still see all three VNETs listed?

If you checked all the above and you are still not getting the expected results, reach out to an instructor.

Thanks for attending!