Azure Firewall

Contents
Azure Firewall documentation

Overview
What is Azure Firewall?
Well-Architected review of Azure Firewall
Quickstarts
Deploy with IP Groups - ARM template
Deploy with multiple addresses - ARM template
Deploy with Availability Zones - Bicep
Deploy with Availability Zones - ARM template
Tutorials
Deploy and configure
Deploy in hybrid network
Filter inbound traffic with DNAT
Samples
Azure PowerShell
Concepts
Azure Firewall Standard features
Azure Firewall Premium features
Azure Firewall preview features
IDPS signature rule categories
Azure Firewall Premium in the portal
Azure Firewall Premium certificates
Azure Firewall web categories
FQDN tags
Infrastructure FQDNs
Logs and metrics
Threat intelligence
Policy rule sets
Rule processing logic
Service tags
IP Groups
Forced tunneling
Certifications
Central management
Remote work support
FQDN in network rules
DNS Proxy details
Security baseline
FTP support
Performance
How-to guides
Deploy and configure - classic
Deploy in hybrid network - classic
Filter inbound traffic with DNAT - classic
Deploy using Azure PowerShell
Deploy policy using Azure PowerShell
Deploy in hybrid network - PowerShell
Deploy using Azure CLI
Deploy with multiple public IP
Deploy with Availability Zones
Integrate with load balancer
Application rules with SQL FQDNs
SNAT private ranges
Create IP Groups
Protect Azure Virtual Desktop
Protect Azure Kubernetes Service (AKS)
DNS settings
Monitor diagnostic logs
Azure Firewall Workbook
Deploy and configure Firewall Premium
Deploy Enterprise CA Certificates for Premium
Migrate to Azure Firewall Premium
Migrate to Premium using Terraform
Scale Outbound SNAT Ports
Add or modify rules using PowerShell
Reference
Azure CLI
Azure PowerShell
.NET
Java
Node.js
Python
REST
Azure Resource Manager
Resources
FAQ
Author templates
Azure Roadmap
Community templates
Pricing
Regional availability
What is Azure Firewall?
8/4/2022 • 13 minutes to read • Edit Online
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.
Azure Firewall is offered in two SKUs: Standard and Premium.
Azure Firewall Standard

Azure Firewall Standard provides L3-L7 filtering and threat intelligence feeds directly from Microsoft Cyber
Security. Threat intelligence-based filtering can alert and deny traffic from/to known malicious IP addresses and
domains which are updated in real time to protect against new and emerging attacks.
To learn about Firewall Standard features, see Azure Firewall Standard features.
Azure Firewall Premium

Azure Firewall Premium provides advanced capabilities include signature-based IDPS to allow rapid detection of
attacks by looking for specific patterns. These patterns can include byte sequences in network traffic, or known
malicious instruction sequences used by malware. There are more than 58,000 signatures in over 50 categories
which are updated in real time to protect against new and emerging exploits. The exploit categories include
malware, phishing, coin mining, and Trojan attacks.
To learn about Firewall Premium features, see Azure Firewall Premium features.
Azure Firewall Manager

You can use Azure Firewall Manager to centrally manage Azure Firewalls across multiple subscriptions. Firewall
Manager leverages firewall policy to apply a common set of network/application rules and configuration to the
firewalls in your tenant.
Firewall Manager supports firewalls in both VNet and Virtual WANs (Secure Virtual Hub) environments. Secure
Virtual Hubs use the Virtual WAN route automation solution to simplify routing traffic to the firewall with a few
clicks.
To learn more about Azure Firewall Manager, see Azure Firewall Manager.
Pricing and SLA

For Azure Firewall pricing information, see Azure Firewall pricing.
For Azure Firewall SLA information, see Azure Firewall SLA.
Supported regions
For the supported regions for Azure Firewall, see Azure products available by region.
What's new
To learn what's new with Azure Firewall, see Azure updates.
Known issues
Azure Firewall Standard has the following known issues:
NOTE
Any issue that applies to Standard also applies to Premium.
ISSUE DESC RIP T IO N M IT IGAT IO N
Network filtering rules for non- Network filtering rules for non- Azure Firewall uses the Standard Load
TCP/UDP protocols (for example ICMP) TCP/UDP protocols don't work with Balancer, which doesn't support SNAT
don't work for Internet bound traffic SNAT to your public IP address. Non- for IP protocols today. We're exploring
TCP/UDP protocols are supported options to support this scenario in a
between spoke subnets and VNets. future release.
Missing PowerShell and CLI support Azure PowerShell and CLI don't It's still possible to use ICMP as a
for ICMP support ICMP as a valid protocol in protocol via the portal and the REST
network rules. API. We're working to add ICMP in
PowerShell and CLI soon.
FQDN tags require a protocol: port to Application rules with FQDN tags You can use https as the port:
be set require port: protocol definition. protocol value. We're working to make
this field optional when FQDN tags are
used.
Moving a firewall to a different Moving a firewall to a different Supporting this functionality is on our
resource group or subscription isn't resource group or subscription isn't road map. To move a firewall to a
supported supported. different resource group or
subscription, you must delete the
current instance and recreate it in the
new resource group or subscription.
Threat intelligence alerts may get Network rules with destination 80/443 Create outbound filtering for 80/443
masked for outbound filtering masks threat using application rules. Or, change the
intelligence alerts when configured to threat intelligence mode to Aler t and
alert only mode. Deny .
Azure Firewall DNAT doesn't work for Azure Firewall DNAT support is limited This is a current limitation.
private IP destinations to Internet egress/ingress. DNAT
doesn't currently work for private IP
destinations. For example, spoke to
spoke.
Can't remove first public IP Each Azure Firewall public IP address is This is by design.
configuration assigned to an IP configuration. The
first IP configuration is assigned during
the firewall deployment, and typically
also contains a reference to the firewall
subnet (unless configured explicitly
differently via a template deployment).
You can't delete this IP configuration
because it would de-allocate the
firewall. You can still change or remove
the public IP address associated with
this IP configuration if the firewall has
at least one other public IP address
available to use.
Availability zones can only be Availability zones can only be This is by design.
configured during deployment. configured during deployment. You
can't configure Availability Zones after
a firewall has been deployed.
SNAT on inbound connections In addition to DNAT, connections via To preserve the original source for
the firewall public IP address (inbound) HTTP/S, consider using XFF headers.
are SNATed to one of the firewall For example, use a service such as
private IPs. This requirement today Azure Front Door or Azure Application
(also for Active/Active NVAs) to ensure Gateway in front of the firewall. You
symmetric routing. can also add WAF as part of Azure
Front Door and chain to the firewall.
SQL FQDN filtering support only in For Azure SQL Database, Azure For SQL in redirect mode (the default if
proxy mode (port 1433) Synapse Analytics, and Azure SQL connecting from within Azure), you can
Managed Instance: instead filter access using the SQL
service tag as part of Azure Firewall
SQL FQDN filtering is supported in network rules.
proxy-mode only (port 1433).
For Azure SQL IaaS:
If you're using non-standard ports,

you can specify those ports in the
application rules.
Outbound SMTP traffic on TCP port Outbound email messages that are Use authenticated SMTP relay services,
25 is blocked sent directly to external domains (like which typically connect through TCP
outlook.com and gmail.com ) on port 587, but also supports other
TCP port 25 can be blocked by Azure ports. For more information, see
platform. This is the default platform Troubleshoot outbound SMTP
behavior in Azure, Azure Firewall does connectivity problems in Azure.
not introduce any additional specific Currently, Azure Firewall may be able
restriction. to communicate to public IPs by using
outbound TCP 25, but it's not
guaranteed to work, and it's not
supported for all subscription types.
For private IPs like virtual networks,
VPNs, and Azure ExpressRoute, Azure
Firewall supports an outbound
connection of TCP port 25.
SNAT port exhaustion Azure Firewall currently supports 2496 This is a platform limitation. You can
ports per Public IP address per work around the limits by configuring
backend virtual machine scale set Azure Firewall deployments with a
instance. By default, there are two minimum of five public IP addresses
virtual machine scale set instances. So, for deployments susceptible to SNAT
there are 4992 ports per flow exhaustion. This increases the SNAT
(destination IP, destination port and ports available by five times. Allocate
protocol (TCP or UDP). The firewall from an IP address prefix to simplify
scales up to a maximum of 20 downstream permissions. For a more
instances. permanent solution, you can deploy a
NAT gateway to overcome the SNAT
port limits. This approach is supported
for VNET deployments.
For more information, see Scale SNAT

ports with Azure Virtual Network NAT.
DNAT isn't supported with Forced Firewalls deployed with Forced This is by design because of
Tunneling enabled Tunneling enabled can't support asymmetric routing. The return path
inbound access from the Internet for inbound connections goes via the
because of asymmetric routing. on-premises firewall, which hasn't seen
the connection established.
Outbound Passive FTP may not work Passive FTP establishes different An explicit SNAT configuration is
for Firewalls with multiple public IP connections for control and data planned. In the meantime, you can
addresses, depending on your FTP channels. When a Firewall with multiple configure your FTP server to accept
server configuration. public IP addresses sends data data and control channels from
outbound, it randomly selects one of different source IP addresses (see an
its public IP addresses for the source IP example for IIS). Alternatively, consider
address. FTP may fail when data and using a single IP address in this
control channels use different source situation.
IP addresses, depending on your FTP
server configuration.
Inbound Passive FTP may not work Passive FTP establishes different Preserving the original source IP
depending on your FTP server connections for control and data address is being investigated. In the
configuration channels. Inbound connections on meantime, you can configure your FTP
Azure Firewall are SNATed to one of server to accept data and control
the firewall private IP addresses to channels from different source IP
ensure symmetric routing. FTP may fail addresses.
when data and control channels use
different source IP addresses,
depending on your FTP server
configuration.
Active FTP will not work when the FTP Active FTP utilizes a PORT command This is a general limitation of Active
client must reach an FTP server across from the FTP client that directs the FTP FTP when used in conjunction with
the internet. server what IP and port to use for the client-side NAT.
data channel. This PORT command
utilizes the private IP of the client
which cannot be changed. Client-side
traffic traversing the Azure Firewall will
be NAT for Internet-based
communications, making the PORT
command seen as invalid by the FTP
server.
NetworkRuleHit metric is missing a The ApplicationRuleHit metric allows A fix is being investigated.
protocol dimension filtering based protocol, but this
capability is missing in the
corresponding NetworkRuleHit metric.
NAT rules with ports between 64000 Azure Firewall allows any port in the 1- This is a current limitation.
and 65535 are unsupported 65535 range in network and
application rules, however NAT rules
only support ports in the 1-63999
range.
Configuration updates may take five An Azure Firewall configuration update A fix is being investigated.
minutes on average can take three to five minutes on
average, and parallel updates aren't
supported.
Azure Firewall uses SNI TLS headers to If browser or server software doesn't If browser or server software doesn't
filter HTTPS and MSSQL traffic support the Server Name Indicator support SNI, then you may be able to
(SNI) extension, you can't connect control the connection using a
through Azure Firewall. network rule instead of an application
rule. See Server Name Indication for
software that supports SNI.
Can't add firewall policy tags using the Azure Firewall Policy has a patch A fix is being investigated. Or, you can
portal or Azure Resource Manager support limitation that prevents you use the Azure PowerShell cmdlet
(ARM) templates from adding a tag using the Azure Set-AzFirewallPolicy to update
portal or ARM templates. The tags.
following error is generated: Could not
save the tags for the resource.
IPv6 not currently supported If you add an IPv6 address to a rule, Use only IPv4 addresses. IPv6 support
the firewall fails. is under investigation.
Updating multiple IP Groups fails with When you update two or more IP This is a known issue/limitation.
conflict error. Groups attached to the same firewall,
one of the resources goes into a failed When you update an IP Group, it
state. triggers an update on all firewalls that
the IPGroup is attached to. If an
update to a second IP Group is started
while the firewall is still in the Updating
state, then the IPGroup update fails.
To avoid the failure, IP Groups

attached to the same firewall must be
updated one at a time. Allow enough
time between updates to allow the
firewall to get out of the Updating
state.
Removing RuleCollectionGroups using Removing a RuleCollectionGroup using This is not a supported operation.
ARM templates not supported. ARM templates is not supported and
results in failure.
DNAT rule for allow any (*) will SNAT If a DNAT rule allows any (*) as the This is a current limitation.
traffic. Source IP address, then an implicit
Network rule will match VNet-VNet
traffic and will always SNAT the traffic.
Adding a DNAT rule to a secured This results in an asynchronous route Not supported.
virtual hub with a security provider is for the returning DNAT traffic, which
not supported. goes to the security provider.
Error encountered when creating more The maximal number of This is a current limitation.
than 2000 rule collections. NAT/Application or Network rule
collections is 2000 (Resource Manager
limit).
Unable to see Network Rule Name in Azure Firewall network rule log data Network rule name logging is in
Azure Firewall Logs does not show the Rule name for preview. For for information, see Azure
network traffic. Firewall preview features.
XFF header in HTTP/S XFF headers are overwritten with the A fix is being investigated.
original source IP address as seen by
the firewall. This is applicable for the
following use cases:
- HTTP requests
- HTTPS requests with TLS termination
Can't upgrade to Premium with You can't currently upgrade to Azure Deploy a new Premium firewall in
Availability Zones in the Southeast Firewall Premium with Availability Southeast Asia without Availability
Asia region Zones in the Southeast Asia region. Zones, or deploy in a region that
supports Availability Zones.
Can’t deploy Firewall with Availability When you deploy a Firewall with First create a new zone redundant
Zones with a newly created Public IP Availability Zones, you can’t use a Public IP address, then assign this
address newly created Public IP address. previously created IP address during
the Firewall deployment.

Azure Firewall Premium has the following known issues:
ESNI support for FQDN resolution in Encrypted SNI isn't supported in Today only Firefox supports ESNI
HTTPS HTTPS handshake. through custom configuration.
Suggested workaround is to disable
this feature.
Client Certification Authentication is Client certificates are used to build a None

not supported mutual identity trust between the
client and the server. Client certificates
are used during a TLS negotiation.
Azure firewall renegotiates a
connection with the server and has no
access to the private key of the client
certificates.
QUIC/HTTP3 QUIC is the new major version of HTTP. Configure passing UDP 80/443 as
It's a UDP-based protocol over 80 network rules.
(PLAN) and 443 (SSL). FQDN/URL/TLS
inspection won't be supported.
Untrusted customer signed certificates Customer signed certificates are not A fix is being investigated.
trusted by the firewall once received
from an intranet-based web server.
Wrong source IP address in Alerts with When plain text HTTP traffic is in use, A fix is being investigated.
IDPS for HTTP (without TLS and IDPS issues a new alert, and the
inspection). destination is a public IP address, the
displayed source IP address is wrong
(the internal IP address is displayed
instead of the original IP address).
Certificate Propagation After a CA certificate is applied on the A fix is being investigated.

firewall, it may take between 5-10
minutes for the certificate to take
effect.
TLS 1.3 support TLS 1.3 is partially supported. The TLS Updates are being investigated.
tunnel from client to the firewall is
based on TLS 1.2, and from the firewall
to the external Web server is based on
TLS 1.3.
KeyVault Private Endpoint KeyVault supports Private Endpoint A fix is being investigated.
access to limit its network exposure.
Trusted Azure Services can bypass this
limitation if an exception is configured
as described in the KeyVault
documentation. Azure Firewall is not
currently listed as a trusted service and
can't access the Key Vault.
Availability Zones for Firewall Premium You can't currently deploy Azure Deploy the firewall in Southeast Asia
in the Southeast Asia region Firewall Premium with Availability without Availability Zones, or deploy in
Zones in the Southeast Asia region. a region that supports Availability
Zones.
Next steps
Quickstart: Create an Azure Firewall and a firewall policy - ARM template
Quickstart: Deploy Azure Firewall with Availability Zones - ARM template
Tutorial: Deploy and configure Azure Firewall using the Azure portal
Learn module: Introduction to Azure Firewall
Quickstart: Create an Azure Firewall and IP Groups
- ARM template
In this quickstart, you use an Azure Resource Manager template (ARM template) to deploy an Azure Firewall
with sample IP Groups used in a network rule and application rule. An IP Group is a top-level resource that
allows you to define and group IP addresses, ranges, and subnets into a single object. This is useful for
managing IP addresses in Azure Firewall rules. You can either manually enter IP addresses or import them from
a file.
An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for
your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment
without writing the sequence of programming commands to create the deployment.
If your environment meets the prerequisites and you're familiar with using ARM templates, select the Deploy to
Azure button. The template will open in the Azure portal.
Prerequisites
An Azure account with an active subscription. Create an account for free.
Review the template

This template creates an Azure Firewall and IP Groups, along with the necessary resources to support the Azure
Firewall.
The template used in this quickstart is from Azure Quickstart Templates.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"virtualNetworkName": {
"type": "string",
"defaultValue": "[concat('vnet', uniqueString(resourceGroup().id))]",
"metadata": {
"description": "virtual network name"
}
},
"ipgroups_name1": {
"defaultValue": "[concat('ipgroup1', uniqueString(resourceGroup().id))]",
"type": "String"
},
"ipgroups_name2": {
"defaultValue": "[concat('ipgroup2', uniqueString(resourceGroup().id))]",
"type": "String"
},
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"location": {
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_D2s_v3",
"metadata": {
"description": "Zone numbers e.g. 1,2,3."
}
},
"numberOfFirewallPublicIPAddresses": {
"type": "int",
"defaultValue": 1,
"minValue": 1,
"maxValue": 100,
"metadata": {
"description": "Number of public IP addresses for the Azure Firewall"
}
},
"authenticationType": {
"type": "string",
"defaultValue": "sshPublicKey",
"allowedValues": [
"sshPublicKey",
"password"
],
"metadata": {
"description": "Type of authentication to use on the Virtual Machine. SSH key is recommended."
}
},
"adminPasswordOrKey": {
"type": "securestring",
"metadata": {
"description": "SSH Key or password for the Virtual Machine. SSH key is recommended."
}
}
},
"variables": {
"vnetAddressPrefix": "10.0.0.0/16",
"serversSubnetPrefix": "10.0.2.0/24",
"azureFirewallSubnetPrefix": "10.0.1.0/24",
"jumpboxSubnetPrefix": "10.0.0.0/24",
"nextHopIP": "10.0.1.4",
"azureFirewallSubnetName": "AzureFirewallSubnet",
"jumpBoxSubnetName": "JumpboxSubnet",
"serversSubnetName": "ServersSubnet",
"jumpBoxPublicIPAddressName": "JumpHostPublicIP",
"jumpBoxNsgName": "JumpHostNSG",
"jumpBoxNicName": "JumpHostNic",
"jumpBoxSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
parameters('virtualNetworkName'), variables('jumpBoxSubnetName'))]",
"serverNicName": "ServerNic",
"serverSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
parameters('virtualNetworkName'), variables('serversSubnetName'))]",
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sajumpbox')]",
"azfwRouteTableName": "AzfwRouteTable",
"firewallName": "firewall1",
"publicIPNamePrefix": "publicIP",
"azureFirewallSubnetId": "
[resourceId('Microsoft.Network/virtualNetworks/subnets',parameters('virtualNetworkName'),
variables('azureFirewallSubnetName'))]",
"azureFirewallSubnetJSON": "[json(format('{{\"id\": \"{0}\"}}', variables('azureFirewallSubnetId')))]",
"copy": [
{
"name": "azureFirewallIpConfigurations",
"count": "[parameters('numberOfFirewallPublicIPAddresses')]",
"input": {
"name": "[concat('IpConf', copyIndex('azureFirewallIpConfigurations'))]",
"properties": {
"subnet": "[if(equals(copyIndex('azureFirewallIpConfigurations'), 0),
variables('azureFirewallSubnetJSON'), json('null'))]",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
concat(variables('publicIPNamePrefix'), add(copyIndex('azureFirewallIpConfigurations'), 1)))]"
}
}
}
}
],
"linuxConfiguration": {
"disablePasswordAuthentication": true,
"ssh": {
"publicKeys": [
{
"path": "[concat('/home/', parameters('adminUsername'), '/.ssh/authorized_keys')]",
"keyData": "[parameters('adminPasswordOrKey')]"
}
]
}
},
"networkSecurityGroupName": "[concat(variables('serversSubnetName'), '-nsg')]"
},
"resources": [
{
"type": "Microsoft.Network/ipGroups",
"apiVersion": "2020-06-01",
"name": "[parameters('ipgroups_name1')]",
"location": "[parameters('location')]",
"properties": {
"ipAddresses": [
"13.73.64.64/26",
"13.73.208.128/25",
"52.126.194.0/23"
]
}
},
{
"type": "Microsoft.Network/ipGroups",
"apiVersion": "2020-06-01",
"name": "[parameters('ipgroups_name2')]",
"properties": {
"ipAddresses": [
"12.0.0.0/24",
"13.9.0.0/24"
]
}
},
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2019-06-01",
"name": "[variables('storageAccountName')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2",
"properties": {}
},
{
"type": "Microsoft.Network/routeTables",
"apiVersion": "2020-06-01",
"name": "[variables('azfwRouteTableName')]",
"properties": {
"disableBgpRoutePropagation": false,
"routes": [
{
"name": "AzfwDefaultRoute",
"properties": {
"addressPrefix": "0.0.0.0/0",
"nextHopType": "VirtualAppliance",
"nextHopIpAddress": "[variables('nextHopIP')]"
}
}
]
}
},
{
"comments": "Simple Network Security Group for subnet [variables('serversSubnetName')]",
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "[variables('networkSecurityGroupName')]",
"properties": {}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-06-01",
"name": "[parameters('virtualNetworkName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/routeTables', variables('azfwRouteTableName'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"tags": {
"displayName": "[parameters('virtualNetworkName')]"
},
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('jumpBoxSubnetName')]",
"properties": {
"addressPrefix": "[variables('jumpboxSubnetPrefix')]"
}
},
{
"name": "[variables('azureFirewallSubnetName')]",
"properties": {
"addressPrefix": "[variables('azureFirewallSubnetPrefix')]"
}
},
{
"name": "[variables('serversSubnetName')]",
"properties": {
"addressPrefix": "[variables('serversSubnetPrefix')]",
"routeTable": {
"id": "[resourceId('Microsoft.Network/routeTables', variables('azfwRouteTableName'))]"
},
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-06-01",
"name": "[concat(variables('publicIPNamePrefix'), add(copyIndex(), 1))]",
"sku": {
"name": "Standard"
},
"copy": {
"name": "publicIpCopy",
"count": "[parameters('numberOfFirewallPublicIPAddresses')]"
},
"properties": {
"publicIPAllocationMethod": "Static",
"publicIPAddressVersion": "IPv4"
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('jumpBoxPublicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('jumpBoxNsgName')]",
"properties": {
"securityRules": [
{
"name": "myNetworkSecurityGroupRuleSSH",
"properties": {
"protocol": "Tcp",
"sourcePortRange": "*",
"destinationPortRange": "22",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 1000,
"direction": "Inbound"
}
}
]
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "[variables('JumpBoxNicName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', variables('jumpBoxPublicIPAddressName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('jumpBoxNsgName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
variables('jumpBoxPublicIPAddressName'))]"
},
},
"subnet": {
"id": "[variables('jumpBoxSubnetId')]"
}
}
}
],
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('jumpBoxNsgName'))]"
}
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('ServerNicName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]"
],
"properties": {
{
"properties": {
"subnet": {
"id": "[variables('serverSubnetId')]"
}
}
}
]
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "JumpBox",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('JumpBoxNicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage"
}
},
"osProfile": {
"computerName": "JumpBox",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPasswordOrKey')]",
"linuxConfiguration": "[if(equals(parameters('authenticationType'), 'password'), json('null'),
variables('linuxConfiguration'))]"
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('JumpBoxNicName'))]"
}
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
}
},
{
"apiVersion": "2020-06-01",
"name": "Server",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('ServerNicName'))]"
],
"properties": {
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage"
}
},
"osProfile": {
"computerName": "Server",
"adminPassword": "[parameters('adminPasswordOrKey')]",
"linuxConfiguration": "[if(equals(parameters('authenticationType'), 'password'), json('null'),
variables('linuxConfiguration'))]"
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('ServerNicName'))]"
}
]
},
"enabled": true,
}
}
}
},
{
"type": "Microsoft.Network/azureFirewalls",
"apiVersion": "2020-06-01",
"name": "[variables('firewallName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/ipGroups', parameters('ipgroups_name1'))]",
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]",
"publicIpCopy"
],
],
"properties": {
"ipConfigurations": "[variables('azureFirewallIpConfigurations')]",
"applicationRuleCollections": [
{
"name": "appRc1",
"properties": {
"priority": 101,
"action": {
"type": "Allow"
},
"rules": [
{
"name": "someAppRule",
"protocols": [
{
"protocolType": "Http",
"port": 8080
}
],
"targetFqdns": [
"*bing.com"
],
"sourceIpGroups": [
"[resourceId('Microsoft.Network/ipGroups', parameters('ipgroups_name1'))]"
]
},
{
"name": "someOtherAppRule",
"protocols": [
{
"protocolType": "Mssql",
"port": 1433
}
],
"targetFqdns": [
"[concat('sql1', environment().suffixes.sqlServerHostname)]"
],
"sourceIpGroups": [
]
}
]
}
}
],
"networkRuleCollections": [
{
"name": "netRc1",
"properties": {
"priority": 200,
"action": {
"type": "Allow"
},
"rules": [
{
"name": "networkRule",
"description": "desc1",
"protocols": [
"UDP",
"TCP",
"ICMP"
],
"sourceAddresses": [
"10.0.0.0",
"111.1.0.0/23"
],
"sourceIpGroups": [
],
"destinationIpGroups": [
],
"destinationPorts": [
"90"
]
}
]
}
}
]
}
}
]
}
Multiple Azure resources are defined in the template:

Microsoft.Network/ipGroups
Microsoft.Storage/storageAccounts
Microsoft.Network/routeTables
Microsoft.Network/networkSecurityGroups
Microsoft.Network/vir tualNetworks
Microsoft.Network/publicIPAddresses
Microsoft.Network/networkInterfaces
Microsoft.Compute/vir tualMachines
Microsoft.Network/azureFirewalls
Deploy the template

Deploy the ARM template to Azure:
1. Select Deploy to Azure to sign in to Azure and open the template. The template creates an Azure
Firewall, the network infrastructure, and two virtual machines.
2. In the portal, on the Create an Azure Firewall with IpGroups page, type or select the following
values:
Subscription: Select from existing subscriptions
Resource group: Select from existing resource groups or select Create new , and select OK .
Location: Select a location
Virtual Network Name: Type a name for the new virtual network (VNet)
IP Group Name 1: Type name for IP Group 1
IP Group Name 2: Type name for IP Group 2
Admin Username: Type username for the administrator user account
Authentication: Select sshPublicKey or password
Admin Password: Type an administrator password or key
3. Select I agree to the terms and conditions stated above and then select Purchase . The deployment
can take 10 minutes or longer to complete.
Review deployed resources

In the Azure portal, review the deployed resources, especially the firewall rules that use IP Groups.
To learn about the JSON syntax and properties for a firewall in a template, see Microsoft.Network azureFirewalls
template reference.
Clean up resources
When you no longer need the resources that you created with the firewall, delete the resource group. This
removes the firewall and all the related resources.
To delete the resource group, call the Remove-AzResourceGroup cmdlet:
Remove-AzResourceGroup -Name "<your resource group name>"
Next steps
Tutorial: Deploy and configure Azure Firewall in a hybrid network using the Azure portal
Quickstart: Create an Azure Firewall with multiple
public IP addresses - ARM template
In this quickstart, you use an Azure Resource Manager template (ARM template) to deploy an Azure Firewall
with multiple public IP addresses from a public IP address prefix. The deployed firewall has NAT rule collection
rules that allow RDP connections to two Windows Server 2019 virtual machines.
For more information about Azure Firewall with multiple public IP addresses, see Deploy an Azure Firewall with
multiple public IP addresses using Azure PowerShell.
Prerequisites
Review the template

This template creates an Azure Firewall with two public IP addresses, along with the necessary resources to
support the Azure Firewall.
{
"metadata": {
"_generator": {
"name": "bicep",
"version": "0.8.9.13224",
"templateHash": "15231316908103169117"
}
},
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Admin username for the backend servers"
}
},
"adminPassword": {
"type": "secureString",
"metadata": {
"description": "Password for the admin account on the backend servers"
}
},
"location": {
"type": "string",
"type": "string",
"metadata": {
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_B2ms",
"metadata": {
"description": "Size of the virtual machine."
}
}
},
"variables": {
"copy": [
{
"count": "[length(range(0, 2))]",
"input": {
"name": "[format('IpConf{0}', add(range(0, 2)[copyIndex('azureFirewallIpConfigurations')], 1))]",
"properties": {
"subnet": "[if(equals(range(0, 2)[copyIndex('azureFirewallIpConfigurations')], 0),
json(format('{{\"id\": \"{0}\"}}', variables('azureFirewallSubnetId'))), json('null'))]",
"id": "[resourceId('Microsoft.Network/publicIPAddresses', format('{0}{1}',
variables('publicIpAddressName'), add(range(0, 2)[range(0, 2)[copyIndex('azureFirewallIpConfigurations')]],
1)))]"
}
}
}
}
],
"virtualMachineName": "myVM",
"virtualNetworkName": "myVNet",
"networkInterfaceName": "net-int",
"ipConfigName": "ipconfig",
"ipPrefixName": "public_ip_prefix",
"ipPrefixSize": 31,
"publicIpAddressName": "public_ip",
"nsgName": "vm-nsg",
"firewallName": "FW-01",
"vnetPrefix": "10.0.0.0/16",
"fwSubnetPrefix": "10.0.0.0/24",
"backendSubnetPrefix": "10.0.1.0/24",
"azureFirewallSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
variables('virtualNetworkName'), 'AzureFirewallSubnet')]"
},
"resources": [
{
"copy": {
"name": "nsg",
"count": "[length(range(0, 2))]"
},
"apiVersion": "2022-01-01",
"name": "[format('{0}{1}', variables('nsgName'), add(range(0, 2)[copyIndex()], 1))]",
"properties": {
"securityRules": [
{
"name": "RDP",
"properties": {
"protocol": "Tcp",
"access": "Allow",
"priority": 300,
"priority": 300,
}
}
]
}
},
{
"type": "Microsoft.Network/publicIPPrefixes",
"apiVersion": "2022-01-01",
"name": "[variables('ipPrefixName')]",
"properties": {
"prefixLength": "[variables('ipPrefixSize')]",
},
"sku": {
"name": "Standard"
}
},
{
"copy": {
"name": "publicIPAddress",
},
"apiVersion": "2022-01-01",
"name": "[format('{0}{1}', variables('publicIpAddressName'), add(range(0, 2)[copyIndex()], 1))]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPPrefix": {
"id": "[resourceId('Microsoft.Network/publicIPPrefixes', variables('ipPrefixName'))]"
},
"idleTimeoutInMinutes": 4
},
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPPrefixes', variables('ipPrefixName'))]"
]
},
{
"apiVersion": "2022-01-01",
"name": "[variables('virtualNetworkName')]",
"properties": {
"addressSpace": {
"[variables('vnetPrefix')]"
]
},
"subnets": [
{
"name": "myBackendSubnet",
"properties": {
"addressPrefix": "[variables('backendSubnetPrefix')]",
"routeTable": {
"id": "[resourceId('Microsoft.Network/routeTables', 'rt-01')]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
],
"enableDdosProtection": false,
"enableVmProtection": false
"enableVmProtection": false
},
"dependsOn": [
"[resourceId('Microsoft.Network/routeTables', 'rt-01')]"
]
},
{
"type": "Microsoft.Network/virtualNetworks/subnets",
"apiVersion": "2022-01-01",
"name": "[format('{0}/{1}', variables('virtualNetworkName'), 'AzureFirewallSubnet')]",
"properties": {
"addressPrefix": "[variables('fwSubnetPrefix')]",
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
},
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
]
},
{
"copy": {
"name": "virtualMachine",
},
"apiVersion": "2022-03-01",
"name": "[format('{0}{1}', variables('virtualMachineName'), add(range(0, 2)[copyIndex()], 1))]",
"properties": {
},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2019-Datacenter",
"version": "latest"
},
"osDisk": {
"osType": "Windows",
"createOption": "FromImage",
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
},
"diskSizeGB": 127
}
},
"osProfile": {
"computerName": "[format('{0}{1}', variables('virtualMachineName'), add(range(0, 2)[copyIndex()],
1))]",
"adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVMAgent": true,
"enableAutomaticUpdates": true
},
"allowExtensionOperations": true
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', format('{0}{1}',
variables('networkInterfaceName'), add(range(0, 2)[range(0, 2)[copyIndex()]], 1)))]"
}
]
}
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', format('{0}{1}',
variables('networkInterfaceName'), add(range(0, 2)[range(0, 2)[copyIndex()]], 1)))]"
]
},
{
"copy": {
"name": "netInterface",
},
"apiVersion": "2022-01-01",
"name": "[format('{0}{1}', variables('networkInterfaceName'), add(range(0, 2)[copyIndex()], 1))]",
"properties": {
{
"name": "[format('{0}{1}', variables('ipConfigName'), add(range(0, 2)[copyIndex()], 1))]",
"properties": {
"subnet": {
"id": "[reference(resourceId('Microsoft.Network/virtualNetworks',
variables('virtualNetworkName'))).subnets[0].id]"
},
"primary": true
}
}
],
"enableAcceleratedNetworking": false,
"enableIPForwarding": false,
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', format('{0}{1}',
variables('nsgName'), add(range(0, 2)[range(0, 2)[copyIndex()]], 1)))]"
}
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', format('{0}{1}', variables('nsgName'),
add(range(0, 2)[range(0, 2)[copyIndex()]], 1)))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
]
},
{
"apiVersion": "2022-01-01",
"properties": {
"sku": {
"name": "AZFW_VNet",
"tier": "Standard"
},
"threatIntelMode": "Alert",
{
"name": "web",
"properties": {
"priority": 100,
"action": {
"type": "Allow"
},
"rules": [
{
"name": "wan-address",
"protocols": [
{
"port": 80
},
{
"protocolType": "Https",
"port": 443
}
],
"targetFqdns": [
"getmywanip.com"
],
"*"
]
},
{
"name": "google",
"protocols": [
{
"port": 80
},
{
"port": 443
}
],
"targetFqdns": [
"www.google.com"
],
"10.0.1.0/24"
]
},
{
"name": "wupdate",
"protocols": [
{
"port": 80
},
{
"port": 443
}
],
"fqdnTags": [
"WindowsUpdate"
],
"*"
]
}
]
}
}
],
"natRuleCollections": [
{
"name": "Coll-01",
"properties": {
"priority": 100,
"action": {
"type": "Dnat"
},
"rules": [
{
"name": "rdp-01",
"protocols": [
"TCP"
],
"translatedAddress": "10.0.1.4",
"translatedPort": "3389",
"*"
],
"destinationAddresses": [
"[reference(resourceId('Microsoft.Network/publicIPAddresses', format('{0}{1}',
variables('publicIpAddressName'), add(range(0, 2)[0], 1)))).ipAddress]"
],
"3389"
]
},
{
"name": "rdp-02",
"protocols": [
"TCP"
],
"translatedAddress": "10.0.1.5",
"*"
],
"[reference(resourceId('Microsoft.Network/publicIPAddresses', format('{0}{1}',
variables('publicIpAddressName'), add(range(0, 2)[1], 1)))).ipAddress]"
],
"3389"
]
}
]
}
}
]
},
"dependsOn": [
"publicIPAddress",
"[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'),
'AzureFirewallSubnet')]"
]
},
{
"apiVersion": "2022-01-01",
"name": "rt-01",
"properties": {
"routes": [
{
"name": "fw",
"properties": {
"nextHopIpAddress": "10.0.0.4"
}
}
]
}
}
]
}

Microsoft.Network/publicIPPrefix
Deploy the template

2. In the portal, on the Create an Azure Firewall with multiple IP public addresses page, type or
select the following values:
Subscription: Select from existing subscriptions
Resource group: Select from existing resource groups or select Create new , and select OK .
Location: Select a location
Admin Username: Type username for the administrator user account
Admin Password: Type an administrator password or key
3. Select I agree to the terms and conditions stated above and then select Purchase . The deployment
can take 10 minutes or longer to complete.
Validate the deployment

In the Azure portal, review the deployed resources. Note the firewall public IP addresses.
Use Remote Desktop Connection to connect to the firewall public IP addresses. Successful connections
demonstrates firewall NAT rules that allow the connection to the backend servers.
Clean up resources
When you no longer need the resources that you created with the firewall, delete the resource group. This
removes the firewall and all the related resources.
To delete the resource group, call the Remove-AzResourceGroup cmdlet:
Remove-AzResourceGroup -Name "<your resource group name>"
Next steps
Quickstart: Deploy Azure Firewall with Availability
Zones - Bicep
In this quickstart, you use Bicep to deploy an Azure Firewall in three Availability Zones.
Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Azure resources. It provides
concise syntax, reliable type safety, and support for code reuse. Bicep offers the best authoring experience for
your infrastructure-as-code solutions in Azure.
The Bicep file creates a test network environment with a firewall. The network has one virtual network (VNet)
with three subnets: AzureFirewallSubnet, ServersSubnet, and JumpboxSubnet. The ServersSubnet and
JumpboxSubnet subnet each have a single, two-core Windows Server virtual machine.
The firewall is in the AzureFirewallSubnet subnet, and has an application rule collection with a single rule that
allows access to www.microsoft.com .
A user-defined route points network traffic from the ServersSubnet subnet through the firewall, where the
firewall rules are applied.
For more information about Azure Firewall, see Deploy and configure Azure Firewall using the Azure portal.
Prerequisites
Review the Bicep file

This Bicep file creates an Azure Firewall with Availability Zones, along with the necessary resources to support
the Azure Firewall.
The Bicep file used in this quickstart is from Azure Quickstart Templates.
@description('virtual network name')

param virtualNetworkName string = 'test-vnet'
@description('Location for all resources.')

param location string = resourceGroup().location
@description('Username for the Virtual Machine.')

param adminUsername string
@description('Password for the Virtual Machine.')

@secure()
param adminPassword string
@description('Availability zone numbers e.g. 1,2,3.')

param availabilityZones array = [
'1'
'2'
'3'
]
@description('Number of public IP addresses for the Azure Firewall')

@minValue(1)
@maxValue(100)
param numberOfFirewallPublicIPAddresses int = 1
param numberOfFirewallPublicIPAddresses int = 1
@description('Size of the virtual machine.')

param jumpBoxSize string = 'Standard_D2s_v3'
@description('Size of the virtual machine.')

param serverSize string = 'Standard_D2s_v3'
var vnetAddressPrefix = '10.0.0.0/16'

var serversSubnetPrefix = '10.0.2.0/24'
var azureFirewallSubnetPrefix = '10.0.1.0/24'
var jumpboxSubnetPrefix = '10.0.0.0/24'
var nextHopIP = '10.0.1.4'
var azureFirewallSubnetName = 'AzureFirewallSubnet'
var jumpBoxSubnetName = 'JumpboxSubnet'
var serversSubnetName = 'ServersSubnet'
var jumpBoxPublicIPAddressName = 'JumpHostPublicIP'
var jumpBoxNsgName = 'JumpHostNSG'
var jumpBoxNicName = 'JumpHostNic'
var jumpBoxSubnetId = resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetworkName,
jumpBoxSubnetName)
var serverNicName = 'ServerNic'
var serverSubnetId = resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetworkName,
serversSubnetName)
var storageAccountName = '${uniqueString(resourceGroup().id)}sajumpbox'
var azfwRouteTableName = 'AzfwRouteTable'
var firewallName = 'firewall1'
var publicIPNamePrefix = 'publicIP'
var azureFirewallSubnetId = resourceId('Microsoft.Network/virtualNetworks/subnets', virtualNetworkName,
azureFirewallSubnetName)
var azureFirewallSubnetJSON = json('{"id": "${azureFirewallSubnetId}"}')
var networkSecurityGroupName = '${serversSubnetName}-nsg'
var azureFirewallIpConfigurations = [for i in range(0, numberOfFirewallPublicIPAddresses): {
name: 'IpConf${i}'
properties: {
subnet: ((i == 0) ? azureFirewallSubnetJSON : json('null'))
publicIPAddress: {
id: publicIPAddress[i].id
}
}
}]
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = {

name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'Storage'
properties: {}
}
resource azfwRouteTable 'Microsoft.Network/routeTables@2021-03-01' = {

name: azfwRouteTableName
location: location
properties: {
disableBgpRoutePropagation: false
routes: [
{
name: 'AzfwDefaultRoute'
properties: {
addressPrefix: '0.0.0.0/0'
nextHopType: 'VirtualAppliance'
nextHopIpAddress: nextHopIP
}
}
]
}
}
resource nsg 'Microsoft.Network/networkSecurityGroups@2021-03-01' = {
name: networkSecurityGroupName
location: location
properties: {}
}
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-05-01' = {

name: virtualNetworkName
location: location
tags: {
displayName: virtualNetworkName
}
properties: {
addressSpace: {
addressPrefixes: [
vnetAddressPrefix
]
}
subnets: [
{
name: jumpBoxSubnetName
properties: {
addressPrefix: jumpboxSubnetPrefix
}
}
{
name: azureFirewallSubnetName
properties: {
addressPrefix: azureFirewallSubnetPrefix
}
}
{
name: serversSubnetName
properties: {
addressPrefix: serversSubnetPrefix
routeTable: {
id: azfwRouteTable.id
}
networkSecurityGroup: {
id: nsg.id
}
}
}
]
}
}
resource publicIPAddress 'Microsoft.Network/publicIPAddresses@2021-03-01' = [for i in range(0,

numberOfFirewallPublicIPAddresses): {
name: '${publicIPNamePrefix}${i+1}'
location: location
sku: {
name: 'Standard'
}
properties: {
publicIPAllocationMethod: 'Static'
publicIPAddressVersion: 'IPv4'
}
zones: availabilityZones
}]
resource jumpBoxPublicIPAddress 'Microsoft.Network/publicIPAddresses@2021-03-01' = {

name: jumpBoxPublicIPAddressName
location: location
properties: {
publicIPAllocationMethod: 'Dynamic'
}
}
resource jumpBoxNsg 'Microsoft.Network/networkSecurityGroups@2021-05-01' = {
name: jumpBoxNsgName
location: location
properties: {
securityRules: [
{
name: 'myNetworkSecurityGroupRuleRDP'
properties: {
protocol: 'Tcp'
sourcePortRange: '*'
destinationPortRange: '3389'
sourceAddressPrefix: '*'
destinationAddressPrefix: '*'
access: 'Allow'
priority: 1000
direction: 'Inbound'
}
}
]
}
}
resource JumpBoxNic 'Microsoft.Network/networkInterfaces@2021-05-01' = {

name: jumpBoxNicName
location: location
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
privateIPAllocationMethod: 'Dynamic'
publicIPAddress: {
id: jumpBoxPublicIPAddress.id
}
subnet: {
id: jumpBoxSubnetId
}
}
}
]
networkSecurityGroup: {
id: jumpBoxNsg.id
}
}
dependsOn: [
virtualNetwork
]
}
resource ServerNic 'Microsoft.Network/networkInterfaces@2021-05-01' = {

name: serverNicName
location: location
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
privateIPAllocationMethod: 'Dynamic'
subnet: {
id: serverSubnetId
}
}
}
]
}
dependsOn: [
virtualNetwork
]
]
}
resource JumpBoxVM 'Microsoft.Compute/virtualMachines@2021-11-01' = {

name: 'JumpBox'
location: location
properties: {
hardwareProfile: {
vmSize: jumpBoxSize
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
sku: '2019-Datacenter'
version: 'latest'
}
osDisk: {
osType: 'Windows'
createOption: 'FromImage'
diskSizeGB: 127
}
}
osProfile: {
computerName: 'JumpBox'
adminUsername: adminUsername
adminPassword: adminPassword
}
networkProfile: {
networkInterfaces: [
{
id: JumpBoxNic.id
}
]
}
diagnosticsProfile: {
bootDiagnostics: {
enabled: true
storageUri: storageAccount.properties.primaryEndpoints.blob
}
}
}
}
resource ServerVM 'Microsoft.Compute/virtualMachines@2021-11-01' = {

name: 'Server'
location: location
properties: {
hardwareProfile: {
vmSize: serverSize
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
sku: '2019-Datacenter'
version: 'latest'
}
osDisk: {
osType: 'Windows'
createOption: 'FromImage'
diskSizeGB: 127
}
}
osProfile: {
computerName: 'Server'
adminUsername: adminUsername
adminPassword: adminPassword
}
networkProfile: {
networkProfile: {
networkInterfaces: [
{
id: ServerNic.id
}
]
}
diagnosticsProfile: {
bootDiagnostics: {
enabled: true
storageUri: storageAccount.properties.primaryEndpoints.blob
}
}
}
}
resource firewall 'Microsoft.Network/azureFirewalls@2021-05-01' = {

name: firewallName
location: location
zones: ((length(availabilityZones) == 0) ? json('null') : availabilityZones)
properties: {
ipConfigurations: azureFirewallIpConfigurations
applicationRuleCollections: [
{
name: 'appRc1'
properties: {
priority: 101
action: {
type: 'Allow'
}
rules: [
{
name: 'appRule1'
protocols: [
{
port: 80
protocolType: 'Http'
}
{
port: 443
protocolType: 'Https'
}
]
targetFqdns: [
'www.microsoft.com'
]
sourceAddresses: [
'10.0.2.0/24'
]
}
]
}
}
]
networkRuleCollections: [
{
name: 'netRc1'
properties: {
priority: 200
action: {
type: 'Allow'
}
rules: [
{
name: 'netRule1'
protocols: [
'TCP'
]
sourceAddresses: [
'10.0.2.0/24'
'10.0.2.0/24'
]
destinationAddresses: [
'*'
]
destinationPorts: [
'8000-8999'
]
}
]
}
}
]
}
dependsOn: [
virtualNetwork
publicIPAddress
]
}
Multiple Azure resources are defined in the Bicep file:

Deploy the Bicep file

1. Save the Bicep file as main.bicep to your local computer.
2. Deploy the Bicep file using either Azure CLI or Azure PowerShell.
CLI
PowerShell
az group create --name exampleRG --location eastus

az deployment group create --resource-group exampleRG --template-file main.bicep --parameters
adminUsername=<admin-user>
NOTE
Replace <admin-user> with the administrator login username for the virtual machine. You'll be prompted to
enter adminPassword .
When the deployment finishes, you should see a message indicating the deployment succeeded.

Use the Azure portal, Azure CLI, or Azure PowerShell to validate the deployment and review the deployed
resources.
CLI
CLI
PowerShell
az resource list --resource-group exampleRG
To learn about the syntax and properties for a firewall in a Bicep file, see Microsoft.Network/azureFirewalls.
Clean up resources
When you no longer need them, use the Azure portal, Azure CLI, or Azure PowerShell to remove the resource
group, firewall, and all related resources.
CLI
PowerShell
az group delete --name exampleRG
Next steps
Next, you can monitor the Azure Firewall logs.
Tutorial: Monitor Azure Firewall logs
Quickstart: Deploy Azure Firewall with Availability
Zones - ARM template
In this quickstart, you use an Azure Resource Manager template (ARM template) to deploy an Azure Firewall in
three Availability Zones.
The template creates a test network environment with a firewall. The network has one virtual network (VNet)
with three subnets: AzureFirewallSubnet, ServersSubnet, and JumpboxSubnet. The ServersSubnet and
JumpboxSubnet subnet each have a single, two-core Windows Server virtual machine.
The firewall is in the AzureFirewallSubnet subnet, and has an application rule collection with a single rule that
allows access to www.microsoft.com .
A user-defined route points network traffic from the ServersSubnet subnet through the firewall, where the
firewall rules are applied.
For more information about Azure Firewall, see Deploy and configure Azure Firewall using the Azure portal.
Prerequisites
Review the template

This template creates an Azure Firewall with Availability Zones, along with the necessary resources to support
the Azure Firewall.
{
"metadata": {
"_generator": {
"name": "bicep",
"version": "0.7.4.23292",
"templateHash": "1131141795323801257"
}
},
"parameters": {
"virtualNetworkName": {
"type": "string",
"defaultValue": "test-vnet",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
}
},
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "secureString",
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"availabilityZones": {
"type": "array",
"defaultValue": [
"1",
"2",
"3"
],
"metadata": {
"description": "Availability zone numbers e.g. 1,2,3."
}
},
"numberOfFirewallPublicIPAddresses": {
"type": "int",
"defaultValue": 1,
"maxValue": 100,
"minValue": 1,
"metadata": {
"description": "Number of public IP addresses for the Azure Firewall"
}
},
"jumpBoxSize": {
"type": "string",
"metadata": {
}
},
"serverSize": {
"type": "string",
"metadata": {
}
}
},
"variables": {
"copy": [
{
"count": "[length(range(0, parameters('numberOfFirewallPublicIPAddresses')))]",
"input": {
"name": "[format('IpConf{0}', range(0, parameters('numberOfFirewallPublicIPAddresses'))
[copyIndex('azureFirewallIpConfigurations')])]",
"properties": {
"subnet": "[if(equals(range(0, parameters('numberOfFirewallPublicIPAddresses'))
[copyIndex('azureFirewallIpConfigurations')], 0), variables('azureFirewallSubnetJSON'), json('null'))]",
variables('publicIPNamePrefix'), add(range(0, parameters('numberOfFirewallPublicIPAddresses'))[range(0,
parameters('numberOfFirewallPublicIPAddresses'))[copyIndex('azureFirewallIpConfigurations')]], 1)))]"
}
}
}
}
],
"vnetAddressPrefix": "10.0.0.0/16",
"serversSubnetPrefix": "10.0.2.0/24",
"azureFirewallSubnetPrefix": "10.0.1.0/24",
"jumpboxSubnetPrefix": "10.0.0.0/24",
"nextHopIP": "10.0.1.4",
"azureFirewallSubnetName": "AzureFirewallSubnet",
"jumpBoxSubnetName": "JumpboxSubnet",
"serversSubnetName": "ServersSubnet",
"jumpBoxPublicIPAddressName": "JumpHostPublicIP",
"jumpBoxNsgName": "JumpHostNSG",
"jumpBoxNicName": "JumpHostNic",
"jumpBoxSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
parameters('virtualNetworkName'), variables('jumpBoxSubnetName'))]",
"serverNicName": "ServerNic",
"serverSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
parameters('virtualNetworkName'), variables('serversSubnetName'))]",
"storageAccountName": "[format('{0}sajumpbox', uniqueString(resourceGroup().id))]",
"azfwRouteTableName": "AzfwRouteTable",
"firewallName": "firewall1",
"publicIPNamePrefix": "publicIP",
"azureFirewallSubnetId": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
parameters('virtualNetworkName'), variables('azureFirewallSubnetName'))]",
"azureFirewallSubnetJSON": "[json(format('{{\"id\": \"{0}\"}}', variables('azureFirewallSubnetId')))]",
"networkSecurityGroupName": "[format('{0}-nsg', variables('serversSubnetName'))]"
},
"resources": [
{
"apiVersion": "2021-08-01",
"name": "[variables('storageAccountName')]",
"sku": {
},
"kind": "Storage",
"properties": {}
},
{
"apiVersion": "2021-03-01",
"name": "[variables('azfwRouteTableName')]",
"properties": {
"routes": [
{
"name": "AzfwDefaultRoute",
"properties": {
"nextHopIpAddress": "[variables('nextHopIP')]"
}
}
]
}
},
{
"apiVersion": "2021-03-01",
"name": "[variables('networkSecurityGroupName')]",
"properties": {}
"properties": {}
},
{
"apiVersion": "2021-05-01",
"name": "[parameters('virtualNetworkName')]",
"tags": {
"displayName": "[parameters('virtualNetworkName')]"
},
"properties": {
"addressSpace": {
"[variables('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('jumpBoxSubnetName')]",
"properties": {
"addressPrefix": "[variables('jumpboxSubnetPrefix')]"
}
},
{
"name": "[variables('azureFirewallSubnetName')]",
"properties": {
"addressPrefix": "[variables('azureFirewallSubnetPrefix')]"
}
},
{
"name": "[variables('serversSubnetName')]",
"properties": {
"addressPrefix": "[variables('serversSubnetPrefix')]",
"routeTable": {
"id": "[resourceId('Microsoft.Network/routeTables', variables('azfwRouteTableName'))]"
},
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
},
"dependsOn": [
"[resourceId('Microsoft.Network/routeTables', variables('azfwRouteTableName'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
]
},
{
"copy": {
"name": "publicIPAddress",
"count": "[length(range(0, parameters('numberOfFirewallPublicIPAddresses')))]"
},
"apiVersion": "2021-03-01",
"name": "[format('{0}{1}', variables('publicIPNamePrefix'), add(range(0,
parameters('numberOfFirewallPublicIPAddresses'))[copyIndex()], 1))]",
"sku": {
"name": "Standard"
},
"properties": {
},
"zones": "[parameters('availabilityZones')]"
},
{
"apiVersion": "2021-03-01",
"name": "[variables('jumpBoxPublicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
}
},
{
"apiVersion": "2021-05-01",
"name": "[variables('jumpBoxNsgName')]",
"properties": {
"securityRules": [
{
"name": "myNetworkSecurityGroupRuleRDP",
"properties": {
"protocol": "Tcp",
"access": "Allow",
"priority": 1000,
}
}
]
}
},
{
"apiVersion": "2021-05-01",
"name": "[variables('jumpBoxNicName')]",
"properties": {
{
"properties": {
variables('jumpBoxPublicIPAddressName'))]"
},
"subnet": {
"id": "[variables('jumpBoxSubnetId')]"
}
}
}
],
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('jumpBoxNsgName'))]"
}
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('jumpBoxNsgName'))]",
"[resourceId('Microsoft.Network/publicIPAddresses', variables('jumpBoxPublicIPAddressName'))]",
]
},
{
"apiVersion": "2021-05-01",
"name": "[variables('serverNicName')]",
"properties": {
{
"properties": {
"subnet": {
"id": "[variables('serverSubnetId')]"
}
}
}
]
},
"dependsOn": [
]
},
{
"apiVersion": "2021-11-01",
"name": "JumpBox",
"properties": {
"vmSize": "[parameters('jumpBoxSize')]"
},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
"diskSizeGB": 127
}
},
"osProfile": {
"computerName": "JumpBox",
"adminPassword": "[parameters('adminPassword')]"
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('jumpBoxNicName'))]"
}
]
},
"enabled": true,
}
}
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', variables('jumpBoxNicName'))]",
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
]
},
{
"apiVersion": "2021-11-01",
"name": "Server",
"properties": {
"vmSize": "[parameters('serverSize')]"
},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
"diskSizeGB": 127
}
},
"osProfile": {
"computerName": "Server",
"adminPassword": "[parameters('adminPassword')]"
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('serverNicName'))]"
}
]
},
"enabled": true,
}
}
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', variables('serverNicName'))]",
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
]
},
{
"apiVersion": "2021-05-01",
"zones": "[if(equals(length(parameters('availabilityZones')), 0), json('null'),
parameters('availabilityZones'))]",
"properties": {
{
"name": "appRc1",
"properties": {
"priority": 101,
"action": {
"type": "Allow"
},
"rules": [
{
"name": "appRule1",
"protocols": [
{
"port": 80,
"protocolType": "Http"
},
{
"port": 443,
"protocolType": "Https"
}
}
],
"targetFqdns": [
"www.microsoft.com"
],
"10.0.2.0/24"
]
}
]
}
}
],
"networkRuleCollections": [
{
"name": "netRc1",
"properties": {
"priority": 200,
"action": {
"type": "Allow"
},
"rules": [
{
"name": "netRule1",
"protocols": [
"TCP"
],
"10.0.2.0/24"
],
"*"
],
"8000-8999"
]
}
]
}
}
]
},
"dependsOn": [
"publicIPAddress",
]
}
]
}

Deploy the template

2. In the portal, on the Create a sandbox setup of Azure Firewall with Zones page, type or select the
following values:
Resource group : Select Create new , type a name for the resource group, and select OK .
Vir tual Network Name : Type a name for the new VNet.
Admin Username : Type a username for the administrator user account.
Admin Password : Type an administrator password.
3. Read the terms and conditions, and then select I agree to the terms and conditions stated above
and then select Purchase . The deployment can take 10 minutes or longer to complete.

Explore the resources that were created with the firewall.
To learn about the JSON syntax and properties for a firewall in a template, see
Microsoft.Network/azureFirewalls.
Clean up resources
When you no longer need them, you can remove the resource group, firewall, and all related resources by
running the Remove-AzResourceGroup PowerShell command. To remove a resource group named
MyResourceGroup, run:
Remove-AzResourceGroup -Name MyResourceGroup
Don't remove the resource group and firewall if you plan to continue on to the firewall monitoring tutorial.
Next steps
Tutorial: Deploy and configure Azure Firewall and
policy using the Azure portal
Controlling outbound network access is an important part of an overall network security plan. For example, you
may want to limit access to web sites. Or, you may want to limit the outbound IP addresses and ports that can be
accessed.
One way you can control outbound network access from an Azure subnet is with Azure Firewall and Firewall
Policy. With Azure Firewall and Firewall Policy, you can configure:
Application rules that define fully qualified domain names (FQDNs) that can be accessed from a subnet.
Network rules that define source address, protocol, destination port, and destination address.
Network traffic is subjected to the configured firewall rules when you route your network traffic to the firewall
as the subnet default gateway.
For this tutorial, you create a simplified single VNet with two subnets for easy deployment.
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.
AzureFirewallSubnet - the firewall is in this subnet.
Workload-SN - the workload server is in this subnet. This subnet's network traffic goes through the firewall.
In this tutorial, you learn how to:

Set up a test network environment
Deploy a firewall and firewall policy
Create a default route
Configure an application rule to allow access to www.google.com
Configure a network rule to allow access to external DNS servers
Configure a NAT rule to allow a remote desktop to the test server
Test the firewall
If you prefer, you can complete this procedure using Azure PowerShell.
Prerequisites
If you don't have an Azure subscription, create a free account before you begin.
Set up the network

First, create a resource group to contain the resources needed to deploy the firewall. Then create a VNet,
subnets, and a test server.
Create a resource group
The resource group contains all the resources for the tutorial.
1. Sign in to the Azure portal at https://portal.azure.com.
2. On the Azure portal menu, select Resource groups or search for and select Resource groups from any
page. Then select Add .
3. For Subscription , select your subscription.
4. For Resource group name , enter Test-FW-RG.
5. For Region , select a region. All other resources that you create must be in the same region.
6. Select Review + create .
7. Select Create .
Create a VNet
This VNet will have two subnets.
NOTE
The size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall FAQ.
1. On the Azure portal menu or from the Home page, select Create a resource .
2. Select Networking .
3. Search for Vir tual network and select it.
4. Select Create .
6. For Resource group , select Test-FW-RG .
7. For Name , type Test-FW-VN .
8. For Region , select the same location that you used previously.
9. Select Next: IP addresses .
10. For IPv4 Address space , accept the default 10.0.0.0/16 .
11. Under Subnet , select default .
12. For Subnet name change the name to AzureFirewallSubnet . The firewall will be in this subnet, and
the subnet name must be AzureFirewallSubnet.
13. For Address range , type 10.0.1.0/26 .
14. Select Save .
Next, create a subnet for the workload server.
15. Select Add subnet .
16. For Subnet name , type Workload-SN .
17. For Subnet address range , type 10.0.2.0/24 .
18. Select Add .
20. Select Create .
Create a virtual machine
Now create the workload virtual machine, and place it in the Workload-SN subnet.
2. Select Windows Ser ver 2016 Datacenter .
3. Enter these values for the virtual machine:
SET T IN G VA L UE
Resource group Test-FW-RG
Virtual machine name Sr v-Work
Region Same as previous
Image Windows Server 2016 Datacenter
Administrator user name Type a user name
Password Type a password
4. Under Inbound por t rules , Public inbound por ts , select None .

5. Accept the other defaults and select Next: Disks .
6. Accept the disk defaults and select Next: Networking .
7. Make sure that Test-FW-VN is selected for the virtual network and the subnet is Workload-SN .
8. For Public IP , select None .
9. Accept the other defaults and select Next: Management .
10. Select Disable to disable boot diagnostics. Accept the other defaults and select Review + create .
11. Review the settings on the summary page, and then select Create .
12. After the deployment completes, select the Sr v-Work resource and note the private IP address for later
use.
Deploy the firewall and policy

Deploy the firewall into the VNet.
2. Type firewall in the search box and press Enter .
3. Select Firewall and then select Create .
4. On the Create a Firewall page, use the following table to configure the firewall:
SET T IN G VA L UE
Subscription <your subscription>
Name Test-FW01
Region Select the same location that you used previously
Firewall management Use a Firewall Policy to manage this firewall
Firewall policy Add new :

fw-test-pol
your selected region
Choose a virtual network Use existing : Test-FW-VN
Public IP address Add new :

Name : fw-pip
5. Accept the other default values, then select Review + create .

6. Review the summary, and then select Create to create the firewall.
This will take a few minutes to deploy.
7. After deployment completes, go to the Test-FW-RG resource group, and select the Test-FW01 firewall.
8. Note the firewall private and public IP addresses. You'll use these addresses later.

For the Workload-SN subnet, configure the outbound default route to go through the firewall.
1. On the Azure portal menu, select All ser vices or search for and select All services from any page.
2. Under Networking , select Route tables .
3. Select Add .
7. For Name , type Firewall-route .
9. Select Create .
After deployment completes, select Go to resource .
1. On the Firewall-route page, select Subnets and then select Associate .
2. Select Vir tual network > Test-FW-VN .
3. For Subnet , select Workload-SN . Make sure that you select only the Workload-SN subnet for this
route, otherwise your firewall won't work correctly.
4. Select OK .
5. Select Routes and then select Add .
6. For Route name , type fw-dg .
7. For Address prefix , type 0.0.0.0/0 .
8. For Next hop type , select Vir tual appliance .
Azure Firewall is actually a managed service, but virtual appliance works in this situation.
9. For Next hop address , type the private IP address for the firewall that you noted previously.
10. Select OK .
Configure an application rule

This is the application rule that allows outbound access to www.google.com .
1. Open the Test-FW-RG , and select the fw-test-pol firewall policy.
2. Select Application rules .
3. Select Add a rule collection .
4. For Name , type App-Coll01 .
5. For Priority , type 200 .
6. For Rule collection action , select Allow .
7. Under Rules , for Name , type Allow-Google .
8. For Source type , select IP address .
9. For Source , type 10.0.2.0/24 .
10. For Protocol:por t , type http, https .
11. For Destination Type , select FQDN .
12. For Destination , type www.google.com
13. Select Add .
Azure Firewall includes a built-in rule collection for infrastructure FQDNs that are allowed by default. These
FQDNs are specific for the platform and can't be used for other purposes. For more information, see
Infrastructure FQDNs.
Configure a network rule

This is the network rule that allows outbound access to two IP addresses at port 53 (DNS).
1. Select Network rules .
3. For Name , type Net-Coll01 .
6. For Rule collection group , select DefaultNetworkRuleCollectionGroup .
7. Under Rules , for Name , type Allow-DNS .
8. For Source type , select IP Address .
9. For Source , type 10.0.2.0/24 .
10. For Protocol , select UDP .
11. For Destination Por ts , type 53 .
12. For Destination type select IP address .
13. For Destination , type 209.244.0.3,209.244.0.4 .
These are public DNS servers operated by CenturyLink.
14. Select Add .
Configure a DNAT rule

This rule allows you to connect a remote desktop to the Srv-Work virtual machine through the firewall.
1. Select the DNAT rules .
3. For Name , type rdp .
5. For Rule collection group , select DefaultDnatRuleCollectionGroup .
6. Under Rules , for Name , type rdp-nat .
8. For Source , type * .
9. For Protocol , select TCP .
11. For Destination Type , select IP Address .
12. For Destination , type the firewall public IP address.
13. For Translated address , type the Sr v-work private IP address.
14. For Translated por t , type 3389 .
15. Select Add .
Change the primary and secondary DNS address for the Srv-Work network interface
For testing purposes in this tutorial, configure the server's primary and secondary DNS addresses. This isn't a
general Azure Firewall requirement.
page. Select the Test-FW-RG resource group.
2. Select the network interface for the Sr v-Work virtual machine.
3. Under Settings , select DNS ser vers .
4. Under DNS ser vers , select Custom .
5. Type 209.244.0.3 in the Add DNS ser ver text box, and 209.244.0.4 in the next text box.
6. Select Save .
7. Restart the Sr v-Work virtual machine.
Test the firewall

Now, test the firewall to confirm that it works as expected.
1. Connect a remote desktop to firewall public IP address and sign in to the Sr v-Work virtual machine.
2. Open Internet Explorer and browse to https://www.google.com .
3. Select OK > Close on the Internet Explorer security alerts.
You should see the Google home page.
4. Browse to https://www.microsoft.com .
You should be blocked by the firewall.
So now you've verified that the firewall rules are working:
You can browse to the one allowed FQDN, but not to any others.
You can resolve DNS names using the configured external DNS server.
Clean up resources
You can keep your firewall resources for the next tutorial, or if no longer needed, delete the Test-FW-RG
resource group to delete all firewall-related resources.
Next steps
Deploy and configure Azure Firewall Premium
Tutorial: Deploy and configure Azure Firewall and
policy in a hybrid network using the Azure portal
When you connect your on-premises network to an Azure virtual network to create a hybrid network, the ability
to control access to your Azure network resources is an important part of an overall security plan.
You can use Azure Firewall and Firewall Policy to control network access in a hybrid network using rules that
define allowed and denied network traffic.
For this tutorial, you create three virtual networks:
VNet-Hub - the firewall is in this virtual network.
VNet-Spoke - the spoke virtual network represents the workload located on Azure.
VNet-Onprem - The on-premises virtual network represents an on-premises network. In an actual
deployment, it can be connected by either a VPN or ExpressRoute connection. For simplicity, this tutorial uses
a VPN gateway connection, and an Azure-located virtual network is used to represent an on-premises
network.

Create the firewall hub virtual network
Create the spoke virtual network
Create the on-premises virtual network
Configure and deploy the firewall and policy
Create and connect the VPN gateways
Peer the hub and spoke virtual networks
Create the routes
Create the virtual machines
Test the firewall
If you want to use Azure PowerShell instead to complete this procedure, see Deploy and configure Azure
Firewall in a hybrid network using Azure PowerShell.
Prerequisites
A hybrid network uses the hub-and-spoke architecture model to route traffic between Azure VNets and on-
premises networks. The hub-and-spoke architecture has the following requirements:
Set Use this vir tual network's gateway or Route Ser ver when peering VNet-Hub to VNet-Spoke. In
a hub-and-spoke network architecture, a gateway transit allows the spoke virtual networks to share the
VPN gateway in the hub, instead of deploying VPN gateways in every spoke virtual network.
Additionally, routes to the gateway-connected virtual networks or on-premises networks will
automatically propagate to the routing tables for the peered virtual networks using the gateway transit.
For more information, see Configure VPN gateway transit for virtual network peering.
Set Use the remote vir tual network's gateways or Route Ser ver when you peer VNet-Spoke to
VNet-Hub. If Use the remote vir tual network's gateways or Route Ser ver is set and Use this
vir tual network's gateway or Route Ser ver on remote peering is also set, the spoke virtual network
uses gateways of the remote virtual network for transit.
To route the spoke subnet traffic through the hub firewall, you can use a User Defined route (UDR) that
points to the firewall with the Vir tual network gateway route propagation option disabled. The
Vir tual network gateway route propagation disabled option prevents route distribution to the
spoke subnets. This prevents learned routes from conflicting with your UDR. If you want to keep Vir tual
network gateway route propagation enabled, make sure to define specific routes to the firewall to
override those that are published from on-premises over BGP.
Configure a UDR on the hub gateway subnet that points to the firewall IP address as the next hop to the
spoke networks. No UDR is required on the Azure Firewall subnet, as it learns routes from BGP.
See the Create Routes section in this tutorial to see how these routes are created.
NOTE
Azure Firewall must have direct Internet connectivity. If your AzureFirewallSubnet learns a default route to your on-
premises network via BGP, you must override this with a 0.0.0.0/0 UDR with the NextHopType value set as Internet to
maintain direct Internet connectivity.
Azure Firewall can be configured to support forced tunneling. For more information, see Azure Firewall forced tunneling.
NOTE
Traffic between directly peered VNets is routed directly even if a UDR points to Azure Firewall as the default gateway. To
send subnet to subnet traffic to the firewall in this scenario, a UDR must contain the target subnet network prefix explicitly
on both subnets.

First, create the resource group to contain the resources for this tutorial:
2. On the Azure portal home page, select Resource groups > Create .
4. For Resource group name , type FW-Hybrid-Test .
5. For Region , select (US) East US . All resources that you create later must be in the same location.
6. Select Review + Create .
7. Select Create .
Now, create the VNet:
NOTE
1. From the Azure portal home page, select Create a resource .

2. Under Networking , select Vir tual network .
3. Select Create .
4. For Resource group , select FW-Hybrid-Test .
5. For Name , type VNet-hub .
6. Select Next: IP Addresses .
7. For IPv4 Address space , delete the default address and type 10.5.0.0/16 .
8. Under Subnet name , select Add subnet .
9. For Subnet name type AzureFirewallSubnet . The firewall will be in this subnet, and the subnet name
must be AzureFirewallSubnet.
11. Select Add .
13. Select Create .

2. In Networking , select Vir tual network .
3. Select Create .
5. For Name , type VNet-Spoke .
6. For Region , select (US) East US .
8. For IPv4 address space , delete the default address and type 10.6.0.0/16 .
10. For Subnet name type SN-Workload .
12. Select Add .
14. Select Create .

4. For Name , type VNet-OnPrem .
6. Select Next : IP Addresses
9. For Subnet name type SN-Corp .
11. Select Add .
13. Select Create .
Now create a second subnet for the gateway.
1. On the VNet-Onprem page, select Subnets .
2. Select +Subnet .
3. For Name , type GatewaySubnet .
4. For Subnet address range type 192.168.2.0/24 .
5. Select Save .
Configure and deploy the firewall

Now deploy the firewall into the firewall hub virtual network.
2. In the left column, select Networking , and search for and then select Firewall , and then select Create .
SET T IN G VA L UE
Resource group FW-Hybrid-Test
Name AzFW01
Region East US
Firewall tier Standard
Firewall policy Add new:

hybrid-test-pol
East US
Choose a virtual network Use existing:

VNet-hub
Public IP address Add new:

fw-pip

This takes a few minutes to deploy.
6. After deployment completes, go to the FW-Hybrid-Test resource group, and select the AzFW01
firewall.
7. Note the private IP address. You'll use it later when you create the default route.
Configure network rules
First, add a network rule to allow web traffic.
1. From the FW-Hybrid-Test resource group, select the hybrid-test-pol Firewall Policy.
2. Select Network rules .
3. Select Add add a rule collection .
4. For Name , type RCNet01 .
7. Under Rules , for Name , type AllowWeb .
9. For Source , type 192.168.1.0/24 .
12. For Destination type , select IP address .
13. For Destination , type 10.6.0.0/16 .
Now add a rule to allow RDP traffic.
On the second rule row, type the following information:
1. Name , type AllowRDP .
3. For Source , type 192.168.1.0/24 .
7. For Destination , type 10.6.0.0/16
8. Select Add .

The hub and on-premises virtual networks are connected via VPN gateways.
Create a VPN gateway for the hub virtual network
Now create the VPN gateway for the hub virtual network. Network-to-network configurations require a
RouteBased VpnType. Creating a VPN gateway can often take 45 minutes or more, depending on the selected
VPN gateway SKU.
2. In the search text box, type vir tual network gateway .
3. Select Vir tual network gateway , and select Create .
4. For Name , type GW-hub .
5. For Region , select the same region that you used previously.
6. For Gateway type , select VPN .
7. For VPN type , select Route-based .
8. For SKU , select Basic .
9. For Vir tual network , select VNet-hub .
10. For Public IP address , select Create new , and type VNet-hub-GW-pip for the name.
11. Accept the remaining defaults and then select Review + create .
12. Review the configuration, then select Create .
Create a VPN gateway for the on-premises virtual network
Now create the VPN gateway for the on-premises virtual network. Network-to-network configurations require a
VPN gateway SKU.
2. In the search text box, type vir tual network gateway and press Enter .
4. For Name , type GW-Onprem .
9. For Vir tual network , select VNet-Onprem .
10. For Public IP address , select Create new , and type VNet-Onprem-GW-pip for the name.
Create the VPN connections
Now you can create the VPN connections between the hub and on-premises gateways.
In this step, you create the connection from the hub virtual network to the on-premises virtual network. You'll
see a shared key referenced in the examples. You can use your own values for the shared key. The important
thing is that the shared key must match for both connections. Creating a connection can take a short while to
complete.
1. Open the FW-Hybrid-Test resource group and select the GW-hub gateway.
2. Select Connections in the left column.
3. Select Add .
4. The the connection name, type Hub-to-Onprem .
5. Select VNet-to-VNet for Connection type .
6. For the Second vir tual network gateway , select GW-Onprem .
7. For Shared key (PSK) , type AzureA1b2C3 .
8. Select OK .
Create the on-premises to hub virtual network connection. This step is similar to the previous one, except you
create the connection from VNet-Onprem to VNet-hub. Make sure the shared keys match. The connection will
be established after a few minutes.
1. Open the FW-Hybrid-Test resource group and select the GW-Onprem gateway.
3. Select Add .
4. For the connection name, type Onprem-to-Hub .
6. For the Second vir tual network gateway , select GW-hub .
8. Select OK .
Verify the connection
After about five minutes or so, the status of both connections should be Connected .
Now peer the hub and spoke virtual networks.
1. Open the FW-Hybrid-Test resource group and select the VNet-hub virtual network.
2. In the left column, select Peerings .
3. Select Add .
4. Under This vir tual network :
SET T IN G N A M E VA L UE
Peering link name HubtoSpoke
Traffic to remote virtual network Allow (default)
Traffic forwarded from remote virtual network Allow (default)
Virtual network gateway Use this virtual network's gateway
5. Under Remote vir tual network :
Peering link name SpoketoHub
Virtual network deployment model Resource manager
Virtual network VNet-Spoke
Virtual network gateway Use the remote virtual network's gateway

6. Select Add .
Create the routes

Next, create a couple routes:
A route from the hub gateway subnet to the spoke subnet through the firewall IP address
A default route from the spoke subnet through the firewall IP address
2. In the search text box, type route table and press Enter .
3. Select Route table .
4. Select Create .
5. Select the FW-Hybrid-Test for the resource group.
7. For the name, type UDR-Hub-Spoke .
9. Select Create .
10. After the route table is created, select it to open the route table page.
11. Select Routes in the left column.
12. Select Add .
13. For the route name, type ToSpoke .
14. For the Address prefix destination , select IP Addresses .
15. For the Destination IP addresses/CIDR ranges , type 10.6.0.0/16 .
16. For next hop type, select Vir tual appliance .
17. For next hop address, type the firewall's private IP address that you noted earlier.
18. Select Add .
Now associate the route to the subnet.
1. On the UDR-Hub-Spoke - Routes page, select Subnets .
2. Select Associate .
3. Under Vir tual network , select VNet-hub .
4. Under Subnet , select GatewaySubnet .
5. Select OK .
Now create the default route from the spoke subnet.
4. Select Create .
7. For the name, type UDR-DG .
8. For Propagate gateway route , select No .
10. Select Create .
13. Select Add .
14. For the route name, type ToHub .
15. For the Address prefix destination , select IP Addresses .
16. For the Destination IP addresses/CIDR ranges , type 0.0.0.0/0 .
19. Select Add .
1. On the UDR-DG - Routes page, select Subnets .
3. Under Vir tual network , select VNet-spoke .
4. Under Subnet , select SN-Workload .
5. Select OK .
Create virtual machines

Now create the spoke workload and on-premises virtual machines, and place them in the appropriate subnets.
Create the workload virtual machine
Create a virtual machine in the spoke virtual network, running IIS, with no public IP address.
2. Under Popular Marketplace products , select Windows Ser ver 2019 Datacenter .
Resource group - Select FW-Hybrid-Test
Vir tual machine name : VM-Spoke-01
Region - Same region that you're used previously
User name : <type a user name>
Password : <type a password>
4. For Public inbound por ts , select Allow selected por ts , and then select HTTP (80) , and RDP (3389) .
5. Select Next:Disks .
6. Accept the defaults and select Next: Networking .
7. Select VNet-Spoke for the virtual network and the subnet is SN-Workload .
9. Select Next:Management .
10. For Boot diagnostics , Select Disable .
11. Select Review+Create , review the settings on the summary page, and then select Create .
Install IIS
After the virtual machine is created, install IIS.
1. From the Azure portal, open the Cloud Shell and make sure that it's set to PowerShell .
2. Run the following command to install IIS on the virtual machine and change the location if necessary:
Set-AzVMExtension `
-ResourceGroupName FW-Hybrid-Test `
-ExtensionName IIS `
-VMName VM-Spoke-01 `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell
Add-Content -Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
Create the on-premises virtual machine

This is a virtual machine that you use to connect using Remote Desktop to the public IP address. From there, you
then connect to the on-premises server through the firewall.
2. Under Popular Marketplace products , select Windows Ser ver 2019 Datacenter .
Resource group - Select existing, and then select FW-Hybrid-Test .
Vir tual machine name - VM-Onprem.
Region - Same region that you're used previously.
User name : <type a user name>.
Password : <type a user password>.
4. For Public inbound por ts , select Allow selected por ts , and then select RDP (3389)
6. Accept the defaults and select Next:Networking .
7. Select VNet-Onprem for virtual network and the subnet is SN-Corp .
NOTE
Azure provides a default outbound access IP for VMs that either aren't assigned a public IP address or are in the back-end
pool of an internal basic Azure load balancer. The default outbound access IP mechanism provides an outbound IP
address that isn't configurable.
For more information, see Default outbound access in Azure.
The default outbound access IP is disabled when either a public IP address is assigned to the VM or the VM is placed in
the back-end pool of a standard load balancer, with or without outbound rules. If an Azure Virtual Network network
address translation (NAT) gateway resource is assigned to the subnet of the virtual machine, the default outbound access
IP is disabled.
VMs that are created by virtual machine scale sets in flexible orchestration mode don't have default outbound access.
For more information about outbound connections in Azure, see Use source network address translation (SNAT) for
outbound connections.
Test the firewall

1. First, note the private IP address for VM-spoke-01 virtual machine.
2. From the Azure portal, connect to the VM-Onprem virtual machine.
3. Open a web browser on VM-Onprem , and browse to http://<VM-spoke-01 private IP>.
You should see the VM-spoke-01 web page:
4. From the VM-Onprem virtual machine, open a remote desktop to VM-spoke-01 at the private IP
address.
Your connection should succeed, and you should be able to sign in.
You can browse web server on the spoke virtual network.
You can connect to the server on the spoke virtual network using RDP.
Next, change the firewall network rule collection action to Deny to verify that the firewall rules work as
expected.
1. Select the hybrid-test-pol Firewall Policy.
2. Select Rule Collections .
3. Select the RCNet01 rule collection.
4. For Rule collection action , select Deny .
5. Select Save .
Close any existing remote desktops before testing the changed rules. Now run the tests again. They should all
fail this time.
Clean up resources
You can keep your firewall resources for the next tutorial, or if no longer needed, delete the FW-Hybrid-Test
Next steps
Tutorial: Filter inbound Internet traffic with Azure
Firewall policy DNAT using the Azure portal
You can configure Azure Firewall policy Destination Network Address Translation (DNAT) to translate and filter
inbound Internet traffic to your subnets. When you configure DNAT, the rule collection action is set to DNAT .
Each rule in the NAT rule collection can then be used to translate your firewall public IP address and port to a
private IP address and port. DNAT rules implicitly add a corresponding network rule to allow the translated
traffic. For security reasons, the recommended approach is to add a specific Internet source to allow DNAT
access to the network and avoid using wildcards. To learn more about Azure Firewall rule processing logic, see
Azure Firewall rule processing logic.
Deploy a firewall and policy
Test the firewall
Prerequisites

2. On the Azure portal home page, select Resource groups , then select Add .
4. For Resource group name , type RG-DNAT-Test .
7. Select Create .
Set up the network environment

For this tutorial, you create a two peered VNets:
VN-Hub - the firewall is in this VNet.
VN-Spoke - the workload server is in this VNet.
First, create the VNets and then peer them.
Create the Hub VNet
1. From the Azure portal home page, select All ser vices .
2. Under Networking , select Vir tual networks .
3. Select Add .
4. For Resource group , select RG-DNAT-Test .
5. For Name , type VN-Hub .
6. For Region , select the same region that you used before.
9. Under Subnet name , select default .
10. Edit the Subnet name and type AzureFirewallSubnet .
The firewall will be in this subnet, and the subnet name must be AzureFirewallSubnet.
NOTE
The size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall
FAQ.

12. Select Save .
14. Select Create .
Create a spoke VNet
3. Select Add .
5. For Name , type VN-Spoke .
8. For IPv4 Address space , edit the default and type 192.168.0.0/16 .
10. For the Subnet name type SN-Workload .
12. Select Add .
14. Select Create .
Peer the VNets
Now peer the two VNets.
1. Select the VN-Hub virtual network.
2. Under Settings , select Peerings .
3. Select Add .
4. Under This vir tual network , for the Peering link name , type Peer-HubSpoke .
5. Under Remote vir tual network , for Peering link name , type Peer-SpokeHub .
6. Select VN-Spoke for the virtual network.
7. Accept all the other defaults, and then select Add .
Create a workload virtual machine, and place it in the SN-Workload subnet.
1. From the Azure portal menu, select Create a resource .
2. Under Popular , select Windows Ser ver 2016 Datacenter .
Basics
3. For Vir tual machine name , type Sr v-Workload .
5. Type a username and password.
6. Select Next: Disks .
Disks
1. Select Next: Networking .
Networking
1. For Vir tual network , select VN-Spoke .
2. For Subnet , select SN-Workload .
4. For Public inbound por ts , select None .
5. Leave the other default settings and select Next: Management .
Management
1. For Boot diagnostics , select Disable .
Review + Create
Review the summary, and then select Create . This will take a few minutes to complete.
After deployment finishes, note the private IP address for the virtual machine. It will be used later when you
configure the firewall. Select the virtual machine name, and under Settings , select Networking to find the
private IP address.
Deploy the firewall and policy

1. From the portal home page, select Create a resource .
2. Search for Firewall , and then select Firewall .
3. Select Create .
SET T IN G VA L UE
Resource group Select RG-DNAT-Test

SET T IN G VA L UE
Name FW-DNAT-test
Firewall policy Add new :

fw-dnat-pol
your selected region
Choose a virtual network Use existing : VN-Hub
Public IP address Add new , Name: fw-pip .
5. Accept the other defaults, and then select Review + create .

7. After deployment completes, go to the RG-DNAT-Test resource group, and select the FW-DNAT-test
firewall.
8. Note the firewall's private and public IP addresses. You'll use them later when you create the default route
and NAT rule.

For the SN-Workload subnet, you configure the outbound default route to go through the firewall.
3. Select Add .
7. For Name , type RT-FW-route .
9. Select Create .
10. Select Go to resource .
11. Select Subnets , and then select Associate .
14. Select OK .
15. Select Routes , and then select Add .
17. For Address prefix , type 0.0.0.0/0 .
20. Select OK .
Configure a NAT rule

This rule allows you to connect a remote desktop to the Srv-Workload virtual machine through the firewall.
1. Open the RG-DNAT-Test resource group, and select the fw-dnat-pol firewall policy.
2. Under Settings , select DNAT rules .
6. For Rule collection group , select DefaultDnatRuleCollectionGroup .
12. For Destination Type , select IP Address .
13. For Destination , type the firewall public IP address.
14. For Translated address , type the Sr v-Workload private IP address.
16. Select Add .
Test the firewall

1. Connect a remote desktop to firewall public IP address. You should be connected to the Sr v-Workload
virtual machine.
2. Close the remote desktop.
Clean up resources
You can keep your firewall resources for the next tutorial, or if no longer needed, delete the RG-DNAT-Test
Next steps
Azure Firewall PowerShell samples
The following table includes links to Azure PowerShell script samples that create firewalls:
SA M P L E DESC RIP T IO N
Create an Azure Firewall and test infrastructure Creates an Azure Firewall and a test network infrastructure.
Azure Firewall Standard features
Azure Firewall Standard is a managed, cloud-based network security service that protects your Azure Virtual
Network resources.
Azure Firewall includes the following features:

Built-in high availability
Availability Zones
Unrestricted cloud scalability
Application FQDN filtering rules
Network traffic filtering rules
FQDN tags
Service tags
Threat intelligence
DNS proxy
Custom DNS
Deployment without public IP address in Forced Tunnel Mode
Outbound SNAT support
Inbound DNAT support
Multiple public IP addresses
Azure Monitor logging
Forced tunneling
Web categories
Certifications
Built-in high availability

High availability is built in, so no extra load balancers are required and there's nothing you need to configure.
Availability Zones
Azure Firewall can be configured during deployment to span multiple Availability Zones for increased
availability. With Availability Zones, your availability increases to 99.99% uptime. For more information, see the
Azure Firewall Service Level Agreement (SLA). The 99.99% uptime SLA is offered when two or more Availability
Zones are selected.
You can also associate Azure Firewall to a specific zone just for proximity reasons, using the service standard
99.95% SLA.
There's no additional cost for a firewall deployed in more than one Availability Zone. However, there are added
costs for inbound and outbound data transfers associated with Availability Zones. For more information, see
Bandwidth pricing details.
Azure Firewall Availability Zones are available in regions that support Availability Zones. For more information,
see Regions that support Availability Zones in Azure
NOTE
Availability Zones can only be configured during deployment. You can't configure an existing firewall to include Availability
Zones.
For more information about Availability Zones, see Regions and Availability Zones in Azure.
Unrestricted cloud scalability

Azure Firewall can scale out as much as you need to accommodate changing network traffic flows, so you don't
need to budget for your peak traffic.
Application FQDN filtering rules

You can limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names
(FQDN) including wild cards. This feature doesn't require TLS termination.
Network traffic filtering rules

You can centrally create allow or deny network filtering rules by source and destination IP address, port, and
protocol. Azure Firewall is fully stateful, so it can distinguish legitimate packets for different types of
connections. Rules are enforced and logged across multiple subscriptions and virtual networks.
Azure Firewall supports stateful filtering of Layer 3 and Layer 4 network protocols. Layer 3 IP protocols can be
filtered by selecting Any protocol in the Network rule and select the wild-card * for the port.
FQDN tags
FQDN tags make it easy for you to allow well-known Azure service network traffic through your firewall. For
example, say you want to allow Windows Update network traffic through your firewall. You create an application
rule and include the Windows Update tag. Now network traffic from Windows Update can flow through your
firewall.
Service tags
A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation.
You can't create your own service tag, nor specify which IP addresses are included within a tag. Microsoft
manages the address prefixes encompassed by the service tag, and automatically updates the service tag as
addresses change.
Threat intelligence
Threat intelligence-based filtering can be enabled for your firewall to alert and deny traffic from/to known
malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat
Intelligence feed.
DNS proxy
With DNS proxy enabled, Azure Firewall can process and forward DNS queries from a Virtual Network(s) to
your desired DNS server. This functionality is crucial and required to have reliable FQDN filtering in network
rules. You can enable DNS proxy in Azure Firewall and Firewall Policy settings. To learn more about DNS proxy,
see Azure Firewall DNS settings.
Custom DNS
Custom DNS allows you to configure Azure Firewall to use your own DNS server, while ensuring the firewall
outbound dependencies are still resolved with Azure DNS. You may configure a single DNS server or multiple
servers in Azure Firewall and Firewall Policy DNS settings. Learn more about Custom DNS, see Azure Firewall
DNS settings.
Azure Firewall can also resolve names using Azure Private DNS. The virtual network where the Azure Firewall
resides must be linked to the Azure Private Zone. To learn more, see Using Azure Firewall as DNS Forwarder
with Private Link.

You can use fully qualified domain names (FQDNs) in network rules based on DNS resolution in Azure Firewall
and Firewall Policy.
The specified FQDNs in your rule collections are translated to IP addresses based on your firewall DNS settings.
This capability allows you to filter outbound traffic using FQDNs with any TCP/UDP protocol (including NTP,
SSH, RDP, and more). As this capability is based on DNS resolution, it is highly recommended you enable the
DNS proxy to ensure name resolution is consistent with your protected virtual machines and firewall.
Deploy Azure Firewall without public IP address in Forced Tunnel

mode
The Azure Firewall service requires a public IP address for operational purposes. While secure, some
deployments prefer not to expose a public IP address directly to the Internet.
In such cases, you can deploy Azure Firewall in Forced Tunnel mode. This configuration creates a management
NIC which is used by Azure Firewall for its operations. The Tenant Datapath network can be configured without a
public IP address, and Internet traffic can be forced tunneled to another firewall or completely blocked.
Forced Tunnel mode cannot be configured at run time. You can either redeploy the Firewall or use the stop and
start facility to reconfigure an existing Azure Firewall in Forced Tunnel mode. Firewalls deployed in Secure Hubs
are always deployed in Forced Tunnel mode.
Outbound SNAT support

All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP (Source Network
Address Translation). You can identify and allow traffic originating from your virtual network to remote Internet
destinations. Azure Firewall doesn't SNAT when the destination IP is a private IP range per IANA RFC 1918.
If your organization uses a public IP address range for private networks, Azure Firewall will SNAT the traffic to
one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to not SNAT
your public IP address range. For more information, see Azure Firewall SNAT private IP address ranges.
You can monitor SNAT port utilization in Azure Firewall metrics. Learn more and see our recommendation on
SNAT port utilization in our firewall logs and metrics documentation.
Inbound DNAT support

Inbound Internet network traffic to your firewall public IP address is translated (Destination Network Address
Translation) and filtered to the private IP addresses on your virtual networks.
Multiple public IP addresses

You can associate multiple public IP addresses (up to 250) with your firewall.
This enables the following scenarios:
DNAT - You can translate multiple standard port instances to your backend servers. For example, if you have
two public IP addresses, you can translate TCP port 3389 (RDP) for both IP addresses.
SNAT - More ports are available for outbound SNAT connections, reducing the potential for SNAT port
exhaustion. At this time, Azure Firewall randomly selects the source public IP address to use for a connection.
If you have any downstream filtering on your network, you need to allow all public IP addresses associated
with your firewall. Consider using a public IP address prefix to simplify this configuration.
Azure Monitor logging

All events are integrated with Azure Monitor, allowing you to archive logs to a storage account, stream events to
your Event Hub, or send them to Azure Monitor logs. For Azure Monitor log samples, see Azure Monitor logs for
Azure Firewall.
For more information, see Tutorial: Monitor Azure Firewall logs and metrics.
Azure Firewall Workbook provides a flexible canvas for Azure Firewall data analysis. You can use it to create rich
visual reports within the Azure portal. For more information, see Monitor logs using Azure Firewall Workbook.
Forced tunneling
You can configure Azure Firewall to route all Internet-bound traffic to a designated next hop instead of going
directly to the Internet. For example, you may have an on-premises edge firewall or other network virtual
appliance (NVA) to process network traffic before it's passed to the Internet. For more information, see Azure
Firewall forced tunneling.
Web categories
Web categories lets administrators allow or deny user access to web site categories such as gambling websites,
social media websites, and others. Web categories are included in Azure Firewall Standard, but it's more fine-
tuned in Azure Firewall Premium. As opposed to the Web categories capability in the Standard SKU that matches
the category based on an FQDN, the Premium SKU matches the category according to the entire URL for both
HTTP and HTTPS traffic. For more information about Azure Firewall Premium, see Azure Firewall Premium
features.
For example, if Azure Firewall intercepts an HTTPS request for www.google.com/news , the following categorization
is expected:
Firewall Standard – only the FQDN part will be examined, so www.google.com will be categorized as
Search Engine.
Firewall Premium – the complete URL will be examined, so www.google.com/news will be categorized as
News.
The categories are organized based on severity under Liability , High-Bandwidth , Business Use ,
Productivity Loss , General Surfing , and Uncategorized .
Category exceptions
You can create exceptions to your web category rules. Create a separate allow or deny rule collection with a
higher priority within the rule collection group. For example, you can configure a rule collection that allows
www.linkedin.com with priority 100, with a rule collection that denies Social networking with priority 200. This
creates the exception for the pre-defined Social networking web category.
Certifications
Azure Firewall is Payment Card Industry (PCI), Service Organization Controls (SOC), International Organization
for Standardization (ISO), and ICSA Labs compliant. For more information, see Azure Firewall compliance
certifications.
Next steps
Azure Firewall Premium provides advanced threat protection that meets the needs of highly sensitive and
regulated environments, such as the payment and healthcare industries.
Organizations can use Premium stock-keeping unit (SKU) features like IDPS and TLS inspection to prevent
malware and viruses from spreading across networks in both lateral and horizontal directions. To meet the
increased performance demands of IDPS and TLS inspection, Azure Firewall Premium uses a more powerful
virtual machine SKU. Like the Standard SKU, the Premium SKU can seamlessly scale up to 30 Gbps and integrate
with availability zones to support the service level agreement (SLA) of 99.99 percent. The Premium SKU
complies with Payment Card Industry Data Security Standard (PCI DSS) environment needs.
Azure Firewall Premium includes the following features:

TLS inspection - decrypts outbound traffic, processes the data, then encrypts the data and sends it to the
destination.
IDPS - A network intrusion detection and prevention system (IDPS) allows you to monitor network activities
for malicious activity, log information about this activity, report it, and optionally attempt to block it.
URL filtering - extends Azure Firewall’s FQDN filtering capability to consider an entire URL. For example,
www.contoso.com/a/c instead of www.contoso.com .
Web categories - administrators can allow or deny user access to website categories such as gambling
websites, social media websites, and others.
TLS inspection
The TLS (Transport Layer Security) protocol primarily provides cryptography for privacy, integrity, and
authenticity using certificates between two or more communicating applications. It runs in the application layer
and is widely used to encrypt the HTTP protocol.
Encrypted traffic has a possible security risk and can hide illegal user activity and malicious traffic. Azure Firewall
without TLS inspection (as shown in the following diagram) has no visibility into the data that flows in the
encrypted TLS tunnel, and so can't provide a full protection coverage.
The second diagram shows how Azure Firewall Premium terminates and inspects TLS connections to detect,
alert, and mitigate malicious activity in HTTPS. The firewall actually creates two dedicated TLS connections: one
with the Web Server (contoso.com) and another connection with the client. Using the customer provided CA
certificate, it generates an on-the-fly certificate, which replaces the Web Server certificate and shares it with the
client to establish the TLS connection between the firewall and the client.
Azure Firewall without TLS inspection:
Azure Firewall with TLS inspection:
The following use cases are supported with Azure Firewall:

Outbound TLS Inspection
To protect against malicious traffic that is sent from an internal client hosted in Azure to the Internet.
East-West TLS Inspection (includes traffic that goes from/to an on-premises network)
To protect your Azure workloads from potential malicious traffic sent from within Azure.
The following use case is supported by Azure Web Application Firewall on Azure Application Gateway:
Inbound TLS Inspection
To protect internal servers or applications hosted in Azure from malicious requests that arrive from the
Internet or an external network. Application Gateway provides end-to-end encryption.
TIP
TLS 1.0 and 1.1 are being deprecated and won’t be supported. TLS 1.0 and 1.1 versions of TLS/Secure Sockets Layer (SSL)
have been found to be vulnerable, and while they still currently work to allow backwards compatibility, they aren't
recommended. Migrate to TLS 1.2 as soon as possible.
To learn more about Azure Firewall Premium Intermediate CA certificate requirements, see Azure Firewall
Premium certificates.
IDPS
A network intrusion detection and prevention system (IDPS) allows you to monitor your network for malicious
activity, log information about this activity, report it, and optionally attempt to block it.
Azure Firewall Premium provides signature-based IDPS to allow rapid detection of attacks by looking for
specific patterns, such as byte sequences in network traffic, or known malicious instruction sequences used by
malware. The IDPS signatures are applicable for both application and network level traffic (Layers 3-7), they're
fully managed, and continuously updated. IDPS can be applied to inbound, spoke-to-spoke (East-West), and
outbound traffic. Spoke-to-spoke (East-West) includes traffic that goes from/to an on-premises network. You
can configure your IDPS private IP address ranges using the Private IP ranges preview feature. For more
information, see Azure Firewall preview features.
The Azure Firewall signatures/rulesets include:
An emphasis on fingerprinting actual malware, Command and Control, exploit kits, and in the wild malicious
activity missed by traditional prevention methods.
Over 58,000 rules in over 50 categories.
The categories include malware command and control, phishing, trojans, botnets, informational
events, exploits, vulnerabilities, SCADA network protocols, exploit kit activity, and more.
20 to 40+ new rules are released each day.
Low false positive rating by using state-of-the-art malware sandbox and global sensor network feedback
loop.
IDPS allows you to detect attacks in all ports and protocols for non-encrypted traffic. However, when HTTPS
traffic needs to be inspected, Azure Firewall can use its TLS inspection capability to decrypt the traffic and better
detect malicious activities.
The IDPS Bypass List allows you to not filter traffic to any of the IP addresses, ranges, and subnets specified in
the bypass list.
IDPS signature rules
IDPS signature rules allow you to:
Customize one or more signatures and change their mode to Disabled, Alert or Alert and Deny.
For example, if you receive a false positive where a legitimate request is blocked by Azure Firewall due to
a faulty signature, you can use the signature ID from the network rules logs, and set its IDPS mode to off.
This causes the "faulty" signature to be ignored and resolves the false positive issue.
You can apply the same fine-tuning procedure for signatures that are creating too many low-priority
alerts, and therefore interfering with visibility for high-priority alerts.
Get a holistic view of the entire 55,000 signatures
Smart search
Allows you to search through the entire signatures database by any type of attribute. For example, you
can search for specific CVE-ID to discovered what signatures are taking care of this CVE by typing the ID
in the search bar.
IDPS signature rules have the following properties:
C O L UM N DESC RIP T IO N
Signature ID Internal ID for each signature. This ID is also presented in

Azure Firewall Network Rules logs.
Mode Indicates if the signature is active or not, and whether

firewall will drop or alert upon matched traffic. The below
signature mode can override IDPS mode
- Disabled : The signature isn't enabled on your firewall.
- Aler t : You'll receive alerts when suspicious traffic is
detected.
- Aler t and Deny : You'll receive alerts and suspicious traffic
will be blocked. Few signature categories are defined as
“Alert Only”, therefore by default, traffic matching their
signatures won't be blocked even though IDPS mode is set
to “Alert and Deny”. Customers may override this by
customizing these specific signatures to “Alert and Deny”
mode.
Note: IDPS alerts are available in the portal via network rule
log query.
Severity Each signature has an associated severity level that indicates

the probability that the signature is an actual attack.
- Low : An abnormal event is one that doesn't normally
occur on a network or Informational events are logged.
Probability of attack is low.
- Medium : The signature indicates an attack of a suspicious
nature. The administrator should investigate further.
- High : The attack signatures indicate that an attack of a
severe nature is being launched. There's little probability that
the packets have a legitimate purpose.
Direction The traffic direction for which the signature is applied.

- Inbound : Signature is applied only on traffic arriving from
the Internet and destined in Azure private IP range
(according to IANA RFC 1918).
- Outbound : Signature is applied only on traffic sent from
Azure private IP range (according to IANA RFC 1918) to the
Internet.
- Bidirectional: Signature is always applied on any traffic
direction.
C O L UM N DESC RIP T IO N
Group The group name that the signature belongs to.
Description Structured from the following three parts:

- Categor y name : The category name that the signature
belongs to as described in Azure Firewall IDPS signature rule
categories.
- High level description of the signature
- CVE-ID (optional) in the case where the signature is
associated with a specific CVE. The ID is listed here.
Protocol The protocol associated with this signature.
Source/Destination Ports The ports associated with this signature.
Last updated The last date that this signature was introduced or modified.
URL filtering
URL filtering extends Azure Firewall’s FQDN filtering capability to consider an entire URL. For example,
URL Filtering can be applied both on HTTP and HTTPS traffic. When HTTPS traffic is inspected, Azure Firewall
Premium can use its TLS inspection capability to decrypt the traffic and extract the target URL to validate
whether access is permitted. TLS inspection requires opt-in at the application rule level. Once enabled, you can
use URLs for filtering with HTTPS.
Web categories
social media websites, and others. Web categories will also be included in Azure Firewall Standard, but it will be
more fine-tuned in Azure Firewall Premium. As opposed to the Web categories capability in the Standard SKU
that matches the category based on an FQDN, the Premium SKU matches the category according to the entire
URL for both HTTP and HTTPS traffic.
For example, if Azure Firewall intercepts an HTTPS request for www.google.com/news , the following categorization
is expected:
Firewall Standard – only the FQDN part will be examined, so www.google.com will be categorized as
Search Engine.
Firewall Premium – the complete URL will be examined, so www.google.com/news will be categorized as
News.
The categories are organized based on severity under Liability , High-Bandwidth , Business Use ,
Productivity Loss , General Surfing , and Uncategorized . For a detailed description of the web categories,
see Azure Firewall web categories.
Web category logging
You can view traffic that has been filtered by Web categories in the Application logs. Web categories field is
only displayed if it has been explicitly configured in your firewall policy application rules. For example, if you
don't have a rule that explicitly denies Search Engines, and a user requests to go to www.bing.com, only a default
deny message is displayed as opposed to a Web categories message. This is because the web category wasn't
explicitly configured.
Category exceptions
You can create exceptions to your web category rules. Create a separate allow or deny rule collection with a
higher priority within the rule collection group. For example, you can configure a rule collection that allows
www.linkedin.com with priority 100, with a rule collection that denies Social networking with priority 200. This
creates the exception for the pre-defined Social networking web category.
Web category search
You can identify what category a given FQDN or URL is by using the Web Categor y Check feature. To use this,
select the Web Categories tab under Firewall Policy Settings . This is useful when defining your application
rules for destination traffic.
Category change
Under the Web Categories tab in Firewall Policy Settings , you can request a categorization change if you:
think an FQDN or URL should be under a different category
or
have a suggested category for an uncategorized FQDN or URL
Once you submit a category change report, you'll be given a token in the notifications that indicate that we've
received the request for processing. You can check whether the request is in progress, denied, or approved by
entering the token in the search bar. Be sure to save your token ID to do so.
Supported regions
For the supported regions for Azure Firewall, see Azure products available by region.
Next steps
Learn about Azure Firewall Premium certificates
Azure Firewall preview features
The following Azure Firewall preview features are available publicly for you to deploy and test. Some of the
preview features are available on the Azure portal, and some are only visible using a feature flag.
IMPORTANT
These features are currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms
that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
Feature flags
As new features are released to preview, some of them will be behind a feature flag. To enable the functionality
in your environment, you must enable the feature flag on your subscription. These features are applied at the
subscription level for all firewalls (VNet firewalls and SecureHub firewalls).
This article will be updated to reflect the features that are currently in preview with instructions to enable them.
When the features move to General Availability (GA), they'll be available to all customers without the need to
enable a feature flag.
Preview features
The following features are available in preview.
Network rule name logging (preview)
Currently, a network rule hit event shows the following attributes in the logs:
Source and destination IP/port
Action (allow, or deny)
With this new feature, the event logs for network rules also show the following attributes:
Policy name
Rule collection group
Rule collection
Rule name
To enable the Network Rule name Logging feature, the following commands need to be run in Azure
PowerShell. For the feature to immediately take effect, an operation needs to be run on the firewall. This can be a
rule change (least intrusive), a setting change, or a stop/start operation. Otherwise, the firewall/s is updated with
the feature within several days.
Run the following Azure PowerShell commands to configure Azure Firewall network rule name logging:
Connect-AzAccount
Select-AzSubscription -Subscription "subscription_id or subscription_name"
Register-AzProviderFeature -FeatureName AFWEnableNetworkRuleNameLogging -ProviderNamespace Microsoft.Network
Register-AzResourceProvider -ProviderNamespace Microsoft.Network
Run the following Azure PowerShell command to turn off this feature:
Unregister-AzProviderFeature -FeatureName AFWEnableNetworkRuleNameLogging -ProviderNamespace
Microsoft.Network
IDPS Private IP ranges (preview)

In Azure Firewall Premium IDPS, private IP address ranges are used to identify if traffic is inbound, outbound, or
internal (East-West). Each signature is applied on specific traffic direction, as indicated in the signature rules
table. By default, only ranges defined by IANA RFC 1918 are considered private IP addresses. So traffic sent from
a private IP address range to a private IP address range is considered internal. To modify your private IP
addresses, you can now easily edit, remove, or add ranges as needed.
Structured firewall logs (preview)

Today, the following diagnostic log categories are available for Azure Firewall:
Application rule log
Network rule log
DNS proxy log
These log categories use Azure diagnostics mode. In this mode, all data from any diagnostic setting will be
collected in the AzureDiagnostics table.
With this new feature, you'll be able to choose to use Resource Specific Tables instead of the existing
AzureDiagnostics table. In case both sets of logs are required, at least two diagnostic settings need to be created
per firewall.
In Resource specific mode, individual tables in the selected workspace are created for each category selected
in the diagnostic setting. This method is recommended since it:
makes it much easier to work with the data in log queries
makes it easier to discover schemas and their structure
improves performance across both ingestion latency and query times
allows you to grant Azure RBAC rights on a specific table
New resource specific tables are now available in Diagnostic setting that allows you to utilize the following
newly added categories:
Network rule log - Contains all Network Rule log data. Each match between data plane and network rule
creates a log entry with the data plane packet and the matched rule's attributes.
NAT rule log - Contains all DNAT (Destination Network Address Translation) events log data. Each match
between data plane and DNAT rule creates a log entry with the data plane packet and the matched rule's
attributes.
Application rule log - Contains all Application rule log data. Each match between data plane and Application
rule creates a log entry with the data plane packet and the matched rule's attributes.
Threat Intelligence log - Contains all Threat Intelligence events.
IDPS log - Contains all data plane packets that were matched with one or more IDPS signatures.
DNS proxy log - Contains all DNS Proxy events log data.
Internal FQDN resolve failure log - Contains all internal Firewall FQDN resolution requests that resulted in
failure.
Application rule aggregation log - Contains aggregated Application rule log data for Policy Analytics.
Network rule aggregation log - Contains aggregated Network rule log data for Policy Analytics.
NAT rule aggregation log - Contains aggregated NAT rule log data for Policy Analytics.
By default, the new resource specific tables are disabled. Open a support ticket to enable the functionality in
your environment.
In addition, when setting up your log analytics workspace, you must select whether you want to work with the
AzureDiagnostics table (default) or with Resource Specific Tables.
Additional KQL log queries were added to query structured firewall logs.
NOTE
Existing Workbooks and any Sentinel integration will be adjusted to support the new structured logs when Resource
Specific mode is selected.
Policy Analytics (preview)

Policy Analytics provides insights, centralized visibility, and control to Azure Firewall. IT teams today are
challenged to keep Firewall rules up to date, manage existing rules, and remove unused rules. Any accidental
rule updates can lead to a significant downtime for IT teams.
For large, geographically dispersed organizations, manually managing Firewall rules and policies is a complex
and sometimes error-prone process. The new Policy Analytics feature is the answer to this common challenge
faced by IT teams.
You can now refine and update Firewall rules and policies with confidence in just a few steps in the Azure portal.
You have granular control to define your own custom rules for an enhanced security and compliance posture.
You can automate rule and policy management to reduce the risks associated with a manual process.
Pricing
Enabling Policy Analytics on a Firewall Policy associated with a single firewall is billed per policy as described on
the Azure Firewall Manager pricing page. Enabling Policy Analytics on a Firewall Policy associated with more
than one firewall is offered at no additional cost.
Key Policy Analytics features
Policy insight panel : Aggregates insights and highlights relevant policy information.
Rule analytics : Analyzes existing DNAT, Network, and Application rules to identify rules with low utilization
or rules with low usage in a specific time window.
Traffic flow analysis : Maps traffic flow to rules by identifying top traffic flows and enabling an integrated
experience.
Single Rule analysis : Analyzes a single rule to learn what traffic hits that rule to refine the access it
provides and improve the overall security posture.
Prerequisites
An Azure Firewall Standard or Premium
An Azure Firewall Standard or Premium policy attached to the Firewall
The network rule name logging preview feature must be enabled to view network rules analysis
The structured firewall logs feature must be enabled on Firewall Standard or Premium
Enable Policy Analytics
Policy analytics starts monitoring the flows in the DNAT, Network, and Application rule analysis only after you
enable the feature. It can't analyze rules hit before the feature is enabled.
Firewall with no Diagnostics settings configured
1. Once all prerequisites are met, select Policy analytics (preview) in the table of contents.
2. Next, select Configure Workspaces .
3. In the pane that opens, select the Enable Policy Analytics checkbox.
4. Next, choose a log analytics workspace. The log analytics workspace should be the same as the Firewall
attached to the policy.
5. Select Save after you choose the log analytics workspace.
6. Go to the Firewall attached to the policy and enter the Diagnostic settings page. You'll see the
FirewallPolicySetting added there as part of the policy analytics feature.
7. Select Edit Setting , and ensure the Resource specific toggle is checked, and the highlighted tables are
checked. In the previous example, all logs are written to the log analytics workspace.
Firewall with Diagnostics settings already configured
1. Ensure that the Firewall attached to the policy is logging to Resource Specific tables, and that the
following three tables are also selected:
AZFWApplicationRuleAggregation
AZFWNetworkRuleAggregation
AZFWNatRuleAggregation
2. Next, select Policy Analytics (preview) in the table of contents. Once inside the feature, select
Configure Workspaces .
3. Now, select Enable Policy Analytics .
4. Next, choose a log analytics workspace. The log analytics workspace should be the same as the Firewall
attached to the policy.
5. Select Save after you choose the log analytics workspace.
During the save process, you might see the following error message: Failed to update Diagnostic
Settings
You can disregard this error message if the policy was successfully updated.
Next steps
To learn more about Azure Firewall, see What is Azure Firewall?.
Azure Firewall IDPS signature rule categories
Azure Firewall IDPS features over 50 categories that can be assigned to individual signatures. The following
table is a list of definitions for each category.
Categories
C AT EGO RY DESC RIP T IO N
3CORESec This category is for signatures that are generated

automatically from the 3CORESec team’s IP blocklists. These
blocklists are generated by 3CORESec based on malicious
activity from their Honeypots.
ActiveX This category is for signatures that protect against attacks

against Microsoft ActiveX controls and exploits targeting
vulnerabilities in ActiveX controls.
Adware-PUP This category is for signatures to identify software that is

used for ad tracking or other types of spyware related
activity.
Attack Response This category is for signatures to identify responses

indicative of intrusion—examples include but not limited to
LMHost file download, presence of certain web banners and
the detection of Metasploit Meterpreter kill command. These
signatures are designed to catch the results of a successful
attack. Things like id=root, or error messages that indicate a
compromise may have happened.
Botcc (Bot Command and Control) This category is for signatures that are autogenerated from
several sources of known and confirmed active botnet and
other Command andControl (C2) hosts. This category is
updated daily. The category’s primary data source is
Shadowserver.org.
Botcc Port grouped This category is for signatures like those in the Botcc
category but grouped by destination port. Rules grouped by
port can offer higher fidelity than rules not grouped by port.
Chat This category is for signatures that identify traffic related to

many chat clients such as Internet Relay Chat (IRC). Chat
traffic can be indicative of possible check-in activity by threat
actors.
CIArmy This category is for signatures that are generated using

Collective Intelligence’s IP rules for blocking.
Coin mining This category is for signatures with rules that detect
malware, which does coin mining. These signatures can also
detect some legitimate (though often undesirable) coin
mining software.
Compromised This category is for signatures based on a list of known

compromised hosts. This list is confirmed and updated daily.
The signatures in this category can vary from one to several
hundred rules depending on the data sources. The data
sources for this category come from several private but
highly reliable data sources.
Current Events This category is for signatures with rules developed in

response to active and short-lived campaigns and high-
profile items that are expected to be temporary. One
example is fraud campaigns related to disasters. The rules in
this category aren't intended to be kept in the ruleset for
long, or that need to be further tested before they're
considered for inclusion. Most often these will be simple
signatures for the Storm binary URL of the day, signatures to
catch CLSIDs of newly found vulnerable apps where we don’t
have any detail on the exploit, and so on.
DNS (Domain Name Service) This category is for signatures with rules for attacks and
vulnerabilities regarding DNS. This category is also used for
rules related to abuse of DNS such as tunneling.
DOS This category is for signatures that detect Denial of Service

(DoS) attempts. These rules are intended to catch inbound
DoS activity, and provide indication of outbound DoS
activity.
Note: All the signatures in this category are defined as “Alert

Only”, therefore by default, traffic matching these signatures
will not be blocked even though the IDPS mode is set to
“Alert and Deny”. Customers may override this behavior by
mode.
Drop This category is for signatures to block IP addresses on the

Spamhaus DROP (Don’t Route or Peer) list. The rules in this
category are updated daily.
Dshield This category is for signatures based on attackers identified

by Dshield. The rules in this category are updated daily from
the DShield top attackers list, which is reliable.
Exploit This category is for signatures that protect against direct

exploits not otherwise covered in a specific service category.
This category is where specific attacks against vulnerabilities
such as against Microsoft Windows will be found. Attacks
with their own category such as SQL injection have their
own category.
Exploit-Kit This category is for signatures to detect activity related to

Exploit Kits their infrastructure, and delivery.
FTP This category is for signatures related to attacks, exploits,

and vulnerabilities associated with the File Transfer Protocol
(FTP). This category also includes rules that detect non-
malicious FTP activity such as logins for logging purposes.
Games This category is for signatures that identify of gaming traffic

and attacks against those games. The rules cover games
such as World of Warcraft, Starcraft, and other popular
online games. While the games and their traffic aren't
malicious, they're often unwanted and prohibited by policy
on corporate networks.
Hunting This category is for signatures that provide indicators that

when matched with other signatures can be useful for threat
hunting in an environment. These rules can provide false
positives on legitimate traffic and inhibit performance.
They're only recommended for use when actively researching
potential threats in the environment.

mode.
ICMP This category is for signatures related to attacks and

vulnerabilities about Internet Control Message
Protocol(ICMP).
ICMP_info This category is for signatures related to ICMP protocol-

specific events, typically associated with normal operations
for logging purposes.

mode.
IMAP This category is for signatures related to attacks, exploits,

and vulnerabilities about Internet Message Access Protocol
(IMAP). This category also includes rules that detect
nonmalicious IMAP activity for logging purposes.
Inappropriate This category is for signatures to identify potentially activity

related to sites that are pornographic or otherwise not
appropriate for a work environment.
Warning: This category can have a significant performance

impact and high rate of false positives.
Info This category is for signatures to help provide audit level

events that are useful for correlation and identifying
interesting activity, which may not be inherently malicious
but is often observed in malware and other threats. For
example, downloading an Executable over HTTP by IP
address rather than domain name.

mode.
JA3 This category is for signatures to fingerprint malicious SSL

certificates using JA3 hashes. These rules are based on
parameters that are in the SSL handshake negotiation by
both clients and servers. These rules can have a high false
positive rate but can be useful for threat hunting or malware
detonation environments.
Malware This category is for signatures to detect malicious software.

Rules in this category detect activity related to malicious
software that is detected on the network including malware
in transit, active malware, malware infections, malware
attacks, and updating of malware. This is also a highly
important category and it's highly recommended that you
run it.
Misc This category is for signatures not covered in other

categories.
Mobile Malware This category is for signatures that indicate malware that is
associated with mobile and tablet-operating systems like
Google Android, Apple iOS, and others. Malware that is
detected and is associated with mobile operating systems
will generally be placed in this category rather than the
standard categories like Malware.
NETBIOS This category is for signatures related to attacks, exploits,

and vulnerabilities associated with NetBIOS. This category
also includes rules that detect non-malicious NetBIOS
activity for logging purposes.
P2P This category is for signatures for the identification of Peer-

to-Peer (P2P) traffic and attacks against it. Identified P2P
traffic includes torrents, edonkey, Bittorrent, Gnutella, and
Limewire among others. P2P traffic isn't inherently malicious
but is often of notable for enterprises.

mode.
Phishing This category is for signatures that detect credential-

phishing activity. This includes landing pages displaying
credential phishing and successful submission of credentials
into credential-phishing sites.
Policy This category is for signatures that may indicate violations to

an organization’s policy. This can include protocols prone to
abuse, and other application-level transactions, which may
be of interest.

“Alert and Deny”. Customers may override this by
mode.
POP3 This category is for signatures related to attacks, exploits,

and vulnerabilities associated with the Post Office Protocol
3.0 (POP3). This category also includes rules that detect
nonmalicious POP3 activity for logging purposes.
RPC This category is for signatures related to attacks, exploits,

and vulnerabilities regarding Remote Procedure Call (RPC).
This category also includes rules that detect non-malicious
RPC activity for logging purposes.
SCADA This category is for signatures related to attacks, exploits,

and vulnerabilities associated with supervisory control and
data acquisition (SCADA). This category also includes rules
that detect non-malicious SCADA activity for logging
purposes.
SCAN This category is for signatures to detect reconnaissance and

probing from tools such as Nessus, Nikto, and other port
scanning, tools. This category can be useful for detecting
early breach activity and post-infection lateral movement
within an organization.

mode.
Shell code This category is for signatures for remote shell code
detection. Remote shell code is used when an attacker wants
to target a vulnerable process running on another machine
on a local network or intranet. If successfully executed, the
shell code can provide the attacker access to the target
machine across the network. Remote shell codes normally
use standard TCP/IP socket connections to allow the attacker
access to the shell on the target machine. Such shell code
can be categorized based on how this connection is set up: if
the shell code can establish this connection, it's called a
“reverse shell” or a "connect back" shell code because the
shell code connects back to the attacker’s machine.
SMTP This category is for signatures related to attacks, exploits,

and vulnerabilities associated with Simple Mail Transfer
Protocol (SMTP). This category also includes rules that detect
non-malicious SMTP activity for logging purposes.
SNMP This category is for signatures related to attacks, exploits,

and vulnerabilities associated with Simple Network
Management Protocol (SNMP). This category also includes
rules that detect non-malicious SNMP activity for logging
purposes.
SQL This category is for signatures related to attacks, exploits,

and vulnerabilities associated with Structured Query
Language (SQL). This category also includes rules that detect
non-malicious SQL activity for logging purposes.

mode.
TELNET This category is for signatures related to attacks, exploits,

and vulnerabilities associated with TELNET. This category also
includes rules that detect non-malicious TELNET activity for
logging purposes.
TFTP This category is for signatures related to attacks, exploits,

and vulnerabilities associated with Trivial File Transport
Protocol (TFTP). This category also includes rules that detect
nonmalicious TFTP activity for logging purposes.
TOR This category is for signatures for the identification of traffic

to and from TOR exit nodes based on IP address.

mode.
User Agents This category is for signatures to detect suspicious and

anomalous user agents. Known malicious user agents are
placed in the Malware category.
VOIP This category is for signatures for attacks and vulnerabilities

associated with Voice over IP (VOIP) including SIP, H.323,
and RTP among others.
Web Client This category is for signatures for attacks and vulnerabilities
associated with web clients such as web browsers and also
client-side applications like CURL, WGET, and others.
Web Server This category is for signatures to detect attacks against web
server infrastructure such as APACHE, TOMCAT, NGINX,
Microsoft Internet Information Services (IIS), and other web
server software.
Web Specific Apps This category is for signatures to detect attacks and
vulnerabilities in specific web applications.
WORM This category is for signatures to detect malicious activity

that automatically attempts to spread across the internet or
within a network by exploiting a vulnerability are classified as
the WORM category. While the actual exploit itself will
typically be identified in the Exploit or given protocol
category, another entry in this category may be made if the
actual malware engaging in worm-like propagation can be
identified as well.
Next steps
To learn more about Azure Firewall Premium features, see Azure Firewall Premium features.
Azure Firewall Premium in the Azure portal
Azure Firewall Premium is a next generation firewall with capabilities that are required for highly sensitive and
regulated environments. It includes the following features:
TLS inspection - decrypts outbound traffic, processes the data, then encrypts the data and sends it to the
destination.
For more information, see Azure Firewall Premium features.
Deploy the firewall

Deploying an Azure Firewall Premium is similar to deploying a standard Azure Firewall:
For Firewall tier , you select Premium and for Firewall policy , you select an existing Premium policy or
create a new one.
Configure the Premium policy

Configuring a Premium firewall policy is similar to configuring a Standard firewall policy. With a Premium policy,
you can configure the Premium features:
Rule configuration
When you configure application rules in a Premium policy, you can configure addition Premium features:
Next steps
To see the Azure Firewall Premium features in action, see Deploy and configure Azure Firewall Premium.
Azure Firewall Premium certificates
To properly configure Azure Firewall Premium TLS inspection, you must provide a valid intermediate CA
certificate and deposit it in Azure Key vault.
Certificates used by Azure Firewall Premium

There are three types of certificates used in a typical deployment:
Intermediate CA Cer tificate (CA Cer tificate)
A Certificate Authority (CA) is an organization that is trusted to sign digital certificates. A CA verifies
identity and legitimacy of a company or individual requesting a certificate. If the verification is successful,
the CA issues a signed certificate. When the server presents the certificate to the client (for example, your
web browser) during a SSL/TLS handshake, the client attempts to verify the signature against a list of
known good signers. Web browsers normally come with lists of CAs that they implicitly trust to identify
hosts. If the authority is not in the list, as with some sites that sign their own certificates, the browser
alerts the user that the certificate is not signed by a recognized authority and asks the user if they wish to
continue communications with unverified site.
Ser ver Cer tificate (Website cer tificate)
A certificate associated with a specific domain name. If a website has a valid certificate, it means that a
certificate authority has taken steps to verify that the web address actually belongs to that organization.
When you type a URL or follow a link to a secure website, your browser checks the certificate for the
following characteristics:
The website address matches the address on the certificate.
The certificate is signed by a certificate authority that the browser recognizes as a trusted authority.
Occasionally users may connect to a server with an untrusted certificate. Azure Firewall will drop the
connection as if the server terminated the connection.
Root CA Cer tificate (root cer tificate)
A certificate authority can issue multiple certificates in the form of a tree structure. A root certificate is the
top-most certificate of the tree.
Azure Firewall Premium can intercept outbound HTTP/S traffic and auto-generate a server certificate for
www.website.com . This certificate is generated using the Intermediate CA certificate that you provide. End-user
browser and client applications (IaaS, PaaS and other workloads) must trust your organization Root CA
certificate or intermediate CA certificate for this procedure to work.
Intermediate CA certificate requirements
Ensure your CA certificate complies with the following requirements:
When deployed as a Key Vault secret, you must use Password-less PFX (Pkcs12) with a certificate and a
private key.
It must be a single certificate, and shouldn’t include the entire chain of certificates.
It must be valid for one year forward.
It must be an RSA private key with minimal size of 4096 bytes.
It must have the KeyUsage extension marked as Critical with the KeyCertSign flag (RFC 5280; 4.2.1.3 Key
Usage).
It must have the BasicContraints extension marked as Critical (RFC 5280; 4.2.1.9 Basic Constraints).
The CA flag must be set to TRUE.
The Path Length must be greater than or equal to one.
Azure Key Vault

Azure Key Vault is a platform-managed secret store that you can use to safeguard secrets, keys, and TLS/SSL
certificates. Azure Firewall Premium supports integration with Key Vault for server certificates that are attached
to a Firewall Policy.
To configure your key vault:
You need to import an existing certificate with its key pair into your key vault.
Alternatively, you can also use a key vault secret that's stored as a password-less, base-64 encoded PFX file. A
PFX file is a digital certificate containing both private key and public key.
It's recommended to use a CA certificate import because it allows you to configure an alert based on
certificate expiration date.
After you've imported a certificate or a secret, you need to define access policies in the key vault to allow the
identity to be granted get access to the certificate/secret.
The provided CA certificate needs to be trusted by your Azure workload. Ensure they are deployed correctly.
The Key Vault Networking must be set to allow access from All networks .
You can either create or reuse an existing user-assigned managed identity, which Azure Firewall uses to retrieve
certificates from Key Vault on your behalf. For more information, see What is managed identities for Azure
resources?
Configure a certificate in your policy

To configure a CA certificate in your Firewall Premium policy, select your policy and then select TLS inspection .
Select Enabled on the TLS inspection page. Then select your CA certificate in Azure Key Vault, as shown in the
following figure:
IMPORTANT
To see and configure a certificate from the Azure portal, you must add your Azure user account to the Key Vault Access
policy. Give your user account Get and List under Secret Permissions .
Create your own self-signed CA certificate

If you want to create your own certificates to help you test and verify TLS inspection, you can use the following
scripts to create your own self-signed Root CA and Intermediate CA.
IMPORTANT
For production, you should use your corporate PKI to create an Intermediate CA certificate. A corporate PKI leverages the
existing infrastructure and handles the Root CA distribution to all endpoint machines. For more information, see Deploy
and configure Enterprise CA certificates for Azure Firewall.
There are two versions of this script:

a bash script cert.sh
a PowerShell script cert.ps1
Also, both scripts use the openssl.cnf configuration file. To use the scripts, copy the contents of openssl.cnf ,
and cert.sh or cert.ps1 to your local computer.
The scripts generate the following files:
rootCA.crt/rootCA.key - Root CA public certificate and private key.
interCA.crt/interCA.key - Intermediate CA public certificate and private key
interCA.pfx - Intermediate CA pkcs12 package which will be used by firewall
IMPORTANT
rootCA.key should be stored in a secure offline location. The scripts generate a certificate with validity of 1024 days. The
scripts require openssl binaries installed in your local machine. For more information see https://www.openssl.org/
After the certificates are created, deploy them to the following locations:
rootCA.crt - Deploy on endpoint machines (Public certificate only).
interCA.pfx - Import as certificate on a Key Vault and assign to firewall policy.
openssl.cnf
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha512
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ interCA_ext ]
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ server_ext ]
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
Bash script - cert.sh

#!/bin/bash
# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj
"/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext
# Create intermediate CA request

openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj
"/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"
# Sign on the intermediate CA

openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days
1024 -sha256 -extfile openssl.cnf -extensions interCA_ext
# Export the intermediate CA into PFX

openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"
echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo " - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo " - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo " - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"
PowerShell - cert.ps1
# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj
'/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext
# Create intermediate CA request

openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj
'/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'
# Sign on the intermediate CA

openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days
3650 -sha256 -extfile openssl.cnf -extensions interCA_ext
# Export the intermediate CA into PFX

openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'
Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host " - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host " - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host " - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"
Certificate auto-generation
For non-production deployments, you can use the Azure Firewall Premium Certification Auto-Generation
mechanism, which automatically creates the following three resources for you:
Managed Identity
Key Vault
Self-signed Root CA certificate
Just choose the new managed identity, and it ties the three resources together in your Premium policy and sets
up TLS inspection.
Troubleshooting
If your CA certificate is valid, but you can’t access FQDNs or URLs under TLS inspection, check the following
items:
Ensure the web server certificate is valid.
Ensure the Root CA certificate is installed on client operating system.
Ensure the browser or HTTPS client contains a valid root certificate. Firefox and some other browsers may
have special certification policies.
Ensure the URL destination type in your application rule covers the correct path and any other hyperlinks
embedded in the destination HTML page. You can use wildcards for easy coverage of the entire required
URL path.
Next steps
Learn more about Azure Firewall Premium features
Azure Firewall web categories
social media websites, and others. The categories are organized based on severity under Liability, High-
Bandwidth, Business use, Productivity loss, General surfing, and Uncategorized.
Liability
Alcohol + tobacco Sites that are contain, promote, or sell alcohol- or tobacco-
related products or services.
Child abuse images Sites that present or discuss children in abusive or sexual
acts.
Child inappropriate Sites that are unsuitable for children, which may contain R-
rated or tasteless content, profanity, or adult material.
Criminal activity Sites that promote or advise on how to commit illegal or

criminal activity, or to avoid detection for such activity.
Criminal activity includes murder, building bombs, illegal
manipulation of electronic devices, hacking, fraud, and illegal
distribution of software.
Dating + personals Sites that promote networking for relationships such as

dating and marriage, such as matchmaking, online dating,
and spousal introduction.
Gambling Sites that offer or related to online gambling, lottery, betting

agencies involving chance, and casinos.
Hacking Sites that promote or advise on how to get unauthorized

access to proprietary computer systems, for stealing
information, perpetrating fraud, creating viruses, or
committing other illegal activity related to theft or digital
inform.
Hate + intolerance Sites that promote a supremacist political agenda,

encouraging oppression of people or groups of people
based on their race, religion, gender, age, disability, sexual
orientation, or nationality.
Illegal drug Sites with information on the purchase, manufacture, and

use of illegal or recreational drugs, and misuse of
prescription drugs and other compounds.
Illegal software Sites that illegally distribute software or copyrighted

materials such as movies, music, software cracks, illicit serial
numbers, illegal license key generators.
Lingerie + swimsuits Sites that offer images of models in suggestive costume,

with semi-nudity permitted. Includes sites offering lingerie or
swimwear.
Marijuana Sites that contain information, discussions, or sale of

marijuana and associated products or services, including
legalizing marijuana and/or using marijuana for medicinal
purposes.
Nudity Sites that contain full or partial nudity that are not
necessarily overtly sexual in intent.
Pornography/sexually explicit Sites that contain explicit sexual content. Includes adult
products such as sex toys, CD-ROMs, and videos, adult
services such as videoconferencing, escort services, and strip
clubs, erotic stories, and textual descriptions of sexual acts.
School cheating Sites that promote unethical practices such as cheating or

plagiarism by providing test answers, written essays,
research papers, or term papers.
Self-harm Sites that promote actions that are relating to harming

oneself, such as suicide, anorexia, bulimia, etc.
Sex education Sites relating to sex education, including subjects such as

respect for partner, abortion, contraceptives, sexually
transmitted diseases, and pregnancy.
Tasteless Sites with offensive or tasteless content, including profanity.
Violence Sites that contain images or text depicting or advocating

physical assault against humans, animals, or institutions.
Sites of gruesome nature.
Weapons Sites that depict, sell, review, or describe guns and weapons,
including for sport.
High bandwidth
Image sharing Sites that host digital photographs and images, online photo
albums, and digital photo exchanges.
Peer-to-peer Sites that enable direct exchange of files between users

without dependence on a central server.
Streaming media + downloads Sites that deliver streaming content, such as Internet radio,
Internet TV or MP3 and live or archived media download
sites. Includes fan sites, or official sites run by musicians,
bands, or record labels.
Download sites Sites that contain downloadable software, whether

shareware, freeware, or for a charge.
Entertainment Sites containing programming guides to television, movies,

music and video (including video on demand), celebrity sites,
and entertainment news.
Business use
Business Sites that provide business related information such as

corporate web sites. Information, services, or products that
help businesses of all sizes to do their day-to-day
commercial activities.
Computers + technology Sites that contain information such as product reviews,

discussions, and news about computers, software, hardware,
peripheral, and computer services.
Education Sites sponsored by educational institutions and schools of all

types including distance education. Includes general
educational and reference materials such as dictionaries,
encyclopedias, online courses, teaching aids and discussion
guides.
Finance Sites related to banking, finance, payment or investment,

including banks, brokerages, online stock trading, stock
quotes, fund management, insurance companies, credit
unions, credit card companies, and so on.
Forums + newsgroups Sites for sharing information in the form of newsgroups,

forums, bulletin boards. Does not include personal blogs.
Government Sites run by governmental or military organizations,

departments, or agencies, including police departments, fire
departments, customs bureaus, emergency services, civil
defense, and counterterrorism organizations.
Health + medicine Sites containing information pertaining to health, healthcare

services, fitness and well-being, including information about
medical equipment, hospitals, drugstores, nursing, medicine,
procedures, prescription medications, etc.
Information security Sites that provide legitimate information about data

protection, including newly discovered vulnerabilities and
how to block them.
Job search Sites containing job listings, career information, assistance

with job searches (such as resume writing, interviewing tips,
etc.), employment agencies or head hunters.
News Sites covering news and current events such as newspapers,

newswire services, personalized news services, broadcasting
sites, and magazines.
Non-profits + NGOs Sites devoted to clubs, communities, unions, and non-profit

organizations. Many of these groups exist for educational or
charitable purposes.
Personal sites Sites about or hosted by personal individuals, including

those hosted on commercial sites such as Blogger, AOL, etc.
Private IP addresses Sites that are private IP addresses as defined in RFC 1918,
that is, hosts that do not require access to hosts in other
enterprises (or require limited access) and whose IP address
may be ambiguous between enterprises but are well-defined
within a certain enterprise.
Professional networking Sites that enable professional networking for online

communities.
Search engines + portals Sites enabling the searching of the Web, newsgroups,
images, directories, and other online content. Includes portal
and directory sites such as white/yellow pages.
Translators Sites that translate Web pages or phrases from one

language to another. These sites bypass the proxy server,
presenting the risk that unauthorized content may be
accessed, similar to using an anonymizer.
File repository Web pages including collections of shareware, freeware,

open source, and other software downloads.
Web-based email Sites that enable users to send and receive email through a
web accessible email account.
Productivity loss
Advertisements + popups Sites that provide advertising graphics or other ad content

files that appear on Web pages.
Chat Sites that enable web-based exchange of real-time messages

through chat services or chat rooms.
Cults Sites relating to non-traditional religious practice typically

known as "cults," that is, considered to be false, unorthodox,
extremist, or coercive, with members often living under the
direction of a charismatic leader.
Games Sites relating to computer or other games, information

about game producers, or how to obtain cheat codes.
Game-related publication sites.
Instant messaging Sites that enable logging in to instant messaging services

such as ICQ, AOL Instant Messenger, IRC, MSN, Jabber,
Yahoo Messenger, and the like.
Shopping Sites for online shopping, catalogs, online ordering, auctions,

classified ads. Excludes shopping for products and services
exclusively covered by another category such as health &
medicine.
Social networking Sites that enable social networking for online communities of
various topics, for friendship, or/and dating.
General surfing
Arts Sites with artistic content or relating to artistic institutions

such as theaters, museums, galleries, dance companies,
photography, and digital graphic resources.
Fashion + Beauty Sites concerning fashion, jewelry, glamour, beauty, modeling,

cosmetics, or related products or services. Includes product
reviews, comparisons, and general consumer information.
General Sites that do not clearly fall into other categories, for
example, blank web pages.
Greeting cards Sites that allow people to send and receive greeting cards
and postcards.
Leisure + recreation Sites relating to recreational activities and hobbies including

zoos, public recreation centers, pools, amusement parks, and
hobbies such as gardening, literature, arts & crafts, home
improvement, home décor, family, etc.
Nature + conservation Sites with information related to environmental issues,

sustainable living, ecology, nature, and the environment.
Politics Sites that promote political parties or political advocacy, or

provide information about political parties, interest groups,
elections, legislation, or lobbying. Also includes sites that
offer legal information and advice.
Real estate Sites relating to commercial or residential real estate

services, including renting, purchasing, selling or financing
homes, offices, etc.
Religion Sites that deal with faith, human spirituality or religious

beliefs, including sites of churches, synagogues, mosques,
and other houses of worship.
Restaurants + dining Sites that list, review, promote or advertise food, dining or
catering services. Includes sites for recipes sites, cooking
instruction and tips, food products, and wine advisors.
Sports Sites relating to sports teams, fan clubs, scores, and sports
news. Relates to all sports, whether professional or
recreational.
Transportation Sites that include information about motor vehicles such as

cars, motorcycles, boats, trucks, RVs and the like, including
online purchase sites. Includes manufacturer sites,
dealerships, review sites, pricing, enthusiast’s clubs, and
public transportation etc.
Travel Sites that provide travel and tourism information or online

booking or travel services such as airlines, accommodations,
car rentals. Includes regional or city information sites.
Uncategorized Sites that have not been categorized, such as new websites,
personal sites, and so on.
Next steps
Quickstart: Create an Azure Firewall and a firewall policy - ARM template
Quickstart: Deploy Azure Firewall with Availability Zones - ARM template
Tutorial: Deploy and configure Azure Firewall using the Azure portal
FQDN tags overview
An FQDN tag represents a group of fully qualified domain names (FQDNs) associated with well known
Microsoft services. You can use an FQDN tag in application rules to allow the required outbound network traffic
through your firewall.
For example, to manually allow Windows Update network traffic through your firewall, you need to create
multiple application rules per the Microsoft documentation. Using FQDN tags, you can create an application
rule, include the Windows Updates tag, and now network traffic to Microsoft Windows Update endpoints can
flow through your firewall.
You can't create your own FQDN tags, nor can you specify which FQDNs are included within a tag. Microsoft
manages the FQDNs encompassed by the FQDN tag, and updates the tag as FQDNs change.
The following table shows the current FQDN tags you can use. Microsoft maintains these tags and you can
expect additional tags to be added periodically.
Current FQDN tags

F Q DN TA G DESC RIP T IO N
WindowsUpdate Allow outbound access to Microsoft Update as described in

How to Configure a Firewall for Software Updates.
WindowsDiagnostics Allow outbound access to all Windows Diagnostics

endpoints.
MicrosoftActiveProtectionService (MAPS) Allow outbound access to MAPS.
AppServiceEnvironment (ASE) Allows outbound access to ASE platform traffic. This tag
doesn’t cover customer-specific Storage and SQL endpoints
created by ASE. These should be enabled via Service
Endpoints or added manually.
For more information about integrating Azure Firewall with

ASE, see Locking down an App Service Environment.
AzureBackup Allows outbound access to the Azure Backup services.
AzureHDInsight Allows outbound access for HDInsight platform traffic. This

tag doesn’t cover customer-specific Storage or SQL traffic
from HDInsight. Enable these using Service Endpoints or add
them manually.
WindowsVirtualDesktop Allows outbound Azure Virtual Desktop (formerly Windows

Virtual Desktop) platform traffic. This tag doesn’t cover
deployment-specific Storage and Service Bus endpoints
created by Azure Virtual Desktop. Additionally, DNS and
KMS network rules are required. For more information about
integrating Azure Firewall with Azure Virtual Desktop, see
Use Azure Firewall to protect Azure Virtual Desktop
deployments.
F Q DN TA G DESC RIP T IO N
AzureKubernetesService (AKS) Allows outbound access to AKS. For more information, see
Use Azure Firewall to protect Azure Kubernetes Service (AKS)
Deployments.
NOTE
When selecting FQDN Tag in an application rule, the protocol:port field must be set to https .
Next steps
To learn how to deploy an Azure Firewall, see Tutorial: Deploy and configure Azure Firewall using the Azure
portal.
Infrastructure FQDNs
FQDNs are specific for the platform and can't be used for other purposes.
The following services are included in the built-in rule collection:
Compute access to storage Platform Image Repository (PIR)
Managed disks status storage access
Azure Diagnostics and Logging (MDS)
Overriding
You can override this built-in infrastructure rule collection by creating a deny all application rule collection that is
processed last. It will always be processed before the infrastructure rule collection. Anything not in the
infrastructure rule collection is denied by default.
Next steps
Learn how to deploy and configure an Azure Firewall.
Azure Firewall logs and metrics
You can monitor Azure Firewall using firewall logs. You can also use activity logs to audit operations on Azure
Firewall resources.
You can access some of these logs through the portal. Logs can be sent to Azure Monitor logs, Storage, and
Event Hubs and analyzed in Azure Monitor logs or by different tools such as Excel and Power BI.
Metrics are lightweight and can support near real-time scenarios making them useful for alerting and fast issue
detection.
Diagnostic logs
The following diagnostic logs are available for Azure Firewall:
Application rule log
The Application rule log is saved to a storage account, streamed to Event hubs and/or sent to Azure
Monitor logs only if you've enabled it for each Azure Firewall. Each new connection that matches one of
your configured application rules results in a log for the accepted/denied connection. The data is logged
in JSON format, as shown in the following examples:
Category: application rule logs.

Time: log timestamp.
Properties: currently contains the full message.
note: this field will be parsed to specific fields in the future, while maintaining backward
compatibility with the existing properties field.
{
"category": "AzureFirewallApplicationRule",
"time": "2018-04-16T23:45:04.8295030Z",
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZURE
FIREWALLS/{resourceName}",
"operationName": "AzureFirewallApplicationRuleLog",
"properties": {
"msg": "HTTPS request from 10.1.0.5:55640 to mydestination.com:443. Action: Allow. Rule
Collection: collection1000. Rule: rule1002"
}
}
{
"category": "AzureFirewallApplicationRule",
"time": "2018-04-16T23:45:04.8295030Z",
"resourceId":
"operationName": "AzureFirewallApplicationRuleLog",
"properties": {
"msg": "HTTPS request from 10.11.2.4:53344 to www.bing.com:443. Action: Allow. Rule
Collection: ExampleRuleCollection. Rule: ExampleRule. Web Category: SearchEnginesAndPortals"
}
}
Network rule log
The Network rule log is saved to a storage account, streamed to Event hubs and/or sent to Azure Monitor
logs only if you've enabled it for each Azure Firewall. Each new connection that matches one of your
configured network rules results in a log for the accepted/denied connection. The data is logged in JSON
format, as shown in the following example:
Category: network rule logs.

{
"category": "AzureFirewallNetworkRule",
"time": "2018-06-14T23:44:11.0590400Z",
"resourceId":
"operationName": "AzureFirewallNetworkRuleLog",
"properties": {
"msg": "TCP request from 111.35.136.173:12518 to 13.78.143.217:2323. Action: Deny"
}
}
DNS proxy log

The DNS Proxy log is saved to a storage account, streamed to Event hubs, and/or sent to Azure Monitor
logs only if you’ve enabled it for each Azure Firewall. This log tracks DNS messages to a DNS server
configured using DNS proxy. The data is logged in JSON format, as shown in the following examples:
Category: DNS proxy logs.

Success:
{
"category": "AzureFirewallDnsProxy",
"time": "2020-09-02T19:12:33.751Z",
"resourceId":
"operationName": "AzureFirewallDnsProxyLog",
"properties": {
"msg": "DNS Request: 11.5.0.7:48197 – 15676 AAA IN md-l1l1pg5lcmkq.blob.core.windows.net. udp
55 false 512 NOERROR - 0 2.000301956s"
}
}
Failed:
{
"category": "AzureFirewallDnsProxy",
"time": "2020-09-02T19:12:33.751Z",
"resourceId":
"operationName": "AzureFirewallDnsProxyLog",
"properties": {
"msg": " Error: 2 time.windows.com.reddog.microsoft.com. A: read udp 10.0.1.5:49126-
>168.63.129.160:53: i/o timeout”
}
}
msg format:
[client’s IP address]:[client’s port] – [query ID] [type of the request] [class of the request] [name
of the request] [protocol used] [request size in bytes] [EDNS0 DO (DNSSEC OK) bit set in the query]
[EDNS0 buffer size advertised in the query] [response CODE] [response flags] [response size] [response
duration]
You have three options for storing your logs:

Storage account : Storage accounts are best used for logs when logs are stored for a longer duration and
reviewed when needed.
Event hubs : Event hubs are a great option for integrating with other security information and event
management (SEIM) tools to get alerts on your resources.
Azure Monitor logs : Azure Monitor logs is best used for general real-time monitoring of your application
or looking at trends.
Activity logs
Activity log entries are collected by default, and you can view them in the Azure portal.
You can use Azure activity logs (formerly known as operational logs and audit logs) to view all operations
submitted to your Azure subscription.
Metrics
Metrics in Azure Monitor are numerical values that describe some aspect of a system at a particular time.
Metrics are collected every minute, and are useful for alerting because they can be sampled frequently. An alert
can be fired quickly with relatively simple logic.
The following metrics are available for Azure Firewall:
Application rules hit count - The number of times an application rule has been hit.
Unit: count
Network rules hit count - The number of times a network rule has been hit.
Unit: count
Data processed - Sum of data traversing the firewall in a given time window.
Unit: bytes
Throughput - Rate of data traversing the firewall per second.
Unit: bits per second
Firewall health state - Indicates the health of the firewall based on SNAT port availability.
Unit: percent
This metric has two dimensions:
Status: Possible values are Healthy, Degraded, Unhealthy.
Reason: Indicates the reason for the corresponding status of the firewall.
If SNAT ports are used > 95%, they are considered exhausted and the health is 50% with
status=Degraded and reason=SNAT por t . The firewall keeps processing traffic and existing
connections are not affected. However, new connections may not be established intermittently.
If SNAT ports are used < 95%, then firewall is considered healthy and health is shown as 100%.
If no SNAT ports usage is reported, health is shown as 0%.
SNAT por t utilization - The percentage of SNAT ports that have been utilized by the firewall.
Unit: percent
When you add more public IP addresses to your firewall, more SNAT ports are available, reducing the
SNAT ports utilization. Additionally, when the firewall scales out for different reasons (for example, CPU
or throughput) additional SNAT ports also become available. So effectively, a given percentage of SNAT
ports utilization may go down without you adding any public IP addresses, just because the service
scaled out. You can directly control the number of public IP addresses available to increase the ports
available on your firewall. But, you can't directly control firewall scaling.
If your firewall is running into SNAT port exhaustion, you should add at least five public IP address. This
increases the number of SNAT ports available. For more information, see Azure Firewall features.
Next steps
To learn how to monitor Azure Firewall logs and metrics, see Tutorial: Monitor Azure Firewall logs.
To learn more about metrics in Azure Monitor, see Metrics in Azure Monitor.
Azure Firewall threat intelligence-based filtering
Threat intelligence-based filtering can be enabled for your firewall to alert and deny traffic from/to known
malicious IP addresses, FQDNs, and URLs. The IP addresses, domains and URLs are sourced from the Microsoft
Threat Intelligence feed, which includes multiple sources including the Microsoft Cyber Security team. Intelligent
Security Graph powers Microsoft threat intelligence and is used by multiple services including Microsoft
Defender for Cloud.
If you've enabled threat intelligence-based filtering, the associated rules are processed before any of the NAT
rules, network rules, or application rules.
You can choose to just log an alert when a rule is triggered, or you can choose alert and deny mode.
By default, threat intelligence-based filtering is enabled in alert mode. You can’t turn off this feature or change
the mode until the portal interface becomes available in your region.
Logs
The following log excerpt shows a triggered rule:
{
"category": "AzureFirewallNetworkRule",
"time": "2018-04-16T23:45:04.8295030Z",
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWAL
LS/{resourceName}",
"operationName": "AzureFirewallThreatIntelLog",
"properties": {
"msg": "HTTP request from 10.0.0.5:54074 to somemaliciousdomain.com:80. Action: Alert. ThreatIntel:
Bot Networks"
}
}
Testing
Outbound testing - Outbound traffic alerts should be a rare occurrence, as it means that your
environment has been compromised. To help test outbound alerts are working, a test FQDN has been
created that triggers an alert. Use testmaliciousdomain.eastus.cloudapp.azure.com for your outbound
tests.
Inbound testing - You can expect to see alerts on incoming traffic if DNAT rules are configured on the
firewall. This is true even if only specific sources are allowed on the DNAT rule and traffic is otherwise
denied. Azure Firewall doesn't alert on all known port scanners; only on scanners that are known to also
engage in malicious activity.
Next steps
See Azure Firewall Log Analytics samples
Learn how to deploy and configure an Azure Firewall
Review the Microsoft Security intelligence report
Azure Firewall Policy rule sets
Firewall Policy is a top-level resource that contains security and operational settings for Azure Firewall. You can
use Firewall Policy to manage rule sets that the Azure Firewall uses to filter traffic. Firewall policy organizes,
prioritizes, and processes the rule sets based on a hierarchy with the following components: rule collection
groups, rule collections, and rules.
Rule collection groups

A rule collection group is used to group rule collections. They're the first unit to be processed by the Azure
Firewall and they follow a priority order based on values. There are three default rule collection groups, and
their priority values are preset by design. They're processed in the following order:
RUL E C O L L EC T IO N GRO UP N A M E P RIO RIT Y
Default DNAT (Destination Network Address Translation) rule 100

collection group
Default Network rule collection group 200
Default Application rule collection group 300
Even though you can't delete the default rule collection groups nor modify their priority values, you can
manipulate their processing order in a different way. If you need to define a priority order that is different than
the default design, you can create custom rule collection groups with your wanted priority values. In this
scenario, you don't use the default rule collection groups at all and use only the ones you create to customize
the processing logic.
Rule collection groups contain one or multiple rule collections, which can be of type DNAT, network, or
application. For example, you can group rules belonging to the same workloads or a VNet in a rule collection
group.
Rule collection groups have a maximum size of 2 MB. If you need more than 2 MB, you can split the rules into
multiple rule collection groups. A Firewall Policy can contain 50 rule collection groups.
Rule collections
A rule collection belongs to a rule collection group, and it contains one or multiple rules. They're the second unit
processed by the firewall and they follow a priority order based on values. Rule collections must have a defined
action (allow or deny) and a priority value. The defined action applies to all the rules within the rule collection.
The priority value determines order the rule collections are processed.
There are three types of rule collections:
DNAT
Network
Application
Rule collection types must match their parent rule collection group category. For example, a DNAT rule
collection can only be part of a DNAT rule collection group.
Rules
A rule belongs to a rule collection, and it specifies which traffic is allowed or denied in your network. They're the
third unit to be processed by the firewall and they don't follow a priority order based on values. The processing
logic for rules follows a top-down approach. All traffic that passes through the firewall is evaluated by the
defined rules for an allow or deny match. If there's no rule that allows the traffic, then the traffic is denied by
default.
For application rules, the traffic is processed by our built-in infrastructure rule collection before it's denied by
default.
There are three types of rules:
DNAT
Network
Application
DNAT rules
DNAT rules allow or deny inbound traffic through the firewall public IP address(es). You can use a DNAT rule
when you want a public IP address to be translated into a private IP address. The Azure Firewall public IP
addresses can be used to listen to inbound traffic from the Internet, filter the traffic and translate this traffic to
internal resources in Azure.
Network rules
Network rules allow or deny inbound, outbound, and east-west traffic based on the network layer (L3) and
transport layer (L4).
You can use a network rule when you want to filter traffic based on IP addresses, any ports, and any protocols.
Application rules
Application rules allow or deny inbound, outbound, and east-west traffic based on the application layer (L7). You
can use an application rule when you want to filter traffic based on fully qualified domain names (FQDNs) and
HTTP/HTTPS protocols.
Next steps
Learn more about Azure Firewall rule processing: Configure Azure Firewall rules.
Configure Azure Firewall rules
You can configure NAT rules, network rules, and applications rules on Azure Firewall using either classic rules or
Firewall Policy. Azure Firewall denies all traffic by default, until rules are manually configured to allow traffic.
Rule processing using classic rules

Rule collections are processed according to the rule type in priority order, lower numbers to higher numbers
from 100 to 65,000. A rule collection name can have only letters, numbers, underscores, periods, or hyphens. It
must begin with a letter or number, and end with a letter, number, or underscore. The maximum name length is
80 characters.
It's best to initially space your rule collection priority numbers in 100 increments (100, 200, 300, and so on) so
you have room to add more rule collections if needed.
Rule processing using Firewall Policy

With Firewall Policy, rules are organized inside Rule Collections and Rule Collection Groups. Rule Collection
Groups contain zero or more Rule Collections. Rule Collections are type NAT, Network, or Applications. You can
define multiple Rule Collection types within a single Rule Group. You can define zero or more Rules in a Rule
Collection. Rules in a Rule Collection must be of the same type (NAT, Network, or Application).
Rules are processed based on Rule Collection Group Priority and Rule Collection priority. Priority is any number
between 100 (highest priority) to 65,000 (lowest priority). Highest priority Rule Collection Groups are processed
first. Inside a rule collection group, Rule Collections with highest priority (lowest number) are processed first.
If a Firewall Policy is inherited from a parent policy, Rule Collection Groups in the parent policy always takes
precedence regardless of the priority of a child policy.
NOTE
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.
Here's an example policy:
NAME TYPE P RIO RIT Y RUL ES IN H ERIT ED F RO M
BaseRCG1 Rule collection group 200 8 Parent policy
DNATRC1 DNAT rule collection 600 7 Parent policy
DNATRC3 DNAT rule collection 610 3 Parent policy
NetworkRc1 Network rule 800 1 Parent policy

collection
BaseRCG2 Rule collection group 300 3 Parent policy

NAME TYPE P RIO RIT Y RUL ES IN H ERIT ED F RO M
AppRCG2 Application rule 1200 2 Parent policy

collection
NetworkRC2 Network rule 1300 1 Parent policy

collection
ChildRCG1 Rule collection group 300 5 -
ChAppRC1 Application rule 700 3 -

collection
ChNetRC1 Network rule 900 2 -

collection
ChildRCG2 Rule collection group 650 9 -
ChNetRC2 Network rule 1100 2 -

collection
ChAppRC2 Application rule 2000 7 -

collection
ChDNATRC3 DNAT rule collection 3000 2 -
The rule processing will be in the following order: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1,
NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
For more information about Firewall Policy rule sets, see Azure Firewall Policy rule sets.
Threat Intelligence
If you enable threat intelligence-based filtering, those rules are highest priority and are always processed first
(before network and application rules). Threat-intelligence filtering may deny traffic before any configured rules
are processed. For more information, see Azure Firewall threat intelligence-based filtering.
IDPS
When IDPS is configured in Alert mode, the IDPS engine works in parallel to the rule processing logicand
generates alerts on matching signatures for both inbound and outbound flows.For an IDPS signature match, an
alert is logged in firewall logs. However, since the IDPS engine works in parallel to the rule processing
engine,traffic that is denied/allowed by application/network rules may still generate another log entry.
When IDPS is configured in Alertand Denymode, the IDPS engine isinlineand activated after the rules processing
engine. So bothengines generate alertsand may blockmatching flows.
Session drops done by IDPS blocks the flow silently. So no RST is sent on the TCP level.Since IDPS inspects traffic
always after the Network/Application rule has been matched (Allow/Deny) and marked in logs, another Drop
message may be logged where IDPS decides to deny the session because of a signature match.
When TLS inspection is enabled both unencrypted and encrypted traffic is inspected.
Outbound connectivity
Network rules and applications rules
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. If configured, IDPS is done on all traversed traffic and upon signature match, IDPS may alert or/and
block suspicious traffic.
If there's no network rule match, and if the protocol is HTTP, HTTPS, or MSSQL, the packet is then evaluated by
the application rules in priority order.
For HTTP, Azure Firewall looks for an application rule match according to the Host header. For HTTPS, Azure
Firewall looks for an application rule match according to SNI only.
In both HTTP and TLS inspected HTTPS cases, the firewall ignores the packet's destination IP address and uses
the DNS resolved IP address from the Host header. The firewall expects to get port number in the Host header,
otherwise it assumes the standard port 80. Ifthere's a port mismatch between the actual TCP port and the port
in the host header, the traffic is dropped.DNS resolution is done by Azure DNS or by a custom DNS if configured
on the firewall.
NOTE
Both HTTPand HTTPS protocols (with TLS inspection) are always filled by Azure Firewall with XFF (X-Forwarded-For)
header equal to the original source IP address.
When an application rule contains TLS inspection, the firewall rules engine process SNI, Host Header, and also
the URL to match the rule.
If still no match is found within application rules, then the packet is evaluated against theinfrastructure rule
collection. If there's still no match, then the packet is denied by default.
NOTE
Network rules can be configured forTCP,UDP,ICMP, orAnyIP protocol. Any IP protocol includes all the IP protocols as
defined in theInternet Assigned Numbers Authority (IANA) Protocol Numbersdocument. If a destination port is explicitly
configured, then the rule is translated to a TCP+UDP rule. Before November 9, 2020,AnymeantTCP, orUDP, orICMP. So,
you might have configured a rule before that date with Protocol = Any , and destination por ts = '*' . If you don't
intend to allow any IP protocol as currently defined, then modify the rule to explicitly configure the protocol(s) you want
(TCP, UDP, or ICMP).
Inbound connectivity
DNAT rules and Network rules
Inbound Internet connectivity can be enabled by configuring Destination Network Address Translation (DNAT) as
described in Tutorial: 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, an implicit corresponding network rule to allow the
translated traffic is added. For security reasons, the recommended approach is to add a specific internet source
to allow DNAT access to the network and avoid using wildcards.
Application rules aren't applied for inbound connections. So if you want to filter inbound HTTP/S traffic, you
should use Web Application Firewall (WAF). For more information, see What is Azure Web Application Firewall?
Examples
The following examples show the results of some of these rule combinations.
Example 1
Connection to google.com is allowed because of a matching network rule.
Network rule
Action: Allow
DEST IN AT IO N DEST IN AT IO N DEST IN AT IO N

NAME P ROTO C O L SO URC E T Y P E SO URC E TYPE A DDRESS P O RT S
Allow-web TCP IP address * IP address * 80,443
Application rule
Action: Deny
NAME SO URC E T Y P E SO URC E P ROTO C O L : P O RT TA RGET F Q DN S
Deny-google IP address * http:80,https:443 google.com
Result
The connection to google.com is allowed because the packet matches the Allow-web network rule. Rule
processing stops at this point.
Example 2
SSH traffic is denied because a higher priority Deny network rule collection blocks it.
Network rule collection 1
Name: Allow-collection
Priority: 200
Action: Allow

Allow-SSH TCP IP address * IP address * 22
Network rule collection 2

Name: Deny-collection
Priority: 100
Action: Deny

Deny-SSH TCP IP address * IP address * 22
Result
SSH connections are denied because a higher priority network rule collection blocks it. Rule processing stops at
this point.
Rule changes
If you change a rule to deny previously allowed traffic, any relevant existing sessions are dropped.
Three-way handshake behavior
As a stateful service, Azure Firewall completes a TCP three-way handshake for allowed traffic, from a source to
the destination.For example, VNet-A to VNet-B.
Creating an allow rule from VNet-A to VNet-B doesn't mean thatnew initiated connectionsfrom VNet-B to VNet-
Aare allowed.
As a result, there's no need to create an explicit deny rule from VNet-B to VNet-A. If you create this deny rule,
you'llinterrupt the three-way handshake from the initial allow rule from VNet-A to VNet-B.
Next steps
Azure Firewall service tags
A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation.
You can’t create your own service tag, nor specify which IP addresses are included within a tag. Microsoft
manages the address prefixes encompassed by the service tag, and automatically updates the service tag as
addresses change.
Azure Firewall service tags can be used in the network rules destination field. You can use them in place of
specific IP addresses.
Supported service tags

See Virtual network service tags for a list of service tags that are available for use in Azure firewall network
rules.
Configuration
Azure Firewall supports configuration of service tags via PowerShell, Azure CLI, or the Azure portal.
Configure via Azure PowerShell
In this example, we must first get context to our previously created Azure Firewall instance.
$FirewallName = "AzureFirewall"
$ResourceGroup = "AzureFirewall-RG"
$azfirewall = Get-AzFirewall -Name $FirewallName -ResourceGroupName $ResourceGroup
Next, we must create a new rule. For the Destination, you can specify the text value of the service tag you wish to
leverage, as mentioned previously.
$rule = New-AzFirewallNetworkRule -Name "AllowSQL" -Description "Allow access to Azure Database as a Service
(SQL, MySQL, PostgreSQL, Datawarehouse)" -SourceAddress "10.0.0.0/16" -DestinationAddress Sql -
DestinationPort 1433 -Protocol TCP
$ruleCollection = New-AzFirewallNetworkRuleCollection -Name "Data Collection" -Priority 1000 -Rule $rule -
ActionType Allow
Next, we must update the variable containing our Azure Firewall definition with the new network rules we
created.
$azFirewall.NetworkRuleCollections.add($ruleCollection)
Last, we must commit the Network Rule changes to the running Azure Firewall instance.
Set-AzFirewall -AzureFirewall $azfirewall
Next steps
To learn more about Azure Firewall rules, see Azure Firewall rule processing logic.
IP Groups in Azure Firewall
IP Groups allow you to group and manage IP addresses for Azure Firewall rules in the following ways:
As a source address in DNAT rules
As a source or destination address in network rules
As a source address in application rules
An IP Group can have a single IP address, multiple IP addresses, or one or more IP address ranges.
IP Groups can be reused in Azure Firewall DNAT, network, and application rules for multiple firewalls across
regions and subscriptions in Azure. Group names must be unique. You can configure an IP Group in the Azure
portal, Azure CLI, or REST API. A sample template is provided to help you get started.
NOTE
IP Groups are not currently available in Azure national cloud environments.
Sample format
The following IPv4 address format examples are valid to use in IP Groups:
Single address: 10.0.0.0
CIDR notation: 10.1.0.0/32
Address range: 10.2.0.0-10.2.0.31
Create an IP Group
An IP Group can be created using the Azure portal, Azure CLI, or REST API. For more information, see Create an
IP Group.
Browse IP Groups
1. In the Azure portal search bar, type IP Groups and select it. You can see the list of the IP Groups, or you
can select Add to create a new IP Group.
2. Select an IP Group to open the overview page. You can edit, add, or delete IP addresses or IP Groups.
Manage an IP Group
You can see all the IP addresses in the IP Group and the rules or resources that are associated with it. To delete
an IP Group, you must first dissociate the IP Group from the resource that is using it.
1. To view or edit the IP addresses, select IP Addresses under Settings on the left pane.
2. To add a single or multiple IP address(es), select Add IP Addresses . This opens the Drag or Browse page
for an upload, or you can enter the address manually.
3. Selecting the ellipses (… ) to the right to edit or delete IP addresses. To edit or delete multiple IP addresses,
select the boxes and select Edit or Delete at the top.
4. Finally, can export the file in the CSV file format.
NOTE
If you delete all the IP addresses in an IP Group while it is still in use in a rule, that rule is skipped.
Use an IP Group
You can now select IP Group as a Source type or Destination type for the IP address(es) when you create
Azure Firewall DNAT, application, or network rules.
Region availability
IP Groups are available in all public cloud regions.
IP address limits
You can have a maximum of 100 IP Groups per firewall with a maximum 5000 individual IP addresses or IP
prefixes per each IP Group.
Related Azure PowerShell cmdlets

The following Azure PowerShell cmdlets can be used to create and manage IP Groups:
New-AzIpGroup
Remove-AzIPGroup
Get-AzIpGroup
Set-AzIpGroup
New-AzFirewallNetworkRule
New-AzFirewallApplicationRule
New-AzFirewallNatRule
Next steps
Azure Firewall forced tunneling
When you configure a new Azure Firewall, you can route all Internet-bound traffic to a designated next hop
instead of going directly to the Internet. For example, you may have a default route advertised via BGP or using
User Defined Route (UDR) to force traffic to an on-premises edge firewall or other network virtual appliance
(NVA) to process network traffic before it's passed to the Internet. To support this configuration, you must create
Azure Firewall with Forced Tunnel configuration enabled. This is a mandatory requirement to avoid service
disruption. If this is a pre-existing firewall, you must recreate the firewall in Forced Tunnel mode to support this
configuration. For more information, see the Azure Firewall FAQ about stopping and restarting a firewall in
Forced Tunnel mode.
Azure Firewall provides automatic SNAT for all outbound traffic to public IP addresses. Azure Firewall doesn’t
SNAT when the destination IP address is a private IP address range per IANA RFC 1918. This logic works
perfectly when you egress directly to the Internet. However, with forced tunneling enabled, Internet-bound traffic
is SNATed to one of the firewall private IP addresses in the AzureFirewallSubnet. This hides the source address
from your on-premises firewall. You can configure Azure Firewall to not SNAT regardless of the destination IP
address by adding 0.0.0.0/0 as your private IP address range. With this configuration, Azure Firewall can never
egress directly to the Internet. For more information, see Azure Firewall SNAT private IP address ranges.
IMPORTANT
If you deploy a Secured Virtual Hub in forced tunnel mode, advertising the default route over Express Route or VPN
Gateway is not currently supported. A fix is being investigated.
Forced tunneling configuration

You can configure Forced Tunneling during Firewall creation by enabling Forced Tunnel mode as shown below.
To support forced tunneling, Service Management traffic is separated from customer traffic. An additional
dedicated subnet named AzureFirewallManagementSubnet (minimum subnet size /26) is required with its
own associated public IP address. This public IP address is for management traffic. It is used exclusively by the
Azure platform and can't be used for any other purpose.
In Forced Tunneling mode, the Azure Firewall service incorporates the Management subnet
(AzureFirewallManagementSubnet) for its operational purposes. By default, the service associates a system-
provided route table to the Management subnet. The only route allowed on this subnet is a default route to the
Internet and Propagate gateway routes must be disabled. Avoid associating customer route tables to the
Management subnet when you create the firewall.
Within this configuration, the AzureFirewallSubnet can now include routes to any on-premises firewall or NVA
to process traffic before it's passed to the Internet. You can also publish these routes via BGP to
AzureFirewallSubnet if Propagate gateway routes is enabled on this subnet.
For example, you can create a default route on the AzureFirewallSubnet with your VPN gateway as the next hop
to get to your on-premises device. Or you can enable Propagate gateway routes to get the appropriate
routes to the on-premises network.
If you enable forced tunneling, Internet-bound traffic is SNATed to one of the firewall private IP addresses in
AzureFirewallSubnet, hiding the source from your on-premises firewall.
If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one
of the firewall private IP addresses in AzureFirewallSubnet. However, you can configure Azure Firewall to not
SNAT your public IP address range. For more information, see Azure Firewall SNAT private IP address ranges.
Once you configure Azure Firewall to support forced tunneling, you can't undo the configuration. If you remove
all other IP configurations on your firewall, the management IP configuration is removed as well and the firewall
is deallocated. The public IP address assigned to the management IP configuration can't be removed, but you
can assign a different public IP address.
Next steps
Azure Firewall certifications
Azure Firewall is Payment Card Industry (PCI), Service Organization Controls (SOC), International Organization
for Standardization (ISO), ICSA Labs, and HITRUST compliant.
The following certifications are for global Azure and Azure Government.
Global Azure certifications

The following Azure Firewall certifications are for global Azure:
23 NYCRR 500
AFM and DNB (Netherlands)
AMF and ACPR (France)
APRA(Australia)
Argentina PDPA
Australia IRAP
CDSA
CFTC 1.31
CSA STAR Attestation
CSA STAR Certification
CSA STAR Self-Assessment
Canadian Privacy Laws
DPP(UK)
EU ENISA IAF
EU Model Clauses
European Banking Authority
FCA and PRA (UK)
FERPA (US)
FFIEC(US)
FINMA (Switzerland)
FSA (Denmark)
GLBA (US)
Germany C5
GxP (FDA 21 CFR Part 11)
HIPAA
HITECH Act (US)
HITRUST
ISO 20000-1:2011
ISO 22301:2012
ISO 27001:2013
ISO 27017:2015
ISO 27018:2014
ISO 9001:2015
Japan My Number Act
K-ISMS
KNF(Poland)
MAS and ABS (Singapore)
MPAA(US)
NBB and FSMA (Belgium)
NEN 7510:2011 (Netherlands)
NHS IG Toolkit (UK)
Netherlands BIR 2012
OSFI(Canada)
PCI DSS Level 1
RBI and IRDAI (India)
SOC 1 Type 2
SOC 2 Type 2
SOC 3
SOX (US)
Spain DPA
TISAX
TruSight
UK G-Cloud
WCAG 2.0
Azure Government certifications

The following Azure Firewall certifications are for Azure Government:
CJIS
CNSSI 1253
CSA STAR Attestation
DFARS
DoD DISA SRG Level 2
DoE 10 CFR Part 810
EAR
FIPS 140-2
FedRAMP High
HIPAA
HITECH Act (US)
HITRUST
IRS 1075
ITAR
MARS-E (US)
NERC
NIST Cybersecurity Framework
NIST SP 800-171
SOC 1 Type 2
SOC 2 Type 2
SOC 3
SOX (US)
Section 508 VPATs
ICSA Labs Corporate Firewall Certification
ICSA Labs is a leading vendor in third-party testing and certification of security and health IT products, as well as
network-connected devices. They measure product compliance, reliability, and performance for most of the
world’s top technology vendors.
Azure Firewall is the first cloud firewall service to attain the ICSA Labs Corporate Firewall Certification.
For the Azure Firewall certification report, see the ICSA Labs Certification Testing and Audit Report.
For the Intrusion Prevention Systems (IPS) report, see Network Intrusion Prevention Systems Certification
Testing Report.
For more information, see the ICSA Labs Firewall Certification Program page.
Next steps
For more information about Microsoft compliance, see the following information.
Microsoft Compliance Guide
Overview of Microsoft Azure compliance
Azure Firewall central management
If you manage multiple firewalls, you know that continuously changing firewall rules make it difficult to keep
them in sync. Central IT teams need a way to define base firewall policies and enforce them across multiple
business units. At the same time, DevOps teams want to create their own local derived firewall policies for better
agility.
Azure Firewall Manager can help solve these problems.
Azure Firewall Manager

Azure Firewall Manager is a network security management service that provides central security policy and
route management for cloud-based security perimeters. It makes it easy for Enterprise IT teams to centrally
define network and application level rules for traffic filtering across multiple Azure Firewall instances. You can
span different Azure regions and subscriptions in hub and spoke architectures for traffic governance and
protection. It also provides DevOps better agility with derivedlocal firewall security policies that are
implemented across organizations.
Firewall policy
A Firewall policy is an Azure resource that contains NAT, network, and application rule collections and Threat
Intelligence settings. It's a global resource that can be used across multiple Azure Firewall instances in Secured
Virtual Hubs and Hub Virtual Networks. New policies can be created from scratch or inherited from existing
policies. Inheritance allows DevOps to create local firewall policies on top of organization mandated base policy.
Policies work across regions and subscriptions.
You can create Firewall Policy and associations with Azure Firewall Manager. However, you can also create and
manage a policy using REST API, templates, Azure PowerShell, and CLI. Once you create a policy, you can
associate it with a firewall in a virtual WAN hub making it a Secured Virtual Hub and/or a firewall in a virtual
network making it Hub Virtual Network.
Pricing
Policies are billed based on firewall associations. A policy with zero or one firewall association is free of charge.
A policy with multiple firewall associations is billed at a fixed rate. For more information, see Azure Firewall
Manager Pricing.
Azure Firewall Management partners

The following leading third-party solutions support Azure Firewall central management using standard Azure
REST APIs. Each of these solutions has its own unique characteristics and features:
AlgoSec CloudFlow
Barracuda Cloud Security Guardian
Tufin Orca
Next steps
For more information about Azure Firewall Manager, see What is Azure Firewall Manager?
Azure Firewall remote work support
Azure Firewall is a managed, cloud-based network security service that protects your Azure virtual network
resources. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability.
Virtual Desktop Infrastructure (VDI) deployment support

Work from home policies requires many IT organizations to address fundamental changes in capacity, network,
security, and governance. Employees aren't protected by the layered security policies associated with on-
premises services while working from home. Virtual Desktop Infrastructure (VDI) deployments on Azure can
help organizations rapidly respond to this changing environment. However, you need a way to protect
inbound/outbound Internet access to and from these VDI deployments. You can use Azure Firewall DNAT rules
along with its threat intelligence based filtering capabilities to protect your VDI deployments.
Azure Virtual Desktop support

Azure Virtual Desktop is a comprehensive desktop and app virtualization service running in Azure. It’s the only
virtual desktop infrastructure (VDI) that delivers simplified management, multi-session Windows 10/11,
optimizations for Microsoft 365 apps for enterprise, and support for Remote Desktop Services (RDS)
environments. You can deploy and scale your Windows desktops and apps on Azure in minutes, and get built-in
security and compliance features. Azure Virtual Desktop doesn't require you to open any inbound access to your
virtual network. However, you must allow a set of outbound network connections for the Azure Virtual Desktop
virtual machines that run in your virtual network. For more information, see Use Azure Firewall to protect Azure
Virtual Desktop deployments.
Next steps
Learn more about Azure Virtual Desktop.
Use FQDN filtering in network rules
A fully qualified domain name (FQDN) represents a domain name of a host or IP address(es). You can use
FQDNs in network rules based on DNS resolution in Azure Firewall and Firewall policy. This capability allows
you to filter outbound traffic with any TCP/UDP protocol (including NTP, SSH, RDP, and more). You must enable
DNS Proxy to use FQDNs in your network rules. For more information see Azure Firewall DNS settings.
NOTE
By design, FQDN filtering in network rules doesn’t support wildcards
How it works
Once you define which DNS server your organization needs (Azure DNS or your own custom DNS), Azure
Firewall translates the FQDN to an IP address(es) based on the selected DNS server. This translation happens for
both application and network rule processing.
When a new DNS resolution takes place, new IP addresses are added to firewall rules. Old IP addresses that are
no longer returned by the DNS server expire in 15 minutes. Azure Firewall rules are updated every 15 seconds
from DNS resolution of the FQDNs in network rules.
Differences in application rules vs. network rules
FQDN filtering in application rules for HTTP/S and MSSQL is based on an application level transparent
proxy and the SNI header. As such, it can discern between two FQDNs that are resolved to the same IP
address. This is not the case with FQDN filtering in network rules.
Always use application rules when possible:
If the protocol is HTTP/S or MSSQL, use application rules for FQDN filtering.
For services like AzureBackup, HDInsight, etc., use application rules with FQDN tags.
For any other protocols, you can use network rules for FQDN filtering.
Next steps
Azure Firewall DNS settings
Azure Firewall DNS Proxy details
You can configure Azure Firewall to act as a DNS proxy. A DNS proxy is an intermediary for DNS requests from
client virtual machines to a DNS server.
The following information describes some implementation details for Azure Firewall DNS Proxy.
FQDNs with multiple A records

Azure Firewall acts as a standard DNS client. If multiple A records are in the response, the firewall stores all the
records in cache. If there’s one record per response, the firewall stores only single record. There's no way for a
client to know ahead of time if it should expect one or multiple A records in responses.
FQDN Time to Live (TTL)

When a FQDN TTL (time-to-live) is about to expire, records are cached and expired according to their TTLs. Pre-
fetching isn't used, so the firewall doesn't do a lookup prior to TTL expiration to refresh the record.
Clients not configured to use the firewall DNS proxy

If a client computer is configured to use a DNS server that isn't the firewall DNS proxy, the results can be
unpredictable.
For example, assume a client workload is in US East, and uses a primary DNS server hosted in US East. Azure
Firewall DNS server settings are configured for a secondary DNS server hosted in US West. The firewall’s DNS
server hosted in US West results in a response different than that of the client in US East.
This is a common scenario, and why clients should use the firewall’s DNS proxy functionality. Clients should use
the firewall as their resolver if you use FQDNs in Network rules. You can ensure IP address resolution
consistency by clients and the firewall itself.
In this example, if an FQDN is configured in Network rules, the firewall resolves the FQDN to IP1 (IP address 1)
and updates the network rules to allow access to IP1. If and when the client resolves the same FQDN to IP2
because of a difference in DNS response, its connection attempt won't match the rules on the firewall and will be
denied.
For HTTP/S FQDNs in Application rules, the firewall parses out the FQDN from the host or SNI header, resolves
it, and then connects to that IP address. The destination IP address the client was trying to connect to is ignored.
Next steps
Azure Firewall FTP support
To support FTP, a firewall must consider the following key aspects:

FTP mode – Active or Passive
Client/server location - Internet or intranet
Flow direction - inbound or outbound.
Azure Firewall supports both Active and Passive FTP scenarios. For more information about FTP mode, see
Active FTP vs. Passive FTP, a Definitive Explanation.
By default, Passive FTP is enabled and Active FTP support is disabled to protect against FTP bounce attacks using
the FTPPORTcommand.
However, you can enable Active FTP when you deploy using Azure PowerShell, the Azure CLI, or an Azure ARM
template. Azure Firewall can support both Active and Passive FTP simultaneously. ActiveFTP is a Firewall
property that can be enabled for both Premium and Standard SKUs, secure hub and VNet firewalls, and when
using Firewall Policy and Classic Rules.
Supported scenarios
The following table shows the configuration required to support various FTP scenarios:
F IREWA L L SC EN A RIO A C T IVE F T P M O DE PA SSIVE F T P M O DE
VNet-VNet Network Rules to configure: Network Rules to configure:

- Allow From Source VNet to Dest IP - Allow From Source VNet to Dest IP
port 21 port 21
- Allow From Dest IP port 20 to - Allow From Source VNet to Dest IP
Source VNet <Range of Data Ports>
Outbound VNet - Internet Not supported * Pre-Condition : Configure FTP server

to accept data and control channels
(FTP client in VNet, server on Internet) from different source IP addresses.
Alternatively, configure Azure Firewall
with single Public IP address.
Network Rules to configure:

- Allow From Source VNet to Dest IP
port 21
- Allow From Source VNet to Dest IP
<Range of Data Ports>
F IREWA L L SC EN A RIO A C T IVE F T P M O DE PA SSIVE F T P M O DE
Inbound DNAT DNAT rule to configure: Pre-Condition :

- DNAT From Internet Source to VNet Configure FTP server to accept data
(FTP client on Internet, server in VNet) IP port 21 and control channels from different
source IP addresses.
Network rule to configure:
- Allow From VNet IP port 20 to Tip: Azure Firewall supports limited
Internet Source number of DNAT rules. It is important
to configure the FTP server to use a
small port range on the Data channel.
DNAT Rules to configure:

- DNAT From Internet Source to VNet
IP port 21
- DNAT From Internet Source to VNet
IP <Range of Data Ports>
* Active FTP will not work when the FTP client must reach an FTP server on the Internet. Active FTP uses a PORT
command from the FTP client that tells the FTP server what IP address and port to use for the data channel. This
PORT command uses the private IP address of the client which cannot be changed. Client-side traffic traversing
the Azure Firewall will be NATed for Internet-based communications, so the PORT command is seen as invalid by
the FTP server. This is a general limitation of Active FTP when used with a client-side NAT.
Deploy using Azure PowerShell

To deploy using Azure PowerShell, use the AllowActiveFTP parameter. For more information, see Create a
Firewall with Allow Active FTP.
Deploy using Azure CLI

To deploy using the Azure CLI, use the --allow-active-ftp parameter. For more information, see az network
firewall create.
Deploy Azure Resource Manager (ARM) template

To deploy using an ARM template, use the AdditionalProperties field:
"additionalProperties": {
"Network.FTP.AllowActiveFTP": "True"
},
For more information, see Microsoft.Network azureFirewalls.
Next steps
To learn how to deploy an Azure Firewall, see Deploy and configure Azure Firewall using Azure PowerShell.
Azure Firewall performance
Reliable firewall performance is essential to operate and protect your virtual networks in Azure. More advanced
features (like those found in Azure Firewall Premium) require more processing complexity. This will affect
firewall performance and impact the overall network performance.
Azure Firewall has two versions: Standard and Premium.
Azure Firewall Standard has been generally available since September 2018. It is cloud native, highly
available, with built-in auto scaling firewall-as-a-service. You can centrally govern and log all your traffic
flows using a DevOps approach. The service supports both application and network level-filtering rules,
and is integrated with the Microsoft Threat Intelligence feed for filtering known malicious IP addresses
and domains.
Azure Firewall Premium is a next generation firewall. It has capabilities that are required for highly
sensitive and regulated environments. The features that might affect the performance of the Firewall are
TLS (Transport Layer Security) inspection and IDPS (Intrusion Detection and Prevention).
For more information about Azure Firewall, see What is Azure Firewall?
Performance testing
Before you deploy Azure Firewall, the performance needs to be tested and evaluated to ensure it meets your
expectations. Not only should Azure Firewall handle the current traffic on a network, but it should also be ready
for potential traffic growth. It is recommended to evaluate on a test network and not in a production
environment. The testing should attempt to replicate the production environment as close as possible. This
includes the network topology, and emulating the actual characteristics of the expected traffic through the
firewall.
Performance data
The following set of performance results demonstrates the maximal Azure Firewall throughput in various use
cases. All use cases were measured while Threat intelligence mode was set to alert/deny. Azure Firewall
Premium performance boost feature is enabled on all Azure Firewall premium deployments by default. This
feature includes enabling Accelerated Networking on the underlying firewall virtual machines.
F IREWA L L T Y P E A N D USE C A SE TC P / UDP B A N DW IDT H ( GB P S) H T T P / S B A N DW IDT H ( GB P S)
Standard 30 30
Premium (no TLS/IDPS) 100 100
Premium with TLS - 100
Premium with IDS 100 100

F IREWA L L T Y P E A N D USE C A SE TC P / UDP B A N DW IDT H ( GB P S) H T T P / S B A N DW IDT H ( GB P S)
Premium with IPS 10 10
NOTE
IPS (Intrusion Prevention System) takes place when one or more signatures are configured to Alert and Deny mode.
Azure Firewall also supports the following throughput for single connections:
F IREWA L L USE C A SE T H RO UGH P UT ( GB P S)
Standard 1.3
Max bandwidth for single TCP connection
Premium 9.5
Max bandwidth for single TCP connection
Premium max bandwidth with TLS/IDS 100
Premium single TCP connection with IDPS on Alert and Deny up to 300 Mbps
mode
Performance values are calculated with Azure Firewall at full scale. Actual performance may vary depending on
your rule complexity and network configuration. These metrics are updated periodically as performance
continuously evolves with each release.
Next steps
Deploy and configure Azure Firewall using the
Azure portal
accessed.
One way you can control outbound network access from an Azure subnet is with Azure Firewall. With Azure
Firewall, you can configure:
For this article, you create a simplified single VNet with two subnets for easy deployment.
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.
In this article, you learn how to:

Deploy a firewall
Configure a NAT rule to allow a remote desktop to the test server
Test the firewall
NOTE
This article uses classic Firewall rules to manage the firewall. The preferred method is to use Firewall Policy. To complete
this procedure using Firewall Policy, see Tutorial: Deploy and configure Azure Firewall and policy using the Azure portal
If you prefer, you can complete this procedure using Azure PowerShell.
Prerequisites
Set up the network

subnets, and a test server.
The resource group contains all the resources used in this procedure.
page. Then select Create .
4. For Resource group name , type Test-FW-RG .
5. For Resource group location , select a location. All other resources that you create must be in the same
location.
7. Select Create .
Create a VNet
This VNet will have two subnets.
NOTE
2. Select Networking > Vir tual network .
5. For Name , type Test-FW-VN .
10. For Subnet name change it to AzureFirewallSubnet . The firewall will be in this subnet, and the subnet
name must be AzureFirewallSubnet.
11. For Address range , change it to 10.0.1.0/26 .
12. Select Save .
Next, create a subnet for the workload server.
14. For Subnet name , type Workload-SN .
16. Select Add .
18. Select Create .
Now create the workload virtual machine, and place it in the Workload-SN subnet.
2. Select Windows Ser ver 2019 Datacenter .
SET T IN G VA L UE
Virtual machine name Sr v-Work
Region Same as previous
Image Windows Server 2019 Datacenter
Administrator user name Type a user name
Password Type a password
4. Under Inbound por t rules , Public inbound por ts , select None .

5. Accept the other defaults and select Next: Disks .
6. Accept the disk defaults and select Next: Networking .
7. Make sure that Test-FW-VN is selected for the virtual network and the subnet is Workload-SN .
9. Accept the other defaults and select Next: Management .
10. For Boot diagnostics , select Disable to disable boot diagnostics. Accept the other defaults and select
Review + create .
11. Review the settings on the summary page, and then select Create .
12. After the deployment is complete, select Sr v-Work and note the private IP address that you'll need to
use later.
NOTE
IP is disabled.
Deploy the firewall

Deploy the firewall into the VNet.
2. Type firewall in the search box and press Enter .
3. Select Firewall and then select Create .
SET T IN G VA L UE
Name Test-FW01
Firewall management Use Firewall rules (classic) to manage this firewall
Choose a virtual network Use existing : Test-FW-VN
Public IP address Add new

Name : fw-pip
5. Accept the other default values, then select Review + create .

7. After deployment completes, go to the Test-FW-RG resource group, and select the Test-FW01 firewall.
8. Note the firewall private and public IP addresses. You'll use these addresses later.
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.
As a result, there is no need create an additional UDR to include the AzureFirewallSubnet IP range. This may
result in dropped connections. The original default route is sufficient.
For the Workload-SN subnet, configure the outbound default route to go through the firewall.
1. On the Azure portal menu, select Create a resource .
2. Under Networking , select Route table .
6. For Name , type Firewall-route .
8. Select Create .
After deployment completes, select Go to resource .
1. On the Firewall-route page, select Subnets and then select Associate .
2. Select Vir tual network > Test-FW-VN .
3. For Subnet , select Workload-SN . Make sure that you select only the Workload-SN subnet for this
route, otherwise your firewall won't work correctly.
4. Select OK .
5. Select Routes and then select Add .
7. For Address prefix destination , select IP Addresses .
8. For Destination IP addresses/CIDR ranges , type 0.0.0.0/0 .
11. Select Add .

This is the application rule that allows outbound access to www.google.com .
1. Open the Test-FW-RG , and select the Test-FW01 firewall.
2. On the Test-FW01 page, under Settings , select Rules (classic) .
3. Select the Application rule collection tab.
4. Select Add application rule collection .
5. For Name , type App-Coll01 .
7. For Action , select Allow .
8. Under Rules , Target FQDNs , for Name , type Allow-Google .
10. For Source , type 10.0.2.0/24 .
11. For Protocol:por t , type http, https .
12. For Target FQDNS , type www.google.com
13. Select Add .

This is the network rule that allows outbound access to two IP addresses at port 53 (DNS).
1. Select the Network rule collection tab.
2. Select Add network rule collection .
3. For Name , type Net-Coll01 .
5. For Action , select Allow .
6. Under Rules , IP addresses , for Name , type Allow-DNS .
7. For Protocol , select UDP .
9. For Source , type 10.0.2.0/24 .
10. For Destination type select IP address .
11. For Destination address , type 209.244.0.3,209.244.0.4
These are public DNS servers operated by Level3.
13. Select Add .

This rule allows you to connect a remote desktop to the Srv-Work virtual machine through the firewall.
1. Select the NAT rule collection tab.
2. Select Add NAT rule collection .
9. For Destination address , type the firewall public IP address.
11. For Translated address , type the Srv-work private IP address.
13. Select Add .
For testing purposes, configure the server's primary and secondary DNS addresses. This isn't a general Azure
Firewall requirement.
page. Select the Test-FW-RG resource group.
2. Select the network interface for the Sr v-Work virtual machine.
5. Type 209.244.0.3 in the Add DNS ser ver text box, and 209.244.0.4 in the next text box.
6. Select Save .
7. Restart the Sr v-Work virtual machine.
Test the firewall

1. Connect a remote desktop to the firewall public IP address and sign in to the Srv-Work virtual machine.
2. Open Internet Explorer and browse to https://www.google.com .
3. Select OK > Close on the Internet Explorer security alerts.
You should see the Google home page.
4. Browse to https://www.microsoft.com .
You should be blocked by the firewall.
You can connect to the virtual machine using RDP.
Clean up resources
You can keep your firewall resources to continue testing, or if no longer needed, delete the Test-FW-RG
Next steps
Deploy and configure Azure Firewall in a hybrid
network using the Azure portal
You can use Azure Firewall to control network access in a hybrid network using rules that define allowed and
denied network traffic.
For this article, you create three virtual networks:
deployment, it can be connected by either a VPN or ExpressRoute connection. For simplicity, this procedure
uses a VPN gateway connection, and an Azure-located virtual network is used to represent an on-premises
network.

Create the routes
Test the firewall
If you want to use Azure PowerShell instead to complete this procedure, see Deploy and configure Azure
Firewall in a hybrid network using Azure PowerShell.
NOTE
this procedure using Firewall Policy, see Tutorial: Deploy and configure Azure Firewall and policy in a hybrid network using
the Azure portal.
Prerequisites
A hybrid network uses the hub-and-spoke architecture model to route traffic between Azure VNets and on-
premises networks. The hub-and-spoke architecture has the following requirements:
Set Use this vir tual network's gateway or Route Ser ver when peering VNet-Hub to VNet-Spoke. In
a hub-and-spoke network architecture, a gateway transit allows the spoke virtual networks to share the
VPN gateway in the hub, instead of deploying VPN gateways in every spoke virtual network.
Additionally, routes to the gateway-connected virtual networks or on-premises networks will
automatically propagate to the routing tables for the peered virtual networks using the gateway transit.
For more information, see Configure VPN gateway transit for virtual network peering.
Set Use the remote vir tual network's gateways or Route Ser ver when you peer VNet-Spoke to
VNet-Hub. If Use the remote vir tual network's gateways or Route Ser ver is set and Use this
vir tual network's gateway or Route Ser ver on remote peering is also set, the spoke virtual network
uses gateways of the remote virtual network for transit.
To route the spoke subnet traffic through the hub firewall, you can use a User Defined route (UDR) that
points to the firewall with the Vir tual network gateway route propagation option disabled. The
Vir tual network gateway route propagation disabled option prevents route distribution to the
spoke subnets. This prevents learned routes from conflicting with your UDR. If you want to keep Vir tual
network gateway route propagation enabled, make sure to define specific routes to the firewall to
override those that are published from on-premises over BGP.
Configure a UDR on the hub gateway subnet that points to the firewall IP address as the next hop to the
spoke networks. No UDR is required on the Azure Firewall subnet, as it learns routes from BGP.
See the Create Routes section in this article to see how these routes are created.
NOTE
premises network via BGP, you must override this with a 0.0.0.0/0 UDR with the NextHopType value set as Internet to
maintain direct Internet connectivity.
Azure Firewall can be configured to support forced tunneling. For more information, see Azure Firewall forced tunneling.
NOTE
on both subnets.

First, create the resource group to contain the resources:
2. On the Azure portal home page, select Resource groups > Add .
4. For Resource group name , type FW-Hybrid-Test .
5. For Region , select (US) East US . All resources that you create later must be in the same location.
7. Select Create .
Now, create the VNet:
NOTE

2. Under Networking , select Vir tual network .
3. Select Create .
5. For Name , type VNet-hub .
7. For IPv4 Address space , delete the default address and type 10.5.0.0/16 .
9. For Subnet name type AzureFirewallSubnet . The firewall will be in this subnet, and the subnet name
must be AzureFirewallSubnet.
11. Select Add .
13. Select Create .

4. For Name , type VNet-Spoke .
9. For Subnet name type SN-Workload .
11. Select Add .
13. Select Create .

4. For Name , type VNet-OnPrem .
6. Select Next : IP Addresses
9. For Subnet name type SN-Corp .
11. Select Add .
13. Select Create .
Now create a second subnet for the gateway.
1. On the VNet-Onprem page, select Subnets .
2. Select +Subnet .
3. For Name , type GatewaySubnet .
4. For Subnet address range type 192.168.2.0/24 .
5. Select OK .

Now deploy the firewall into the firewall hub virtual network.
2. In the left column, select Networking , and search for and then select Firewall .
SET T IN G VA L UE
Resource group FW-Hybrid-Test
Name AzFW01
Region East US
Choose a virtual network Use existing :

VNet-hub
Public IP address Add new:

fw-pip .

6. After deployment completes, go to the FW-Hybrid-Test resource group, and select the AzFW01
firewall.
7. Note the private IP address. You'll use it later when you create the default route.
First, add a network rule to allow web traffic.
1. On the AzFW01 page, Select Rules .
2. Select the Network rule collection tab.
3. Select Add network rule collection .
4. For Name , type RCNet01 .
7. Under Rules , for Name , type AllowWeb .
9. For Source , type 192.168.1.0/24 .
13. For Destination , type 10.6.0.0/16 .
Now add a rule to allow RDP traffic.
On the second rule row, type the following information:
1. Name , type AllowRDP .
3. For Source , type 192.168.1.0/24 .
7. For Destination , type 10.6.0.0/16
8. Select Add .

VPN gateway SKU.
2. In the search text box, type vir tual network gateway .
4. For Name , type GW-hub .
9. For Vir tual network , select VNet-hub .
10. For Public IP address , select Create new , and type VNet-hub-GW-pip for the name.
VPN gateway SKU.
2. In the search text box, type vir tual network gateway and press Enter .
4. For Name , type GW-Onprem .
9. For Vir tual network , select VNet-Onprem .
10. For Public IP address , select Create new , and type VNet-Onprem-GW-pip for the name.
Now you can create the VPN connections between the hub and on-premises gateways.
complete.
1. Open the FW-Hybrid-Test resource group and select the GW-hub gateway.
3. Select Add .
4. The the connection name, type Hub-to-Onprem .
6. For the Second vir tual network gateway , select GW-Onprem .
8. Select OK .
1. Open the FW-Hybrid-Test resource group and select the GW-Onprem gateway.
3. Select Add .
4. For the connection name, type Onprem-to-Hub .
6. For the Second vir tual network gateway , select GW-hub .
8. Select OK .
After about five minutes or so, the status of both connections should be Connected .

1. Open the FW-Hybrid-Test resource group and select the VNet-hub virtual network.
2. In the left column, select Peerings .
3. Select Add .
4. Under This vir tual network :
Peering link name HubtoSpoke
Virtual network gateway Use this virtual network's gateway
5. Under Remote vir tual network :
Peering link name SpoketoHub
Virtual network deployment model Resource manager
Virtual network VNet-Spoke

Virtual network gateway Use the remote virtual network's gateway
6. Select Add .
Create the routes
4. Select Create .
7. For the name, type UDR-Hub-Spoke .
9. Select Create .
12. Select Add .
13. For the route name, type ToSpoke .
14. For the address prefix, type 10.6.0.0/16 .
17. Select OK .
1. On the UDR-Hub-Spoke - Routes page, select Subnets .
3. Under Vir tual network , select VNet-hub .
4. Under Subnet , select GatewaySubnet .
5. Select OK .
Now create the default route from the spoke subnet.
4. Select Create .
7. For the name, type UDR-DG .
8. For Propagate gateway route , select No .
10. Select Create .
13. Select Add .
14. For the route name, type ToHub .
15. For the address prefix, type 0.0.0.0/0 .
18. Select OK .
1. On the UDR-DG - Routes page, select Subnets .
3. Under Vir tual network , select VNet-spoke .
4. Under Subnet , select SN-Workload .
5. Select OK .

Create a virtual machine in the spoke virtual network, running IIS, with no public IP address.
Resource group - Select FW-Hybrid-Test .
Vir tual machine name : VM-Spoke-01.
Password : <type a password>
4. For Public inbound por ts , select Allow selected por ts , and then select HTTP (80) , and RDP (3389)
6. Accept the defaults and select Next: Networking .
7. Select VNet-Spoke for the virtual network and the subnet is SN-Workload .
Install IIS
1. From the Azure portal, open the Cloud Shell and make sure that it's set to PowerShell .
2. Run the following command to install IIS on the virtual machine and change the location if necessary:
Set-AzVMExtension `
-ResourceGroupName FW-Hybrid-Test `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell
Add-Content -Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS

This is a virtual machine that you use to connect using Remote Desktop to the public IP address. From there, you
then connect to the on-premises server through the firewall.
Resource group - Select existing, and then select FW-Hybrid-Test .
Vir tual machine name - VM-Onprem.
Password : <type a user password>.
4. For Public inbound por ts , select Allow selected por ts , and then select RDP (3389)
6. Accept the defaults and select Next:Networking .
7. Select VNet-Onprem for virtual network and the subnet is SN-Corp .
NOTE
IP is disabled.
Test the firewall

1. First, note the private IP address for VM-spoke-01 virtual machine.
2. From the Azure portal, connect to the VM-Onprem virtual machine.
3. Open a web browser on VM-Onprem , and browse to http://<VM-spoke-01 private IP>.
You should see the VM-spoke-01 web page:
4. From the VM-Onprem virtual machine, open a remote desktop to VM-spoke-01 at the private IP
address.
Your connection should succeed, and you should be able to sign in.
expected.
1. Select the AzFW01 firewall.
2. Select Rules .
3. Select the Network rule collection tab and select the RCNet01 rule collection.
4. For Action , select Deny .
5. Select Save .
Close any existing remote desktops before testing the changed rules. Now run the tests again. They should all
fail this time.
Clean up resources
You can keep your firewall resources for further testing, or if no longer needed, delete the FW-Hybrid-Test
Next steps
Filter inbound Internet traffic with Azure Firewall
DNAT using the Azure portal
You can configure Azure Firewall Destination Network Address Translation (DNAT) to translate and filter inbound
Internet traffic to your subnets. When you configure DNAT, the NAT rule collection action is set to Dnat . Each
rule in the NAT rule collection can then be used to translate your firewall public IP address and port to a private
IP address and port. DNAT rules implicitly add a corresponding network rule to allow the translated traffic. For
security reasons, the recommended approach is to add a specific Internet source to allow DNAT access to the
network and avoid using wildcards. To learn more about Azure Firewall rule processing logic, see Azure Firewall
rule processing logic.
Deploy a firewall
Test the firewall
NOTE
this procedure using Firewall Policy, see Tutorial: Filter inbound Internet traffic with Azure Firewall policy DNAT using the
Azure portal
Prerequisites

2. On the Azure portal home page, select Resource groups , then select Create .
4. For Resource group , type RG-DNAT-Test .
7. Select Create .
Set up the network environment

For this article, you create a two peered VNets:
VN-Hub - the firewall is in this VNet.
VN-Spoke - the workload server is in this VNet.
First, create the VNets and then peer them.
Create the Hub VNet
3. Select Create .
5. For Name , type VN-Hub .
10. Edit the Subnet name and type AzureFirewallSubnet .
The firewall will be in this subnet, and the subnet name must be AzureFirewallSubnet.
NOTE
The size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall
FAQ.

12. Select Save .
14. Select Create .
Create a spoke VNet
3. Select Create .
5. For Name , type VN-Spoke .
8. For IPv4 Address space , edit the default and type 192.168.0.0/16 .
10. For the Subnet name type SN-Workload .
12. Select Add .
14. Select Create .
Peer the VNets
Now peer the two VNets.
1. Select the VN-Hub virtual network.
2. Under Settings , select Peerings .
3. Select Add .
4. Under This vir tual network , for the Peering link name , type Peer-HubSpoke .
5. Under Remote vir tual network , for Peering link name , type Peer-SpokeHub .
6. Select VN-Spoke for the virtual network.
7. Accept all the other defaults, and then select Add .

Create a workload virtual machine, and place it in the SN-Workload subnet.
1. From the Azure portal menu, select Create a resource .
Basics
3. For Vir tual machine name , type Sr v-Workload .
5. Type a username and password.
6. Select Next: Disks .
Disks
1. Select Next: Networking .
Networking
4. For Public inbound por ts , select None .
5. Leave the other default settings and select Next: Management .
Management
1. For Boot diagnostics , select Disable .
Review + Create
Review the summary, and then select Create . This will take a few minutes to complete.
After deployment finishes, note the private IP address for the virtual machine. It will be used later when you
configure the firewall. Select the virtual machine name, and under Settings , select Networking to find the
private IP address.
NOTE
IP is disabled.
Deploy the firewall

1. From the portal home page, select Create a resource .
2. Search for Firewall , and then select Firewall .
3. Select Create .
SET T IN G VA L UE
Resource group Select RG-DNAT-Test
Name FW-DNAT-test
Choose a virtual network Use existing : VN-Hub
Public IP address Add new , Name: fw-pip .
5. Accept the other defaults, and then select Review + create .

7. After deployment completes, go to the RG-DNAT-Test resource group, and select the FW-DNAT-test
firewall.
8. Note the firewall's private and public IP addresses. You'll use them later when you create the default route
and NAT rule.
For the SN-Workload subnet, you configure the outbound default route to go through the firewall.
3. Select Create .
7. For Name , type RT-FWroute .
9. Select Create .
10. Select Go to resource .
11. Select Subnets , and then select Associate .
14. Select OK .
15. Select Routes , and then select Add .
16. For Route name , type FW-DG .
17. For Address prefix destination , select IP Addresses .
18. For Destination IP addresses/CIDR ranges , type 0.0.0.0/0 .
21. Select Add .
Configure a NAT rule

1. Open the RG-DNAT-Test resource group, and select the FW-DNAT-test firewall.
2. On the FW-DNAT-test page, under Settings , select Rules (classic) .
3. Select Add NAT rule collection .
4. For Name , type RC-DNAT-01 .
6. Under Rules , for Name , type RL-01 .
9. For Source , type *.
10. For Destination Addresses , type the firewall's public IP address.
11. For Destination por ts , type 3389 .
12. For Translated Address type the private IP address for the Srv-Workload virtual machine.
14. Select Add . This will take a few minutes to complete.
Test the firewall

1. Connect a remote desktop to firewall public IP address. You should be connected to the Sr v-Workload
virtual machine.
2. Close the remote desktop.
Clean up resources
You can keep your firewall resources for further testing, or if no longer needed, delete the RG-DNAT-Test
Next steps
Deploy and configure Azure Firewall using Azure
PowerShell
accessed.
For this article, you create a simplified single VNet with three subnets for easy deployment. 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.
AzureBastionSubnet - the subnet used for Azure Bastion, which is used to connect to the workload server.
For more information about Azure Bastion, see What is Azure Bastion?

Deploy a firewall
Test the firewall
If you prefer, you can complete this procedure using the Azure portal.
Prerequisites
This procedure requires that you run PowerShell locally. You must have the Azure PowerShell module installed.
Run Get-Module -ListAvailable Az to find the version. If you need to upgrade, see Install Azure PowerShell
module. After you verify the PowerShell version, run Connect-AzAccount to create a connection with Azure.
Set up the network

subnets, and test servers.
The resource group contains all the resources for the deployment.
New-AzResourceGroup -Name Test-FW-RG -Location "East US"
Create a virtual network and Azure Bastion host

This virtual network has three subnets:
NOTE
$Bastionsub = New-AzVirtualNetworkSubnetConfig -Name AzureBastionSubnet -AddressPrefix 10.0.0.0/27

$FWsub = New-AzVirtualNetworkSubnetConfig -Name AzureFirewallSubnet -AddressPrefix 10.0.1.0/26
$Worksub = New-AzVirtualNetworkSubnetConfig -Name Workload-SN -AddressPrefix 10.0.2.0/24
Now, create the virtual network:
$testVnet = New-AzVirtualNetwork -Name Test-FW-VN -ResourceGroupName Test-FW-RG `

-Location "East US" -AddressPrefix 10.0.0.0/16 -Subnet $Bastionsub, $FWsub, $Worksub
Create public IP address for Azure Bastion host
$publicip = New-AzPublicIpAddress -ResourceGroupName Test-FW-RG -Location "East US" `

-Name Bastion-pip -AllocationMethod static -Sku standard
Create Azure Bastion host
New-AzBastion -ResourceGroupName Test-FW-RG -Name Bastion-01 -PublicIpAddress $publicip -VirtualNetwork

$testVnet

Now create the workload virtual machine, and place it in the appropriate subnet. When prompted, type a user
name and password for the virtual machine.
Create a workload virtual machine. When prompted, type a user name and password for the virtual machine.
#Create the NIC
$wsn = Get-AzVirtualNetworkSubnetConfig -Name Workload-SN -VirtualNetwork $testvnet
$NIC01 = New-AzNetworkInterface -Name Srv-Work -ResourceGroupName Test-FW-RG -Location "East us" -Subnet
$wsn
#Define the virtual machine

$VirtualMachine = New-AzVMConfig -VMName Srv-Work -VMSize "Standard_DS2"
$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName Srv-Work -
ProvisionVMAgent -EnableAutoUpdate
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $NIC01.Id
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName 'MicrosoftWindowsServer' -Offer
'WindowsServer' -Skus '2019-Datacenter' -Version latest
#Create the virtual machine

New-AzVM -ResourceGroupName Test-FW-RG -Location "East US" -VM $VirtualMachine -Verbose
NOTE
IP is disabled.
Deploy the firewall

Now deploy the firewall into the virtual network.
# Get a Public IP for the firewall

$FWpip = New-AzPublicIpAddress -Name "fw-pip" -ResourceGroupName Test-FW-RG `
-Location "East US" -AllocationMethod Static -Sku Standard
# Create the firewall
$Azfw = New-AzFirewall -Name Test-FW01 -ResourceGroupName Test-FW-RG -Location "East US" -VirtualNetwork
$testVnet -PublicIpAddress $FWpip
#Save the firewall private IP address for future use
$AzfwPrivateIP = $Azfw.IpConfigurations.privateipaddress
$AzfwPrivateIP
Note the private IP address. You'll use it later when you create the default route.

Create a table, with BGP route propagation disabled
$routeTableDG = New-AzRouteTable `
-Name Firewall-rt-table `
-ResourceGroupName Test-FW-RG `
-location "East US" `
-DisableBgpRoutePropagation
#Create a route
Add-AzRouteConfig `
-Name "DG-Route" `
-RouteTable $routeTableDG `
-AddressPrefix 0.0.0.0/0 `
-NextHopType "VirtualAppliance" `
-NextHopIpAddress $AzfwPrivateIP `
| Set-AzRouteTable
#Associate the route table to the subnet
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $testVnet `
-Name Workload-SN `
-RouteTable $routeTableDG | Set-AzVirtualNetwork

The application rule allows outbound access to www.google.com.
$AppRule1 = New-AzFirewallApplicationRule -Name Allow-Google -SourceAddress 10.0.2.0/24 `

-Protocol http, https -TargetFqdn www.google.com
$AppRuleCollection = New-AzFirewallApplicationRuleCollection -Name App-Coll01 `

-Priority 200 -ActionType Allow -Rule $AppRule1
$Azfw.ApplicationRuleCollections.Add($AppRuleCollection)
Set-AzFirewall -AzureFirewall $Azfw

The network rule allows outbound access to two IP addresses at port 53 (DNS).
$NetRule1 = New-AzFirewallNetworkRule -Name "Allow-DNS" -Protocol UDP -SourceAddress 10.0.2.0/24 `

-DestinationAddress 209.244.0.3,209.244.0.4 -DestinationPort 53
$NetRuleCollection = New-AzFirewallNetworkRuleCollection -Name RCNet01 -Priority 200 `

-Rule $NetRule1 -ActionType "Allow"
$Azfw.NetworkRuleCollections.Add($NetRuleCollection)
For testing purposes in this procedure, configure the server's primary and secondary DNS addresses. This isn't a
$NIC01.DnsSettings.DnsServers.Add("209.244.0.3")
$NIC01 | Set-AzNetworkInterface
Test the firewall

1. Connect to Sr v-Work virtual machine using Bastion, and sign in.
2. On Sr v-Work , open a PowerShell window and run the following commands:
nslookup www.google.com
nslookup www.microsoft.com
Both commands should return answers, showing that your DNS queries are getting through the firewall.
3. Run the following commands:
Invoke-WebRequest -Uri https://www.google.com

Invoke-WebRequest -Uri https://www.microsoft.com

The www.google.com requests should succeed, and the www.microsoft.com requests should fail. This
demonstrates that your firewall rules are operating as expected.
Clean up resources
resource group to delete all firewall-related resources:
Remove-AzResourceGroup -Name Test-FW-RG
Next steps
Deploy and configure Azure Firewall policy using
Azure PowerShell
accessed.
One way you can control outbound network access from an Azure subnet is with Azure Firewall and Firewall
Policy. With Azure Firewall, you can configure:
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.
AzureBastionSubnet - the subnet used for Azure Bastion, which is used to connect to the workload server.
For more information about Azure Bastion, see What is Azure Bastion?

Deploy a firewall
Create a firewall policy
Test the firewall
If you prefer, you can complete this procedure using the Azure portal.
Prerequisites
This procedure requires that you run PowerShell locally. You must have the Azure PowerShell module installed.
Run Get-Module -ListAvailable Az to find the version. If you need to upgrade, see Install Azure PowerShell
module. After you verify the PowerShell version, run Connect-AzAccount to create a connection with Azure.
Set up the network

New-AzResourceGroup -Name Test-FW-RG -Location "East US"
Create a virtual network and Azure Bastion host

This virtual network has three subnets:
NOTE
$Bastionsub = New-AzVirtualNetworkSubnetConfig -Name AzureBastionSubnet -AddressPrefix 10.0.0.0/27

$FWsub = New-AzVirtualNetworkSubnetConfig -Name AzureFirewallSubnet -AddressPrefix 10.0.1.0/26
$Worksub = New-AzVirtualNetworkSubnetConfig -Name Workload-SN -AddressPrefix 10.0.2.0/24
Now, create the virtual network:
$testVnet = New-AzVirtualNetwork -Name Test-FW-VN -ResourceGroupName Test-FW-RG `

-Location "East US" -AddressPrefix 10.0.0.0/16 -Subnet $Bastionsub, $FWsub, $Worksub
Create public IP address for Azure Bastion host
$publicip = New-AzPublicIpAddress -ResourceGroupName Test-FW-RG -Location "East US" `

-Name Bastion-pip -AllocationMethod static -Sku standard
Create Azure Bastion host
New-AzBastion -ResourceGroupName Test-FW-RG -Name Bastion-01 -PublicIpAddress $publicip -VirtualNetwork

$testVnet

Now create the workload virtual machine, and place it in the appropriate subnet. When prompted, type a user
name and password for the virtual machine.
Create a workload virtual machine. When prompted, type a user name and password for the virtual machine.
#Create the NIC
$wsn = Get-AzVirtualNetworkSubnetConfig -Name Workload-SN -VirtualNetwork $testvnet
$NIC01 = New-AzNetworkInterface -Name Srv-Work -ResourceGroupName Test-FW-RG -Location "East us" -Subnet
$wsn

$VirtualMachine = New-AzVMConfig -VMName Srv-Work -VMSize "Standard_DS2"
$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName Srv-Work -
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $NIC01.Id

New-AzVM -ResourceGroupName Test-FW-RG -Location "East US" -VM $VirtualMachine -Verbose
Create a Firewall Policy

$fwpol = New-AzFirewallPolicy -Name fw-pol -ResourceGroupName Test-FW-RG -Location eastus
Configure a firewall policy application rule

The application rule allows outbound access to www.google.com .
$RCGroup = New-AzFirewallPolicyRuleCollectionGroup -Name AppRCGroup -Priority 100 -FirewallPolicyObject

$fwpol
$apprule1 = New-AzFirewallPolicyApplicationRule -Name Allow-google -SourceAddress "10.0.2.0/24" -Protocol
"http:80","https:443" -TargetFqdn www.google.com
$appcoll1 = New-AzFirewallPolicyFilterRuleCollection -Name App-coll01 -Priority 100 -Rule $appRule1 -
ActionType "Allow"
Set-AzFirewallPolicyRuleCollectionGroup -Name $RCGroup.Name -Priority 100 -RuleCollection $appcoll1 -
FirewallPolicyObject $fwPol
Configure a firewall policy network rule

$RCGroup = New-AzFirewallPolicyRuleCollectionGroup -Name NetRCGroup -Priority 200 -FirewallPolicyObject

$fwpol
$netrule1 = New-AzFirewallPolicyNetworkRule -name Allow-DNS -protocol UDP -sourceaddress 10.0.2.0/24 -
destinationaddress 209.244.0.3,209.244.0.4 -destinationport 53
$netcoll1 = New-AzFirewallPolicyFilterRuleCollection -Name Net-coll01 -Priority 200 -Rule $netrule1 -
ActionType "Allow"
Set-AzFirewallPolicyRuleCollectionGroup -Name $RCGroup.Name -Priority 200 -RuleCollection $netcoll1 -
FirewallPolicyObject $fwPol
Deploy the firewall

$FWpip = New-AzPublicIpAddress -Name "fw-pip" -ResourceGroupName Test-FW-RG `
-Location "East US" -AllocationMethod Static -Sku Standard
$Azfw = New-AzFirewall -Name Test-FW01 -ResourceGroupName Test-FW-RG -Location "East US" -VirtualNetwork
$testVnet -PublicIpAddress $FWpip -FirewallPolicyId $fwpol.Id
$AzfwPrivateIP

$routeTableDG = New-AzRouteTable `
-Name Firewall-rt-table `
-ResourceGroupName Test-FW-RG `
-location "East US" `
#Create a route
Add-AzRouteConfig `
-Name "DG-Route" `
-RouteTable $routeTableDG `
| Set-AzRouteTable
-VirtualNetwork $testVnet `
-Name Workload-SN `
-RouteTable $routeTableDG | Set-AzVirtualNetwork
Change the primary and secondary DNS address for the Srv-Work
network interface
For testing purposes in this procedure, configure the server's primary and secondary DNS addresses. This isn't a
$NIC01 | Set-AzNetworkInterface
Test the firewall

1. Connect to Sr v-Work virtual machine using Bastion, and sign in.
2. On Sr v-Work , open a PowerShell window and run the following commands:


So now you've verified that the firewall policy rules are working:
Clean up resources
You can keep your firewall resources for further testing, or if no longer needed, delete the Test-FW-RG resource
group to delete all firewall-related resources:
Remove-AzResourceGroup -Name Test-FW-RG
Next steps
Deploy and configure Azure Firewall in a hybrid
network using Azure PowerShell
You can use Azure Firewall to control network access in a hybrid network using rules that define allowed and
denied network traffic.
For this article, you create three virtual networks:
deployment, it can be connected by either a VPN or ExpressRoute connection. For simplicity, this article uses
a VPN gateway connection, and an Azure-located virtual network is used to represent an on-premises
network.

Declare the variables
Create the routes
Test the firewall
If you want to use Azure portal instead to complete this tutorial, see Tutorial: Deploy and configure Azure
Firewall in a hybrid network using the Azure portal.
NOTE
This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with
Azure. To get started with the Az PowerShell module, see Install Azure PowerShell. To learn how to migrate to the Az
PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Prerequisites
This article requires that you run PowerShell locally. You must have the Azure PowerShell module installed. Run
Get-Module -ListAvailable Az to find the version. If you need to upgrade, see Install Azure PowerShell module.
After you verify the PowerShell version, run Login-AzAccount to create a connection with Azure.
There are three key requirements for this scenario to work correctly:
A User Defined Route (UDR) on the spoke subnet that points to the Azure Firewall IP address as the
default gateway. Virtual network gateway route propagation must be Disabled on this route table.
A UDR on the hub gateway subnet must point to the firewall IP address as the next hop to the spoke
networks.
No UDR is required on the Azure Firewall subnet, as it learns routes from BGP.
Make sure to set AllowGatewayTransit when peering VNet-Hub to VNet-Spoke and
UseRemoteGateways when peering VNet-Spoke to VNet-Hub.
See the Create Routes section in this article to see how these routes are created.
NOTE
premises network via BGP, you must configure Azure Firewall in forced tunneling mode. If this is an existing Azure Firewall,
which cannot be reconfigured in forced tunneling mode, it is recommended to add a 0.0.0.0/0 UDR on the
AzureFirewallSubnet with the NextHopType value set as Internet to maintain direct Internet connectivity.
For more information, see Azure Firewall forced tunneling.
NOTE
on both subnets.
To review the related Azure PowerShell reference documentation, see Azure PowerShell Reference.
Declare the variables

The following example declares the variables using the values for this article. In some cases, you might need to
replace some values with your own to work in your subscription. Modify the variables if needed, then copy and
paste them into your PowerShell console.
$RG1 = "FW-Hybrid-Test"
$Location1 = "East US"
# Variables for the firewall hub VNet
$VNetnameHub = "VNet-hub"
$SNnameHub = "AzureFirewallSubnet"
$VNetHubPrefix = "10.5.0.0/16"
$SNHubPrefix = "10.5.0.0/24"
$SNGWHubPrefix = "10.5.1.0/24"
$GWHubName = "GW-hub"
$GWHubpipName = "VNet-hub-GW-pip"
$GWIPconfNameHub = "GW-ipconf-hub"
$ConnectionNameHub = "hub-to-Onprem"
# Variables for the spoke virtual network
$VnetNameSpoke = "VNet-Spoke"
$SNnameSpoke = "SN-Workload"
$VNetSpokePrefix = "10.6.0.0/16"
$SNSpokePrefix = "10.6.0.0/24"
$SNSpokeGWPrefix = "10.6.1.0/24"
# Variables for the on-premises virtual network
$VNetnameOnprem = "Vnet-Onprem"
$SNNameOnprem = "SN-Corp"
$VNetOnpremPrefix = "192.168.0.0/16"
$SNOnpremPrefix = "192.168.1.0/24"
$SNGWOnpremPrefix = "192.168.2.0/24"
$GWOnpremName = "GW-Onprem"
$GWIPconfNameOnprem = "GW-ipconf-Onprem"
$ConnectionNameOnprem = "Onprem-to-hub"
$GWOnprempipName = "VNet-Onprem-GW-pip"
$SNnameGW = "GatewaySubnet"

First, create the resource group to contain the resources for this article:
New-AzResourceGroup -Name $RG1 -Location $Location1
Define the subnets to be included in the virtual network:
$FWsub = New-AzVirtualNetworkSubnetConfig -Name $SNnameHub -AddressPrefix $SNHubPrefix

$GWsub = New-AzVirtualNetworkSubnetConfig -Name $SNnameGW -AddressPrefix $SNGWHubPrefix
Now, create the firewall hub virtual network:
$VNetHub = New-AzVirtualNetwork -Name $VNetnameHub -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetHubPrefix -Subnet $FWsub,$GWsub
Request a public IP address to be allocated to the VPN gateway you'll create for your virtual network. Notice that
the AllocationMethod is Dynamic . You can't specify the IP address that you want to use. It's dynamically
allocated to your VPN gateway.
$gwpip1 = New-AzPublicIpAddress -Name $GWHubpipName -ResourceGroupName $RG1 `
-Location $Location1 -AllocationMethod Dynamic

Define the subnets to be included in the spoke virtual network:
$Spokesub = New-AzVirtualNetworkSubnetConfig -Name $SNnameSpoke -AddressPrefix $SNSpokePrefix

$GWsubSpoke = New-AzVirtualNetworkSubnetConfig -Name $SNnameGW -AddressPrefix $SNSpokeGWPrefix
Create the spoke virtual network:
$VNetSpoke = New-AzVirtualNetwork -Name $VnetNameSpoke -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetSpokePrefix -Subnet $Spokesub,$GWsubSpoke

Define the subnets to be included in the virtual network:
$Onpremsub = New-AzVirtualNetworkSubnetConfig -Name $SNNameOnprem -AddressPrefix $SNOnpremPrefix

$GWOnpremsub = New-AzVirtualNetworkSubnetConfig -Name $SNnameGW -AddressPrefix $SNGWOnpremPrefix
Now, create the on-premises virtual network:
$VNetOnprem = New-AzVirtualNetwork -Name $VNetnameOnprem -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetOnpremPrefix -Subnet $Onpremsub,$GWOnpremsub
Request a public IP address to be allocated to the gateway you'll create for the virtual network. Notice that the
AllocationMethod is Dynamic . You can't specify the IP address that you want to use. It's dynamically allocated to
your gateway.
$gwOnprempip = New-AzPublicIpAddress -Name $GWOnprempipName -ResourceGroupName $RG1 `

-Location $Location1 -AllocationMethod Dynamic

Now deploy the firewall into the hub virtual network.

$FWpip = New-AzPublicIpAddress -Name "fw-pip" -ResourceGroupName $RG1 `
-Location $Location1 -AllocationMethod Static -Sku Standard
$Azfw = New-AzFirewall -Name AzFW01 -ResourceGroupName $RG1 -Location $Location1 -VirtualNetworkName
$VNetnameHub -PublicIpName fw-pip
$AzfwPrivateIP

$Rule1 = New-AzFirewallNetworkRule -Name "AllowWeb" -Protocol TCP -SourceAddress $SNOnpremPrefix `
-DestinationAddress $VNetSpokePrefix -DestinationPort 80
$Rule2 = New-AzFirewallNetworkRule -Name "AllowRDP" -Protocol TCP -SourceAddress $SNOnpremPrefix `

-DestinationAddress $VNetSpokePrefix -DestinationPort 3389
$NetRuleCollection = New-AzFirewallNetworkRuleCollection -Name RCNet01 -Priority 100 `

-Rule $Rule1,$Rule2 -ActionType "Allow"
$Azfw.NetworkRuleCollections = $NetRuleCollection

Create the VPN gateway configuration. The VPN gateway configuration defines the subnet and the public IP
address to use.
$vnet1 = Get-AzVirtualNetwork -Name $VNetnameHub -ResourceGroupName $RG1

$subnet1 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfNameHub `
-Subnet $subnet1 -PublicIpAddress $gwpip1
VPN gateway SKU.
New-AzVirtualNetworkGateway -Name $GWHubName -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku basic

Create the VPN gateway configuration. The VPN gateway configuration defines the subnet and the public IP
address to use.
$vnet2 = Get-AzVirtualNetwork -Name $VNetnameOnprem -ResourceGroupName $RG1

$subnet2 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet2
$gwipconf2 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfNameOnprem `
-Subnet $subnet2 -PublicIpAddress $gwOnprempip
VPN gateway SKU.
New-AzVirtualNetworkGateway -Name $GWOnpremName -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf2 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku basic

Now you can create the VPN connections between the hub and on-premises gateways
Get the VPN gateways
$vnetHubgw = Get-AzVirtualNetworkGateway -Name $GWHubName -ResourceGroupName $RG1
$vnetOnpremgw = Get-AzVirtualNetworkGateway -Name $GWOnpremName -ResourceGroupName $RG1
Create the connections

complete.
New-AzVirtualNetworkGatewayConnection -Name $ConnectionNameHub -ResourceGroupName $RG1 `

-VirtualNetworkGateway1 $vnetHubgw -VirtualNetworkGateway2 $vnetOnpremgw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
New-AzVirtualNetworkGatewayConnection -Name $ConnectionNameOnprem -ResourceGroupName $RG1 `

-VirtualNetworkGateway1 $vnetOnpremgw -VirtualNetworkGateway2 $vnetHubgw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'

You can verify a successful connection by using the Get-AzVirtualNetworkGatewayConnection cmdlet, with or
without -Debug. Use the following cmdlet example, configuring the values to match your own. If prompted,
select A to run All . In the example, -Name refers to the name of the connection that you want to test.
Get-AzVirtualNetworkGatewayConnection -Name $ConnectionNameHub -ResourceGroupName $RG1
After the cmdlet finishes, view the values. In the following example, the connection status shows as Connected
and you can see ingress and egress bytes.
"connectionStatus": "Connected",
"ingressBytesTransferred": 33509044,
"egressBytesTransferred": 4142431

# Peer hub to spoke

Add-AzVirtualNetworkPeering -Name HubtoSpoke -VirtualNetwork $VNetHub -RemoteVirtualNetworkId $VNetSpoke.Id
-AllowGatewayTransit
# Peer spoke to hub

Add-AzVirtualNetworkPeering -Name SpoketoHub -VirtualNetwork $VNetSpoke -RemoteVirtualNetworkId $VNetHub.Id
-AllowForwardedTraffic -UseRemoteGateways
Create the routes

#Create a route table

$routeTableHubSpoke = New-AzRouteTable `
-Name 'UDR-Hub-Spoke' `
-ResourceGroupName $RG1 `
-location $Location1
#Create a route
Get-AzRouteTable `
-Name UDR-Hub-Spoke `
| Add-AzRouteConfig `
-Name "ToSpoke" `
-AddressPrefix $VNetSpokePrefix `
| Set-AzRouteTable
-VirtualNetwork $VNetHub `
-Name $SNnameGW `
-AddressPrefix $SNGWHubPrefix `
-RouteTable $routeTableHubSpoke | `
Set-AzVirtualNetwork
#Now create the default route
#Create a table, with BGP route propagation disabled. The property is now called "Virtual network gateway
route propagation," but the API still refers to the parameter as "DisableBgpRoutePropagation."
$routeTableSpokeDG = New-AzRouteTable `
-Name 'UDR-DG' `
-location $Location1 `
#Create a route
Get-AzRouteTable `
-Name UDR-DG `
| Add-AzRouteConfig `
-Name "ToFirewall" `
| Set-AzRouteTable
-VirtualNetwork $VNetSpoke `
-Name $SNnameSpoke `
-AddressPrefix $SNSpokePrefix `
-RouteTable $routeTableSpokeDG | `
Set-AzVirtualNetwork

Create a virtual machine in the spoke virtual network, running IIS, with no public IP address, and allows pings in.
When prompted, type a user name and password for the virtual machine.
# Create an inbound network security group rule for ports 3389 and 80
$nsgRuleRDP = New-AzNetworkSecurityRuleConfig -Name Allow-RDP -Protocol Tcp `
-Direction Inbound -Priority 200 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix
$SNSpokePrefix -DestinationPortRange 3389 -Access Allow
$nsgRuleWeb = New-AzNetworkSecurityRuleConfig -Name Allow-web -Protocol Tcp `
-Direction Inbound -Priority 202 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix
$SNSpokePrefix -DestinationPortRange 80 -Access Allow
# Create a network security group

$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $RG1 -Location $Location1 -Name NSG-Spoke02 -
SecurityRules $nsgRuleRDP,$nsgRuleWeb
#Create the NIC

$NIC = New-AzNetworkInterface -Name spoke-01 -ResourceGroupName $RG1 -Location $Location1 -SubnetId
$VnetSpoke.Subnets[0].Id -NetworkSecurityGroupId $nsg.Id

$VirtualMachine = New-AzVMConfig -VMName VM-Spoke-01 -VMSize "Standard_DS2"
$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName Spoke-01 -
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $NIC.Id

New-AzVM -ResourceGroupName $RG1 -Location $Location1 -VM $VirtualMachine -Verbose
#Install IIS on the VM

Set-AzVMExtension `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server"}' `
-Location $Location1

This is a simple virtual machine that you use to connect using Remote Desktop to the public IP address. From
there, you then connect to the on-premises server through the firewall. When prompted, type a user name and
password for the virtual machine.
New-AzVm `
-Name "VM-Onprem" `
-Location $Location1 `
-VirtualNetworkName $VNetnameOnprem `
-SubnetName $SNNameOnprem `
-OpenPorts 3389 `
-Size "Standard_DS2"
NOTE
IP is disabled.
Test the firewall

First, get and then note the private IP address for VM-spoke-01 virtual machine.
$NIC.IpConfigurations.privateipaddress
From the Azure portal, connect to the VM-Onprem virtual machine.

Open a web browser on VM-Onprem , and browse to http://<VM-spoke-01 private IP>.
You should see the Internet Information Services default page.
From VM-Onprem , open a remote desktop to VM-spoke-01 at the private IP address.
Your connection should succeed, and you should be able to sign in using your chosen username and password.
expected. Run the following script to change the rule collection action to Deny .
$rcNet = $azfw.GetNetworkRuleCollectionByName("RCNet01")
$rcNet.action.type = "Deny"
Set-AzFirewall -AzureFirewall $azfw
Now run the tests again. They should all fail this time. Close any existing remote desktops before testing the
changed rules.
Clean up resources
You can keep your firewall resources for the next tutorial, or if no longer needed, delete the FW-Hybrid-Test
Next steps
Deploy and configure Azure Firewall using Azure
CLI
accessed.
Application rules that define fully qualified domain names (FQDNs) that can be accessed from a subnet. The
FQDN can also include SQL instances.
deployments, a hub and spoke model is recommended. The firewall is in its own VNet. The workload servers are
in peered VNets in the same region with one or more subnets.
Jump-SN - The "jump" server is in this subnet. The jump server has a public IP address that you can connect
to using Remote Desktop. From there, you can then connect to (using another Remote Desktop) the workload
server.

Deploy a firewall
Test the firewall
If you prefer, you can complete this procedure using the Azure portal or Azure PowerShell.
If you don't have an Azure subscription, create an Azure free account before you begin.
Prerequisites
Use the Bash environment in Azure Cloud Shell. For more information, see Azure Cloud Shell Quickstart -
Bash.
If you prefer to run CLI reference commands locally, install the Azure CLI. If you're running on Windows
or macOS, consider running Azure CLI in a Docker container. For more information, see How to run the
Azure CLI in a Docker container.
If you're using a local installation, sign in to the Azure CLI by using the az login command. To finish
the authentication process, follow the steps displayed in your terminal. For other sign-in options,
see Sign in with the Azure CLI.
When you're prompted, install the Azure CLI extension on first use. For more information about
extensions, see Use extensions with the Azure CLI.
Run az version to find the version and dependent libraries that are installed. To upgrade to the
latest version, run az upgrade.
This article requires version 2.0.4 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is
already installed.
Set up the network

az group create --name Test-FW-RG --location eastus
Create a VNet
This virtual network has three subnets.
NOTE
az network vnet create \
--name Test-FW-VN \
--resource-group Test-FW-RG \
--location eastus \
--address-prefix 10.0.0.0/16 \
--subnet-name AzureFirewallSubnet \
--subnet-prefix 10.0.1.0/26
az network vnet subnet create \
--name Workload-SN \
--vnet-name Test-FW-VN \
--address-prefix 10.0.2.0/24
--name Jump-SN \

Now create the jump and workload virtual machines, and place them in the appropriate subnets. When
prompted, type a password for the virtual machine.
Create the Srv-Jump virtual machine.
az vm create \
--name Srv-Jump \
--location eastus \
--image win2016datacenter \
--subnet Jump-SN \
--admin-username azureadmin
az vm open-port --port 3389 --resource-group Test-FW-RG --name Srv-Jump
Create a NIC for Srv-Work with specific DNS server IP addresses and no public IP address to test with.
az network nic create \

-g Test-FW-RG \
-n Srv-Work-NIC \
--subnet Workload-SN \
--public-ip-address "" \
--dns-servers 209.244.0.3 209.244.0.4
Now create the workload virtual machine. When prompted, type a password for the virtual machine.
az vm create \
--name Srv-Work \
--location eastus \
--image win2016datacenter \
--nics Srv-Work-NIC \
--admin-username azureadmin
NOTE
IP is disabled.
Deploy the firewall

az network firewall create \

--name Test-FW01 \
--location eastus
az network public-ip create \
--name fw-pip \
--location eastus \
--allocation-method static \
--sku standard
az network firewall ip-config create \
--firewall-name Test-FW01 \
--name FW-config \
--public-ip-address fw-pip \
--vnet-name Test-FW-VN
az network firewall update \
--name Test-FW01 \
--resource-group Test-FW-RG
az network public-ip show \
--name fw-pip \
--resource-group Test-FW-RG
fwprivaddr="$(az network firewall ip-config list -g Test-FW-RG -f Test-FW01 --query "[?name=='FW-
config'].privateIpAddress" --output tsv)"

az network route-table create \

--name Firewall-rt-table \
--location eastus \
--disable-bgp-route-propagation true
Create the route.

az network route-table route create \
--name DG-Route \
--route-table-name Firewall-rt-table \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address $fwprivaddr
Associate the route table to the subnet
az network vnet subnet update \

-n Workload-SN \
-g Test-FW-RG \
--address-prefixes 10.0.2.0/24 \
--route-table Firewall-rt-table

The application rule allows outbound access to www.google.com.
az network firewall application-rule create \

--collection-name App-Coll01 \
--name Allow-Google \
--protocols Http=80 Https=443 \
--target-fqdns www.google.com \
--source-addresses 10.0.2.0/24 \
--priority 200 \
--action Allow

az network firewall network-rule create \

--collection-name Net-Coll01 \
--destination-addresses 209.244.0.3 209.244.0.4 \
--destination-ports 53 \
--name Allow-DNS \
--protocols UDP \
--priority 200 \
--action Allow
Test the firewall

1. Note the private IP address for the Sr v-Work virtual machine:
az vm list-ip-addresses \
-g Test-FW-RG \
-n Srv-Work
2. Connect a remote desktop to Sr v-Jump virtual machine, and sign in. From there, open a remote desktop
connection to the Sr v-Work private IP address and sign in.
3. On SRV-Work , open a PowerShell window and run the following commands:


Clean up resources
resource group to delete all firewall-related resources:
az group delete \
-n Test-FW-RG
Next steps
Deploy an Azure Firewall with multiple public IP
addresses using Azure PowerShell
This feature enables the following scenarios:

DNAT - You can translate multiple standard port instances to your backend servers. For example, if you have
two public IP addresses, you can translate TCP port 3389 (RDP) for both IP addresses.
SNAT - Additional ports are available for outbound SNAT connections, reducing the potential for SNAT port
exhaustion. At this time, Azure Firewall randomly selects the source public IP address to use for a connection.
If you have any downstream filtering on your network, you need to allow all public IP addresses associated
with your firewall. Consider using a public IP address prefix to simplify this configuration.
Azure Firewall with multiple public IP addresses is available via the Azure portal, Azure PowerShell, Azure CLI,
REST, and templates. You can deploy an Azure Firewall with up to 250 public IP addresses.
The following Azure PowerShell examples show how you can configure, add, and remove public IP addresses for
Azure Firewall.
NOTE
You can't remove the first ipConfiguration from the Azure Firewall public IP address configuration page. If you want to
modify the IP address, you can use Azure PowerShell.
Create a firewall with two or more public IP addresses

This example creates a firewall attached to virtual network vnet with two public IP addresses.
$rgName = "resourceGroupName"
$vnet = Get-AzVirtualNetwork `
-Name "vnet" `
-ResourceGroupName $rgName
$pip1 = New-AzPublicIpAddress `
-Name "AzFwPublicIp1" `
-ResourceGroupName "rg" `
-Sku "Standard" `
-Location "centralus" `
-AllocationMethod Static
-Sku "Standard" `
New-AzFirewall `
-Name "azFw" `
-ResourceGroupName $rgName `
-Location centralus `
-VirtualNetwork $vnet `
-PublicIpAddress @($pip1, $pip2)
Add a public IP address to an existing firewall
In this example, the public IP address azFwPublicIp1 is attached to the firewall.
$pip = New-AzPublicIpAddress `
-Name "azFwPublicIp1" `
-Sku "Standard" `
$azFw = Get-AzFirewall `
-Name "AzureFirewall" `
-ResourceGroupName "rg"
$azFw.AddPublicIpAddress($pip)
$azFw | Set-AzFirewall
Remove a public IP address from an existing firewall

In this example, the public IP address azFwPublicIp1 is detached from the firewall.
$pip = Get-AzPublicIpAddress `
-Name "azFwPublicIp1" `
$azFw = Get-AzFirewall `
-Name "AzureFirewall" `
$azFw.RemovePublicIpAddress($pip)
Next steps
Quickstart: Create an Azure Firewall with multiple public IP addresses - Resource Manager template
Deploy an Azure Firewall with Availability Zones
using Azure PowerShell
Azure Firewall can be configured during deployment to span multiple Availability Zones for increased
availability.
This feature enables the following scenarios:
You can increase availability to 99.99% uptime. For more information, see the Azure Firewall Service Level
Agreement (SLA). The 99.99% uptime SLA is offered when two or more Availability Zones are selected.
You can also associate Azure Firewall to a specific zone just for proximity reasons, using the service standard
99.95% SLA.
For more information about Azure Firewall Availability Zones, see What is Azure Firewall?
The following Azure PowerShell example shows how you can deploy an Azure Firewall with Availability Zones.
Create a firewall with Availability Zones

This example creates a firewall in zones 1, 2, and 3.
When the standard public IP address is created, no specific zone is specified. This creates a zone-redundant IP
address by default. Standard public IP addresses can be configured either in all zones, or a single zone.
It's important to know, because you can't have a firewall in zone 1 and an IP address in zone 2. But you can have
a firewall in zone 1 and IP address in all zones, or a firewall and an IP address in the same single zone for
proximity purposes.
$rgName = "resourceGroupName"
$vnet = Get-AzVirtualNetwork `
-Name "vnet" `
-ResourceGroupName $rgName
-Sku "Standard" `
New-AzFirewall `
-Name "azFw" `
-ResourceGroupName $rgName `
-Location centralus `
-VirtualNetwork $vnet `
-PublicIpAddress @($pip1) `
-Zone 1,2,3
Next steps
Integrate Azure Firewall with Azure Standard Load
Balancer
You can integrate an Azure Firewall into a virtual network with an Azure Standard Load Balancer (either public or
internal).
The preferred design is to integrate an internal load balancer with your Azure firewall, as this is a much simpler
design. You can use a public load balancer if you already have one deployed and you want to keep it in place.
However, you need to be aware of an asymmetric routing issue that can break functionality with the public load
balancer scenario.
For more information about Azure Load Balancer, see What is Azure Load Balancer?
Public load balancer

With a public load balancer, the load balancer is deployed with a public frontend IP address.
Asymmetric routing
Asymmetric routing is where a packet takes one path to the destination and takes another path when returning
to the source. This issue occurs when a subnet has a default route going to the firewall's private IP address and
you're using a public load balancer. In this case, the incoming load balancer traffic is received via its public IP
address, but the return path goes through the firewall's private IP address. Since the firewall is stateful, it drops
the returning packet because the firewall isn't aware of such an established session.
Fix the routing issue
When you deploy an Azure Firewall into a subnet, one step is to create a default route for the subnet directing
packets through the firewall's private IP address located on the AzureFirewallSubnet. For more information, see
Tutorial: Deploy and configure Azure Firewall using the Azure portal.
When you introduce the firewall into your load balancer scenario, you want your Internet traffic to come in
through your firewall's public IP address. From there, the firewall applies its firewall rules and NATs the packets
to your load balancer's public IP address. This is where the problem occurs. Packets arrive on the firewall's public
IP address, but return to the firewall via the private IP address (using the default route). To avoid this problem,
create an additional host route for the firewall's public IP address. Packets going to the firewall's public IP
address are routed via the Internet. This avoids taking the default route to the firewall's private IP address.
Route table example
For example, the following routes are for a firewall at public IP address 20.185.97.136, and private IP address
10.0.1.4.
NAT rule example

In the following example, a NAT rule translates RDP traffic to the firewall at 20.185.97.136 over to the load
balancer at 20.42.98.220:
Health probes
Remember, you need to have a web service running on the hosts in the load balancer pool if you use TCP health
probes to port 80, or HTTP/HTTPS probes.
Internal load balancer

With an internal load balancer, the load balancer is deployed with a private frontend IP address.
There's no asymmetric routing issue with this scenario. The incoming packets arrive at the firewall's public IP
address, get translated to the load balancer's private IP address, and then returns to the firewall's private IP
address using the same return path.
So, you can deploy this scenario similar to the public load balancer scenario, but without the need for the
firewall public IP address host route.
The virtual machines in the backend pool can have outbound Internet connectivity through the Azure Firewall.
Configure a user defined route on the virtual machine's subnet with the firewall as the next hop.
Additional security
To further enhance the security of your load-balanced scenario, you can use network security groups (NSGs).
For example, you can create an NSG on the backend subnet where the load-balanced virtual machines are
located. Allow incoming traffic originating from the firewall IP address/port.
For more information about NSGs, see Security groups.
Next steps
Configure Azure Firewall application rules with SQL
FQDNs
You can now configure Azure Firewall application rules with SQL FQDNs. This allows you to limit access from
your virtual networks to only the specified SQL server instances.
With SQL FQDNs, you can filter traffic:
From your VNets to an Azure SQL Database or Azure Synapse Analytics. For example: Only allow access to
sql-server1.database.windows.net.
From on-premises to Azure SQL Managed Instances or SQL IaaS running in your VNets.
From spoke-to-spoke to Azure SQL Managed Instances or SQL IaaS running in your VNets.
SQL FQDN filtering is supported in proxy-mode only (port 1433). If you use SQL in the default redirect mode,
you can filter access using the SQL service tag as part of network rules. If you use non-default ports for SQL
IaaS traffic, you can configure those ports in the firewall application rules.
Configure using Azure CLI

1. Deploy an Azure Firewall using Azure CLI.
2. If you filter traffic to Azure SQL Database, Azure Synapse Analytics, or SQL Managed Instance, ensure the
SQL connectivity mode is set to Proxy . To learn how to switch SQL connectivity mode, see Azure SQL
Connectivity Settings.
NOTE
SQL proxy mode can result in more latency compared to redirect. If you want to continue using redirect mode,
which is the default for clients connecting within Azure, you can filter access using the SQL service tag in firewall
network rules.
3. Create a new rule collection with an application rule using SQL FQDN to allow access to a SQL server:
az extension add -n azure-firewall
az network firewall application-rule create \

-g FWRG \
--f azfirewall \
--c sqlRuleCollection \
--priority 1000 \
--action Allow \
--name sqlRule \
--protocols mssql=1433 \
--target-fqdns sql-serv1.database.windows.net
Configure using Azure PowerShell

1. Deploy an Azure Firewall using Azure PowerShell.
NOTE
network rules.
3. Create a new rule collection with an application rule using SQL FQDN to allow access to a SQL server:
$AzFw = Get-AzFirewall -Name "azfirewall" -ResourceGroupName "FWRG"
$sqlRule = @{
Name = "sqlRule"
Protocol = "mssql:1433"
TargetFqdn = "sql-serv1.database.windows.net"
SourceAddress = "10.0.0.0/24"
}
$rule = New-AzFirewallApplicationRule @sqlRule
$sqlRuleCollection = @{
Name = "sqlRuleCollection"
Priority = 1000
Rule = $rule
ActionType = "Allow"
}
$ruleCollection = New-AzFirewallApplicationRuleCollection @sqlRuleCollection
$Azfw.ApplicationRuleCollections.Add($ruleCollection)
Set-AzFirewall -AzureFirewall $AzFw
Configure using the Azure portal

1. Deploy an Azure Firewall using Azure CLI.
NOTE
network rules.
3. Add the application rule with the appropriate protocol, port, and SQL FQDN and then select Save .
4. Access SQL from a virtual machine in a VNet that filters the traffic through the firewall.
5. Validate that Azure Firewall logs show the traffic is allowed.
Next steps
To learn about SQL proxy and redirect modes, see Azure SQL Database connectivity architecture.
Azure Firewall SNAT private IP address ranges
Azure Firewall provides automatic SNAT for all outbound traffic to public IP addresses. By default, Azure Firewall
doesn't SNAT with Network rules when the destination IP address is in a private IP address range per IANA RFC
1918 or shared address space per IANA RFC 6598. Application rules are always applied using a transparent
proxy whatever the destination IP address.
This logic works well when you route traffic directly to the Internet. However, if you've enabled forced tunneling,
Internet-bound traffic is SNATed to one of the firewall private IP addresses in AzureFirewallSubnet, hiding the
source from your on-premises firewall.
If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one
of the firewall private IP addresses in AzureFirewallSubnet. However, you can configure Azure Firewall to not
SNAT your public IP address range. For example, to specify an individual IP address you can specify it like this:
192.168.1.10 . To specify a range of IP addresses, you can specify it like this: 192.168.1.0/24 .
To configure Azure Firewall to never SNAT regardless of the destination IP address, use 0.0.0.0/0 as
your private IP address range. With this configuration, Azure Firewall can never route traffic directly to
the Internet.
To configure the firewall to always SNAT regardless of the destination address, use
255.255.255.255/32 as your private IP address range.
IMPORTANT
The private address range that you specify only applies to network rules. Currently, application rules always SNAT.
IMPORTANT
If you want to specify your own private IP address ranges, and keep the default IANA RFC 1918 address ranges, make
sure your custom list still includes the IANA RFC 1918 range.
You can configure the SNAT private IP addresses using the following methods. You must configure the SNAT
private addresses using the method appropriate for your configuration. Firewalls associated with a firewall
policy must specify the range in the policy and not use AdditionalProperties .
M ET H O D USIN G C L A SSIC RUL ES USIN G F IREWA L L P O L IC Y
Azure portal supported supported
Azure PowerShell configure PrivateRange currently unsupported
Azure CLI configure --private-ranges currently unsupported
ARM template configure AdditionalProperties in configure snat/privateRanges in

firewall property firewall policy
Configure SNAT private IP address ranges - Azure PowerShell

Classic rules
You can use Azure PowerShell to specify private IP address ranges for the firewall.
NOTE
The firewall PrivateRange property is ignored for firewalls associated with a Firewall Policy. You must use the SNAT
property in firewallPolicies as described in Configure SNAT private IP address ranges - ARM template.
New firewall
For a new firewall using classic rules, the Azure PowerShell cmdlet is:
$azFw = @{
Name = '<fw-name>'
ResourceGroupName = '<resourcegroup-name>'
Location = '<location>'
VirtualNetworkName = '<vnet-name>'
PublicIpName = '<public-ip-name>'
PrivateRange = @("IANAPrivateRanges", "192.168.1.0/24", "192.168.1.10")
}
New-AzFirewall @azFw
NOTE
Deploying Azure Firewall using New-AzFirewall requires an existing VNet and Public IP address. See Deploy and
configure Azure Firewall using Azure PowerShell for a full deployment guide.
NOTE
IANAPrivateRanges is expanded to the current defaults on Azure Firewall while the other ranges are added to it. To keep
the IANAPrivateRanges default in your private range specification, it must remain in your PrivateRange specification as
shown in the following examples.
For more information, see New-AzFirewall.

Existing firewall
To configure an existing firewall using classic rules, use the following Azure PowerShell cmdlets:
$azfw = Get-AzFirewall -Name '<fw-name>' -ResourceGroupName '<resourcegroup-name>'

$azfw.PrivateRange = @("IANAPrivateRanges","192.168.1.0/24", "192.168.1.10")
Configure SNAT private IP address ranges - Azure CLI

Classic rules
You can use Azure CLI to specify private IP address ranges for the firewall using classic rules.
New firewall
For a new firewall using classic rules, the Azure CLI command is:
az network firewall create \
-n <fw-name> \
-g <resourcegroup-name> \
--private-ranges 192.168.1.0/24 192.168.1.10 IANAPrivateRanges
NOTE
Deploying Azure Firewall using Azure CLI command az network firewall create requires additional configuration
steps to create public IP addresses and IP configuration. See Deploy and configure Azure Firewall using Azure CLI for a full
deployment guide.
NOTE
IANAPrivateRanges is expanded to the current defaults on Azure Firewall while the other ranges are added to it. To keep
the IANAPrivateRanges default in your private range specification, it must remain in your private-ranges specification
as shown in the following examples.
Existing firewall
To configure an existing firewall using classic rules, the Azure CLI command is:

-n <fw-name> \
-g <resourcegroup-name> \
--private-ranges 192.168.1.0/24 192.168.1.10 IANAPrivateRanges
Configure SNAT private IP address ranges - ARM template

Classic rules
To configure SNAT during ARM Template deployment, you can add the following to the additionalProperties
property:
"additionalProperties": {
"Network.SNAT.PrivateRanges": "IANAPrivateRanges , IPRange1, IPRange2"
},
Firewall policy
Azure Firewalls associated with a firewall policy have supported SNAT private ranges since the 2020-11-01 API
version. Currently, you can use a template to update the SNAT private range on the Firewall Policy. The following
sample configures the firewall to always SNAT network traffic:
{
"type":"Microsoft.Network/firewallPolicies",
"apiVersion":"2020-11-01",
"name":"[parameters('firewallPolicies_DatabasePolicy_name')]",
"location":"eastus",
"properties":{
"sku":{
"tier":"Standard"
},
"snat":{
"privateRanges":[255.255.255.255/32]
}
}
Configure SNAT private IP address ranges - Azure portal

Classic rules
You can use the Azure portal to specify private IP address ranges for the firewall.
1. Select your resource group, and then select your firewall.
2. On the Over view page, Private IP Ranges , select the default value IANA RFC 1918 .
The Edit Private IP Prefixes page opens:
3. By default, IANAPrivateRanges is configured.
4. Edit the private IP address ranges for your environment and then select Save .
Firewall policy
1. Select your resource group, and then select your firewall policy.
2. Select Private IP ranges (SNAT) in the Settings column.
By default, Use the default Azure Firewall Policy SNAT behavior is selected.
3. To customize the SNAT configuration, clear the check box, and under Perform SNAT select the
conditions to perform SNAT for your environment.
4. Select Apply .
Next steps
Learn about Azure Firewall forced tunneling.
Create IP Groups
IP Groups allow you to group and manage IP addresses for Azure Firewall rules. They can have a single IP
address, multiple IP addresses, or one or more IP address ranges.
Create an IP Group - Azure portal

To create an IP Group by using the Azure portal:
1. On the Azure portal home page, select Create a resource .
2. In the search box, enter IP Groups , and then select IP Groups .
3. Select Create .
4. Select your subscription.
5. Select a resource group or create a new one.
6. Enter a unique name for you IP Group, and then select a region.
8. Type an IP address, multiple IP addresses, or IP address ranges.
There are two ways to enter IP addresses:
You can manually enter them
You can import them from a file
To import from a file, select Impor t from a file . You may either drag your file to the box or select
Browse for files . If necessary, you can review and edit your uploaded IP addresses.
When you type an IP address, the portal validates it to check for overlapping, duplicates, and formatting
issues.
9. When finished, select Review + Create .
10. Select Create .
Create an IP Group - Azure PowerShell

This example creates an IP Group with an address prefix and an IP address by using Azure PowerShell:
$ipGroup = @{
Name = 'ipGroup'
ResourceGroupName = 'ipGroupRG'
Location = 'West US'
IpAddress = @('10.0.0.0/24', '192.168.1.10')
}
New-AzIpGroup @ipGroup
Create an IP Group - Azure CLI

This example creates an IP Group with an address prefix and an IP address by using the Azure CLI:
az network ip-group create \

--name ipGroup \
--resource-group ipGroupRG \
--location westus \
--ip-addresses '10.0.0.0/24' '192.168.1.10'
Next steps
Learn more about IP Groups
Use Azure Firewall to protect Azure Virtual Desktop
deployments
Azure Virtual Desktop is a desktop and app virtualization service that runs on Azure. When an end user
connects to an Azure Virtual Desktop environment, their session is run by a host pool. A host pool is a collection
of Azure virtual machines that register to Azure Virtual Desktop as session hosts. These virtual machines run in
your virtual network and are subject to the virtual network security controls. They need outbound Internet
access to the Azure Virtual Desktop service to operate properly and might also need outbound Internet access
for end users. Azure Firewall can help you lock down your environment and filter outbound traffic.
Follow the guidelines in this article to provide additional protection for your Azure Virtual Desktop host pool
using Azure Firewall.
Prerequisites
A deployed Azure Virtual Desktop environment and host pool.
An Azure Firewall deployed with at least one Firewall Manager Policy
For more information, see Tutorial: Create a host pool by using the Azure portal
To learn more about Azure Virtual Desktop environments see Azure Virtual Desktop environment.
Host pool outbound access to Azure Virtual Desktop

The Azure virtual machines you create for Azure Virtual Desktop must have access to several Fully Qualified
Domain Names (FQDNs) to function properly. Azure Firewall provides an Azure Virtual Desktop FQDN Tag to
simplify this configuration. Use the following steps to allow outbound Azure Virtual Desktop platform traffic:
You will need to create an Azure Firewall Policy and create Rule Collections for Network Rules and Applications
Rules. Give the Rule Collection a priority and an allow or deny action.
Create network rules
DEST IN AT IO N DEST IN AT IO N
NAME SO URC E T Y P E SO URC E P ROTO C O L P O RT S TYPE DEST IN AT IO N
Rule Name IP Address VNet or TCP 80 IP Address 169.254.169.

Subnet IP 254,
Address 168.63.129.1
6
Rule Name IP Address VNet or TCP 443 Service Tag AzureCloud,

Subnet IP WindowsVirtu
Address alDesktop,
AzureFrontDo
or.Frontend
Rule Name IP Address VNet or TCP, UDP 53 IP Address *

Subnet IP
Address
Rule name IP Address VNet or TCP 1688 IP address 20.118.99.22

Subnet IP 4,
Address 40.83.235.53
(azkms.core.wi
ndows.net)
Rule name IP Address VNet or TCP 1688 IP address 23.102.135.2

Subnet IP 46
Address (kms.core.win
dows.net)
NOTE
Some deployments might not need DNS rules. For example, Azure Active Directory Domain controllers forward DNS
queries to Azure DNS at 168.63.129.16.
Create application rules

DEST IN AT IO N
NAME SO URC E T Y P E SO URC E P ROTO C O L TYPE DEST IN AT IO N
Rule Name IP Address VNet or Subnet Https:443 FQDN Tag WindowsVirtualD

IP Address esktop,
WindowsUpdate,
Windows
Diagnostics,
MicrosoftActiveP
rotectionService
IMPORTANT
We recommend that you don't use TLS inspection with Azure Virtual Desktop. For more information, see the proxy server
guidelines.
Host pool outbound access to the Internet

Depending on your organization needs, you might want to enable secure outbound internet access for your end
users. If the list of allowed destinations is well-defined (for example, for Microsoft 365 access), you can use
Azure Firewall application and network rules to configure the required access. This routes end-user traffic
directly to the internet for best performance. If you need to allow network connectivity for Windows 365 or
Intune, see Network requirments for Windows 365 and Network endpoints for Intune.
If you want to filter outbound user internet traffic by using an existing on-premises secure web gateway, you can
configure web browsers or other applications running on the Azure Virtual Desktop host pool with an explicit
proxy configuration. For example, see How to use Microsoft Edge command-line options to configure proxy
settings. These proxy settings only influence your end-user internet access, allowing the Azure Virtual Desktop
platform outbound traffic directly via Azure Firewall.
Control user access to the web

Admins can allow or deny user access to different website categories. Add a rule to your Application Collection
from your specific IP address to web categories you want to allow or deny. Review all the web categories.
Additional considerations
You might need to configure additional firewall rules, depending on your requirements:
NTP server access
By default, virtual machines running Windows connect to time.windows.com over UDP port 123 for time
synchronization. Create a network rule to allow this access, or for a time server that you use in your
environment.
Next steps
Learn more about Azure Virtual Desktop: What is Azure Virtual Desktop?
Use Azure Firewall to protect Azure Kubernetes
Service (AKS) clusters
This article shows you how you can protect Azure Kubernetes Service (AKS) clusters by using Azure Firewall to
secure outbound and inbound traffic.
Background
Azure Kubernetes Service (AKS) offers a managed Kubernetes cluster on Azure. For more information, see Azure
Kubernetes Service.
Despite AKS being a fully managed solution, it does not offer a built-in solution to secure ingress and egress
traffic between the cluster and external networks. Azure Firewall offers a solution to this.
AKS clusters are deployed on a virtual network. This network can be managed (created by AKS) or custom (pre-
configured by the user beforehand). In either case, the cluster has outbound dependencies on services outside
of that virtual network (the service has no inbound dependencies). For management and operational purposes,
nodes in an AKS cluster need to access certain ports and fully qualified domain names (FQDNs) describing these
outbound dependencies. This is required for various functions including, but not limited to, the nodes that
communicate with the Kubernetes API server. They download and install core Kubernetes cluster components
and node security updates, or pull base system container images from Microsoft Container Registry (MCR), and
so on. These outbound dependencies are almost entirely defined with FQDNs, which don't have static addresses
behind them. The lack of static addresses means that Network Security Groups can't be used to lock down
outbound traffic from an AKS cluster. For this reason, by default, AKS clusters have unrestricted outbound
(egress) Internet access. This level of network access allows nodes and services you run to access external
resources as needed.
However, in a production environment, communications with a Kubernetes cluster should be protected to
prevent against data exfiltration along with other vulnerabilities. All incoming and outgoing network traffic must
be monitored and controlled based on a set of security rules. If you want to do this, you will have to restrict
egress traffic, but a limited number of ports and addresses must remain accessible to maintain healthy cluster
maintenance tasks and satisfy those outbound dependencies previously mentioned.
The simplest solution uses a firewall device that can control outbound traffic based on domain names. A firewall
typically establishes a barrier between a trusted network and an untrusted network, such as the Internet. Azure
Firewall, for example, can restrict outbound HTTP and HTTPS traffic based on the FQDN of the destination,
giving you fine-grained egress traffic control, but at the same time allows you to provide access to the FQDNs
encompassing an AKS cluster’s outbound dependencies (something that NSGs cannot do). Likewise, you can
control ingress traffic and improve security by enabling threat intelligence-based filtering on an Azure Firewall
deployed to a shared perimeter network. This filtering can provide alerts, and deny traffic to and from known
malicious IP addresses and domains.
See the following video by Abhinav Sriram for a quick overview on how this works in practice on a sample
environment:
You can download a zip file from the Microsoft Download Center that contains a bash script file and a yaml file
to automatically configure the sample environment used in the video. It configures Azure Firewall to protect
both ingress and egress traffic. The following guides walk through each step of the script in more detail so you
can set up a custom configuration.
The following diagram shows the sample environment from the video that the script and guide configure:
There is one difference between the script and the following guide. The script uses managed identities, but the
guide uses a service principal. This shows you two different ways to create an identity to manage and create
cluster resources.
Restrict egress traffic using Azure Firewall

Set configuration via environment variables
Define a set of environment variables to be used in resource creations.
PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"
Create a virtual network with multiple subnets

Provision a virtual network with two separate subnets, one for the cluster, one for the firewall. Optionally you
could also create one for internal service ingress.
Create a resource group to hold all of the resources.
# Create Resource Group
az group create --name $RG --location $LOC
Create a virtual network with two subnets to host the AKS cluster and the Azure Firewall. Each will have their
own subnet. Let's start with the AKS network.
# Dedicated virtual network with AKS subnet
az network vnet create \

--resource-group $RG \
--name $VNET_NAME \
--location $LOC \
--address-prefixes 10.42.0.0/16 \
--subnet-name $AKSSUBNET_NAME \
--subnet-prefix 10.42.1.0/24
# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)

--resource-group $RG \
--vnet-name $VNET_NAME \
--name $FWSUBNET_NAME \
Create and set up an Azure Firewall with a UDR

Azure Firewall inbound and outbound rules must be configured. The main purpose of the firewall is to enable
organizations to configure granular ingress and egress traffic rules into and out of the AKS Cluster.
IMPORTANT
If your cluster or application creates a large number of outbound connections directed to the same or small subset of
destinations, you might require more firewall frontend IPs to avoid maxing out the ports per frontend IP. For more
information on how to create an Azure firewall with multiple IPs, see here
Create a standard SKU public IP resource that will be used as the Azure Firewall frontend address.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Register the preview cli-extension to create an Azure Firewall.
# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
The IP address created earlier can now be assigned to the firewall frontend.
NOTE
Set up of the public IP address to the Azure Firewall may take a few minutes. To leverage FQDN on network rules we need
DNS proxy enabled, when enabled the firewall will listen on port 53 and will forward DNS requests to the DNS server
specified above. This will allow the firewall to translate that FQDN automatically.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address

$FWPUBLICIP_NAME --vnet-name $VNET_NAME
When the previous command has succeeded, save the firewall frontend IP address for configuration later.
# Capture Firewall IP Address for Later Use
FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)

FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIpAddress" -o
tsv)
NOTE
If you use secure access to the AKS API server with authorized IP address ranges, you need to add the firewall public IP
into the authorized IP range.
Create a UDR with a hop to Azure Firewall

Azure automatically routes traffic between Azure subnets, virtual networks, and on-premises networks. If you
want to change any of Azure's default routing, you do so by creating a route table.
Create an empty route table to be associated with a given subnet. The route table will define the next hop as the
Azure Firewall created above. Each subnet can have zero or one route table associated to it.
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME

az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --
address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name
$FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
See virtual network route table documentation about how you can override Azure's default system routes or
add additional routes to a subnet's route table.
Adding firewall rules
NOTE
For applications outside of the kube-system or gatekeeper-system namespaces that needs to talk to the API server, an
additional network rule to allow TCP communication to port 443 for the API server IP in addition to adding application
rule for fqdn-tag AzureKubernetesService is required.
Below are three network rules you can use to configure on your firewall, you may need to adapt these rules
based on your deployment. The first rule allows access to port 9000 via TCP. The second rule allows access to
port 1194 and 123 via UDP. Both these rules will only allow traffic destined to the Azure Region CIDR that we're
using, in this case East US. Finally, we'll add a third network rule opening port 123 to ntp.ubuntu.com FQDN via
UDP (adding an FQDN as a network rule is one of the specific features of Azure Firewall, and you'll need to
adapt it when using your own options).
After setting the network rules, we'll also add an application rule using the AzureKubernetesService that covers
all needed FQDNs accessible through TCP port 443 and port 80.
# Add FW Network Rules
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --

protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --
action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --
protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols
'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
# Add FW Application Rules
az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --

source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow -
-priority 100
See Azure Firewall documentation to learn more about the Azure Firewall service.
Associate the route table to AKS
To associate the cluster with the firewall, the dedicated subnet for the cluster's subnet must reference the route
table created above. Association can be done by issuing a command to the virtual network holding both the
cluster and firewall to update the route table of the cluster's subnet.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table
$FWROUTE_TABLE_NAME
Deploy AKS with outbound type of UDR to the existing network

Now an AKS cluster can be deployed into the existing virtual network. We'll also use outbound type
userDefinedRouting , this feature ensures any outbound traffic will be forced through the firewall and no other
egress paths will exist (by default the Load Balancer outbound type could be used).
The target subnet to be deployed into is defined with the environment variable, $SUBNETID . We didn't define the
$SUBNETID variable in the previous steps. To set the value for the subnet ID, you can use the following command:
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o
tsv)
You'll define the outbound type to use the UDR that already exists on the subnet. This configuration will enable
AKS to skip the setup and IP provisioning for the load balancer.
IMPORTANT
For more information on outbound type UDR including limitations, see egress outbound type UDR.
TIP
Additional features can be added to the cluster deployment such as Private Cluster .
The AKS feature for API ser ver authorized IP ranges can be added to limit API server access to only the firewall's
public endpoint. The authorized IP ranges feature is denoted in the diagram as optional. When enabling the authorized IP
range feature to limit API server access, your developer tools must use a jumpbox from the firewall's virtual network or
you must add all developer endpoints to the authorized IP range.
az aks create -g $RG -n $AKSNAME -l $LOC \

--node-count 3 \
--network-plugin $PLUGIN \
--outbound-type userDefinedRouting \
--vnet-subnet-id $SUBNETID \
--api-server-authorized-ip-ranges $FWPUBLIC_IP
NOTE
For creating and using your own VNet and route table where the resources are outside of the worker node resource
group, the CLI will add the role assignment automatically. If you are using an ARM template or other client, you need to
use the Principal ID of the cluster managed identity to perform a [role assignment.][add role to identity]
If you are not using the CLI but using your own VNet or route table which are outside of the worker node resource
group, it's recommended to use [user-assigned control plane identity][Bring your own control plane managed identity].
For system-assigned control plane identity, we cannot get the identity ID before creating cluster, which causes delay for
role assignment to take effect.
Enable developer access to the API server

If you used authorized IP ranges for the cluster on the previous step, you must add your developer tooling IP
addresses to the AKS cluster list of approved IP ranges in order to access the API server from there. Another
option is to configure a jumpbox with the needed tooling inside a separate subnet in the Firewall's virtual
network.
Add another IP address to the approved ranges with the following command
# Retrieve your IP address

CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list

az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Use the [az aks get-credentials][az-aks-get-credentials] command to configure kubectl to connect to your
newly created Kubernetes cluster.
az aks get-credentials -g $RG -n $AKSNAME
Restrict ingress traffic using Azure Firewall

You can now start exposing services and deploying applications to this cluster. In this example, we'll expose a
public service, but you may also choose to expose an internal service via internal load balancer.
Deploy the Azure voting app application by copying the yaml below to a file named example.yaml .
# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-storage
spec:
replicas: 1
selector:
matchLabels:
app: voting-storage
template:
metadata:
labels:
app: voting-storage
spec:
containers:
- name: voting-storage
image: mcr.microsoft.com/aks/samples/voting/storage:2.0
args: ["--ignore-db-dir=lost+found"]
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
type: Opaque
data:
MYSQL_USER: ZGJ1c2Vy
MYSQL_PASSWORD: UGFzc3dvcmQxMg==
MYSQL_DATABASE: YXp1cmV2b3Rl
MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-storage
labels:
app: voting-storage
spec:
ports:
- port: 3306
name: mysql
selector:
app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app
name: voting-app
spec:
replicas: 1
selector:
matchLabels:
app: voting-app
template:
metadata:
labels:
app: voting-app
spec:
containers:
- name: voting-app
image: mcr.microsoft.com/aks/samples/voting/app:2.0
imagePullPolicy: Always
ports:
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
- name: ANALYTICS_HOST
value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-app
labels:
app: voting-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: voting-app
---
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-analytics
spec:
replicas: 1
selector:
matchLabels:
app: voting-analytics
version: "2.0"
template:
metadata:
labels:
version: "2.0"
spec:
containers:
- name: voting-analytics
image: mcr.microsoft.com/aks/samples/voting/analytics:2.0
imagePullPolicy: Always
ports:
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_USER
valueFrom:
secretKeyRef:
key: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-analytics
labels:
spec:
ports:
- port: 8080
name: http
selector:
Deploy the service by running:
kubectl apply -f example.yaml
Add a DNAT rule to Azure Firewall
IMPORTANT
When you use Azure Firewall to restrict egress traffic and create a user-defined route (UDR) to force all egress traffic, make
sure you create an appropriate DNAT rule in Firewall to correctly allow ingress traffic. Using Azure Firewall with a UDR
breaks the ingress setup due to asymmetric routing. (The issue occurs if the AKS subnet has a default route that goes to
the firewall's private IP address, but you're using a public load balancer - ingress or Kubernetes service of type:
LoadBalancer). In this case, the incoming load balancer traffic is received via its public IP address, but the return path goes
through the firewall's private IP address. Because the firewall is stateful, it drops the returning packet because the firewall
isn't aware of an established session. To learn how to integrate Azure Firewall with your ingress or service load balancer,
see Integrate Azure Firewall with Azure Standard Load Balancer.
To configure inbound connectivity, a DNAT rule must be written to the Azure Firewall. To test connectivity to your
cluster, a rule is defined for the firewall frontend public IP address to route to the internal IP exposed by the
internal service.
The destination address can be customized as it's the port on the firewall to be accessed. The translated address
must be the IP address of the internal load balancer. The translated port must be the exposed port for your
Kubernetes service.
You'll need to specify the internal IP address assigned to the load balancer created by the Kubernetes service.
Retrieve the address by running:
kubectl get services
The IP address needed will be listed in the EXTERNAL-IP column, similar to the following.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m
voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m
voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m
Get the service IP by running:
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Add the NAT rule by running:
az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --

destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --
source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
Validate connectivity
Navigate to the Azure Firewall frontend IP address in a browser to validate connectivity.
You should see the AKS voting app. In this example, the Firewall public IP was 52.253.228.132 .
Clean up resources
To clean up Azure resources, delete the AKS resource group.
az group delete -g $RG
Next steps
Learn more about Azure Kubernetes Service, see Kubernetes core concepts for Azure Kubernetes Service
(AKS).
You can configure a custom DNS server and enable DNS proxy for Azure Firewall. Configure these settings
when you deploy the firewall, or configure them later from the DNS settings page. By default, Azure Firewall
uses Azure DNS and DNS Proxy is disabled.
DNS servers
A DNS server maintains and resolves domain names to IP addresses. By default, Azure Firewall uses Azure DNS
for name resolution. The DNS ser ver setting lets you configure your own DNS servers for Azure Firewall name
resolution. You can configure a single server or multiple servers. If you configure multiple DNS servers, the
server used is chosen randomly. You can configure a maximum of 15 DNS servers in Custom DNS .
NOTE
For instances of Azure Firewall that are managed by using Azure Firewall Manager, the DNS settings are configured in the
associated Azure Firewall policy.
Configure custom DNS servers - Azure portal

1. Under Azure Firewall Settings , select DNS Settings .
2. Under DNS ser vers , you can type or add existing DNS servers that have been previously specified in your
virtual network.
3. Select Apply .
The firewall now directs DNS traffic to the specified DNS servers for name resolution.
Configure custom DNS servers - Azure CLI

The following example updates Azure Firewall with custom DNS servers by using the Azure CLI.
--name fwName \
--resource-group fwRG \
--dns-servers 10.1.0.4 10.1.0.5
IMPORTANT
The command az network firewall requires the Azure CLI extension azure-firewall to be installed. You can install
it by using the command az extension add --name azure-firewall .
Configure custom DNS servers - Azure PowerShell

The following example updates Azure Firewall with custom DNS servers by using Azure PowerShell.
$dnsServers = @("10.1.0.4", "10.1.0.5")

$azFw = Get-AzFirewall -Name "fwName" -ResourceGroupName "fwRG"
$azFw.DNSServer = $dnsServers
DNS proxy
You can configure Azure Firewall to act as a DNS proxy. A DNS proxy is an intermediary for DNS requests from
client virtual machines to a DNS server.
If you want to enable FQDN (fully qualified domain name) filtering in network rules, enable DNS proxy and
update the virtual machine configuration to use the firewall as a DNS proxy.
If you enable FQDN filtering in network rules, and you don't configure client virtual machines to use the firewall
as a DNS proxy, then DNS requests from these clients might travel to a DNS server at a different time or return
a different response compared to that of the firewall. DNS proxy puts Azure Firewall in the path of the client
requests to avoid inconsistency.
When Azure Firewall is a DNS proxy, two caching function types are possible:
Positive cache : DNS resolution is successful. The firewall caches these responses according to the TTL
(time to live) in the response up to a maximum of 1 hour.
Negative cache : DNS resolution results in no response or no resolution. The firewall caches these
responses according to the TTL in the response, up to a max of 30 minutes.
The DNS proxy stores all resolved IP addresses from FQDNs in network rules. As a best practice, use FQDNs that
resolve to one IP address.
Policy inheritance
Policy DNS settings applied to a standalone firewall override the standalone firewall’s DNS settings. A child
policy inherits all parent policy DNS settings, but it can override the parent policy.
For example, to use FQDNs in network rule, DNS proxy should be enabled. But if a parent policy does not have
DNS proxy enabled, the child policy won't support FQDNs in network rules unless you locally override this
setting.
DNS proxy configuration
DNS proxy configuration requires three steps:
1. Enable the DNS proxy in Azure Firewall DNS settings.
2. Optionally, configure your custom DNS server or use the provided default.
3. Configure the Azure Firewall private IP address as a custom DNS address in your virtual network DNS server
settings. This setting ensures DNS traffic is directed to Azure Firewall.
Configure DNS proxy - Azure portal
To configure DNS proxy, you must configure your virtual network DNS servers setting to use the firewall private
IP address. Then enable the DNS proxy in the Azure Firewall DNS settings .
C o n fi g u r e v i r t u a l n e t w o r k D N S se r v e r s
1. Select the virtual network where the DNS traffic will be routed through the Azure Firewall instance.
4. Enter the firewall's private IP address.
5. Select Save .
6. Restart the VMs that are connected to the virtual network so they're assigned the new DNS server settings.
VMs continue to use their current DNS settings until they're restarted.
En a b l e D N S p r o x y
1. Select your Azure Firewall instance.

2. Under Settings , select DNS settings .
3. By default, DNS Proxy is disabled. When this setting is enabled, the firewall listens on port 53 and forwards
DNS requests to the configured DNS servers.
4. Review the DNS ser vers configuration to make sure that the settings are appropriate for your environment.
5. Select Save .
Configure DNS proxy - Azure CLI

You can use the Azure CLI to configure DNS proxy settings in Azure Firewall. You can also use it to update virtual
networks to use Azure Firewall as the DNS server.
The following example configures the virtual network to use Azure Firewall as the DNS server.
az network vnet update \

--name VNetName \
--resource-group VNetRG \
--dns-servers <firewall-private-IP>
The following example enables the DNS proxy feature in Azure Firewall.

--name fwName \
--resource-group fwRG \
--enable-dns-proxy true
Configure DNS proxy - Azure PowerShell

You can use Azure PowerShell to configure DNS proxy settings in Azure Firewall. You can also use it to update
virtual networks to use Azure Firewall as the DNS server.
The following example configures the virtual network to use Azure Firewall as a DNS server.
$dnsServers = @("<firewall-private-IP>")
$VNet = Get-AzVirtualNetwork -Name "VNetName" -ResourceGroupName "VNetRG"
$VNet.DhcpOptions.DnsServers = $dnsServers
$VNet | Set-AzVirtualNetwork
The following example enables the DNS proxy feature in Azure Firewall.
$azFw = Get-AzFirewall -Name "fwName" -ResourceGroupName "fwRG"

$azFw.DNSEnableProxy = $true
High availability failover

DNS proxy has a failover mechanism that stops using a detected unhealthy server and uses another DNS server
that is available.
If all DNS servers are unavailable, there's no fallback to another DNS server.
Health checks
DNS proxy performs five-second health check loops for as long as the upstream servers report as unhealthy.
The health checks are a recursive DNS query to the root name server. Once an upstream server is considered
healthy, the firewall stops health checks until the next error. When a healthy proxy returns an error, the firewall
selects another DNS server in the list.
Next steps
Azure Firewall DNS Proxy details
FQDN filtering in network rules
Monitor Azure Firewall logs and metrics
You can monitor Azure Firewall using firewall logs. You can also use activity logs to audit operations on Azure
Firewall resources. Using metrics, you can view performance counters in the portal.
You can access some of these logs through the portal. Logs can be sent to Azure Monitor logs, Storage, and
Event Hubs and analyzed in Azure Monitor logs or by different tools such as Excel and Power BI.
NOTE
This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in a
Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the
terminology to better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.
NOTE
This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with
Azure. To get started with the Az PowerShell module, see Install Azure PowerShell. To learn how to migrate to the Az
PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
Prerequisites
Before starting, you should read Azure Firewall logs and metrics for an overview of the diagnostics logs and
metrics available for Azure Firewall.
Enable diagnostic logging through the Azure portal

It can take a few minutes for the data to appear in your logs after you complete this procedure to turn on
diagnostic logging. If you don't see anything at first, check again in a few more minutes.
1. In the Azure portal, open your firewall resource group and select the firewall.
2. Under Monitoring , select Diagnostic settings .
For Azure Firewall, three service-specific logs are available:
AzureFirewallApplicationRule
AzureFirewallNetworkRule
AzureFirewallDnsProxy
3. Select Add diagnostic setting . The Diagnostics settings page provides the settings for the diagnostic
logs.
4. In this example, Azure Monitor logs stores the logs, so type Firewall log analytics for the name.
5. Under Log , select AzureFirewallApplicationRule , AzureFirewallNetworkRule , and
AzureFirewallDnsProxy to collect the logs.
6. Select Send to Log Analytics to configure your workspace.
7. Select your subscription.
8. Select Save .
Enable diagnostic logging by using PowerShell

Activity logging is automatically enabled for every Resource Manager resource. Diagnostic logging must be
enabled to start collecting the data available through those logs.
To enable diagnostic logging with PowerShell, use the following steps:
1. Note your Log Analytics Workspace resource ID, where the log data is stored. This value is of the form:
/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/microsoft.operationalinsights/workspaces/<workspace name>
You can use any workspace in your subscription. You can use the Azure portal to find this information.
The information is located in the resource Proper ties page.
2. Note the resource ID for the firewall. This value is of the form:
name>/providers/Microsoft.Network/azureFirewalls/<Firewall name>
You can use the portal to find this information.

3. Enable diagnostic logging for all logs and metrics by using the following PowerShell cmdlet:
$diagSettings = @{
Name = 'toLogAnalytics'
ResourceId = '/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Network/azureFirewalls/<Firewall name>'
WorkspaceId = '/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/microsoft.operationalinsights/workspaces/<workspace name>'
Enabled = $true
}
Set-AzDiagnosticSetting @diagSettings
Enable diagnostic logging by using the Azure CLI

Activity logging is automatically enabled for every Resource Manager resource. Diagnostic logging must be
enabled to start collecting the data available through those logs.
To enable diagnostic logging with Azure CLI, use the following steps:
1. Note your Log Analytics Workspace resource ID, where the log data is stored. This value is of the form:
name>/providers/microsoft.operationalinsights/workspaces/<workspace name>
You can use any workspace in your subscription. You can use the Azure portal to find this information.
The information is located in the resource Proper ties page.
2. Note the resource ID for the firewall. This value is of the form:
name>/providers/Microsoft.Network/azureFirewalls/<Firewall name>
You can use the portal to find this information.

3. Enable diagnostic logging for all logs and metrics by using the following Azure CLI command:
az monitor diagnostic-settings create -n 'toLogAnalytics'
--resource '/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Network/azureFirewalls/<Firewall name>'
--workspace '/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/microsoft.operationalinsights/workspaces/<workspace name>'
--logs '[{\"category\":\"AzureFirewallApplicationRule\",\"Enabled\":true},
{\"category\":\"AzureFirewallNetworkRule\",\"Enabled\":true},
{\"category\":\"AzureFirewallDnsProxy\",\"Enabled\":true}]'
--metrics '[{\"category\": \"AllMetrics\",\"enabled\": true}]'
View and analyze the activity log

You can view and analyze activity log data by using any of the following methods:
Azure tools : Retrieve information from the activity log through Azure PowerShell, the Azure CLI, the
Azure REST API, or the Azure portal. Step-by-step instructions for each method are detailed in the Activity
operations with Resource Manager article.
Power BI : If you don't already have a Power BI account, you can try it for free. By using the Azure Activity
Logs content pack for Power BI, you can analyze your data with preconfigured dashboards that you can
use as is or customize.
Microsoft Sentinel : You can connect Azure Firewall logs to Microsoft Sentinel, enabling you to view log
data in workbooks, use it to create custom alerts, and incorporate it to improve your investigation. The
Azure Firewall data connector in Microsoft Sentinel is currently in public preview. For more information,
see Connect data from Azure Firewall.
See the following video by Mohit Kumar for an overview:
View and analyze the network and application rule logs

visual reports within the Azure portal. You can tap into multiple Firewalls deployed across Azure, and combine
them into unified interactive experiences.
You can also connect to your storage account and retrieve the JSON log entries for access and performance logs.
After you download the JSON files, you can convert them to CSV and view them in Excel, Power BI, or any other
data-visualization tool.
TIP
If you are familiar with Visual Studio and basic concepts of changing values for constants and variables in C#, you can use
the log converter tools available from GitHub.
View metrics
Browse to an Azure Firewall. Under Monitoring , select Metrics . To view the available values, select the METRIC
drop-down list.
Next steps
Now that you've configured your firewall to collect logs, you can explore Azure Monitor logs to view your data.
Monitor logs using Azure Firewall Workbook
Networking monitoring solutions in Azure Monitor logs
Monitor logs using Azure Firewall Workbook
visual reports within the Azure portal. You can tap into multiple Firewalls deployed across Azure, and combine
them into unified interactive experiences.
You can gain insights into Azure Firewall events, learn about your application and network rules, and see
statistics for firewall activities across URLs, ports, and addresses. Azure Firewall Workbook allows you to filter
your firewalls and resource groups, and dynamically filter per category with easy to read data sets when
investigating an issue in your logs.
Prerequisites
Before starting, you should enable diagnostic logging through the Azure portal. Also, read Azure Firewall logs
and metrics for an overview of the diagnostics logs and metrics available for Azure Firewall.
Get started
To deploy the workbook, go to Azure Monitor Workbook for Azure Firewall and following the instructions on the
page. Azure Firewall Workbook is designed to work across multi-tenants, multi-subscriptions, and is filterable to
multiple firewalls.
Overview page
The overview page provides you with a way to filter across workspaces, time, and firewalls. It shows events by
time across firewalls and log types (application, networks, threat intel, DNS proxy).
Application rule log statistics

This page shows unique sources of IP address over time, application rule count usage, denied/allowed FQDN
over time, and filtered data. You can filter data based on IP address.
The Web Categories view summarizes all allow and deny access log actions based on severity as configured by
the firewall administrator.
Network rule log statistics

This page provides a view by rule action – allow/deny, target port by IP and DNAT over time. You can also filter
by action, port, and destination type.
You can also filter logs based on time window:

IDPS log statistics
This page provides an overview of the IDPS actions count for all traffic that match the IDPS rules: Protocol,
Signature ID, Source IP.
Investigations
You can look at the logs and understand more about the resource based on the source IP address. You can get
information like virtual machine name and network interface name. It's simple to filter to the resource from the
logs.
Next steps
Learn more about Azure Firewall Diagnostics
Azure Firewall Premium is a next generation firewall with capabilities that are required for highly sensitive and
regulated environments. It includes the following features:
TLS Inspection - decrypts outbound traffic, processes the data, then encrypts the data and sends it to the
destination.
For more information, see Azure Firewall Premium features.
You'll use a template to deploy a test environment that has a central VNet (10.0.0.0/16) with three subnets:
a worker subnet (10.0.10.0/24)
an Azure Bastion subnet (10.0.20.0/24)
a firewall subnet (10.0.100.0/24)
A single central VNet is used in this test environment for simplicity. For production purposes, a hub and spoke
topology with peered VNets is more common.
The worker virtual machine is a client that sends HTTP/S requests through the firewall.
Prerequisites
Deploy the infrastructure
The template deploys a complete testing environment for Azure Firewall Premium enabled with IDPS, TLS
Inspection, URL Filtering, and Web Categories:
a new Azure Firewall Premium and Firewall Policy with predefined settings to allow easy validation of its core
capabilities (IDPS, TLS Inspection, URL Filtering, and Web Categories)
deploys all dependencies including Key Vault and a Managed Identity. In a production environment, these
resources may already be created and not needed in the same template.
generates self-signed Root CA and deploys it on the generated Key Vault
generates a derived Intermediate CA and deploys it on a Windows test virtual machine (WorkerVM)
a Bastion Host (BastionHost) is also deployed and can be used to connect to the Windows testing machine
(WorkerVM)
Test the firewall

Now you can test IDPS, TLS Inspection, Web filtering, and Web categories.
Add firewall diagnostics settings
To collect firewall logs, you need to add diagnostics settings to collect firewall logs.
1. Select the DemoFirewall and under Monitoring , select Diagnostic settings .
2. Select Add diagnostic setting .
3. For Diagnostic setting name , type fw-diag.
4. Under log , select AzureFirewallApplicationRule , and AzureFirewallNetworkRule .
5. Under Destination details , select Send to Log Analytics workspace .
6. Select Save .
IDPS tests
To test IDPS, you should deploy your own internal test Web server with an appropriate server certificate. This
test includes sending malicious traffic to a Web server, so it isn't advisable to do this to a public Web server. For
more information about Azure Firewall Premium certificate requirements, see Azure Firewall Premium
certificates.
You can use curl to control various HTTP headers and simulate malicious traffic.
To test IDPS for HTTP traffic:
1. On the WorkerVM virtual machine, open an administrator command prompt window.
2. Type the following command at the command prompt:
curl -A "HaxerMen" <your web server address>
3. You'll see your Web server response.

4. Go to the Firewall Network rule logs on the Azure portal to find an alert similar to the following message:
{ “msg” : “TCP request from 10.0.100.5:16036 to 10.0.20.10:80. Action: Alert. Rule: 2032081. IDS:
USER_AGENTS Suspicious User Agent (HaxerMen). Priority: 1. Classification: A Network Tojan was
detected”}
NOTE
It can take some time for the data to begin showing in the logs. Give it at least a couple minutes to allow for the
logs to begin showing the data.
5. Add a signature rule for signature 2032081:

a. Select the DemoFirewallPolicy and under Settings select IDPS .
b. Select the Signature rules tab.
c. Under Signature ID , in the open text box type 2032081.
d. Under Mode , select Deny .
e. Select Save .
f. Wait for the deployment to complete before proceeding.
6. On WorkerVM, run the curl command again:
curl -A "HaxerMen" <your web server address>
Since the HTTP request is now blocked by the firewall, you'll see the following output after the connection
timeout expires:
read tcp 10.0.100.5:55734->10.0.20.10:80: read: connection reset by peer
7. Go to the Monitor logs in the Azure portal and find the message for the blocked request.
To test IDPS for HTTPS traffic
Repeat these curl tests using HTTPS instead of HTTP. For example:
curl --ssl-no-revoke -A "HaxerMen" <your web server address>
You should see the same results that you had with the HTTP tests.
TLS Inspection with URL filtering
Use the following steps to test TLS Inspection with URL filtering.
1. Edit the firewall policy application rules and add a new rule called AllowURL to the AllowWeb rule
collection. Configure the target URL www.nytimes.com/section/world , Source IP address * , Destination type
URL , select TLS Inspection , and protocols http, https .
2. When the deployment completes, open a browser on WorkerVM and go to
https://www.nytimes.com/section/world and validate that the HTML response is displayed as expected in
the browser.
3. In the Azure portal, you can view the entire URL in the Application rule Monitoring logs:
Some HTML pages may look incomplete because they refer to other URLs that are denied. To solve this issue,
the following approach can be taken:
If the HTML page contain links to other domains, you can add these domains to a new application rule
with allow access to these FQDNs.
If the HTML page contain links to sub URLs then you can modify the rule and add an asterisk to the URL.
For example: targetURLs=www.nytimes.com/section/world*
Alternatively, you can add a new URL to the rule. For example:
www.nytimes.com/section/world, www.nytimes.com/section/world/*
Web categories testing

Let's create an application rule to allow access to sports web sites.
1. From the portal, open your resource group and select DemoFirewallPolicy .
2. Select Application Rules , and then Add a rule collection .
3. For Name , type GeneralWeb, Priority 103, Rule collection group select
DefaultApplicationRuleCollectionGroup .
4. Under Rules for Name type AllowSports, Source *, Protocol http, https, select TLS Inspection ,
Destination Type select Web categories, Destination select Sports.
5. Select Add .
6. When the deployment completes, go to WorkerVM and open a web browser and browse to
https://www.nfl.com .
You should see the NFL web page, and the Application rule log shows that a Web Categor y: Spor ts
rule was matched and the request was allowed.
Next steps
Deploy and configure Enterprise CA certificates for
Azure Firewall
Azure Firewall Premium includes a TLS inspection feature, which requires a certificate authentication chain. For
production deployments, you should use an Enterprise PKI to generate the certificates that you use with Azure
Firewall Premium. Use this article to create and manage an Intermediate CA certificate for Azure Firewall
Premium.
For more information about certificates used by Azure Firewall Premium, see Azure Firewall Premium
certificates.
Prerequisites
To use an Enterprise CA to generate a certificate to use with Azure Firewall Premium, you must have the
following resources:
an Active Directory Forest
an Active Directory Certification Services Root CA with Web Enrollment enabled
an Azure Firewall Premium with Premium tier Firewall Policy
an Azure Key Vault
a Managed Identity with Read permissions to Cer tificates and Secrets defined in the Key Vault Access
Policy
Request and export a certificate

1. Access the web enrollment site on the Root CA, usually https://<servername>/certsrv and select Request a
Cer tificate .
2. Select Advanced Cer tificate Request .
3. Select Create and Submit a Request to this CA .
4. Fill out the form using the Subordinate Certification Authority template.
5. Submit the request and install the certificate.
6. Assuming this request is made from a Windows Server using Internet Explorer, open Internet Options .
7. Navigate to the Content tab and select Cer tificates .
8. Select the certificate that was just issued and then select Expor t .
9. Select Next to begin the wizard. Select Yes, expor t the private key , and then select Next .
10. .pfx file format is selected by default. Uncheck Include all cer tificates in the cer tification path if
possible . If you export the entire certificate chain, the import process to Azure Firewall will fail.
11. Assign and confirm a password to protect the key, and then select Next .
12. Choose a file name and export location and then select Next .
13. Select Finish and move the exported certificate to a secure location.
Add the certificate to a Firewall Policy

1. In the Azure portal, navigate to the Certificates page of your Key Vault, and select Generate/Impor t .
2. Select Impor t as the method of creation, name the certificate, select the exported .pfx file, enter the
password, and then select Create .

3. Navigate to the TLS Inspection page of your Firewall policy and select your Managed identity, Key Vault,
and certificate.
4. Select Save .
Validate TLS inspection

1. Create an Application Rule using TLS inspection to the destination URL or FQDN of your choice. For example:
*bing.com .
2. From a domain-joined machine within the Source range of the rule, navigate to your Destination and select
the lock symbol next to the address bar in your browser. The certificate should show that it was issued by
your Enterprise CA rather than a public CA.
3. Show the certificate to display more details, including the certificate path.
4. In Log Analytics, run the following KQL query to return all requests that have been subject to TLS Inspection:
AzureDiagnostics
| where ResourceType == "AZUREFIREWALLS"
| where Category == "AzureFirewallApplicationRule"
| where msg_s contains "Url:"
| sort by TimeGenerated desc
The result shows the full URL of inspected traffic:
Next steps
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.
This article guides you with the required steps to manually migrate your Standard firewall and policy to
Premium.
Before you start the migration, understand the performance considerations and plan ahead for the required
maintenance window. Typical down time of 20-30 minutes is expected.
The following general steps are required for a successful migration:
1. Create new Premium policy based on your existing Standard policy or classic rules. By the end of this step
your new premium policy will include all your existing rules and policy settings.
Migrate Classic rules to Standard policy
Migrate an existing policy using Azure PowerShell
2. Migrate Azure Firewall from Standard to Premium using stop/start.
3. Attach the newly created Premium policy to your Premium Firewall.
IMPORTANT
Upgrading a Standard Firewall deployed in Southeast Asia with Availability Zones is not currently supported.
If you use Terraform to deploy the Azure Firewall, you can use Terraform to migrate to Azure Firewall Premium.
For more information, see Migrate Azure Firewall Standard to Premium using Terraform.
Performance considerations
Performance is a consideration when migrating from the standard SKU. IDPS and TLS inspection are compute
intensive operations. The premium SKU uses a more powerful VM SKU, which scales to a maximum throughput
of 30 Gbps comparable with the standard SKU. The 30-Gbps throughput is supported when configured with
IDPS in alert mode. Use of IDPS in deny mode and TLS inspection increases CPU consumption. Degradation in
max throughput might occur.
The firewall throughput might be lower than 30 Gbps when you’ve one or more signatures set to Aler t and
Deny or application rules with TLS inspection enabled. Microsoft recommends customers perform full-scale
testing in their Azure deployment to ensure the firewall service performance meets your expectations.
Downtime
Migrate your firewall during a planned maintenance time, as there will be some downtime when you Migrate
Azure Firewall from Standard to Premium using stop/start.
Migrate Classic rules to Standard policy

During your migration process, you may need to migrate your Classic firewall rules to a Standard policy. You can
do this using the Azure portal:
1. From the Azure portal, select your standard firewall. On the Over view page, select Migrate to firewall
policy .
2. On the Migrate to firewall policy page, select Review + create .

3. Select Create .
The deployment takes a few minutes to complete.
You can also migrate existing Classic rules from Azure Firewall using Azure PowerShell to create policies. For
more information, see Migrate Azure Firewall configurations to Azure Firewall policy using PowerShell
Migrate an existing policy using Azure PowerShell

Transform-Policy.ps1 is an Azure PowerShell script that creates a new Premium policy from an existing
Standard policy.
Given a standard firewall policy ID, the script transforms it to a Premium Azure firewall policy. The script first
connects to your Azure account, pulls the policy, transforms/adds various parameters, and then uploads a new
Premium policy. The new premium policy is named <previous_policy_name>_premium . If it's a child policy
transformation, a link to the parent policy will remain.
Usage example:
Transform-Policy -PolicyId /subscriptions/XXXXX-XXXXXX-XXXXX/resourceGroups/some-resource-
group/providers/Microsoft.Network/firewallPolicies/policy-name
IMPORTANT
The script doesn't migrate Threat Intelligence and SNAT private ranges settings. You'll need to note those settings before
proceeding and migrate them manually. Otherwise, you might encounter inconsistent traffic filtering with your new
upgraded firewall.
This script requires the latest Azure PowerShell. Run Get-Module -ListAvailable Az to see which versions are
installed. If you need to install, see Install Azure PowerShell module.
<#
.SYNOPSIS
Given an Azure firewall policy id the script will transform it to a Premium Azure firewall policy.
The script will first pull the policy, transform/add various parameters and then upload a new
premium policy.
The created policy will be named <previous_policy_name>_premium if no new name provided else new
policy will be named as the parameter passed.
.Example
Transform-Policy -PolicyId /subscriptions/XXXXX-XXXXXX-XXXXX/resourceGroups/some-resource-
group/providers/Microsoft.Network/firewallPolicies/policy-name -NewPolicyName <optional param for the new
policy name>
#>
param (
#Resource id of the azure firewall policy.
#Resource id of the azure firewall policy.
[Parameter(Mandatory=$true)]
[string]
$PolicyId,
#new filewallpolicy name, if not specified will be the previous name with the '_premium' suffix
[Parameter(Mandatory=$false)]
[string]
$NewPolicyName = ""
)
$ErrorActionPreference = "Stop"
$script:PolicyId = $PolicyId
$script:PolicyName = $NewPolicyName
function ValidatePolicy {
[CmdletBinding()]
param (
[Object]
$Policy
)
Write-Host "Validating resource is as expected"
if ($null -eq $Policy) {

Write-Error "Recived null policy"
exit(1)
}
if ($Policy.GetType().Name -ne "PSAzureFirewallPolicy") {
Write-Host "Resource must be of type Microsoft.Network/firewallPolicies" -ForegroundColor Red
exit(1)
}
if ($Policy.Sku.Tier -eq "Premium") {

Write-Host "Policy is already premium"
exit(1)
}
}
function GetPolicyNewName {
[CmdletBinding()]
param (
[Microsoft.Azure.Commands.Network.Models.PSAzureFirewallPolicy]
$Policy
)
if (-not [string]::IsNullOrEmpty($script:PolicyName)) {
return $script:PolicyName
}
return $Policy.Name + "_premium"

}
function TransformPolicyToPremium {
[CmdletBinding()]
param (
[Microsoft.Azure.Commands.Network.Models.PSAzureFirewallPolicy]
$Policy
)
$NewPolicyParameters = @{
Name = (GetPolicyNewName -Policy $Policy)
ResourceGroupName = $Policy.ResourceGroupName
Location = $Policy.Location
ThreatIntelMode = $Policy.ThreatIntelMode
BasePolicy = $Policy.BasePolicy.Id
DnsSetting = $Policy.DnsSettings
Tag = $Policy.Tag
SkuTier = "Premium"
}
Write-Host "Creating new policy"

$premiumPolicy = New-AzFirewallPolicy @NewPolicyParameters
Write-Host "Populating rules in new policy"

foreach ($ruleCollectionGroup in $Policy.RuleCollectionGroups) {
$ruleResource = Get-AzResource -ResourceId $ruleCollectionGroup.Id
$ruleToTransfom = Get-AzFirewallPolicyRuleCollectionGroup -AzureFirewallPolicy $Policy -Name
$ruleResource.Name
$ruleCollectionGroup = @{
FirewallPolicyObject = $premiumPolicy
Priority = $ruleToTransfom.Properties.Priority
Name = $ruleToTransfom.Name
}
if ($ruleToTransfom.Properties.RuleCollection.Count) {
$ruleCollectionGroup["RuleCollection"] = $ruleToTransfom.Properties.RuleCollection
}
Set-AzFirewallPolicyRuleCollectionGroup @ruleCollectionGroup
}
}
function ValidateAzNetworkModuleExists {
Write-Host "Validating needed module exists"
$networkModule = Get-InstalledModule -Name "Az.Network" -MinimumVersion 4.5 -ErrorAction
SilentlyContinue
if ($null -eq $networkModule) {
Write-Host "Please install Az.Network module version 4.5.0 or higher, see instructions:
https://github.com/Azure/azure-powershell#installation"
exit(1)
}
$resourceModule = Get-InstalledModule -Name "Az.Resources" -MinimumVersion 4.2 -ErrorAction
SilentlyContinue
if ($null -eq $resourceModule) {
Write-Host "Please install Az.Resources module version 4.2.0 or higher, see instructions:
https://github.com/Azure/azure-powershell#installation"
exit(1)
}
Import-Module Az.Network -MinimumVersion 4.5.0
Import-Module Az.Resources -MinimumVersion 4.2.0
}
ValidateAzNetworkModuleExists
$policy = Get-AzFirewallPolicy -ResourceId $script:PolicyId
ValidatePolicy -Policy $policy
TransformPolicyToPremium -Policy $policy
Migrate Azure Firewall using stop/start

If you use Azure Firewall Standard SKU with firewall policy, you can use the Allocate/Deallocate method to
migrate your Firewall SKU to Premium. This migration approach is supported on both VNet Hub and Secure
Hub Firewalls. When you migrate a Secure Hub deployment, it will preserve the firewall public IP address.
The minimum Azure PowerShell version requirement is 6.5.0. For more information, see Az 6.5.0.
Migrate a VNET Hub Firewall
Deallocate the Standard Firewall
$azfw = Get-AzFirewall -Name "<firewall-name>" -ResourceGroupName "<resource-group-name>"
$azfw.Deallocate()
Allocate Firewall Premium (single public IP address)

$azfw.Sku.Tier="Premium"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "<resource-group-name>" -Name "<Virtual-Network-
Name>"
$publicip = Get-AzPublicIpAddress -Name "<Firewall-PublicIP-name>" -ResourceGroupName "<resource-
group-name>"
$azfw.Allocate($vnet,$publicip)
Allocate Firewall Premium (multiple public IP addresses)
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"

$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet,@($publicip1,$publicip2))
Allocate Firewall Premium in Forced Tunnel Mode

$vnet = Get-AzVirtualNetwork -ResourceGroupName "<resource-group-name>" -Name "<Virtual-Network-
Name>"
$publicip = Get-AzPublicIpAddress -Name "<Firewall-PublicIP-name>" -ResourceGroupName "<resource-
group-name>"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "<resource-group-name>"-Name "<Management-
PublicIP-name>"
$azfw.Allocate($vnet,$publicip,$mgmtPip)
Migrate a Secure Hub Firewall

Deallocate the Standard Firewall

$azfw.Deallocate()
Allocate Firewall Premium
$azfw = Get-AzFirewall -Name -Name "<firewall-name>" -ResourceGroupName "<resource-group-name>"

$hub = get-azvirtualhub -ResourceGroupName "<resource-group-name>" -name "<vWANhub-name>"
$azfw.Allocate($hub.id)
Attach a Premium policy to a Premium Firewall

You can attach a Premium policy to the new Premium Firewall using the Azure portal:
Next steps
Learn more about Azure Firewall Premium features
Scale SNAT ports with Azure Virtual Network NAT
Azure Firewall provides 2496 SNAT ports per public IP address configured per backend virtual machine scale set
instance (Minimum of 2 instances), and you can associate up to 250 public IP addresses. Depending on your
architecture and traffic patterns, you might need more than the 512,000 available SNAT ports with this
configuration. For example, when you use it to protect large Azure Virtual Desktop deployments that integrate
with Microsoft 365 Apps.
Another challenge with using a large number of public IP addresses is when there are downstream IP address
filtering requirements. Azure Firewall randomly selects the source public IP address to use for a connection, so
you need to allow all public IP addresses associated with it. Even if you use Public IP address prefixes and you
need to associate 250 public IP addresses to meet your outbound SNAT port requirements, you still need to
create and allow 16 public IP address prefixes.
A better option to scale outbound SNAT ports is to use an Azure Virtual Network NAT as a NAT gateway. It
provides 64,000 SNAT ports per public IP address and supports up to 16 public IP addresses, effectively
providing up to 1,024,000 outbound SNAT ports.
When a NAT gateway resource is associated with an Azure Firewall subnet, all outbound Internet traffic
automatically uses the public IP address of the NAT gateway. There’s no need to configure User Defined Routes.
Response traffic uses the Azure Firewall public IP address to maintain flow symmetry. If there are multiple IP
addresses associated with the NAT gateway, the IP address is randomly selected. It isn't possible to specify what
address to use.
There’s no double NAT with this architecture. Azure Firewall instances send the traffic to NAT gateway using
their private IP address rather than Azure Firewall public IP address.
NOTE
Using Azure Virtual Network NAT is currently incompatible with Azure Firewall if you have deployed your Azure Firewall
across multiple availability zones.
In addition, Azure Virtual Network NAT integration is not currently supported in secured virtual hub network
architectures. You must deploy using a hub virtual network architecture. For more information about Azure Firewall
architecture options, see What are the Azure Firewall Manager architecture options?.
Associate a NAT gateway with an Azure Firewall subnet - Azure

PowerShell
The following example creates and attaches a NAT gateway with an Azure Firewall subnet using Azure
PowerShell.
# Create public IP addresses
New-AzPublicIpAddress -Name public-ip-1 -ResourceGroupName nat-rg -Sku Standard -AllocationMethod Static -
Location 'South Central US'
New-AzPublicIpAddress -Name public-ip-2 -ResourceGroupName nat-rg -Sku Standard -AllocationMethod Static -
Location 'South Central US'
# Create NAT gateway

$PublicIPAddress1 = Get-AzPublicIpAddress -Name public-ip-1 -ResourceGroupName nat-rg
$PublicIPAddress2 = Get-AzPublicIpAddress -Name public-ip-2 -ResourceGroupName nat-rg
New-AzNatGateway -Name firewall-nat -ResourceGroupName nat-rg -PublicIpAddress
$PublicIPAddress1,$PublicIPAddress2 -Location 'South Central US' -Sku Standard
# Associate NAT gateway to subnet

$virtualNetwork = Get-AzVirtualNetwork -Name nat-vnet -ResourceGroupName nat-rg
$natGateway = Get-AzNatGateway -Name firewall-nat -ResourceGroupName nat-rg
$firewallSubnet = $virtualNetwork.subnets | Where-Object -Property Name -eq AzureFirewallSubnet
$firewallSubnet.NatGateway = $natGateway
$virtualNetwork | Set-AzVirtualNetwork
Associate a NAT gateway with an Azure Firewall subnet - Azure CLI

The following example creates and attaches a NAT gateway with an Azure Firewall subnet using Azure CLI.
# Create public IP addresses

az network public-ip create --name public-ip-1 --resource-group nat-rg --sku standard
az network public-ip create --name public-ip-2 --resource-group nat-rg --sku standard
# Create NAT gateway

az network nat gateway create --name firewall-nat --resource-group nat-rg --public-ip-addresses public-ip-1
public-ip-2
# Associate NAT gateway to subnet

az network vnet subnet update --name AzureFirewallSubnet --vnet-name nat-vnet --resource-group nat-rg --nat-
gateway firewall-nat
Next steps
Design virtual networks with NAT gateway
Add or modify multiple Azure Firewall rules using
Azure PowerShell
When you add new rules to Azure Firewall or Azure Firewall policy, you should use the following steps to reduce
the total update time:
1. Retrieve the Azure Firewall or Azure Firewall Policy object.
2. Add all new rules and perform other desired modifications in the local object. You can add them to an
existing rule collection or create new ones as needed.
3. Push the Firewall or the Firewall Policy updates only when all modifications are done.
The following example shows how to add multiple new DNAT rules to an existing firewall policy using Azure
PowerShell. You should follow these same principles also when:
You update Application or Network rules.
You update a firewall managed with classic rules.
Carefully review the following steps. You should first try it on a test policy to ensure it works as expected for
your needs.
Connect to your Azure account and set the context to your

subscription
Connect-AzAccount
Set-AzContext -Subscription "<Subscritpion ID>"
Create local objects of the firewall policy, rule collection group, and
rule collection
$policy = Get-AzFirewallPolicy -Name "<Policy Name>" -ResourceGroupName "<Resource Group Name>"
$natrulecollectiongroup = Get-AzFirewallPolicyRuleCollectionGroup -Name "<Rule Collection Group Name>" -
ResourceGroupName "<Resource Group Name>" -AzureFirewallPolicyName "<Firewall Policy Name>"
$existingrulecollection = $natrulecollectiongroup.Properties.RuleCollection | where {$_.Name -eq "<rule
collection name"}
Define new rules to add

$newrule1 = New-AzFirewallPolicyNatRule -Name "dnat-rule1" -Protocol "TCP" -SourceAddress "<Source Address>"
-DestinationAddress "<Destination>" -DestinationPort "<Destination Port>" -TranslatedAddress "<Translated
Address>" -TranslatedPort "<Translated Port>"
$newrule2 = New-AzFirewallPolicyNatRule -Name "dnat-rule1" -Protocol "TCP" -SourceAddress "<Source Address>"
-DestinationAddress "<Destination>" -DestinationPort "<Destination Port>" -TranslatedAddress "<Translated
Address>" -TranslatedPort "<Translated Port>"
Add the new rules to the local rule collection object

$existingrulecollection.Rules.Add($newrule1)
$existingrulecollection.Rules.Add($newrule2)
Use this step to add any more rules, or perform any modifications to existing rules in the same rule collection
group.
Update the rule collection on Azure

Set-AzFirewallPolicyRuleCollectionGroup -Name " <Rule Collection Group Name> " -FirewallPolicyObject $policy
-Priority 200 -RuleCollection $natrulecollectiongroup.Properties.rulecollection
Next steps
Azure Firewall Policy rule sets
What is Azure Resource Manager?
Azure Resource Manager is the deployment and management service for Azure. It provides a management layer
that enables you to create, update, and delete resources in your Azure account. You use management features,
like access control, locks, and tags, to secure and organize your resources after deployment.
To learn about Azure Resource Manager templates (ARM templates), see the ARM template overview. To learn
about Bicep, see Bicep overview.
Consistent management layer

When you send a request through any of the Azure APIs, tools, or SDKs, Resource Manager receives the request.
It authenticates and authorizes the request before forwarding it to the appropriate Azure service. Because all
requests are handled through the same API, you see consistent results and capabilities in all the different tools.
The following image shows the role Azure Resource Manager plays in handling Azure requests.
All capabilities that are available in the portal are also available through PowerShell, Azure CLI, REST APIs, and
client SDKs. Functionality initially released through APIs will be represented in the portal within 180 days of
initial release.
Terminology
If you're new to Azure Resource Manager, there are some terms you might not be familiar with.
resource - A manageable item that is available through Azure. Virtual machines, storage accounts, web
apps, databases, and virtual networks are examples of resources. Resource groups, subscriptions,
management groups, and tags are also examples of resources.
resource group - A container that holds related resources for an Azure solution. The resource group
includes those resources that you want to manage as a group. You decide which resources belong in a
resource group based on what makes the most sense for your organization. See Resource groups.
resource provider - A service that supplies Azure resources. For example, a common resource provider is
Microsoft.Compute , which supplies the virtual machine resource. Microsoft.Storage is another common
resource provider. See Resource providers and types.
declarative syntax - Syntax that lets you state "Here's what I intend to create" without having to write the
sequence of programming commands to create it. ARM templates and Bicep files are examples of declarative
syntax. In those files, you define the properties for the infrastructure to deploy to Azure.
ARM template - A JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a
resource group, subscription, management group, or tenant. The template can be used to deploy the
resources consistently and repeatedly. See Template deployment overview.
Bicep file - A file for declaratively deploying Azure resources. Bicep is a language that's been designed to
provide the best authoring experience for infrastructure as code solutions in Azure. See Bicep overview.
For more definitions of Azure terminology, see Azure fundamental concepts.
The benefits of using Resource Manager

With Resource Manager, you can:
Manage your infrastructure through declarative templates rather than scripts.
Deploy, manage, and monitor all the resources for your solution as a group, rather than handling these
resources individually.
Redeploy your solution throughout the development lifecycle and have confidence your resources are
deployed in a consistent state.
Define the dependencies between resources so they're deployed in the correct order.
Apply access control to all services because Azure role-based access control (Azure RBAC) is natively
integrated into the management platform.
Apply tags to resources to logically organize all the resources in your subscription.
Clarify your organization's billing by viewing costs for a group of resources sharing the same tag.
Understand scope
Azure provides four levels of scope: management groups, subscriptions, resource groups, and resources. The
following image shows an example of these layers.
You apply management settings at any of these levels of scope. The level you select determines how widely the
setting is applied. Lower levels inherit settings from higher levels. For example, when you apply a policy to the
subscription, the policy is applied to all resource groups and resources in your subscription. When you apply a
policy on the resource group, that policy is applied to the resource group and all its resources. However, another
resource group doesn't have that policy assignment.
For information about managing identities and access, see Azure Active Directory.
You can deploy templates to tenants, management groups, subscriptions, or resource groups.
Resource groups
There are some important factors to consider when defining your resource group:
All the resources in your resource group should share the same lifecycle. You deploy, update, and delete
them together. If one resource, such as a server, needs to exist on a different deployment cycle it should
be in another resource group.
Each resource can exist in only one resource group.
You can add or remove a resource to a resource group at any time.
You can move a resource from one resource group to another group. For more information, see Move
resources to new resource group or subscription.
The resources in a resource group can be located in different regions than the resource group.
When you create a resource group, you need to provide a location for that resource group.
You may be wondering, "Why does a resource group need a location? And, if the resources can have
different locations than the resource group, why does the resource group location matter at all?"
The resource group stores metadata about the resources. When you specify a location for the resource
group, you're specifying where that metadata is stored. For compliance reasons, you may need to ensure
that your data is stored in a particular region.
If a resource group's region is temporarily unavailable, you can't update resources in the resource group
because the metadata is unavailable. The resources in other regions will still function as expected, but you
can't update them. This condition doesn't apply to global resources like Azure Content Delivery Network,
Azure DNS, Azure Traffic Manager, and Azure Front Door.
For more information about building reliable applications, see Designing reliable Azure applications.
A resource group can be used to scope access control for administrative actions. To manage a resource
group, you can assign Azure Policies, Azure roles, or resource locks.
You can apply tags to a resource group. The resources in the resource group don't inherit those tags.
A resource can connect to resources in other resource groups. This scenario is common when the two
resources are related but don't share the same lifecycle. For example, you can have a web app that
connects to a database in a different resource group.
When you delete a resource group, all resources in the resource group are also deleted. For information
about how Azure Resource Manager orchestrates those deletions, see Azure Resource Manager resource
group and resource deletion.
You can deploy up to 800 instances of a resource type in each resource group. Some resource types are
exempt from the 800 instance limit. For more information, see resource group limits.
Some resources can exist outside of a resource group. These resources are deployed to the subscription,
management group, or tenant. Only specific resource types are supported at these scopes.
To create a resource group, you can use the portal, PowerShell, Azure CLI, or an ARM template.
Resiliency of Azure Resource Manager

The Azure Resource Manager service is designed for resiliency and continuous availability. Resource Manager
and control plane operations (requests sent to management.azure.com ) in the REST API are:
Distributed across regions. Some services are regional.
Distributed across Availability Zones (and regions) in locations that have multiple Availability Zones.
Not dependent on a single logical data center.
Never taken down for maintenance activities.
This resiliency applies to services that receive requests through Resource Manager. For example, Key Vault
benefits from this resiliency.
Next steps
To learn about limits that are applied across Azure services, see Azure subscription and service limits,
quotas, and constraints.
To learn about moving resources, see Move resources to new resource group or subscription.
To learn about tagging resources, see Use tags to organize your Azure resources.
To learn about locking resources, see Lock resources to prevent unexpected changes.
Understand the structure and syntax of ARM
templates
This article describes the structure of an Azure Resource Manager template (ARM template). It presents the
different sections of a template and the properties that are available in those sections.
This article is intended for users who have some familiarity with ARM templates. It provides detailed
information about the structure of the template. For a step-by-step tutorial that guides you through the process
of creating a template, see Tutorial: Create and deploy your first ARM template. To learn about ARM templates
through a guided set of modules on Microsoft Learn, see Deploy and manage resources in Azure by using ARM
templates.
TIP
Bicep is a new language that offers the same capabilities as ARM templates but with a syntax that's easier to use. If you're
considering infrastructure as code options, we recommend looking at Bicep.
To learn about the elements of a Bicep file, see Understand the structure and syntax of Bicep files.
Template format
In its simplest structure, a template has the following elements:
{
"contentVersion": "",
"apiProfile": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}
EL EM EN T N A M E REQ UIRED DESC RIP T IO N

$schema Yes Location of the JavaScript Object

Notation (JSON) schema file that
describes the version of the template
language. The version number you use
depends on the scope of the
deployment and your JSON editor.
If you're using Visual Studio Code with

the Azure Resource Manager tools
extension, use the latest version for
resource group deployments:
https://schema.management.azure.com/schemas/2019-
04-01/deploymentTemplate.json#
Other editors (including Visual Studio)

may not be able to process this
schema. For those editors, use:
01-01/deploymentTemplate.json#
For subscription deployments, use:

05-01/subscriptionDeploymentTemplate.json#
For management group deployments,

use:
08-01/managementGroupDeploymentTemplate.json#
For tenant deployments, use:

08-01/tenantDeploymentTemplate.json#
contentVersion Yes Version of the template (such as

1.0.0.0). You can provide any value for
this element. Use this value to
document significant changes in your
template. When deploying resources
using the template, this value can be
used to make sure that the right
template is being used.
apiProfile No An API version that serves as a

collection of API versions for resource
types. Use this value to avoid having
to specify API versions for each
resource in the template. When you
specify an API profile version and don't
specify an API version for the resource
type, Resource Manager uses the API
version for that resource type that is
defined in the profile.
The API profile property is especially

helpful when deploying a template to
different environments, such as Azure
Stack and global Azure. Use the API
profile version to make sure your
template automatically uses versions
that are supported in both
environments. For a list of the current
API profile versions and the resources
API versions defined in the profile, see
API Profile.
For more information, see Track

versions using API profiles.
parameters No Values that are provided when

deployment is executed to customize
resource deployment.
variables No Values that are used as JSON

fragments in the template to simplify
template language expressions.
functions No User-defined functions that are

available within the template.
resources Yes Resource types that are deployed or

updated in a resource group or
subscription.
outputs No Values that are returned after

deployment.
Each element has properties you can set. This article describes the sections of the template in greater detail.
Parameters
In the parameters section of the template, you specify which values you can input when deploying the
resources. You're limited to 256 parameters in a template. You can reduce the number of parameters by using
objects that contain multiple properties.
The available properties for a parameter are:
"parameters": {
"<parameter-name>" : {
"type" : "<type-of-parameter-value>",
"defaultValue": "<default-value-of-parameter>",
"allowedValues": [ "<array-of-allowed-values>" ],
"minValue": <minimum-value-for-int>,
"maxValue": <maximum-value-for-int>,
"minLength": <minimum-length-for-string-or-array>,
"maxLength": <maximum-length-for-string-or-array-parameters>,
"metadata": {
"description": "<description-of-the parameter>"
}
}
}
parameter-name Yes Name of the parameter. Must be a

valid JavaScript identifier.
type Yes Type of the parameter value. The

allowed types and values are string ,
securestring , int , bool, object ,
secureObject , and array . See Data
types in ARM templates.
defaultValue No Default value for the parameter, if no

value is provided for the parameter.
allowedValues No Array of allowed values for the

parameter to make sure that the right
value is provided.
minValue No The minimum value for int type

parameters, this value is inclusive.
maxValue No The maximum value for int type

parameters, this value is inclusive.
minLength No The minimum length for string, secure

string, and array type parameters, this
value is inclusive.
maxLength No The maximum length for string, secure

string, and array type parameters, this
value is inclusive.
description No Description of the parameter that is

displayed to users through the portal.
For more information, see Comments
in templates.
For examples of how to use parameters, see Parameters in ARM templates.

In Bicep, see parameters.
Variables
In the variables section, you construct values that can be used throughout your template. You don't need to
define variables, but they often simplify your template by reducing complex expressions. The format of each
variable matches one of the data types.
The following example shows the available options for defining a variable:
"variables": {
"<variable-name>": "<variable-value>",
"<variable-name>": {
<variable-complex-type-value>
},
"<variable-object-name>": {
"copy": [
{
"name": "<name-of-array-property>",
"count": <number-of-iterations>,
"input": <object-or-value-to-repeat>
}
]
},
"copy": [
{
"name": "<variable-array-name>",
"input": <object-or-value-to-repeat>
}
]
}
For information about using copy to create several values for a variable, see Variable iteration.
For examples of how to use variables, see Variables in ARM template.
In Bicep, see variables.
Functions
Within your template, you can create your own functions. These functions are available for use in your template.
Typically, you define complicated expressions that you don't want to repeat throughout your template. You
create the user-defined functions from expressions and functions that are supported in templates.
When defining a user function, there are some restrictions:
The function can't access variables.
The function can only use parameters that are defined in the function. When you use the parameters function
within a user-defined function, you're restricted to the parameters for that function.
The function can't call other user-defined functions.
The function can't use the reference function.
Parameters for the function can't have default values.
"functions": [
{
"namespace": "<namespace-for-functions>",
"members": {
"<function-name>": {
"parameters": [
{
"name": "<parameter-name>",
"type": "<type-of-parameter-value>"
}
],
"output": {
"type": "<type-of-output-value>",
"value": "<function-return-value>"
}
}
}
}
],
namespace Yes Namespace for the custom functions.

Use to avoid naming conflicts with
template functions.
function-name Yes Name of the custom function. When

calling the function, combine the
function name with the namespace.
For example, to call a function named
uniqueName in the namespace
contoso, use
"[contoso.uniqueName()]" .
parameter-name No Name of the parameter to be used

within the custom function.
parameter-value No Type of the parameter value. The

allowed types and values are string ,
securestring , int , bool, object ,
secureObject , and array .
output-type Yes Type of the output value. Output

values support the same types as
function input parameters.
output-value Yes Template language expression that is

evaluated and returned from the
function.
For examples of how to use custom functions, see User-defined functions in ARM template.
In Bicep, user-defined functions aren't supported. Bicep does support a variety of functions and operators.
Resources
In the resources section, you define the resources that are deployed or updated.
You define resources with the following structure:
"resources": [
{
"condition": "<true-to-deploy-this-resource>",
"type": "<resource-provider-namespace/resource-type-name>",
"apiVersion": "<api-version-of-resource>",
"name": "<name-of-the-resource>",
"comments": "<your-reference-notes>",
"location": "<location-of-resource>",
"dependsOn": [
"<array-of-related-resource-names>"
],
"tags": {
"<tag-name1>": "<tag-value1>",
"<tag-name2>": "<tag-value2>"
},
"identity": {
"type": "<system-assigned-or-user-assigned-identity>",
"userAssignedIdentities": {
"<resource-id-of-identity>": {}
}
},
"sku": {
"name": "<sku-name>",
"tier": "<sku-tier>",
"size": "<sku-size>",
"family": "<sku-family>",
"capacity": <sku-capacity>
},
"kind": "<type-of-resource>",
"scope": "<target-scope-for-extension-resources>",
"copy": {
"name": "<name-of-copy-loop>",
"mode": "<serial-or-parallel>",
"batchSize": <number-to-deploy-serially>
},
"plan": {
"name": "<plan-name>",
"promotionCode": "<plan-promotion-code>",
"publisher": "<plan-publisher>",
"product": "<plan-product>",
"version": "<plan-version>"
},
"properties": {
"<settings-for-the-resource>",
"copy": [
{
"name": ,
"count": ,
"input": {}
}
]
},
"resources": [
"<array-of-child-resources>"
]
}
]
condition No Boolean value that indicates whether

the resource will be provisioned during
this deployment. When true , the
resource is created during deployment.
When false , the resource is skipped
for this deployment. See condition.
type Yes Type of the resource. This value is a

combination of the namespace of the
resource provider and the resource
type (such as
). To determine available values, see
template reference. For a child
resource, the format of the type
depends on whether it's nested within
the parent resource or defined outside
of the parent resource. See Set name
and type for child resources.
apiVersion Yes Version of the REST API to use for

creating the resource. When creating a
new template, set this value to the
latest version of the resource you're
deploying. As long as the template
works as needed, keep using the same
API version. By continuing to use the
same API version, you minimize the
risk of a new API version changing
how your template works. Consider
updating the API version only when
you want to use a new feature that is
introduced in a later version. To
determine available values, see
template reference.
name Yes Name of the resource. The name must

follow URI component restrictions
defined in RFC3986. Azure services
that expose the resource name to
outside parties validate the name to
make sure it isn't an attempt to spoof
another identity. For a child resource,
the format of the name depends on
whether it's nested within the parent
resource or defined outside of the
parent resource. See Set name and
type for child resources.
comments No Your notes for documenting the

resources in your template. For more
information, see Comments in
templates.
location Varies Supported geo-locations of the

provided resource. You can select any
of the available locations, but typically
it makes sense to pick one that is close
to your users. Usually, it also makes
sense to place resources that interact
with each other in the same region.
Most resource types require a location,
but some types (such as a role
assignment) don't require a location.
See Set resource location.
dependsOn No Resources that must be deployed

before this resource is deployed.
Resource Manager evaluates the
dependencies between resources and
deploys them in the correct order.
When resources aren't dependent on
each other, they're deployed in parallel.
The value can be a comma-separated
list of a resource names or resource
unique identifiers. Only list resources
that are deployed in this template.
Resources that aren't defined in this
template must already exist. Avoid
adding unnecessary dependencies as
they can slow your deployment and
create circular dependencies. For
guidance on setting dependencies, see
Define the order for deploying
resources in ARM templates.
tags No Tags that are associated with the

resource. Apply tags to logically
organize resources across your
subscription.
identity No Some resources support managed

identities for Azure resources. Those
resources have an identity object at
the root level of the resource
declaration. You can set whether the
identity is user-assigned or system-
assigned. For user-assigned identities,
provide a list of resource IDs for the
identities. Set the key to the resource
ID and the value to an empty object.
For more information, see Configure
managed identities for Azure resources
on an Azure VM using templates.
sku No Some resources allow values that

define the SKU to deploy. For example,
you can specify the type of
redundancy for a storage account.
kind No Some resources allow a value that

defines the type of resource you
deploy. For example, you can specify
the type of Cosmos DB to create.
scope No The scope property is only available for

extension resource types. Use it when
specifying a scope that is different than
the deployment scope. See Setting
scope for extension resources in ARM
templates.
copy No If more than one instance is needed,

the number of resources to create. The
default mode is parallel. Specify serial
mode when you don't want all or the
resources to deploy at the same time.
For more information, see Create
several instances of resources in Azure
Resource Manager.
plan No Some resources allow values that

define the plan to deploy. For example,
you can specify the marketplace image
for a virtual machine.
properties No Resource-specific configuration

settings. The values for the properties
are the same as the values you provide
in the request body for the REST API
operation (PUT method) to create the
resource. You can also specify a copy
array to create several instances of a
property. To determine available
values, see template reference.
resources No Child resources that depend on the

resource being defined. Only provide
resource types that are permitted by
the schema of the parent resource.
Dependency on the parent resource
isn't implied. You must explicitly define
that dependency. See Set name and
type for child resources.
In Bicep, see resources.
Outputs
In the outputs section, you specify values that are returned from deployment. Typically, you return values from
resources that were deployed.
The following example shows the structure of an output definition:
"outputs": {
"<output-name>": {
"condition": "<boolean-value-whether-to-output-value>",
"type": "<type-of-output-value>",
"value": "<output-value-expression>",
"copy": {
"input": <values-for-the-variable>
}
}
}
output-name Yes Name of the output value. Must be a

valid JavaScript identifier.
condition No Boolean value that indicates whether

this output value is returned. When
true , the value is included in the
output for the deployment. When
false , the output value is skipped
for this deployment. When not
specified, the default value is true .
type Yes Type of the output value. Output

values support the same types as
template input parameters. If you
specify securestring for the output
type, the value isn't displayed in the
deployment history and can't be
retrieved from another template. To
use a secret value in more than one
template, store the secret in a Key
Vault and reference the secret in the
parameter file. For more information,
see Use Azure Key Vault to pass secure
parameter value during deployment.
value No Template language expression that is

evaluated and returned as output
value. Specify either value or copy .
copy No Used to return more than one value

for an output. Specify value or copy .
For more information, see Output
iteration in ARM templates.
For examples of how to use outputs, see Outputs in ARM template.

In Bicep, see outputs.
Comments and metadata

You have a few options for adding comments and metadata to your template.
Comments
For inline comments, you can use either // or /* ... */ . In Visual Studio Code, save the parameter files with
comments as the JSON with comments (JSONC) file type, otherwise you will get an error message saying
"Comments not permitted in JSON".
NOTE
When using Azure CLI to deploy templates with comments, use version 2.3.0 or later, and specify the
--handle-extended-json-format switch.
{
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[parameters('location')]", //defaults to resource group location
"dependsOn": [ /* storage account and network interface must be deployed first */
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
In Visual Studio Code, the Azure Resource Manager Tools extension can automatically detect an ARM template
and change the language mode. If you see Azure Resource Manager Template at the bottom-right corner of
Visual Studio Code, you can use the inline comments. The inline comments are no longer marked as invalid.
In Bicep, see comments.

Metadata
You can add a metadata object almost anywhere in your template. Resource Manager ignores the object, but
your JSON editor may warn you that the property isn't valid. In the object, define the properties you need.
{
"metadata": {
"comments": "This template was developed for demonstration purposes.",
"author": "Example Name"
},
For parameters , add a metadata object with a description property.
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "User name for the Virtual Machine."
}
},
When deploying the template through the portal, the text you provide in the description is automatically used as
a tip for that parameter.
For resources , add a comments element or a metadata object. The following example shows both a comments
element and a metadata object.
"resources": [
{
"apiVersion": "2018-07-01",
"name": "[concat('storage', uniqueString(resourceGroup().id))]",
"comments": "Storage account used to store VM disks",
"metadata": {
"comments": "These tags are needed for policy compliance."
},
"tags": {
"Dept": "[parameters('deptName')]",
"Environment": "[parameters('environment')]"
},
"sku": {
},
"kind": "Storage",
"properties": {}
}
]
For outputs , add a metadata object to the output value.
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]",
"metadata": {
"comments": "Return the fully qualified domain name"
}
},
You can't add a metadata object to user-defined functions.
Multi-line strings
You can break a string into multiple lines. For example, see the location property and one of the comments in
the following JSON example.
NOTE
To deploy templates with multi-line strings, use Azure PowerShell or Azure CLI. For CLI, use version 2.3.0 or later, and
specify the --handle-extended-json-format switch.
Multi-line strings aren't supported when you deploy the template through the Azure portal, a DevOps pipeline, or the
REST API.
{
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[
parameters('location')
]", //defaults to resource group location
/*
storage account and network interface
must be deployed first
*/
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
In Bicep, see multi-line strings.
Next steps
To view complete templates for many different types of solutions, see the Azure Quickstart Templates.
For details about the functions you can use from within a template, see ARM template functions.
To combine several templates during deployment, see Using linked and nested templates when deploying
Azure resources.
For recommendations about creating templates, see ARM template best practices.
For answers to common questions, see Frequently asked questions about ARM templates.

Azure Firewall

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Firewall

Uploaded by

Copyright:

Available Formats

Contents

Azure Firewall documentation

Azure Firewall Standard

Azure Firewall Premium

Azure Firewall Manager

Pricing and SLA

ISSUE DESC RIP T IO N M IT IGAT IO N

For Azure SQL IaaS:

If you're using non-standard ports,

For more information, see Scale SNAT

To avoid the failure, IP Groups

Azure Firewall Premium

ISSUE DESC RIP T IO N M IT IGAT IO N

Client Certification Authentication is Client certificates are used to build a None

Certificate Propagation After a CA certificate is applied on the A fix is being investigated.

Review the template

Multiple Azure resources are defined in the template:

Deploy the template

Review deployed resources

Remove-AzResourceGroup -Name "<your resource group name>"

Review the template

Multiple Azure resources are defined in the template:

Deploy the template

Validate the deployment

Remove-AzResourceGroup -Name "<your resource group name>"

Review the Bicep file

@description('virtual network name')

@description('Location for all resources.')

@description('Username for the Virtual Machine.')

@description('Password for the Virtual Machine.')

@description('Availability zone numbers e.g. 1,2,3.')

@description('Number of public IP addresses for the Azure Firewall')

@description('Size of the virtual machine.')

@description('Size of the virtual machine.')

var vnetAddressPrefix = '10.0.0.0/16'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = {

resource azfwRouteTable 'Microsoft.Network/routeTables@2021-03-01' = {

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-05-01' = {

resource publicIPAddress 'Microsoft.Network/publicIPAddresses@2021-03-01' = [for i in range(0,

resource jumpBoxPublicIPAddress 'Microsoft.Network/publicIPAddresses@2021-03-01' = {

resource JumpBoxNic 'Microsoft.Network/networkInterfaces@2021-05-01' = {

resource ServerNic 'Microsoft.Network/networkInterfaces@2021-05-01' = {

resource JumpBoxVM 'Microsoft.Compute/virtualMachines@2021-11-01' = {

resource ServerVM 'Microsoft.Compute/virtualMachines@2021-11-01' = {

resource firewall 'Microsoft.Network/azureFirewalls@2021-05-01' = {

Multiple Azure resources are defined in the Bicep file:

Deploy the Bicep file

az group create --name exampleRG --location eastus

Review deployed resources

az resource list --resource-group exampleRG

az group delete --name exampleRG

Review the template

Multiple Azure resources are defined in the template:

Deploy the template

Review deployed resources

Remove-AzResourceGroup -Name MyResourceGroup

In this tutorial, you learn how to:

Set up the network

Resource group Test-FW-RG

Virtual machine name Sr v-Work

Region Same as previous

Image Windows Server 2016 Datacenter

Administrator user name Type a user name