Task 1: Fundamental Azure Services

Azure Portal

The Azure portal is a web-based, unified console that lets you create and manage all your Azure resources. With the Azure portal, you can manage your Azure subscription using a graphical user interface. You can build, manage, and monitor everything from simple web apps to complex cloud deployments in the portal. For example, you can set up a new database, increase the compute power of your virtual machines, and monitor your monthly costs. You can review all available resources, and use guided wizards to create new ones.

The Azure portal is designed for resiliency and continuous availability. It has a presence in every Azure datacenter. This configuration makes the Azure portal resilient to individual datacenter failures and helps avoid network slowdowns by being close to users. The Azure portal updates continuously, and it requires no downtime for maintenance activities. You can access the Azure portal with any supported browser.

Azure Resource Group

An Azure Resource Group is a container similar to a folder that enables you to manage related resources for an Azure solution. By using the resource group, you can coordinate changes to the related resources. For example, you can deploy an update to the resource group and have confidence that the resources are updated in a coordinated operation. Or, when you’re finished with the solution, you can delete the resource group and know that all of the resources are deleted.

There are some important factors to consider when defining your resource group:

• All the resources in your resource group should share the same lifecycle. You deploy, update, and delete them together. If one resource, such as a server, needs to exist on a different deployment cycle it should be in another resource group.
• Each resource can exist in only one resource group.
• You can add or remove a resource to a resource group at any time.
• You can move a resource from one resource group to another group.
• The resources in a resource group can be located in different regions than the resource group, but it’s recommended that you use the same location.
• A resource group can be used to scope access control for administrative actions. To manage a resource group, you can assign Azure Policies, Azure roles, or resource locks.
• You can apply tags to a resource group. The resources in the resource group don’t inherit those tags.
• A resource can connect to resources in other resource groups. This scenario is common when the two resources are related but don’t share the same lifecycle. For example, you can have a web app that connects to a database in a different resource group.
• When you delete a resource group, all resources in the resource group are also deleted.
• You can deploy up to 800 instances of a resource type in each resource group. Some resource types are exempt from the 800 instance limit. For more information, see resource group limits
• Some resources can exist outside of a resource group. These resources are deployed to the subscription, management group, or tenant. Only specific resource types are supported at these scopes.
• To create a resource group, you can use the portal, Azure Resource Manager REST API, PowerShell, Azure CLI, ARM templates, and IaC tools, to name a few.

Azure Marketplace

Azure Marketplace is an online store for solutions that are built on or built for Azure. Buyers can access Azure Marketplace in the Azure portal or access the Azure Marketplace online store. The Azure Marketplace online store includes listings for consulting and managed services. Azure Marketplace consulting services are professional service offerings that help customers get started with or accelerate the use of Azure.

Azure Marketplace is a part of Azure, so you can access the catalog of Azure Marketplace solutions in the Azure portal through the Create a resource option. This option opens Azure Marketplace within the Azure portal, where you can search for solutions by name or by category.

Task 2: Azure Networking Concepts

Azure Virtual Network

Azure Virtual Network is a service that provides the fundamental building block for your private network in Azure. An instance of the service (a virtual network) enables many types of Azure resources to securely communicate with each other, the internet, and on-premises networks. These Azure resources include virtual machines (VMs).

All resources in a virtual network by default cannot communicate outbound with the internet. You can use a public IP address, NAT gateway, or public load balancer to manage your outbound connections. You can communicate inbound with a resource by assigning a public IP address or a public load balancer.

You can connect virtual networks to each other by using virtual peering. The resources in either virtual network can then communicate with each other. The virtual networks that you connect can be in the same, or different, Azure regions.

You can connect your on-premises computers and networks to a virtual network by using any of the following options:

• Point-to-site virtual private network (VPN): Established between a virtual network and a single computer in your network. Each computer that wants to establish connectivity with a virtual network must configure its connection. This connection type is useful if you’re just getting started with Azure, or for developers, because it requires few or no changes to an existing network. The communication between your computer and a virtual network is sent through an encrypted tunnel over the internet.

• Site-to-site VPN: Established between your on-premises VPN device and an Azure VPN gateway that’s deployed in a virtual network. This connection type enables any on-premises resource that you authorize to access a virtual network. The communication between your on-premises VPN device and an Azure VPN gateway is sent through an encrypted tunnel over the internet.

• Azure ExpressRoute: Established between your network and Azure, through an ExpressRoute partner. This connection is private. Traffic doesn’t go over the internet.

You can filter network traffic between subnets by using either or both of the following options:

• Network security groups: Network security groups and application security groups can contain multiple inbound and outbound security rules. These rules enable you to filter traffic to and from resources by source and destination IP address, port, and protocol.

• Network virtual appliances (NVA): A network virtual appliance is a VM that performs a network function, such as a firewall or WAN optimization. The FortiGate is considered a NVA.

• Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the internet, by default. You can implement either or both of the following options to override the default routes that Azure creates:

  • Route tables: You can create custom route tables that control where traffic is routed to for each subnet.

  • Border gateway protocol (BGP) routes: If you connect your virtual network to your on-premises network by using an Azure VPN gateway, ExpressRoute connection, or FortiGate NVA, you can propagate your on-premises BGP routes to your virtual networks.

Azure Virtual Network Concepts

Before diving into the reference architecture for this workshop, let’s review some basic Azure networking concepts.

• Address space: When creating a virtual network, you must specify a custom private IP address space using public and private (RFC 1918) addresses. Azure assigns resources in a virtual network a private IP address from the address space that you assign. For example, if you deploy a VM in a virtual network with address space, 10.0.0.0/16, the VM is assigned a private IP like 10.0.0.4.

• Subnets: Subnets enable you to segment the virtual network into one or more sub-networks and allocate a portion of the virtual network’s address space to each subnet. You can then deploy Azure resources in a specific subnet. Just like in a traditional network, subnets allow you to segment your virtual network address space into segments that are appropriate for the organization’s internal network. Segmentation improves address allocation efficiency. You can “secure” resources within subnets using Network Security Groups.

• Regions: A virtual network is scoped to a single region/location; however, multiple virtual networks from different regions can be connected together using Virtual Network Peering.

• Subscription: A virtual network is scoped to a subscription. You can implement multiple virtual networks within each Azure subscription and Azure region.

In this workshop we will use these components to highlight insertion of FortiGate NGFW into an enterprise architecture.

Task 3: FortiGate-VM Support for Azure

FortiGate-VM

By combining stateful inspection with a comprehensive suite of powerful security features, FortiGate Next Generation Firewall (NGFW) technology delivers complete content and network protection. This solution is available for deployment on Microsoft Azure.

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, VPN, and SD-WAN work in concert to identify and mitigate the latest complex security threats.

FortiGate-VM Azure Deploymnet Options

• Standalone NVA

• Active/Passive NVAs - with these failover options

  • Using Azure Load Balancers for failover
  • Using Azure Resource Manager API for Public and Private IP address movement

• Active/Active NVAs

Azure Virtual WAN Hub deployment

Instance Type Support

FortiGate-VM supports a variety of Instance Types on Azure

Licensing

FortiGate-VM supports the following Licensing methods

• PAYG - Pay As You Go - per CPU cost assessed hourly

• BYOL - Bring Your Own License

• FortiFlex - Point based entitlement assessed daily.

Azure Environment Provision

Public Cloud - 102 - Azure Foundational

Provision an environment for this workshop

Task 1: Azure Portal Lab Access

Lab Environment

This lab is configured to allow each student to have their own training lab environment using pre-created Azure resource groups all in one shared Azure Subscription.

Azure Portal Lab Access

First log in to the Azure Portal, next access to the lab environment.

To access the Azure Portal sign-in page

1. Open a browser and access the following URL:

   https://portal.azure.com

2. Use the credentials shared with you by your instructors or the credentials received via email.

   Username: “fgtXX@fortinetcloud.onmicrosoft.com”

3. Enter Temporary Access Pass

   

4. Click Sign in.

5. Click Yes on the ‘Stay signed in?’ prompt

6. Click Cancel on the ‘Welcome to Microsoft Azure’ page.

   

7. Click on Resource Groups in the main page.

   

8. Confirm your resource group is shown - fgtXX-azure102-workshop

   

Task 1: Deploy an Azure Virtual Network (VNET)

Deploy a VNET (Virtual Network) in the assigned workshop Resource Group.

1. Click the Hamburger menu in the upper-left corner of the Azure Portal to show the “Portal Menu”

2. Click “Virtual networks”

3. Click “+ Create”

   

   

   

   You will be redirected to the Create virtual network template.

   Under the Basics tab, the Subscription and Resource Groups may already be filled in with your assigned info. If not, see the screenshot below for details.

4. In the Instance details section, enter the following:

   • Virtual network name: abc-server-vnet
   • Region: (US) West US 3

5. Click “Next : Security”

   

6. On the Security tab, ensure none of the services are selected - Feel free to read through the available services that can be enabled.

7. Click “Next : IP addresses”

8. Edit the default address space, change to 192.168.1.0/24

9. Click The pencil icon to the right of the “default” subnet, in the new window to the right, update the following settings:

   • Name: snet-a
   • Starting address: 192.168.1.128
   • Size: /27
   • Click Save

   

10. Click “+ Add a subnet” add the following subnet:

    • Name: snet-b
    • Starting address: 192.168.1.160
    • Size: /27
    • Click Add

    

11. Click “Review + create”

    

12. Confirm the settings

13. Click “Create”

    

14. Click your Resource Group link, When the deployment is complete

    

Your Resource Group should now have a VNET named abc-server-vnet

1. Click on the VNET name and explore the various settings that can be applied to or utilized with an Azure Virtual Network.

2. Click on “Subnets” under “Settings” to view the subnets that were just created.

At this point these are your Azure Resources

Task 2: Deploy Linux Virtual Machines

Now that a VNET is configured, Task 2 will cover

• Deploying two Linux Virtual Machines (VMs) in the VNET
• Identify assigned Public IP (PIP)
• Confirm access to the Internet
• Confirm access between each VM

linux-a-vm will have an interface in subnet snet-a linux-b-vm will have an interface in subnet snet-b

Steps to create linux-a-vm

1. Click the Hamburger menu in the upper-left corner of the Azure Portal to show the “Portal Menu”

2. Click “Virtual machines”

3. Click “+ Create”

   

   

4. Click Virtual Machine", You will be redirected to the Create a virtual machine template.

   Under the Basics tab, the Subscription and Resource Groups may already be filled in with your assigned info. If not, see the screenshot below for details.

5. Update the following fields:

   (Leave the default entry for fields not listed here)

   • Resource group: fgtXX-azure102-workshop
   • Virtual machine name: linux-a-vm
   • Availability options: No infrastructure redundancy required
   • Security type: Standard
   • Image: Select See all images under the image drop-down

   

6. Enter Ubuntu 24.04 LTS in the search field

7. Click “Select”

8. Click “Ubuntu Server 24.04 LTS - x64 Gen 1”

   

   

   Continuing from Create a virtual machine Basics tab:

   • Size: Select See all sizes under the size drop-down

   

9. Search for D2s_v5

10. Select “D2s_v5”

11. Click “Select”

    

    Continuing from Create a virtual machine Basics tab:

    • Authentication type: Password
    • Username: azureuser
    • Password: 123Password#@!
    • Confirm password: 123Password#@!

    

12. Confirm the changes and the other field’s default entries match as shown here.

    

13. Click Next: Disks >.

    On the Disk tab, keep the default settings, take a moment to review the available disk services and settings.

14. Click “Next: Networking >”

    On the Networking tab, update the following fields:

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

    • Virtual network: Select abc-server-vnet
    • Subnet: Select snet-a (192.168.1.128/27)
    • Delete public IP and NIC when VM is deleted: Select

15. Confirm the changes and the other field’s default entries match as shown here.

    

16. Select Review + create >.

    Note

    You are skipping the Management, Monitoring, Advanced, and Tags tabs. Feel free to review those tabs to view the available services and settings on those tabs.

17. Confirm the template validation has passed and select Create

    

    The Deployment is in progress notice is displayed.

    

    Once the Your deployment is complete notice is displayed, click on the fgtXX-azure102-workshop link to be re-directed to your Resource Group.

    

18. Verify the new linux-a-vm and the associated components are listed.

    

Steps to create linux-b-vm

1. Follow the same steps to create the linux-b-vm. You will need to alter the following where appropriate:

   • Virtual machine name: linux-b-vm
   • Subnet: snet-b (192.168.1.160/27)

2. Verify the new linux-b-vm and the associated components are listed.

   

Task 3: Identify VM Information and Unsecured Services

Login to Linux VM Serial Console

Now that both Linux virtual machines, linux-a-vm and linux-b-vm, have been deployed, you are going to identify their assigned private and public IP (PIP) addresses, confirm which ports are open on each VM, and what access is available to and from their assigned subnets.

In the following steps 1-6, you will navigate and identify IP information for both VMs and login to each VM via the serial console, in Azure.

1. Navigate to your Resource Group

2. Right Click on the virtual machine linux-a-vm

3. Select “Open Link in New Tab”

   

   The browser tab will open to the linux-a-vm Overview page, under the Essentials and Properties sections, right-hand side, identify the assigned private and public IP of linux-a-vm

   

4. Navigate to the bottom of the left-side menu

5. Expand “Help”

6. Select “Serial console”

7. Login to the linux-a-vm console using the credentials used when creating the linux-a-vm.

   

8. Repeat the same process to login to the serial console of **linux-b-vm-in another tab

The VNET security policy for company ABC is as follows

linux-a-vm will be the management server. Per company ABC security policy:

• linux-a-vm should only have SSH and PING access to linux-b-vm
• linux-a-vm should have HTTP/HTTPS access to the Internet
• linux-a-vm should be SSH accessible from the Internet

linux-b-vm is the www server. Per company ABC security policy:

• linux-b-vm should be HTTP accessible from the Internet
• linux-b-vm should have HTTP and HTTPS access to the Internet
• linux-b-vm should only have PING access to linux-a-vm

The goals of the following steps, are to note:

• Which service ports are open and listening on each VM
• What access does each VM have across subnets
• Which services to and from the Internet are available to each VM

Using this information, we can implement company ABC’s security policies when securing the VNET with a FortiGate

Configure linux-b-vm first

1. Verify Connectivity and Services

   Note

   These commands are completed from the linux-b-vm

   • Use ping www.yahoo.com
     • confirms DNS and ICMP access to the Internet: (CTRL+c to stop ping)
   • Use wget www.fortinet.com
     • confirms port 80 access to the Internet: (Confirm “200 OK” response)
   • Use curl https://ipinfo.io/ip && echo " linux-b-vm's PIP"
     • confirms port 443 access to the Internet
     • confirms Public IP assigned to linux-b-vm: (Verify against what the Azure portal listed in the Overview section for this VM)

   

   • Check for and install Ubuntu updates

     • sudo apt update
     • sudo apt -y upgrade
     • clear after updates have finished

   • Ping the private IP of linux-a-vm

     • ping 192.168.1.xxx (Refer to previous steps for Private IP)

   • Install NMAP Scan open ports on linux-a-vm

     • sudo apt -y install nmap
     • nmap -F 192.168.1.xxx (Refer to previous steps for Private IP)
     • Note the open port(s) on linux-a-vm

   

   • Confirm SSH access to linux-a-vm:
     • ssh azureuser@192.168.1.xxx (Refer to previous steps for Private IP)
     • Use sudo ss -ltn to confirm the same open ports that NMAP reported
     • Use exit to disconnect from linux-a-vm

   

   

   • Install the web service NGINX
     • sudo apt -y install nginx

Configure linux-a-vm second

• Use ping www.yahoo.com

  • confirms DNS and ICMP access to the Internet: (CTRL+c to stop ping)

• Use wget www.fortinet.com

  • confirms port 80 access to the Internet: (Confirm “200 OK” response)

• Use curl https://ipinfo.io/ip && echo " linux-a-vm's PIP"

  • confirms port 443 access to the Internet
  • confirms Public IP assigned to linux-a-vm: (Verify against what the Azure portal listed in the Overview section for this VM)

• Check for and install Ubuntu updates

  • sudo apt update
  • sudo apt -y upgrade
  • clear after updates have finished

• Ping the private IP of linux-b-vm

  • ping 192.168.1.xxx (Refer to previous steps for Private IP)

• Install NMAP Scan open ports on linux-b-vm

  • sudo apt -y install nmap
  • nmap -F 192.168.1.xxx (Refer to previous steps for Private IP)
  • Note the open port(s) on linux-a-vm

• Confirm SSH access to linux-b-vm:

  • ssh azureuser@192.168.1.xxx (Refer to previous steps for Private IP)
  • Use sudo ss -ltn to confirm the same open ports that NMAP reported
  • Use exit to disconnect from linux-b-vm

The following diagram is a representation of your current VNET and VM deployment.

Task 1: Deploy a FortiGate NVA

In Task 1, you will deploy a FortiGate network virtual appliance (NVA) in your Resource Group. After deployment, you will login to the FortiGate and verify settings.

FortiGate Deployment - Prerequisite

The Single Fortinet FortiGate requires two interfaces

• external (port1) untrusted interface
• internal (port2) trusted interface

These interfaces require two additional subnets be added to VNET acb-server-vnet

Access acb-server-vnet and add these two subnets

• snet-external with address space 192.168.1.0/27
• snet-internal with address space 192.168.1.32/27

Use these screen shots for reference

FortiGate Deployment

1. Navigate to your Resource Group

2. Click “+ Create”

   

   You will be redirected to the Azure Marketplace.

3. Search for Fortinet FortiGate

4. Select “Fortinet FortiGate Next-Generation Firewall”

5. Click “Create”

6. Click “Single VM”

   

   You will be redirected to the Create Single VM template.

   Under the Basics tab, the Subscription and Resource Groups may already be filled in with your assigned info. If not, see the screenshot below for details.

7. Under Instance details, select/enter the following:

   • Region: West US 3
   • FortiGate VM instance Architecture: “X64 - Intel / AMD based processors | Gen1 VM FortiGate 6.4 - 7.4”
   • FortiGate administrative username: azureuser
   • FortiGate password: 123Password#@!
   • Confirm password: 123Password#@!
   • FortiGate Name Prefix: sgl

8. Click “Next”

   

9. On the Instance tab, select the following

   • Fortigate-VM License Type: “Pay As You Go”
   • Fortigate Image Version: “7.4.x” - Select the latest version
   • Size: “F2s_v2” - If the size is not “F2s_v2” use the “Change size” link and select “F2s_v2”
   Tip

   Note the blue shaded areas, they are links to additional information

10. Click “Next”

    

11. On the Networking tab, select the following:

    • Virtual network: abc-server-vnet
    • External Subnet: snet-external
    • Internal subnet: snet-internal
    • Protected subnet: snet-a
    • Accelerated Networking: Disabled
    Note

    snet-b will be protected as well, the template just does not have a selection for it.

12. Click “Next”

    

13. On the Public IP tab, keep the default Public IP address already entered. It should have a “(new)” listed in the beginning of the field.

14. Click “Next”

    

15. On the Advanced tab, keep the default settings.

16. Click “Review + create”

    

17. On the Review + create tab, scroll down and review the template entries.

18. Click “Create”

    

    The screen will refresh and you will see Deployment is in progress.

    

    After a few minutes, you will see Your deployment is complete

19. Click Go to resource group

    

20. Confirm the FortiGate NVA and its related services have been deployed.

    

21. Click “sgl-fgt”

22. View Public IP address on overview page

    

FortiGate Access

1. Use the “Public IP address” in a browser to access the FortiGate interface

2. Enter the login info from above

   

3. Click “Begin” on the FortiGate Setup page

   

4. Click “Later” on the Migrate Config with FortiConverter page

   

5. Select “Disable automatic patch upgrades” then Click “Save and continue” on the Automatic Patch Upgrades for v7.4 page

   

6. Select “I acknowledge” and Click “OK” on the Disable Automatic Patch Upgrades page

   

7. Click “OK” on the Dashboard Setup page

   

8. Select “Don’t show again” and Click “OK” on the What’s new in FortiOS 7.4 video

   

The following diagram is a representation of your current VNET with Linux VM deployment and FortiGate NVA

Task 2: Deploy a Route Table and Create a UDR

In Task 2, you will deploy a Route Table and modify the Route Table by associating both protected subnets to use port2 of the FortiGate as the default route. These routes are referred to as User Defined Routes (UDRs).

Create and configure an Azure Route Table

1. Navigate to your Resource Group

2. Click “+ Create”

   

   You will be redirected to the Azure Marketplace.

3. Search Route Table

4. Select the “Route table” offering from Microsoft

5. Click “Create”

6. Click “Route table”

   

   You will be redirected to the Create Route table template.

   Under the Basics tab, the Subscription and Resource Groups should already be filled in with your assigned info. If not, see the screen shot below for details.

7. Under Instance details, enter the following:

   • Region: West US 3
   • Name: route-table

8. Click “Review + create”

   

9. Click “Create”

   

10. Click on the “Resource group” when the deployment is complete

    

11. Click on “route-table”

12. Click “Routes” under “Settings”

13. Click “+ Add”

14. Enter in the Add route panel

    • Route name: default
    • Destination type: Select IP Addresses
    • Destination IP address/CIDR ranges: 0.0.0.0/0
    • Next hop type: Select Virtual appliance
    • Next hop address: 192.168.1.36 (Confirm this is the same IP assigned to port2 on your FortiGate NVA).

15. Click Add

    

    

    The new route called default is listed under the Routes section

    

16. Add two more routes for snet-a and snet-b.

    • Route name: snet-a
    • Destination type: Select IP Addresses
    • Destination IP address/CIDR ranges: 192.168.1.128/27
    • Next hop type: Select Virtual appliance
    • Next hop address: 192.168.1.36 (Confirm this is the same IP assigned to port2 on your FortiGate NVA).

17. Click Add

    • Route name: snet-b
    • Destination type: Select IP Addresses
    • Destination IP address/CIDR ranges: 192.168.1.160/27
    • Next hop type: Select Virtual appliance
    • Next hop address: 192.168.1.36 (Confirm this is the same IP assigned to port2 on your FortiGate NVA).

18. Click Add

    

19. Click “Subnets”

20. Click “+ Associate”

21. Enter in the Associate subnet panel

    • Virtual network: abc-server-vnet
    • Subnet: Select snet-a

22. Click “OK”

23. Enter in the Associate subnet panel

    • Virtual network: abc-server-vnet
    • Subnet: Select snet-b

24. Click “OK”

    

    

25. Click Overview

26. View a summary of the Routes and associated Subnets

    

Remove the Public IP Addresses from the Linux VMs

1. Navigate to your Resource Group

2. Click on “linux-a-vm-ip”

3. Click on “Disassociate”

4. Click “Yes” to confirm disassociation

5. Click on “Delete”

6. Click “Yes” to confirm deletion

   

   

   

   

7. Repeat for “linux-b-vm-ip”

Because the Route Table is associated to the VNET, directing traffic to the FortiGate using the Public IPs attached to the Linux VMs is not possible because traffic leaving Linux VMs will be forced to the FortiGate and there will be no awareness and the traffic will be dropped.

The following diagram is a representation of your current VNET with Linux VM deployment and FortiGate NVA

Task 3: Confirm Linux VMs access via FortiGate

In Task 3, you will confirm the Linux VMs are using the FortiGate NVA as their default route and that all traffic to/from the Linux VMs is going through the FortiGate.

1. Open Serial consoles linux-a-vm and linux-b-vm

2. From linux-a-vm console run

   • ping www.yahoo.com
   • ping 192.168.1.164 <– Most likely the Private IP of linux-b-vm

   Neither should respond

   

3. From linux-b-vm console run

   • ping www.yahoo.com
   • ping 192.168.1.132 <– Most likely the Private IP of linux-a-vm

   Neither should respond

   

4. Login to the FortiGate

5. Open a CLI session on the FortiGate

   

6. Enter the FortiGate CLI command

   • diagnose sniffer packet port2 'icmp'

7. Run steps two and three again.

   The ICMP echo request traffic reaches the FortiGate, however the FortiGate does not have any policies to allow or deny the traffic.

   

Task 4: Configure FortiGate Policies

In Task 4, now that you have confirmed traffic from both Linux VMs is being routed to the FortiGate, you will create policies that will accomplish the security requirements requested by company ABC.

To meet these requirements, the following access needs to be setup for each Linux VM.

linux-a-vm is the management server and should have the following access:

• SSH and PING access to linux-b-vm
• HTTP and HTTPS access to the Internet
• SSH access to linux-a-vm from the Internet

linux-b-vm is the www server and should have the following access:

• HTTP service from the Internet
• HTTP and HTTPS access to the Internet
• PING access to linux-a-vm

Configure FortiGate Policies and Objects

In the following steps, you will create

• An Address object
• A Virtual IP Address (VIP)
• A Firewall Policy for linux-a-vm

Then repeat each step to create similar configurations for linux-b-vm

From the FortiGate GUI

1. Navigate to Policy & Objects–>Addresses

2. Click “+ Create new”

   

3. Enter the following:

   • Name: linux-a-vm
   • Interface: port2
   • Type: Subnet
   • IP/Netmask: 192.168.1.132/32

4. Click “OK”

   

5. Repeat for linux-b-vm. Your Address screen should have both Linux VMs listed.

6. Click “+ Create new”

7. Enter the following:

   • Name: linux-b-vm
   • Interface: port2
   • Type: Subnet
   • IP/Netmask: 192.168.1.164/32

8. Click “OK”

9. View the created Address Objects

   

10. Navigate to Policy & Objects–>Virtual IPs

11. Click “+ Create new”

12. Enter the following:

    • Name: linux-a-vm_VIP
    • Interface: port1
    • External IP address/range: 192.168.1.4
    • Map to IPv4 address/range: 192.168.1.132
    • Port Forwarding: Enable
    • External service port: 22
    • Map to IPv4 port: 22

13. Click “OK”

    

14. Repeat and create a VIP for linux-b-vm, HTTP is the service port.

    • Name: linux-b-vm_VIP
    • Interface: port1
    • External IP address/range: 192.168.1.4
    • Map to IPv4 address/range: 192.168.1.164
    • Port Forwarding: Enable
    • External service port: 8080
    • Map to IPv4 port: 80

    

15. Navigate to Policy & Objects–>Firewall Policy

16. Click “+ Create new”

17. Enter the following:

    • Name: Internet access to linux-a-vm
    • Incoming interface: port1
    • Outgoing interface: port2
    • Source: all
    • Destination: linux-a-vm_VIP
    • Service: SSH
    • NAT: Toggle to disabled

18. Click “OK”

19. Confirm the new policy for linux-a-vm is displayed

    

20. Enter the following to create a policy to allow SSH and PING access to linux-b-vm.

    • Name: SSH & PING access to linux-b-vm
    • Incoming interface: port2
    • Outgoing interface: port2
    • Source: linux-a-vm
    • Destination: linux-b-vm
    • Service: SSH PING
    • NAT: Toggle to disabled

    Click OK and confirm the new policy is displayed.

    

21. Repeat and modify to finishing adding the required policies

    linux-a-vm needs these additional policies

    • HTTP and HTTPS access to the Internet
      • Name: linux-a-vm access to the internet
      • NAT: enabled

    linux-b-vm needs these additional policies

    • HTTP service from the Internet

      • Name: Internet access to linux-b-vm

    • HTTP and HTTPS access to the Internet

      • Name: linux-b-vm access to the internet
      • NAT: enabled

    • PING access to linux-a-vm

      • Name: Ping Access to linux-a-vm

    When you are finished adding all the policies for both Linux VMs, your Firewall Policy page should look similar to the following:

    

Task 5: Confirm Managed Traffic

In Task 5, you will confirm that the Firewall Policies are correct and accomplish the security requirements for Company ABC. In the following steps, you will run the same cli commands on each Linux VM to confirm which services are reachable and blocked.

Summary of access to/from each Linux VM:

linux-a-vm is the management server and should have the following access:

• SSH and PING access to linux-b-vm

• HTTP and HTTPS access to the Internet

• SSH access to linux-a-vm from the Internet

  From the linux-a-vm CLI:

  1. ping 192.168.1.164 <– Most likely the Private IP of linux-b-vm

     • Ping the private IP of linux-b-vm and confirm replies

  2. ssh azureuser@192.168.1.164 <– Most likely the Private IP of linux-b-vm

     • Confirm SSH access to linux-b-vm and login
     • Type exit to disconnect from linux-b-vm

  3. wget www.fortinet.com

     • Confirm port 80 access to the Internet

  4. curl https://ipinfo.io/ip

     • Confirm port 443 access to the Internet and the public IP assigned to linux-a-vm
     • Confirm against what the Azure portal has listed as the Public IP assigned to the FortiGate

  5. ssh azureuser@<public-ip-of-fortigate>

     • From your client of choice, SSH from the Internet to the VIP assigned to linux-a-vm
     • If you do not have a SSH client installed, use the following website and scan for the SSH service.
       • Select Port Type: “Server Ports”

linux-b-vm is the www server and should have the following access:

• HTTP and HTTPS access to the Internet

• PING access to linux-a-vm

• HTTP service available from the Internet

  From the linux-b-vm CLI:

  1. ping 192.168.1.132 <– Most likely the Private IP of linux-a-vm

     • Ping the private IP of linux-a-vm and confirm replies

  2. wget www.fortinet.com

     • Confirm port 80 access to the Internet

  3. curl https://ipinfo.io/ip

     • Confirm port 443 access to the Internet and the public IP assigned to linux-b-vm
     • Confirm against what the Azure portal has listed as the Public IP assigned to the FortiGate

  4. From your local browser, open a tab and enter http://x.x.x.x:8080 - x.x.x.x is the Public IP of the FortiGate - Confirm the display of NGINX welcome screen.

If all the tests worked as expected you have successfully deployed workloads in an Azure environment and secured them with Fortinet FortiGate.

Thank you for attending Azure 102 Foundational - FortiGate