Deploy a FortiGate Firewall in Azure

Deploy and configure a FortiGate NGFW to protect a segmented Azure network.

Introduction

30 Second Summary

Every building has a security guard at the entrance deciding who gets in and who gets turned away. Cloud networks need the same thing, but instead of a person at a desk, you use a firewall that inspects every packet of traffic flowing in and out.

In this project, you will deploy a FortiGate Next-Generation Firewall in Azure, build a segmented network with three subnets, and configure firewall policies that control exactly which traffic is allowed to reach your protected resources.

What You'll Build

You will deploy a Fortinet FortiGate NGFW from the Azure Marketplace into a custom Virtual Network, route traffic through it using User-Defined Routes, and verify that your firewall policies are actively inspecting and controlling network flows.

By the end of this project, you'll have:

A three-subnet VNet architecture (External, Internal, Protected) following Fortinet's recommended Azure topology.
A FortiGate NGFW deployed from the Azure Marketplace with firewall policies controlling inbound and outbound access.
Verified traffic logs proving the firewall is actively inspecting traffic before it reaches your protected resources.
Secret Mission: Enable Web Filtering on the FortiGate to block access to specific website categories from the Protected subnet.

Are there any prerequisites?

You need an Azure account (free tier or pay-as-you-go). If you are a new Azure user, you can use the $200 free credit that comes with new accounts. All work in this project is done through the Azure Portal in your browser.

Before We Start

Before We Start...

Create the Network Foundation

Every firewall needs a network to protect. Before deploying the FortiGate, you need to build the network infrastructure it will sit inside.

In this step, you will create a Virtual Network with three purpose-built subnets. This three-subnet design is Fortinet's recommended topology for Azure deployments: one subnet faces the internet, one handles internal transit, and one holds the resources you want to protect.

In this step, get ready to:

Create a Resource Group to organize all lab resources.
Create a Virtual Network with the External and Internal subnets.
Add the Protected subnet where backend resources will live.

Create a Resource Group

A Resource Group is a container that holds all related Azure resources together. Creating one first means you can delete every resource from this lab in a single action when you are done.

Open the Azure Portal at portal.azure.com and sign in.
In the search bar at the top, type Resource groups and select it from the results.
Click Create.
In the Resource group field, enter rg-fortigate-lab.
In the Region dropdown, select a region close to you (e.g., East US).
Click Review + create, then click Create.

You should see a "Resource group created" notification in the top right corner of the portal.

Pick a consistent region

Remember which region you chose. Every resource you create in this lab must go in the same region to ensure they can communicate with each other.

Don't see the Create button?

Make sure you are on the Resource Groups page, not inside an existing resource group. The Create button appears in the top toolbar of the Resource Groups list view.

If your subscription is not visible, confirm your Azure account is active and has a valid subscription (free trial or pay-as-you-go).

Help me troubleshoot why I can't create a Resource Group in Azure.

Create a Virtual Network with the External and Internal subnets

The Virtual Network (VNet) is the private network where all your resources will live. You will divide it into subnets to separate traffic by purpose.

In the Azure Portal search bar, type Virtual networks and select it from the results.
Click Create.
Set the Resource group to rg-fortigate-lab.
In the Virtual network name field, enter vnet-fortigate-lab.
Set the Region to the same region you used for the resource group.
Click Next until you reach the IP Addresses tab.

Now configure the address space and subnets.

Set the IPv4 address space to 10.0.0.0/16. If a default address space already exists, edit it to match this value.
Delete any default subnet that was auto-created (select it and click Delete).
Click Add a subnet.
In the Name field, enter ExternalSubnet.
In the Starting address field, enter 10.0.1.0 with a size of /24 (256 addresses).
Click Add.
Click Add a subnet again.
In the Name field, enter InternalSubnet.
In the Starting address field, enter 10.0.2.0 with a size of /24.
Click Add.

Why two subnets for the FortiGate?

The ExternalSubnet maps to the FortiGate's port1 interface, which faces the internet. The InternalSubnet maps to port2, which faces your protected resources.

Separating these into distinct subnets lets the firewall inspect traffic as it crosses from one zone to another. This is the standard Fortinet-recommended topology for Azure.

Click Review + create, then click Create.

Wait for the deployment to complete. You should see a "Your deployment is complete" message.

Address space conflict?

If you see a validation error about overlapping address spaces, make sure you deleted the default subnet before adding your own. The default subnet sometimes uses an overlapping range.

Help me fix an address space conflict when creating my Virtual Network in Azure.

Add the Protected subnet

The third subnet is where your backend resources will live. Traffic from this subnet will be forced through the FortiGate for inspection before reaching the internet.

In the Azure Portal search bar, type Virtual networks and select it.
Click on vnet-fortigate-lab to open it.
In the left sidebar, click Subnets (under the Settings section).
Click + Subnet in the top toolbar.
In the Name field, enter ProtectedSubnet.
In the Subnet address range field, enter 10.0.3.0/24.
Leave all other settings at their defaults and click Save.

You should now see three subnets listed: ExternalSubnet, InternalSubnet, and ProtectedSubnet.

What is network segmentation?

By splitting your network into separate subnets, you create distinct security zones. The FortiGate sits between these zones and decides what traffic is allowed to flow between them.

Without segmentation, all resources share one flat network. A single compromised machine could talk directly to everything else. Segmentation limits the blast radius of any security incident.

Subnet won't save?

Make sure the address range 10.0.3.0/24 does not overlap with your existing subnets. If you used different ranges for the first two subnets, adjust accordingly so there is no overlap.

Help me add a ProtectedSubnet to my Azure Virtual Network.

Your network foundation is ready. You have a three-subnet architecture that separates internet-facing traffic, internal transit, and protected workloads. Next up, you will deploy the FortiGate firewall into this network.

Deploy FortiGate from the Azure Marketplace

Your network foundation is in place. Three subnets are waiting for a firewall to sit between them and control traffic.

In this step, you will deploy a FortiGate Next-Generation Firewall from the Azure Marketplace directly into your VNet. The FortiGate will connect to both the External and Internal subnets, positioning it as the gatekeeper for all traffic entering or leaving the Protected subnet.

In this step, get ready to:

Find and select the FortiGate offering in the Azure Marketplace.
Configure the FortiGate VM with networking and credentials.
Deploy the FortiGate and confirm it completes successfully.

Find FortiGate in the Marketplace

The Azure Marketplace hosts thousands of pre-packaged virtual appliances from third-party vendors. Fortinet publishes the FortiGate firewall here so you can deploy it just like any other VM.

In the Azure Portal, click Create a resource in the top-left area of the portal (or search for it in the top search bar).
In the Marketplace search box, type Fortinet FortiGate Next-Generation Firewall and press Enter.
Select the listing published by Fortinet.
Choose the Single VM deployment option.
Select the Pay As You Go (PAYG) plan.
Click Create to open the deployment wizard.

Why Pay As You Go?

The PAYG plan includes a 30-day free trial for the FortiGate software license. It also includes the UTM bundle with IPS, antivirus, and web filtering features at no extra software cost during the trial.

You will still incur Azure compute and storage charges for the VM itself. For a short lab, these are minimal.

Configure the FortiGate VM

The deployment wizard walks you through the VM's compute, credentials, and networking settings. You will connect the FortiGate's two network interfaces to the subnets you created in the previous step.

On the Basics tab, set the Resource group to rg-fortigate-lab.
Enter fg-vm-lab as the Virtual machine name.
Set the Region to the same region you chose for your resource group.
For Size, select Standard_F2s. This provides enough power for a lab environment.
Set an Admin username (for example, fgadmin).
Set a strong Admin password and confirm it. Remember these credentials because you will use them to log into the FortiGate GUI later.

Save your credentials

Write down or save your admin username and password somewhere safe. You will need them in the next step to access the FortiGate management dashboard.

Now configure the networking settings to connect the FortiGate to your VNet.

Navigate to the Networking tab (or the networking section within the wizard).
For Virtual network, select vnet-fortigate-lab.
Map port1 (the external interface) to ExternalSubnet.
Map port2 (the internal interface) to InternalSubnet.

A public IP address is automatically assigned to port1. This is what you will use to access the FortiGate management GUI from your browser.

Why two interfaces?

port1 on the External subnet faces the internet. This is where inbound traffic arrives and where the management GUI is accessible.

port2 on the Internal subnet faces your Protected workloads. Traffic from the Protected subnet routes through port2 so the FortiGate can inspect it before forwarding it outward through port1.

Review and deploy

Click Review + Create.
Azure will validate your configuration. Confirm there are no errors in the validation summary.
Click Create to begin the deployment.

The deployment takes approximately 5 minutes. You will see a progress screen while Azure provisions the VM, network interfaces, and disk resources.

Wait for the deployment to show Your deployment is complete.
Click Go to resource to open your new FortiGate VM's overview page.

Seeing a validation error?

If validation fails with a quota or size error, your subscription might not have enough vCPU quota in the selected region. Try selecting a different region, or request a quota increase from the Azure Portal under Subscriptions > Usage + quotas.

If you see a subnet conflict error, confirm that ExternalSubnet and InternalSubnet exist in your VNet with the correct address ranges.

Help me troubleshoot my FortiGate deployment validation error in Azure.

Your FortiGate firewall is now running in Azure. Next up, you will log into its management dashboard and explore the same FortiOS interface used on physical Fortinet appliances around the world.

Access the FortiGate Dashboard

Your FortiGate VM is deployed and running, but right now it's just a virtual appliance sitting in your network. To configure firewall policies and monitor traffic, you need to access the FortiGate's web-based management interface.

The FortiGate GUI runs FortiOS, the same operating system used on physical FortiGate appliances in enterprise data centers. Everything you learn in this interface transfers directly to real-world Fortinet deployments.

In this step, get ready to:

Find the FortiGate public IP address in the Azure Portal.
Log into the FortiGate web GUI using your admin credentials.
Explore the FortiGate dashboard and confirm network interface assignments.

Find the FortiGate public IP

The FortiGate's management interface is accessible through the public IP address that Azure assigned to port1 during deployment. You need to find this IP in the Azure Portal.

In the Azure Portal, click Resource groups in the left sidebar.
Select rg-fortigate-lab.
Click on the FortiGate VM (fg-vm-lab).
In the Overview section, find the Public IP address field.
Copy this IP address. You will use it to access the FortiGate GUI.

Where is the public IP?

The public IP appears in the VM's Overview blade, under the Networking section on the right side. It's the IP associated with port1 (the interface connected to the ExternalSubnet).

Don't see a public IP?

If the Public IP field shows blank or "None", the FortiGate deployment may not have attached a public IP to port1. Go to Networking on the VM blade and check that the network interface connected to ExternalSubnet has a public IP associated.

Also confirm the VM's status shows Running. A stopped VM will not display its public IP.

Help me find my FortiGate's public IP address in the Azure Portal.

Log into the FortiGate GUI

The FortiGate management interface runs over HTTPS on the public IP. Because FortiGate uses a self-signed SSL certificate by default, your browser will show a security warning. This is expected and safe for a lab environment.

Open a new browser tab.
Type https:// followed by the FortiGate public IP you copied, then press Enter.
You will see a browser certificate warning. Click Advanced (or Show Details on Safari), then click Proceed or Accept the Risk and Continue.
Enter the admin username and password you set during the FortiGate deployment in Step 2.
Click Login.

You should see the FortiGate dashboard load with several information widgets.

Why the certificate warning?

FortiGate uses a self-signed SSL certificate for its management GUI by default. Your browser cannot verify who issued this certificate, so it warns you. In a production environment, you would replace this with a certificate from a trusted Certificate Authority. For a lab, it's perfectly safe to proceed.

Can't reach the FortiGate login page?

Make sure you are using https:// (not http://). The FortiGate GUI requires HTTPS.

If the connection times out, check that the Network Security Group on the FortiGate's external interface allows inbound HTTPS (port 443). The marketplace deployment typically configures this automatically, but verify under the VM's Networking blade in Azure.

Help me troubleshoot why I cannot reach my FortiGate login page.

Explore the dashboard

The FortiGate dashboard gives you a central view of your firewall's health, interfaces, and security posture. Take a moment to orient yourself.

Find the System Information widget on the dashboard. Note the hostname, firmware version, and serial number displayed here.
Look at the Network section. You should see port1 and port2 listed with their assigned IP addresses.
Confirm that port1 shows an IP in the 10.0.1.0/24 range (the ExternalSubnet).
Confirm that port2 shows an IP in the 10.0.2.0/24 range (the InternalSubnet). This is typically 10.0.2.4. Note this IP down. You will need it later for routing configuration.
Notice the Security Fabric widget. This shows the FortiGate's integration status with other Fortinet products.

Why does the port2 IP matter?

The port2 private IP (typically 10.0.2.4) is the FortiGate's internal-facing interface. In Step 5, you will configure User-Defined Routes that point to this IP as the "next hop" for traffic leaving the Protected subnet. This is how you force all traffic through the firewall for inspection.

What is the Security Fabric?

The Security Fabric is Fortinet's ecosystem for connecting multiple security products (firewalls, switches, access points, SIEM) into a unified management layer. For this lab with a single FortiGate, you won't use it. In enterprise environments, it provides centralized visibility across an entire network.

You now have full access to the FortiGate management interface. Next up, you will deploy a test VM on the Protected subnet so you have something to protect behind this firewall.

Deploy a Test VM on the Protected Subnet

Your FortiGate firewall is deployed and ready to inspect traffic. But there is no traffic to inspect yet.

In this step, you will deploy a lightweight Linux VM on the Protected subnet. This VM simulates a backend server that the FortiGate will protect. By placing it on the ProtectedSubnet with no public IP, the only way traffic can reach it is through the firewall.

In this step, get ready to:

Create a Linux test VM in the same resource group.
Connect the VM to the Protected subnet with no public IP.
Note the VM's private IP for use in firewall policies.

Create a Linux VM

You need a machine sitting behind the firewall to generate traffic for testing. A small Ubuntu VM is perfect for this.

In the Azure Portal, click Create a resource in the top left corner.
Search for Virtual Machine and select Virtual Machine from the results.
Click Create.
Under Resource group, select rg-fortigate-lab.
In the Virtual machine name field, enter vm-protected-test.
For Image, select Ubuntu Server 24.04 LTS.
For Size, select Standard_B1s. This is the smallest burstable size and keeps costs minimal.
Under Administrator account, choose your authentication type (SSH public key or password).
Set an admin username you will remember.
If using SSH, let Azure generate a new key pair. If using password, set a strong password.

Why Standard_B1s?

The Standard_B1s is a burstable VM with 1 vCPU and 1 GB RAM. It is more than enough for a test server that only needs to send a few requests. Azure free accounts include 750 hours of B1s usage for 12 months, so this may cost you nothing.

Connect the VM to the Protected subnet

The networking configuration is the critical part. You want this VM isolated on the ProtectedSubnet with no direct internet access.

Click the Networking tab at the top of the VM creation wizard.
Under Virtual network, select vnet-fortigate-lab.
Under Subnet, select ProtectedSubnet (10.0.3.0/24).
Set Public IP to None. This VM should only be reachable through the FortiGate.
In the NIC network security group section, select Basic.
Ensure SSH (port 22) is allowed as an inbound port. This lets you connect from within the VNet later.

Why no public IP?

A public IP would let traffic reach the VM directly from the internet, bypassing the FortiGate entirely. By removing it, all traffic to and from this VM must pass through the firewall. This is exactly how protected backend servers work in production environments.

Deploy and note the private IP

Click Review + create at the bottom of the page.
Review the summary to confirm the VM is in rg-fortigate-lab, on ProtectedSubnet, and has no public IP.
Click Create.

What if Azure asks to download an SSH key?

If you chose SSH key authentication and let Azure generate a key pair, a dialog will appear asking you to download the private key file (.pem). Download it and save it somewhere safe. You will need it if you want to SSH into the VM later.

The deployment takes about 1-2 minutes.

Once the deployment completes, click Go to resource.
In the VM's Overview page, find the Private IP address field under the Networking section.
Note this IP address down. It will be something like 10.0.3.4. You will use this when configuring firewall policies in the next step.

Why is the private IP likely 10.0.3.4?

Azure reserves the first four IP addresses in every subnet for internal use (.0 for the network, .1 for the default gateway, .2 and .3 for Azure DNS). The first usable IP in the 10.0.3.0/24 subnet is 10.0.3.4.

VM deployment failed?

If you see a quota or capacity error, your subscription may not have enough vCPU quota in the selected region. Try selecting a different region, or check your subscription's usage and quotas under Subscription > Usage + quotas.

If the Standard_B1s size is not available, select another B-series size like Standard_B1ls or Standard_B2s.

Help me troubleshoot my Azure VM deployment failure.

Your test VM is now sitting on the Protected subnet, completely isolated from the public internet. Next up, you will configure routing and firewall policies so that traffic from this VM flows through the FortiGate for inspection.

Configure Routing and Firewall Policies

Your FortiGate firewall and test VM are both running, but right now traffic from the Protected subnet flows directly to the internet without touching the firewall.

Azure does not automatically route traffic through a network virtual appliance. You need to explicitly tell Azure to send Protected subnet traffic through the FortiGate using User-Defined Routes. Then you need firewall policies on the FortiGate to decide what to do with that traffic once it arrives.

In this step, get ready to:

Create a Route Table that forces Protected subnet traffic through the FortiGate.
Create a firewall policy that allows outbound internet access from the Protected subnet.
Create a deny policy that blocks ICMP (ping) traffic for verification purposes.

Create a Route Table with a UDR

Without a User-Defined Route, traffic from the Protected subnet bypasses the FortiGate entirely. A Route Table overrides Azure's default routing and tells the subnet to send traffic to a specific next hop.

In the Azure Portal search bar at the top, type Route tables and select Route tables from the results.
Click + Create.
Set Resource group to rg-fortigate-lab.
Set Name to rt-protected.
Set Region to the same region you used for your resource group (e.g., East US).
Click Review + create, then click Create.

Once the route table is created, you need to associate it with the ProtectedSubnet and add the route that points to the FortiGate.

Click Go to resource to open your new route table.
In the left menu, click Subnets.
Click + Associate.
Set Virtual network to vnet-fortigate-lab.
Set Subnet to ProtectedSubnet.
Click OK.

Now add the route that forces all outbound traffic through the FortiGate.

In the left menu of the route table, click Routes.
Click + Add.
Set Route name to to-internet.
Set Destination type to IP Addresses.
Set Destination IP addresses/CIDR ranges to 0.0.0.0/0.
Set Next hop type to Virtual appliance.
Set Next hop address to 10.0.2.4 (the FortiGate port2 IP on the InternalSubnet).
Click Add.

What does this route do?

The address prefix 0.0.0.0/0 means "all destinations." By setting the next hop to 10.0.2.4 (the FortiGate's internal interface), you are telling Azure to send every packet leaving the ProtectedSubnet to the firewall first.

Without this route, traffic from the test VM would use Azure's default route and go directly to the internet, completely bypassing your firewall.

Confirm the route appears in the Routes list with status Succeeded.

Don't see the route?

Make sure you clicked Routes in the left menu (not Subnets). Also verify you are viewing the rt-protected route table resource, not the VNet itself.

Help me troubleshoot my route table configuration.

Create an outbound firewall policy

Now that traffic from the Protected subnet is being sent to the FortiGate, you need a firewall policy that tells the FortiGate what to do with it. Without a policy, the FortiGate drops all traffic by default.

Switch to your FortiGate browser tab (the one logged into the FortiGate GUI).
In the left navigation menu, click Policy & Objects.
Click Firewall Policy.
Click + Create New.

Fill in the policy settings as follows:

Set Name to protected-to-internet.
Set Incoming Interface to port2.
Set Outgoing Interface to port1.
Set Source to all.
Set Destination to all.
Set Service to ALL.
Set Action to Accept.
Enable the NAT toggle.
Scroll down to the Logging Options section.
Set Log Allowed Traffic to All Sessions.
Click OK to save the policy.

Why enable NAT?

NAT (Network Address Translation) rewrites the source IP of outbound packets to the FortiGate's public IP. Without NAT, replies from the internet would try to route back to 10.0.3.4 directly, which is a private address that the internet cannot reach.

You should see your new protected-to-internet policy listed in the Firewall Policy table.

Policy not saving?

If you see a validation error, check that both Incoming Interface and Outgoing Interface are set. The FortiGate requires both fields to create a valid policy.

Help me troubleshoot my FortiGate firewall policy configuration.

Create a deny policy for verification

A firewall that allows everything is hard to verify. By creating a policy that specifically blocks ICMP (ping) traffic, you can prove the FortiGate is actively inspecting packets and enforcing rules.

In the FortiGate GUI, stay on the Policy & Objects > Firewall Policy page.
Click + Create New.

Fill in the deny policy settings:

Set Name to deny-test.
Set Incoming Interface to port2.
Set Outgoing Interface to port1.
Set Source to all.
Set Destination to all.
Set Service to PING (search for it in the service dropdown).
Set Action to Deny.
Enable Log Violation Traffic so denied pings appear in the logs.
Click OK to save the policy.

Why does policy order matter?

FortiGate evaluates firewall policies from top to bottom. The first policy that matches a packet wins. Your deny-test policy must sit above the protected-to-internet policy. Otherwise the broader allow-all policy would match ICMP traffic first and let it through.

You need to move the deny policy above the allow policy in the list.

On the Firewall Policy page, drag the deny-test row above the protected-to-internet row (click and hold the leftmost column of the row to drag it).
Verify that deny-test now appears above protected-to-internet in the policy list.

Can't drag the policy?

Some FortiGate GUI versions require you to right-click the policy and select Move Before instead of dragging. If drag-and-drop does not work, try right-clicking the deny-test policy row and selecting the move option.

Help me reorder my FortiGate firewall policies.

Your routing and firewall policies are now in place. Next up, you will test that traffic actually flows through the FortiGate and confirm your deny policy blocks pings as expected.

Test and Verify Traffic Flow

Your routes are in place and your firewall policies are live. Now it is time to prove that everything works.

In this step, you will connect to the test VM, generate real traffic, and check the FortiGate logs to confirm the firewall is actively inspecting every packet that crosses the Protected subnet.

In this step, get ready to:

Access the test VM command line through Azure Serial Console.
Verify that outbound traffic routes through the FortiGate.
Confirm firewall policies are filtering traffic by checking FortiGate logs.

Access the test VM through Azure Serial Console

Your test VM vm-protected-test has no public IP address. You cannot SSH into it directly from your computer.

Azure Serial Console gives you a text-based terminal session through the Azure Portal, completely independent of the VM's network connectivity.

In the Azure Portal, open Resource groups and select rg-fortigate-lab.
Click on the vm-protected-test virtual machine to open its overview page.
In the left menu, scroll down to the Help section.
Click Serial console.

A black terminal pane opens on the right side of the screen. If you see a blank screen, press Enter once or twice to trigger the login prompt.

Type the admin username you set when creating the VM and press Enter.
Type your password and press Enter. The characters will not appear as you type.

You should see a standard Ubuntu command-line prompt, confirming you are logged in.

What is Azure Serial Console?

Azure Serial Console connects directly to the VM's serial port (ttyS0). It works even when networking is completely down, which makes it perfect for reaching VMs that have no public IP.

Boot diagnostics must be enabled on the VM for Serial Console to work. Azure enables this by default when you create a VM through the portal.

Serial Console not loading?

If you see an error about boot diagnostics, go to the VM's Boot diagnostics settings under Help and make sure it is enabled.

If you used SSH key authentication (not password) when creating the VM, click Reset password in the Help section of the VM blade to set a password. Serial Console requires password-based login.

help me troubleshoot Azure Serial Console not connecting to my VM

Now that you have a terminal on the test VM, verify that outbound traffic is actually routing through the FortiGate.

Run this command to check your outbound IP address:

curl ifconfig.me

The response should display the FortiGate's public IP address. This is the same public IP you use to access the FortiGate GUI.

Why does this prove traffic is routing through the FortiGate?

The curl ifconfig.me command asks an external service to report which IP address contacted it. If the response shows the FortiGate's public IP instead of a different Azure IP, it means the test VM's traffic left through the FortiGate's external interface.

This confirms that your User-Defined Route is working correctly. All traffic from the Protected subnet is being forwarded to the FortiGate's port2 interface before reaching the internet.

Seeing 'Connection timed out' instead of an IP?

Make sure the protected-to-internet policy in the FortiGate GUI has NAT enabled. Without NAT, return traffic cannot find its way back to the VM.

Also verify the route table rt-protected is associated with ProtectedSubnet and the next hop address matches the FortiGate port2 IP (10.0.2.4).

help me figure out why my test VM cannot reach the internet through the FortiGate

Test the deny policy

You confirmed the FortiGate allows general traffic through. Now test that it can also block traffic based on your deny policy.

In the same Serial Console session, run this command:

ping 8.8.8.8

The ping should hang with no replies. After a few seconds, press Ctrl+C to stop it.

Why does the ping fail?

Your deny-test firewall policy is positioned above the protected-to-internet allow policy. The FortiGate evaluates policies from top to bottom. Because deny-test matches ICMP (ping) traffic first, it blocks the packets before they ever reach the allow policy.

This is how a Next-Generation Firewall gives you granular control. You can allow broad categories of traffic while selectively blocking specific protocols, ports, or applications.

Ping is actually succeeding?

Check the policy order in the FortiGate GUI under Policy & Objects > Firewall Policy. The deny-test policy must be above protected-to-internet. If it is below, drag it above the allow policy and try again.

Also confirm that the deny-test policy has Service set to PING and Action set to Deny.

help me troubleshoot why my FortiGate deny policy is not blocking ping traffic

Check the FortiGate logs

The real power of a firewall is visibility. The FortiGate logs every session that matches a policy, giving you a full audit trail.

Switch to the browser tab with the FortiGate GUI.
In the left menu, click Log & Report.
Click Forward Traffic.

You should see log entries for both the allowed and denied traffic you just generated.

Look for an entry with action accept that shows HTTP or HTTPS traffic from source 10.0.3.4. This is the curl command you ran.
Look for an entry with action deny that shows ICMP traffic from source 10.0.3.4. This is the ping command.
Click on any log entry to expand it. Notice the details: source IP, destination IP, policy name, action taken, and bytes transferred.

What do these logs tell you?

Each log entry proves that traffic from the Protected subnet passed through the FortiGate for inspection. The policy column shows which rule matched the traffic. The action column confirms whether it was allowed or blocked.

In a production environment, these logs feed into a SIEM (Security Information and Event Management) system for real-time alerting and compliance reporting.

Not seeing any log entries?

Logs can take 30 to 60 seconds to appear. Click the refresh icon in the top right of the Forward Traffic view.

If logs still do not appear, verify that both firewall policies have logging enabled. Edit each policy and confirm Log Allowed Traffic is set to All Sessions on the allow policy, and logging is enabled on the deny policy.

help me find my FortiGate forward traffic logs

Secret mission

Enable Web Filtering

Your firewall can do more than just allow or deny traffic by port. In this Secret Mission, you'll enable FortiGate's Web Filtering feature to block entire categories of websites from the Protected subnet.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The FortiGate VM and test VM incur hourly Azure compute charges even when idle, so leaving them running will cost money.

Cost warning

The FortiGate PAYG plan includes a 30-day free software trial, but Azure compute and storage charges still apply. Expect approximately $1-3/day depending on your VM sizes and region. If you are done with the lab, delete the resource group to stop all charges immediately.

Resources you used:

1 FortiGate VM (PAYG, billed hourly for Azure compute).
1 Linux test VM (Standard_B1s).
1 Virtual Network with 3 subnets (ExternalSubnet, InternalSubnet, ProtectedSubnet).
1 Public IP address.
1 Route Table.
Associated NSGs and disks.

Keep everything running

No action needed. Choose this if you are still actively experimenting with your FortiGate lab and want to try more policies or configurations.

Leave all resources running in your rg-fortigate-lab resource group.
Monitor your spending in Azure Cost Management to avoid surprises.
Expect approximately $1-3/day depending on VM sizes and region.

Pause - I'll come back to this later

Deallocate both VMs to stop compute charges. Storage charges still apply but are minimal. You can restart them later to continue the lab.

In the Azure Portal, go to your rg-fortigate-lab resource group.
Click on the FortiGate VM (fg-vm-lab), then click Stop to deallocate it.
Repeat for the test VM (vm-protected-test).
When you are ready to resume, click Start on both VMs.

Delete - I don't want to use this again

Remove all project resources in one action by deleting the entire resource group. This stops all charges immediately.

In the Azure Portal, go to Resource Groups.
Select rg-fortigate-lab.
Click Delete resource group.
Type rg-fortigate-lab to confirm, then click Delete.
This removes all VMs, the VNet, public IP, route table, NSGs, and disks in one step.

Nice Work!

You just deployed an enterprise-grade FortiGate firewall in Azure and built a segmented network from scratch.

You've learned how to:

Designed a three-subnet VNet architecture and deployed a FortiGate NGFW from the Azure Marketplace using the PAYG free trial.
Configured User-Defined Routes and firewall policies to steer and control traffic between the internet and a protected backend VM.
Verified traffic inspection through FortiGate logs, proving the firewall actively filters traffic based on your policies.
Enabled Web Filtering to enforce category-based access control from the Protected subnet.

Ready to quiz yourself?