Because default outbound access for VMs in Azure will be retired on 30 September 2025, I want to take a look how this works at all and how we can transition to an explicit method of public connectivity and disable default outbound access that’s already recommended by Microsoft.


Table Of Contents
  1. How default outbound access for VMs in Azure works
  2. Transition to an explicit method of public connectivity
  3. Links


How default outbound access for VMs in Azure works

In Azure, virtual machines created in a virtual network without explicit outbound connectivity defined, a default outbound public IP address is assigned. This IP address enables outbound connectivity from the resources to the Internet. This access is referred to as default outbound access.

Examples of explicit outbound connectivity are virtual machines:

  • Created within a subnet associated to a NAT gateway.
  • In the backend pool of a standard load balancer with outbound rules defined.
  • In the backend pool of a basic public load balancer.
  • Virtual machines with public IP addresses explicitly associated to them.


The public IPv4 address used for the access is called the default outbound access IP. This IP is implicit and belongs to Microsoft. This IP address is subject to change and it’s not recommended to depend on it for production workloads.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access


  • Secure by default
    • It’s not recommended to open a virtual network to the Internet by default using the zero trust network security principle.
  • Explicit vs. implicit
    • It’s recommended to have explicit methods of connectivity instead of implicit when granting access to resources in your virtual network.
  • Loss of IP address
    • Customers don’t own the default outbound access IP. This IP may change, and any dependency on it could cause issues in the future.


Source: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access#why-is-disabling-default-outbound-access-recommended


In order to show how default outbound access for VMs in Azure works, I will create a new virtual network and virtual machine for this purpose.


Creating a new Virtual Network


By the way you have now the option when creating a new virtual network to deploy it to a so called edge zone. More about you will find in the following article from Microsoft.

What is Azure public MEC?
Azure public multi-access edge compute (MEC) sites are small-footprint extensions of Azure. They’re placed in or near mobile operators’ data centers in metro areas, and are designed to run workloads that require low latency while being attached to the mobile network. Azure public MEC is offered in partnership with the operators. The placement of the infrastructure offers lower latency for applications that are accessed from mobile devices connected to the 5G mobile network.
https://learn.microsoft.com/en-us/azure/public-multi-access-edge-compute-mec/overview



In the Security tab we can add the following services to enhance the security of our virtual network. About how to use the Azure Firewall service we will see further down in this post.

What is Azure Bastion?
https://learn.microsoft.com/en-us/azure/bastion/bastion-overview

What is Azure Firewall?
https://learn.microsoft.com/en-us/azure/firewall/overview

What is Azure DDoS Protection?
https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview


Here I will also add a subnet to my new virtual network in which we place later our virtual machine. We can also add here a NAT gateway for the subnet. In order to show how default outbound access for VMs in Azure works, for now I will first not add a NAT gateway to this subnet. Using a NAT gateway for outbound internet access we will see further down in this post.


More about the Azure NAT gateway you will find in the following article from Microsoft and also further down in this post.

What is Azure NAT Gateway?
https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview


Even there is not explicitly assigned a route table for this subnet, Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. 

If there are conflicting route assignments, user-defined routes will override the default routes.

Source: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview


In order to see the Azure system default routes, you can either use the Azure CLI and its az network cmdlet or the Azure Portal like shown below.

To use the Azure CLI you can either open on your computer the Windows Command Prompt or PowerShell and connect to your tenant and subscription. About how to install the Azure CLI you can read here.

You can also use the integrated Azure Cloud Shell in the Azure portal.

az login

# sign in with a different tenant
az login --tenant <myTenantID>

# if you have multiple subscriptions in your tenant, first set the active subscription you used for your virtual network and subnet.
az account set –subscription "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
az network nic show-effective-route-table -g MyResourceGroup -n MyNic --output table

Source: https://learn.microsoft.com/en-us/cli/azure/network/nic?view=azure-cli-latest#az-network-nic-show-effective-route-table()


Here you can see red marked the default route with the Next Hop named Internet which is used for the default outbound access in case you didn’t associate a NAT gateway or firewall to your subnet.

In case you will use a NAT gateway here, you will btw. see the same default route with the Next Hop named Internet. Only in the background the next hop is then your associated NAT gateway. We will see this further below when adding a NAT gateway to our subnet in order to transition to an explicit method of public connectivity.

Output formats for Azure CLI commands
https://learn.microsoft.com/en-us/cli/azure/format-output-azure-cli

Azure Command-Line Interface (CLI) documentation
https://learn.microsoft.com/en-us/cli/azure/


For using the Azure Portal, select your virtual machine and click within the Network section on Network settings and here on the network interface. (vm001869_z1 in my case).


On the menu from the network interface click within the Help section on Effective routes to see the routes for your virtual machine.

Here you can also see red marked the default route with the Next Hop named Internet which is used for the default outbound access in case you didn’t associate a NAT gateway or firewall to your subnet.


More about how routing in Azure works, you will find in my following post.

Azure VNet Routing





Creating a new Virtual Machine

To demonstrate default outbound access for VMs in Azure, I will create a new dedicated virtual machine in our previously created virtual network and subnet where we didn’t have associated any NAT gateway, firewall or load balancer to.


To demonstrate default outbound access for VMs in Azure, we of course also didn’t associate any public IP to the network interface of our virtual machine.

The virtual machine will have only a private IP address associated to.




As you can see in the screenshot below, even we didn’t have associated any public IP to our virtual machine, nor we have associated a NAT gateway, firewall or load balancer to the subnet our virtual machine was placed in, we are nevertheless able to connect to the DNS server from Google (IP 8.8.8.8 or 8.8.4.4) by using the good old telnet tool to connect to TCP port 53.

TCP port 53 will be used by DNS servers for zone transfers. Telnet is here just capable to connect to the DNS server by performing a TCP 3-way handshake on the given port.

To query DNS servers by default UDP port 53 will be used.

So Telnet is always a great tool to check network connectivity for TCP based services.


We can also check from the command line which public IP address our virtual machine is using for outbound internet access by executing the following command for example and shown below.

dig TXT +short o-o.myaddr.l.google.com @ns1.google.com


So for the default outbound access in my case the virtual machine is using so far the public IP 4.231.17.10.

As mentioned to the beginning, this IP for default outbound access is implicit, belongs to Microsoft and is subject to change. Regarding my experience, the IP is changed in any case if you stop and start the virtual machine.


This IP address belongs to the system routes which as mentioned to the beginning Azure created automatically and will assign them to each subnet in a virtual network by default.

You can’t create system routes, nor can you remove system routes, but you can override some system routes with custom routes. Azure creates default system routes for each subnet, and adds more optional default routes to specific subnets, or every subnet, when you use specific Azure capabilities.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#system-routes


This exactly is the default outbound access for VMs in Azure which will be retired on 30 September 2025 regarding the following article https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/.


Below we will see multiple ways to turn off default outbound access and using an explicit method of public connectivity.



Transition to an explicit method of public connectivity

Using a NAT gateway is the recommended approach to have explicit outbound connectivity. A firewall can also be used to provide this access.

There are multiple ways to turn off default outbound access:

  • Add an explicit outbound connectivity method.
    • Associate a NAT gateway to the subnet of your virtual machine.
    • Associate a standard load balancer configured with outbound rules.
    • Associate a Basic public IP to the virtual machine’s network interface (if there’s only one network interface).
    • Associate a Standard public IP to any of the virtual machine’s network interfaces (if there are multiple network interfaces, having a single NIC with a standard public IP prevents default outbound access for the virtual machine).


Source: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access#how-can-i-transition-to-an-explicit-method-of-public-connectivity-and-disable-default-outbound-access



By using a NAT Gateway

Below I will first show the method by associate a NAT gateway to my existing subnet which we created previously. Therefore I first need to create a new NAT gateway.


Here you can choose between a adding at least one public IP address or in case you need more than one you can create a public IP prefix where dependent on the prefix you will have multiple public IP addresses.

A public IP address prefix is a reserved range of public IP addresses in Azure. Public IP prefixes are assigned from a pool of addresses in each Azure region. You create a public IP address prefix in an Azure region and subscription by specifying a name and prefix size. The prefix size is the number of addresses available for use. Public IP address prefixes consist of IPv4 or IPv6 addresses. In regions with Availability Zones, Public IP address prefixes can be created as zone-redundant or associated with a specific availability zone. After the public IP prefix is created, you can create public IP addresses.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-address-prefix



In the Subnet tab we can and must already associate at least one subnet with the NAT gateway.




In the NAT gateway blade under Outbound IP we can determine the public IP address which is used for outbound internet access.


Here you can see and select the virtual network and subnets the NAT gateway will be used for.


You can also assign directly in the virtual networks blade under Subnets a NAT gateway.



At this point we can check again from the command line which public IP address our virtual machine is now using for outbound internet access by executing the following command we previously already used.

This time it must be the public outbound IP from our NAT Gateway we associated to the subnet our virtual machine was placed to.

dig TXT +short o-o.myaddr.l.google.com @ns1.google.com


Looks good!




By using a Load Balancer

We can also transition to an explicit method of public connectivity by using a public load balancer.

A public load balancer can provide outbound connections for virtual machines (VMs) inside your virtual network. These connections are accomplished by translating their private IP addresses to public IP addresses. Public Load Balancers are used to load balance internet traffic to your VMs.

Source: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#publicloadbalancer

What is Azure Load Balancer?
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#publicloadbalancer


To demonstrate outbound connections by using a public load balancer I will first create a new load balancer for my virtual network and virtual machine.


In order to provide outbound connections to the internet we need to select for the type Public. Under SKU I will use by default Standard.

Choose Standard Load Balancer network load balancing when extreme performance is required coupled with low latency. Choose Gateway Load Balancer to deploy, scale, and run third party appliances in Azure with ease.

More about Gateway Load Balancer you will find in the following article from Microsoft.
https://learn.microsoft.com/en-us/azure/load-balancer/gateway-overview


Here we need to add a frontend IP configuration.


When adding a frontend IP configuration we can choose again as previously for the NAT Gateway between a single public IP address used for the load balancer or by using an IP prefix for multiple public IP addresses.

I will use here also a single public IP address.

Further we need to set the routing preference and can choose between Microsoft Network (aka cold potato) or Internet (aka hot potato). I will choose Microsoft network.

In a nutshell, Microsoft Network aka cold potato means here that the network traffic is routed as long as possible within the Microsoft network before passing it over to the destination in another network. Internet aka hot potato means here that the network traffic will be passed as quickly as possible from the Microsoft network to another network (autonomous system) and finally to the destination.

More about hot potato vs. cold potato you will find in my following post
https://blog.matrixpost.net/hot-potato-vs-cold-potato-routing/


I will not chain a Gateway Load Balancer to my frontend IP Configuration and leave the selection to None.



For the backend pool I will add my dedicated previously created virtual machine.


First I need to add my virtual network and second I will add my virtual machine.



The inbound rules we can skip and just need to create outbound rules.


For the outbound rules I need to select my previously created public frontend IP and my backend pool with the virtual network and virtual machine.

Select public IP addresses or prefixes to be used for outbound traffic. Each public IP address provides 64,000 SNAT ports. Add more IP addresses to increase the number of ports available per instance in the backend pool.

When using default port allocation, Azure may drop existing connections when you scale out. Manually allocate ports to avoid dropped connections.


So under Port allocation I will leave the default setting for Manually choose number of outbound ports.

Adjust the outbound ports according to the amount of instances you have. In my case where I have one public IP address and just one instance, I have the full port range per IP with 64.000 ports.





So from now on the virtual machine should also use the explicit method of public connectivity by using this load balancer for outbound internet access instead the default outbound access for VMs in Azure which will be retired on 30 September 2025.


In order to check if my virtual machine is really using the load balancer for outbound internet access, I will first check which public IP the load balancer is using. You can determine the public IP by clicking on Frontend IP configuration in the Settings menu for the load balancer as shown below.

So in my case this is 20.71.20.193.


In order to determine later which resources the load balancer will use for outbound internet access, you can click on the Backend pools in theSettings from the load balancer.


But now finally to check if the virtual machine is using the load balancer for outbound internet access, I will use again the dig command.

dig TXT +short o-o.myaddr.l.google.com @ns1.google.com


The public IP from my load balancer is 20.71.20.193 as determined previously.

Looks good!




By using a Firewall

Another method to transition to an explicit method of public connectivity is by using the Azure Firewall service.

Azure Firewall uses a static public IP address for your virtual network resources allowing outside firewalls to identify traffic originating from your virtual network.

Azure Firewall’s initial throughput capacity is 2.5 – 3 Gbps and it scales out to 30 Gbps for Standard SKU and 100 Gbps for Premium SKU. It scales out automatically based on CPU usage and throughput.


Azure Firewall is a cloud-native and intelligent network firewall security service that provides the best of breed threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. It provides both east-west and north-south traffic inspection. To learn what’s east-west and north-south traffic, see East-west and north-south traffic.

In a nutshell, North-south refers to the traffic that flows in and out of a datacenter and East-west traffic refers to traffic between or within data centers.

Azure Firewall is offered in three SKUs: Standard, Premium, and Basic.

Source: https://learn.microsoft.com/en-us/azure/firewall/overview


To demonstrate outbound connections by using the Azure Firewall service, I will first create a new Azure Firewall for my virtual network and virtual machine.



When creating the Azure Firewall we first need to select one of the available SKUs: Basic, Standard or Premium.

Depending on the selected SKU, we can create one of the following firewall policy tiers with default settings.

Azure Firewall supports Basic, Standard, and Premium policies.

Basic policy -> NAT rules, Application rules, IP Groups, Threat Intelligence (alerts)

Standard policy -> NAT rules, Network rules, Application rules, Custom DNS, DNS proxy, IP Groups, Web Categories, Threat Intelligence

Premium policy -> All Standard feature support, plus: TLS Insprection, Web Categories, URL Filtering, IDPS



Error: The virtual network must have a subnet named AzureFirewallSubnet

We need to deploy a dedicated subnet in which we place our Azure Firewall.
Further the subnet must be named AzureFirewallSubnet.


For production deployments, a hub and spoke model is recommended, where the firewall is in its own VNet. The workload servers are in peered VNets in the same region with one or more subnets.

Source: https://learn.microsoft.com/en-us/azure/firewall/tutorial-firewall-deploy-portal


Actually I just wanted to demonstrate outbound internet access by using the Azure Firewall service for my Linux VM, but I think it’s a good idea to directly demonstrate the recommended hub and spoke model for production deployments by using a dedicated virtual network and subnet, just for the Azure Firewall service, which is a so called Hub virtual network and later peering it with the workloads virtual network where my Linux VM was placed to, the workloads virtual network is here the so called Spoke virtual network.

In a nutshell the hub and spoke model is:

A hub is a central network zone that controls and inspects ingress or egress traffic between zones: internet, on-premises, and spokes. The hub-and-spoke topology gives your IT department an effective way to enforce security policies in a central location. It also reduces the potential for misconfiguration and exposure.
Source: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/hub-spoke-network-topology

The Spoke is the network zone which includes your workloads and is peered with the HUB network. These workloads can be such as Production or Non-production. Systems in the Spoke network will consume common service components from the HUB network like for example the Azure Firewall, VPN Gateways, Azure Bastion, ….

Hub-spoke architecture refers to site interconnects. You’ve got a central hub (location) that all other sites connect to. All traffic between sites runs through the hub. 


So first I will create a new dedicated virtual network and subnet for the Azure Firewall service and name it HUB-VNet


Under the IP Addresses tab I will use the suggested default address space. The suggested default subnet address range I will change from 10.1.0.0/24 into 10.1.1.0/24. Finally it doesn’t matter but as I wanted to add a further dedicated subnet, just for the Azure Firewall service, I will use therefore the 10.1.0.0/26 subnet later.

I will not add here directly the dedicated subnet for the Azure Firewall service as we can enable the Azure Firewall for this virtual network in the Security tab next in where we also configure the subnet for the Azure Firewall.


As mentioned here in the Security tab we can directly enable and create the Azure Firewall service for our virtual network. I will provide here the subnet address space with 10.1.0.0/26 for the dedicated Azure Firewall subnet. Further I need to create a new public static IP address for the Azure Firewall.

Enabling here the Azure Firewall will create by default a standard tier (or SKU). We can change this later and I will show it further down in this post.

The size of the AzureFirewallSubnet subnet is /26.
Azure Firewall must provision more virtual machine instances as it scales. A /26 address space ensures that the firewall has enough IP addresses available to accommodate the scaling.

For more information about the subnet size, see Azure Firewall FAQ.




When I will now go to my new Hub virtual network and subnets, you can see that the mandatory name for the Azure Firewall subnet is set by default to AzureFirewallSubnet.


For the firewall there is a separate menu item within the virtual network.


When clicking on the firewall above you will get to the Azure Firewall service blade.

The private IP address we can see already on the overview page.


In order to see the static public IP address we can click on Public IP configuration or the link on the right top.


So my static public IP address for the Azure Firewall is 20.126.202.251.


After peering my workload virtual network (so called Spoke network), in which my Linux VM was placed to, the VM should be using this IP for outbound internet access. We will check this later.

Unfortunately I can’t rename my workloads virtual network named VNet-001, which is in this scenario the Spoke network, so I will create also a new virtual network for in order to get a better understanding and to distinguish both networks. This virtual network I will now name SPOKE-VNet.


I will use the suggested address space and default subnet in which I will place my virtual Linux machine.


For the Spoke virtual network I won’t add any security services.


Below you can see that by default for DDOS protection a basic plan will be added at no additional cost. More about DDoS protection in Azure you will find in the following articles from Microsoft.

What is Azure DDoS Protection?
https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview

About Azure DDoS Protection tier Comparison
https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-sku-comparison


Finally I will create a new virtual Linux machine which I will place then into the new Spoke virtual network. Like previously for my existing Linux VM, I will of course also not assign any public IP address to it.

Unfortunately we also cannot just move a virtual machine from one VNet into another, but you can keep the virtual hard disk and attach it later to a new created virtual machine.



Add Peering

So now in order my new Linux VM which was placed into the new virtual network named SPOKE-VNet, can access the internet by using the Azure Firewall from the HUB-VNet, I first have to configure the peering between those two networks.

The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure. Like traffic between virtual machines in the same network, traffic is routed through Microsoft’s private network only.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview


I will configure the peering on the Spoke virtual network and its peering settings where my Linux VM was placed to, but we can also use the peering settings from the HUB virtual network, it doesn’t really matter on which side you will configure it.


Below you will see also the notification (blue highlighted) that you just need to configure the peering on one of the virtual networks and its settings you want to peer, by selecting the remote network, Azure will create both peering links.

For peering to work, two peering links must be created. By selecting remote virtual network, Azure will create both peering links.

The checkboxes with the gateways we can leave blank as the Azure Firewall is not a gateway in term of Azure virtual networks. Allow gateway here is a peering property that lets one virtual network use the VPN gateway in the peered virtual network for cross-premises or VNet-to-VNet connectivity. 
More under https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit


Here you can see both created peering links, one in the Spoke virtual network and one in the Hub virtual network as mentioned.

Peering link in the Spoke virtual network.


Peering link in the Hub virtual network.



Add Route Table

We also need to create a default route to 0.0.0.0/0 with the virtual appliance private IP as a next hop. Therefore I will create a new route table and assign it to the subnet in the Spoke virtual network with my workloads (my Linux VM). This will override Azure’s automatically assigned default route for this subnet.

When creating a route for outbound and inbound connectivity through the firewall, a default route to 0.0.0.0/0 with the virtual appliance private IP as a next hop is sufficient. This will take care of any outgoing and incoming connections to go through the firewall. As an example, if the firewall is fulfilling a TCP-handshake and responding to an incoming request, then the response is directed to the IP address who sent the traffic. This is by design.

Source: https://learn.microsoft.com/en-us/azure/firewall/tutorial-firewall-deploy-portal#create-a-default-route



ER and VPN Gateway route propagation can be disabled on a subnet using a property on a route table. When you disable route propagation, the system doesn’t add routes to the route table of all subnets with Virtual network gateway route propagation disabled. This process applies to both static routes and BGP routes. Connectivity with VPN connections is achieved using custom routes with a next hop type of Virtual network gateway. Route propagation shouldn’t be disabled on the GatewaySubnet. The gateway will not function with this setting disabled. For details, see How to disable Virtual network gateway route propagation.

Source: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#border-gateway-protocol


After the route table is created we have so far neither routes nor associtated subnets in it.


So first I will add a default route to 0.0.0.0/0 with the virtual appliance (Azure Firewall) private’s IP as a next hop.

The private IP from the Azure Firwall we can see on the overview page of the Azure Firewall blade in the Azure Portal.


We can also use the Azure CLI (version 2.50.0 or higher) to determine the private IP address of the Azure Firewall.

# determine the Azure CLI version
az --version

# first we need to install the azure-firewall extension if not already done
az extension add --name azure-firwall

# list all Azure Firewalls
az network firewall list

Source: https://learn.microsoft.com/en-us/cli/azure/network/firewall?view=azure-cli-latest


To add a custom route to our route table, click on Routes and Add as shown below. Here I will add a default route to 0.0.0.0/0 with the virtual appliance (Azure Firewall) private’s IP as a next hop.



Finally I need to associate the route table to the subnet from the Spoke virtual network where I placed my workloads (my Linux VM). In case I also want to place resources in the default subnet from the Hub virtual network, and they need outbound internet access through the Azure Firwall, I also have to associate the route table to this subnet.

You shouldn’t and cannot associate the route table to the /26 subnet where the Azure Firewall service itself is placed and named AzureFirewallSubnet. This Azure Firewall service subnet itself must have the 0.0.0.0/0 route with next hop Internet.





Configure and Manage the Azure Firewall

In order our Linux VM can finally use the Azure Firewall for outbound internet access, we first need to create a new network rule which will allow outbound traffic.

Azure Firewall doesn’t allow a connection to any target IP address/FQDN unless there is an explicit rule that allows it.


As already mentioned, when we enable the Azure Firewall directly during the creation of the virtual network by checking it under the Security tab, by default the standard tier will be used for. I will show further down how we change the tier without any downtime.

Here you can see the standard tier (or SKU).



For the standard tier (or SKU) we have to use classic rules like shown below under the Rules (classic) menu from the Azure Firewall instead of a Firewall policy when using the premium tier.


Below I will add some rules in order to check later from my Linux VM the outbound internet access through the Azure Firewall.

In order to use dig command again, I will also need to allow UPD port 53 traffic to query the google DNS server.

By default the dig command uses standard UDP port 53 to query DNS servers.
Source: https://www.ibm.com/docs/en/aix/7.1?topic=d-dig-command



Now we can check if the virtual machine is using the Azure Firewall service for outbound internet access, I will use once more the dig command.

dig TXT +short o-o.myaddr.l.google.com @ns1.google.com


The public IP from my Azure Firewall service is 20.126.202.251 as shown below.


Looks good! The virtual machine is from now on using the Azure Firewall from the Hub virtual network for outbound internet access.


By the way, if we now check the effective routes again for our virtual machine resp. the associated network interface, which was placed in the subnet we added our route table with the custom default 0.0.0.0/0 route and next hop for the Azure Firewall, we can see that our custom route overwrites the by Azure automatically created default route 0.0.0.0/0 with the next hop Internet.



Network rules vs. Application rules vs. DNAT rules

Outbound connectivity can be done by using Network rules and applications rules, they will not used for inbound connectivity.

You can use a network rule when you want to filter traffic based on IP addresses, any ports, and any protocols. In contrast you can use an application rule when you want to filter traffic based on fully qualified domain names (FQDNs), URLs, and HTTP/HTTPS protocols.

Source: https://learn.microsoft.com/en-us/azure/firewall/policy-rule-sets


If you configure network rules and application rules, then network rules are applied in priority order before application rules. The rules are terminating. So, if a match is found in a network rule, no other rules are processed.

Network rules take precedence over application rules regardless of priority.

Source: https://learn.microsoft.com/en-us/azure/firewall/rule-processing#network-rules-and-applications-rules


Inbound Internet connectivity can be enabled by configuring Destination Network Address Translation (DNAT) as described in Filter inbound traffic with Azure Firewall DNAT using the Azure portal. NAT rules are applied in priority before network rules. If a match is found, the traffic is translated according to the DNAT rule and allowed by the firewall. So the traffic isn’t subject to any further processing by other network rules. For security reasons, the recommended approach is to add a specific Internet source to allow DNAT access to the network and avoid using wildcards.

Source: https://learn.microsoft.com/en-us/azure/firewall/rule-processing#dnat-rules-and-network-rules


Application rules are always processed after Network rules, which are processed after DNAT rules regardless of Rule collection group or Rule collection priority and policy inheritance.

Source: https://learn.microsoft.com/en-us/azure/firewall/rule-processing#rule-processing-using-firewall-policy


More about rule processing you will find in the following article from Microsoft.

Configure Azure Firewall rules
https://learn.microsoft.com/en-us/azure/firewall/rule-processing





Migrate to Azure Firewall Premium

As mentioned earlier we can easily migrate from the standard tier (or SKU) to Azure Firewall Premium.

You can migrate Azure Firewall Standard to Azure Firewall Premium to take advantage of the new Premium capabilities. For more information about Azure Firewall Premium features, see Azure Firewall Premium features.

The easiest way to change your Azure Firewall SKU with no downtime is to use the Change SKU feature. For more information, see Azure Firewall easy upgrade/downgrade.

Source: https://learn.microsoft.com/en-us/azure/firewall/premium-migrate


I will show below the migration by using the Change SKU feature.

Azure Firewall easy upgrade/downgrade
You can now easily upgrade your existing Firewall Standard SKU to Premium SKU and downgrade from Premium to Standard SKU.
https://learn.microsoft.com/en-us/azure/firewall/easy-upgrade


Click on the SKU.



After the migration you can see that the menu on the left has changed. There is no Rules menu anymore and you have to use instead the Firewall policy link instead as shown below.


When clicking above on the policy link, the policy blade below will be shown up. As you can see managing rules have been moved to the policy and we can also see here that our previously created classic rules were successfully migrated to the policy.

For this policy we can also create DNAT rules and application rules as mentioned further above.




Using the Azure Firewall Manager

You can use also the Azure Firewall Manger to centrally deploy and configure multiple Azure Firewall instances that span different Azure regions and subscriptions.

Azure Firewall Manager is a security management service that provides central security policy and route management for cloud-based security perimeters.


More about the Azure Firewall Manager you will find in the following documentation from Microsoft.

Azure Firewall Manager documentation
https://learn.microsoft.com/en-us/azure/firewall-manager/





Links

Default outbound access in Azure
https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access

Default outbound access for VMs in Azure will be retired— transition to a new method of internet access
https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/

What is Azure NAT Gateway?
https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview

What is Azure Load Balancer?
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#publicloadbalancer

Deploy and configure Azure Firewall using the Azure portal
https://learn.microsoft.com/en-us/azure/firewall/tutorial-firewall-deploy-portal

What is Azure Firewall?
https://learn.microsoft.com/en-us/azure/firewall/overview

Azure Firewall FAQ
https://learn.microsoft.com/en-us/azure/firewall/firewall-faq

Azure Firewall Manager documentation
https://learn.microsoft.com/en-us/azure/firewall-manager/