Publish a Web Server with Azure Firewall

Use Azure Firewall DNAT rules to expose a private web server to the internet.

Introduction

30 Second Summary

When you host a server on a private network, it's invisible to the outside world. That's great for security, but useless if you need people to actually reach it.

In this project, you will deploy an Azure Firewall with a DNAT rule that translates inbound internet traffic to a private web server. You'll prove it works by browsing to the firewall's public IP and seeing a web page served from a server that has no public IP of its own.

What You'll Build

A hub network with an Azure Firewall (Basic SKU) that publishes a private web server to the internet using Destination Network Address Translation (DNAT) rules.

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

  • A virtual network with dedicated firewall and workload subnets, plus a route table forcing traffic through the firewall.
  • An Azure Firewall Basic instance with a configured Firewall Policy and a Linux VM running a web server on a private subnet.
  • A DNAT rule that translates inbound HTTP traffic from the firewall's public IP to the VM's private IP, with end-to-end verification.
  • Secret Mission: Expose SSH access on a non-standard port, demonstrating port remapping with a restricted source IP for secure access.

Are there any prerequisites?

You'll need an active Azure subscription with billing enabled (free trial credits work). Familiarity with Azure virtual networks and subnets is helpful but not required.

Create the Virtual Network and Subnets

Before you can deploy a firewall, you need a network for it to protect. Azure Firewall sits inside a virtual network and inspects traffic flowing between subnets and the internet.

In this step, you'll create a resource group to hold all your lab resources, then build a virtual network with three subnets. Each subnet has a specific role: two are reserved for the firewall itself, and one will host your private web server.

In this step, get ready to:
  • Create a resource group to organize all lab resources.
  • Create a virtual network with three subnets for the firewall and workload.
Create the resource group

A resource group is a container that holds related Azure resources so you can manage them as a single unit. You'll put everything for this lab into one group called RG-DNAT-Lab.

  • In the search box at the top of the Azure portal, type Resource groups.
  • Select Resource groups from the search results.
  • Click + Create.
  • Select your subscription from the Subscription dropdown.
  • In the Resource group field, enter RG-DNAT-Lab.
  • For Region, select a region close to you (for example, East US or West Europe).
  • Click Review + Create.
  • Click Create.

After a few seconds, you should see a notification confirming your resource group was created. Click Go to resource group to open it.

What is a resource group?

Think of a resource group as a folder for your Azure resources. Everything inside shares the same lifecycle. When you delete the resource group at the end of this project, all the resources inside get deleted too.

Create the virtual network with three subnets

Your virtual network needs three subnets. Two are mandatory for Azure Firewall Basic, and the third will host your web server VM.

  • In the search box at the top of the portal, type Virtual networks.
  • Select Virtual networks from the search results.
  • Click + Create.

On the Basics tab, fill in the following:

  • Select your subscription from the Subscription dropdown.
  • For Resource group, select RG-DNAT-Lab.
  • In the Name field, enter VNet-DNAT-Lab.
  • For Region, select the same region you used for the resource group.
  • Click Next to proceed past the Security tab (leave defaults).
  • Click Next to reach the IP Addresses tab.

On the IP Addresses tab, configure the address space and subnets:

  • Confirm the IPv4 address space is set to 10.0.0.0/16. If a different value appears, change it to 10.0.0.0/16.
  • If a default subnet exists, select it and click the delete icon to remove it.
  • Click + Add a subnet to create the first subnet.

Add the three subnets one at a time with these exact values:

  • Subnet 1: Set Name to AzureFirewallSubnet and Starting address to 10.0.0.0 with size /26. Click Add.
  • Subnet 2: Set Name to AzureFirewallManagementSubnet and Starting address to 10.0.1.0 with size /26. Click Add.
  • Subnet 3: Set Name to Workload-SN and Starting address to 10.0.2.0 with size /24. Click Add.

Why these exact subnet names?

Azure Firewall requires a subnet named exactly AzureFirewallSubnet with a minimum size of /26. The Basic SKU also requires a second subnet named exactly AzureFirewallManagementSubnet (also minimum /26) to separate Microsoft management traffic from your customer traffic.

The Workload-SN subnet is where your web server VM will live. It uses a /24 range, giving plenty of room for the workload.

  • Click Review + create at the bottom of the page.
  • Once validation passes, click Create.

The virtual network deploys in a few seconds. Once the deployment completes, click Go to resource to open your new VNet.

  • In the left navigation menu of your VNet, click Subnets.
  • Verify you see all three subnets listed: AzureFirewallSubnet, AzureFirewallManagementSubnet, and Workload-SN.

Don't see all three subnets?

Make sure you deleted the default subnet before adding the three new ones. Overlapping address ranges will cause a validation error.

Double check that the subnet names are spelled exactly as shown. Azure Firewall will not deploy if AzureFirewallSubnet or AzureFirewallManagementSubnet are misspelled.

Help me troubleshoot my virtual network subnets

Your network foundation is ready. Next up, you'll deploy an Azure Firewall into this VNet and create the firewall policy that will hold your DNAT rules.

Deploy the Azure Firewall and Policy

Your virtual network is ready with all three subnets in place. Now you need a firewall sitting inside that network to inspect and translate traffic.

In this step, you will deploy an Azure Firewall Basic instance into your VNet, along with a Firewall Policy that will hold all your rules. You will also create two public IP addresses: one for the firewall's data traffic and one for its management traffic.

In this step, get ready to:
  • Create two Standard SKU public IP addresses for the firewall.
  • Deploy an Azure Firewall Basic instance with a Firewall Policy.
  • Note the firewall's public and private IP addresses for later steps.
Create the public IP addresses

Azure Firewall Basic requires two public IP addresses. One handles your data traffic (the IP external users will connect to), and the other handles Microsoft's internal management traffic for the firewall service.

  • In the Azure Portal search bar at the top, type Public IP addresses and select it from the results.
  • Click + Create.
  • Select your subscription.
  • For Resource group, select RG-DNAT-Lab.
  • For Region, select the same region you used for your resource group.
  • For Name, enter fw-pip.
  • For SKU, confirm it is set to Standard.
  • Leave all other defaults and click Review + create, then click Create.

Once the first public IP deploys, repeat the process to create the second one.

  • Click + Create again on the Public IP addresses page.
  • For Resource group, select RG-DNAT-Lab.
  • For Region, select the same region.
  • For Name, enter fw-mgmt-pip.
  • For SKU, confirm it is set to Standard.
  • Click Review + create, then click Create.

Why two public IPs?

Azure Firewall Basic separates your data traffic from Microsoft's internal management traffic. The management NIC handles updates and health metrics communication between the firewall and Microsoft's infrastructure.

This separation prevents management operations from competing with your production traffic for bandwidth.

Don't see Standard SKU as an option?

Basic SKU public IPs have been retired as of September 2025. The portal should default to Standard SKU for new public IPs. If you see Basic selected, switch it to Standard manually.

help me figure out why I can't create a Standard SKU public IP

Deploy the Azure Firewall

Now you will deploy the firewall itself into the AzureFirewallSubnet of your existing VNet, and create a Firewall Policy during the deployment.

  • In the Azure Portal search bar, type Firewalls and select it from the results.
  • Click + Create.
  • For Subscription, select your subscription.
  • For Resource group, select RG-DNAT-Lab.
  • For Name, enter a name for your firewall (for example, FW-DNAT-Lab).
  • For Region, select the same region you have been using.
  • For Firewall tier, select Basic.
  • For Firewall management, confirm it says Use a Firewall Policy to manage this firewall.
  • For Firewall policy, click Add new.
  • Enter fw-dnat-policy as the policy name, select your region, and confirm the Policy tier defaults to Basic.
  • Click OK to confirm the policy.
  • For Choose a virtual network, select Use existing.
  • In the Virtual network dropdown, select VNet-DNAT-Lab.
  • For Public IP address, select fw-pip from the dropdown.
  • For Management public IP address, select fw-mgmt-pip from the dropdown.
  • Click Review + create, review the summary, then click Create.

What is a Firewall Policy?

A Firewall Policy is a top-level resource that holds all your firewall rules in a structured hierarchy. It organizes rules into Rule Collection Groups, which contain Rule Collections, which contain individual rules.

This hierarchy gives you fine-grained control over rule processing order. Microsoft recommends using Firewall Policy over classic rules for all new deployments.

Deployment takes several minutes

Azure Firewall deployment typically takes 5-10 minutes. Wait for the deployment to complete before moving to the next substep. You will see a notification when it finishes.

Deployment failed?

Check that your AzureFirewallSubnet is at least /26 in size and is named exactly AzureFirewallSubnet. Also verify that AzureFirewallManagementSubnet exists and is at least /26. These names and sizes are mandatory requirements for Azure Firewall.

help me troubleshoot my Azure Firewall Basic deployment failure

Note the firewall's IP addresses

You need both the firewall's public IP and private IP for later steps. The public IP is what external users will hit. The private IP is what you will use as the next hop in routing.

  • Once deployment completes, click Go to resource (or navigate to your resource group RG-DNAT-Lab and select the firewall).
  • On the firewall's Overview page, find the Firewall public IP (fw-pip) field and note this IP address.
  • On the same Overview page, find the Firewall private IP field and note this address (it will be something like 10.0.0.4).
  • Save both IP addresses somewhere you can easily access them (a text file or sticky note works well).

Why do I need the private IP?

The firewall's private IP is its address inside your virtual network. In a later step, you will create a route table that sends all outbound traffic from the workload subnet to this private IP. This is how traffic gets forced through the firewall for inspection.

Your firewall is deployed and ready to receive rules. Next up, you will create a web server VM on the private workload subnet that the firewall will protect.

Deploy a Web Server VM on the Private Subnet

Your Azure Firewall is deployed and ready to inspect traffic. Now you need something to protect and publish.

In this step, you will deploy a Linux VM running a web server on the private Workload-SN subnet. The VM will have no public IP address of its own. The only way to reach it from the internet will be through the firewall's DNAT rule, which you will configure in a later step.

In this step, get ready to:
  • Create a Linux VM on the workload subnet with no public IP.
  • Use a cloud-init script to automatically install and start Nginx.
  • Note the VM's private IP address for the DNAT rule.
Create a Linux VM on the workload subnet

You need a web server that lives entirely on the private subnet. By giving the VM no public IP, you ensure the only inbound path from the internet is through the firewall.

  • In the Azure Portal search bar at the top, type Virtual machines.
  • Select Virtual machines from the search results.
  • Click + Create, then select Azure virtual machine.

The Create a virtual machine wizard opens on the Basics tab.

  • Under Resource group, select RG-DNAT-Lab.
  • Enter a name for your VM (for example, vm-web).
  • Set Region to the same region you used for your resource group.
  • Under Availability options, select No infrastructure redundancy required.
  • Under Security type, select Standard.
  • Under Image, select Ubuntu Server 22.04 LTS - x64 Gen2.
  • Under Size, search for and select Standard_B1s. This is a small, low-cost VM suitable for a lab web server.
  • Under Authentication type, select SSH public key.
  • Enter a username (for example, azureuser).
  • Under SSH public key source, select Generate new key pair.
  • Under Public inbound ports, select None.

Now configure the networking settings to place the VM on the private subnet with no public IP.

  • Click the Networking tab at the top of the page.
  • Under Virtual network, select VNet-DNAT-Lab.
  • Under Subnet, select Workload-SN (10.0.2.0/24).
  • Under Public IP, select None.

Why no public IP?

The entire point of this project is to publish the VM through the firewall using DNAT. If the VM had its own public IP, traffic could bypass the firewall entirely.

By removing the public IP, you force all inbound traffic to flow through the Azure Firewall, where your DNAT and filtering rules apply.

Add cloud-init custom data to install Nginx

Instead of manually logging into the VM to install a web server, you can use cloud-init to run a setup script automatically when the VM first boots. Azure passes the script to the VM at provisioning time.

  • Still in the Create a virtual machine wizard, click the Advanced tab at the top of the page.
  • Scroll down to the Custom data field.
  • Paste the following cloud-init script into the Custom data text box:
#cloud-config
package_upgrade: true
packages:
  - nginx
runcmd:
  - systemctl start nginx
  - systemctl enable nginx

What does this script do?

  • `#cloud-config` tells the VM provisioning agent to interpret this as a cloud-init configuration file.
  • `package_upgrade: true` updates all system packages on first boot.
  • `packages: - nginx` installs the Nginx web server.
  • `runcmd` starts Nginx and enables it to start automatically on future reboots.
  • Click Review + create at the bottom of the page.
  • Review the summary. Confirm that the VM uses the Workload-SN subnet and has no public IP.
  • Click Create.

What about the SSH key download prompt?

A popup will appear asking you to download the private SSH key. Click Download private key and create resource. Save the key file somewhere safe on your computer. You will need it for the Secret Mission later.

Wait for the deployment to complete. This typically takes 1-2 minutes.

Deployment failed?

  • If you see a quota error about Standard_B1s, your subscription may not have capacity in that region. Try a different region or request a quota increase.
  • If the VM fails to deploy into Workload-SN, double-check that the subnet exists in VNet-DNAT-Lab and has available address space.

help me troubleshoot my Azure VM deployment failure

Note the VM's private IP address

You need the VM's private IP address to configure the DNAT rule in a later step. The firewall will translate its public IP to this private address.

  • Once deployment completes, click Go to resource.
  • On the VM's Overview page, look at the Networking section on the right side.
  • Find the Private IP address field. It should show an address like 10.0.2.4.
  • Write this IP address down. You will use it when creating the DNAT rule.

Why is the IP 10.0.2.4?

Azure reserves the first four IP addresses in every subnet. In the Workload-SN subnet (10.0.2.0/24), addresses 10.0.2.0 through 10.0.2.3 are reserved. The first available address for your VM is 10.0.2.4.

Your private web server is deployed and running Nginx. Next, you will create a route table that forces all traffic from the workload subnet through the firewall.

Create a Route Table to Direct Traffic Through the Firewall

Your web server VM sits on a private subnet with no public IP. By default, Azure routes all outbound traffic from that subnet straight to the internet. For the firewall to inspect and translate traffic, you need to override this default route.

A User Defined Route (UDR) lets you override Azure's system routes. In this step, you will create a route table that forces all traffic from the workload subnet through the firewall's private IP address.

In this step, get ready to:
  • Create a route table with a default route pointing to the firewall.
  • Associate the route table with the Workload-SN subnet.
Create the route table
  • In the Azure Portal search bar at the top, type Route table.
  • Select Route tables from the search results.
  • Click + Create.
  • In the Create Route table form, fill in the following:
  • Resource group: Select RG-DNAT-Lab.
  • Region: Select the same region you used for your other resources.
  • Name: Enter RT-Workload.
  • Propagate gateway routes: Leave the default of Yes.
  • Click Review + create.
  • Click Create.

What is a route table?

A route table is a set of rules (called routes) that tell Azure where to send network traffic leaving a subnet. Every subnet gets Azure's default routes automatically, but a custom route table lets you override them.

By associating a route table with a subnet, you control the path packets take. In this case, you will force all traffic to pass through the firewall instead of going directly to the internet.

Add a default route pointing to the firewall

Now you need to add a route that captures all outbound traffic and redirects it to the firewall's private IP address.

  • Once the route table deployment finishes, click Go to resource to open RT-Workload.
  • In the left menu, expand Settings and select Routes.
  • Click + Add.
  • In the Add route pane, fill in the following:
  • Route name: Enter fw-default-route.
  • Destination type: Select IP Addresses.
  • Destination IP addresses/CIDR ranges: Enter 0.0.0.0/0.
  • Next hop type: Select Virtual appliance.
  • Next hop address: Enter the firewall's private IP address that you noted earlier (e.g., 10.0.0.4).
  • Click Add.

What does this route do?

The destination 0.0.0.0/0 is a catch-all that matches all traffic not covered by a more specific route. By setting the next hop type to Virtual appliance and pointing it at the firewall's private IP, you are telling Azure to send all outbound traffic from the subnet to the firewall first.

The firewall then inspects that traffic and applies its rules (including DNAT) before deciding what to do with it.

Why Virtual appliance?

Azure Firewall acts as a network virtual appliance (NVA) in your VNet. The Virtual appliance next hop type tells Azure to forward traffic to a specific IP address (the firewall) rather than sending it to the internet or dropping it.

Associate the route table with the workload subnet

The route table exists but has no effect until you associate it with a subnet. Let's attach it to Workload-SN.

  • In the RT-Workload route table, select Subnets from the left menu under Settings.
  • Click + Associate.
  • In the Associate subnet pane:
  • Virtual network: Select VNet-DNAT-Lab.
  • Subnet: Select Workload-SN.
  • Click OK.

You should see Workload-SN appear in the Subnets list of the route table. This confirms the association is active.

Don't see Workload-SN listed?

Make sure you selected VNet-DNAT-Lab as the virtual network. If you have multiple VNets in the subscription, the wrong one may be pre-selected.

Also confirm the route table is in the same region as your VNet. Route tables can only associate with subnets in the same region.

help me associate my route table with my subnet

Your route table is in place. All traffic leaving the workload subnet now flows through the firewall. Next up, you will configure the DNAT rule that tells the firewall how to translate inbound traffic to your private web server.

Configure the DNAT Rule

Your firewall is deployed and the route table is directing traffic through it. Right now, though, the firewall has no rules telling it what to do with incoming traffic.

In this step, you will add a DNAT rule that tells the firewall to translate inbound HTTP traffic on its public IP to your private web server. This is the core mechanism that publishes your internal VM to the internet without giving it a public IP.

In this step, get ready to:
  • Open the Firewall Policy and navigate to the DNAT rules section.
  • Add a DNAT rule collection that maps port 80 on the firewall's public IP to port 80 on the VM's private IP.
Open the Firewall Policy

DNAT rules live inside the Firewall Policy resource, not on the firewall itself. You will navigate to the policy you created during the firewall deployment.

  • In the Azure Portal search bar, type fw-dnat-policy and select it from the results.
  • In the left pane under Settings, select DNAT rules.

You should see an empty rules page. This is where you will add the rule collection that publishes your web server.

Add a DNAT rule collection

Azure Firewall organizes rules into a hierarchy. A Rule Collection Group contains one or more Rule Collections, and each collection contains individual rules. You will create a new rule collection inside the default DNAT group.

  • Select Add a rule collection.
  • For Name, enter rc-dnat-web.
  • For Priority, enter 100.
  • For Rule collection group, select DefaultDnatRuleCollectionGroup.

Now fill in the individual rule fields under the Rules section:

  • For Name, enter allow-http-inbound.
  • For Source type, select IP Address.
  • For Source, enter * to allow traffic from any source.
  • For Protocol, select TCP.
  • For Destination Ports, enter 80.
  • For Destination Type, select IP Address.
  • For Destination, enter the firewall's public IP address (the fw-pip value you noted earlier).
  • For Translated address, enter your VM's private IP address (e.g., 10.0.2.4).
  • For Translated port, enter 80.
  • Select Add to create the rule collection.

What does this DNAT rule do?

When a packet arrives at the firewall's public IP on port 80, the firewall rewrites the packet's destination to your VM's private IP on port 80 and forwards it. The external user never knows the private IP exists.

DNAT rules also implicitly create a corresponding network rule to allow the translated traffic through. You do not need to add a separate network rule for the forwarded packets.

How does Azure Firewall process rules?

Azure Firewall processes rules in a fixed order: DNAT rules first, then Network rules, then Application rules. This order applies regardless of rule collection group priority or policy inheritance.

DNAT rules are terminating. If the firewall finds a DNAT match, it translates the traffic and allows it. No further network rule processing occurs for that traffic.

Wait for the rule collection to finish saving. You should see rc-dnat-web listed in the DNAT rules page with the rule allow-http-inbound beneath it.

Rule collection not saving?

Make sure you selected DefaultDnatRuleCollectionGroup from the dropdown. If this field is blank, the rule collection cannot be saved.

Double check that your Destination field contains the actual public IP address of fw-pip (a numeric IP like 20.x.x.x), not the resource name.

help me troubleshoot why my Azure Firewall DNAT rule collection is not saving

Your DNAT rule is now live. The firewall knows to forward any inbound HTTP traffic on its public IP to your private web server. Next up, you will test this end-to-end by browsing to the firewall's public IP from your own machine.

Test the DNAT Rule

Your DNAT rule is configured and ready. The firewall knows to translate any HTTP traffic arriving on its public IP to your private VM's address.

Now it's time for the moment of truth. You'll open a browser on your local machine and navigate to the firewall's public IP to confirm that the private web server is reachable from the internet.

In this step, get ready to:
  • Browse to the firewall's public IP from your local machine.
  • Verify the default Nginx welcome page is served from your private VM.
Browse to the firewall's public IP

Your VM has no public IP of its own. The only way to reach it from the internet is through the Azure Firewall's public IP, where your DNAT rule intercepts the traffic and translates the destination.

  • Open any web browser on your local machine (Chrome, Edge, Firefox, Safari).
  • In the address bar, type the following URL and press Enter:
http://[[FWPIP="your firewall public IP address"]]

You should see the default Nginx welcome page with the heading Welcome to nginx! displayed in your browser.

What just happened?

Your browser sent an HTTP request to the firewall's public IP on port 80. The firewall matched this against your allow-http-inbound DNAT rule and rewrote the destination address from the firewall's public IP to the VM's private IP (10.0.2.4).

The firewall then forwarded the packet to the VM. Nginx on the VM responded with its welcome page, and the firewall relayed the response back to your browser. At no point did your browser communicate directly with the VM's private address.

Why is this secure?

The VM has no public IP, so it cannot be reached directly from the internet. All inbound traffic must pass through the firewall, where DNAT rules control exactly which ports and protocols are translated. You could add logging, threat intelligence, or additional network rules without ever changing the VM's configuration.

Not seeing the Nginx page?

If the page times out or you see a connection error, check these common causes:

  • DNAT rules can take 1-2 minutes to take effect after saving. Wait a moment and refresh the page.
  • Double-check that you copied the correct public IP. In the Azure Portal, go to your firewall resource and confirm the IP listed under Firewall public IP matches what you typed in the browser.
  • Verify that the route table RT-Workload is associated with the Workload-SN subnet. Without the route, return traffic from the VM may not flow back through the firewall.
  • Confirm your DNAT rule's translated address matches the VM's private IP exactly. Check the VM's Networking tab in the portal to verify.

help me troubleshoot why my Azure Firewall DNAT rule is not translating traffic to my private VM

You just confirmed that your private web server is accessible from the public internet, purely through a DNAT rule on the firewall. Next up, the Secret Mission challenges you to take this further by exposing SSH access on a non-standard port.

Secret mission

Expose SSH on a Non-Standard Port

Your DNAT rule publishes HTTP traffic beautifully. But what if you need remote terminal access to your private VM without exposing the standard SSH port? In this secret mission, you'll add a second DNAT rule that remaps an external non-standard port to internal SSH, making your server harder for automated scanners to find.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Azure Firewall Basic instance is the main cost driver at $0.395 per hour, so leaving resources running will accumulate charges quickly.

Cost warning

Azure Firewall Basic costs $0.395 per deployment hour. Combined with the VM and public IPs, leaving everything running costs roughly $10/day.

If you are done experimenting, delete all resources now to avoid unexpected charges on your Azure bill.

Resources you used:

  • Azure Firewall Basic instance (~$0.395/hour).
  • Linux VM (Standard_B1s) on the Workload-SN subnet (~$0.01/hour).
  • Two Standard public IP addresses (fw-pip and fw-mgmt-pip, ~$0.005/hour each).
  • Virtual network (VNet-DNAT-Lab) with three subnets.
  • Route table (RT-Workload).
  • Firewall Policy (fw-dnat-policy).
  • Resource group (RG-DNAT-Lab) containing all of the above.

Keep everything running

No action needed. Choose this if you are still actively experimenting with your DNAT rules or plan to add more configurations.

  • Your firewall will continue running and accepting inbound traffic on port 80.
  • Expect charges of approximately $10/day while the firewall is running.
  • Monitor your costs in the Azure Portal under Cost Management + Billing.

Pause - I'll come back to this later

Stop the firewall to pause billing. Your configuration is preserved, but the public IPs will be released.

  • In the Azure Portal, navigate to your firewall resource inside RG-DNAT-Lab.
  • Click Stop to deallocate the firewall.
  • Stop (deallocate) the VM as well by navigating to the VM resource and clicking Stop.
  • When you are ready to resume, go back to the firewall resource and click Allocate. You may receive a new public IP address.

Why might your public IP change?

When you stop the firewall, Azure releases its public IP addresses back to the pool. When you restart, Azure assigns new IPs from the pool. Your DNAT rule references the firewall's public IP as the destination, so you will need to update any bookmarks or tests to use the new IP.

Delete - I don't want to use this again

Remove all project resources permanently. This is the recommended option if you have finished the project.

  • In the Azure Portal, search for Resource groups in the top search bar.
  • Select RG-DNAT-Lab from the list.
  • Click Delete resource group at the top of the page.
  • Type RG-DNAT-Lab in the confirmation field to confirm deletion.
  • Click Delete.

What does deleting the resource group remove?

Deleting the resource group removes everything inside it in one action. This includes the Azure Firewall, the VM, the virtual network, both public IP addresses, the route table, and the firewall policy.

That's a Wrap!

That's a Wrap!

Nice work. You just published a private web server to the internet using Azure Firewall DNAT rules.

You've learned how to:

  • Deployed an Azure Firewall Basic instance with a Firewall Policy and configured the supporting network infrastructure (dedicated subnets, public IPs, and route tables).
  • Created a DNAT rule that translates the firewall's public IP (port 80) to a private VM's IP (port 80), publishing an internal web server to the internet without giving it direct exposure.
  • Verified end-to-end connectivity by browsing to the firewall's public IP and seeing the web page served from the private VM, confirming that DNAT rules are processed first in the rule processing order before network and application rules.
  • Added a second DNAT rule demonstrating port remapping (external 2222 to internal 22) with a restricted source IP for secure SSH access.

Ready to quiz yourself?