Azure Firewall

Contents
Azure Firewall documentation

Overview
What is Azure Firewall?
Quickstarts
Deploy with IP Groups - ARM template
Deploy with multiple addresses - ARM template
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 features
FQDN tags
Infrastructure FQDNs
Logs and metrics
Threat intelligence
Rule processing logic
Service tags
IP Groups
Forced tunneling
Certifications
Central management
Remote work support
FQDN in network rules
Security baseline
How-to guides
Deploy 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 Windows Virtual Desktop
Protect Azure Kubernetes Service (AKS)
DNS settings
Monitor diagnostic logs
Azure Monitor logs
Azure Firewall Workbook
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
10/25/2020 • 7 minutes to read • Edit Online
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.
You can centrally create, enforce, and log application and network connectivity policies across subscriptions and
virtual networks. Azure Firewall uses a static public IP address for your virtual network resources allowing outside
firewalls to identify traffic originating from your virtual network. The service is fully integrated with Azure Monitor
for logging and analytics.
Features
To learn about Azure Firewall features, see Azure Firewall features.
Known issues
Azure Firewall has the following known issues:
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 for Azure PowerShell and CLI don't support It's still possible to use ICMP as a
ICMP ICMP as a valid protocol in network protocol via the portal and the REST
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: protocol
be set require port: protocol definition. value. We're working to make this field
optional when FQDN tags are used.
Moving a firewall to a different resource Moving a firewall to a different resource Supporting this functionality is on our
group or subscription isn't supported group or subscription isn't supported. road map. To move a firewall to a
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. For
are SNATed to one of the firewall private example, use a service such as Azure
IPs. This requirement today (also for Front Door or Azure Application
Active/Active NVAs) to ensure Gateway in front of the firewall. You can
symmetric routing. 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 Synapse For SQL in redirect mode (the default if
proxy mode (port 1433) Analytics, and Azure SQL Managed connecting from within Azure), you can
Instance: instead filter access using the SQL
service tag as part of Azure Firewall
During the preview, SQL FQDN filtering network rules.
is supported in 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 traffic on TCP port 25 isn't Outbound SMTP connections that use Follow the recommended method to
allowed TCP port 25 are blocked. Port 25 is send email, as documented in the SMTP
primarily used for unauthenticated troubleshooting article. Or, exclude the
email delivery. This is the default virtual machine that needs outbound
platform behavior for virtual machines. SMTP access from your default route to
For more information, see more the firewall. Instead, configure
Troubleshoot outbound SMTP outbound access directly to the
connectivity issues in Azure. However, internet.
unlike virtual machines, it isn't currently
possible to enable this functionality on
Azure Firewall. Note: to allow
authenticated SMTP (port 587) or
SMTP over a port other than 25, please
make sure you configure a network rule
and not an application rule as SMTP
inspection is not supported at this time.
Active FTP isn't supported Active FTP is disabled on Azure Firewall You can use Passive FTP instead. You
to protect against FTP bounce attacks must still explicitly open TCP ports 20
using the FTP PORT command. and 21 on the firewall.
SNAT port utilization metric shows 0% The Azure Firewall SNAT port utilization This issue has been fixed and rollout to
metric may show 0% usage even when production is targeted for May 2020. In
SNAT ports are used. In this case, using some cases, firewall redeployment
the metric as part of the firewall health resolves the issue, but it's not
metric provides an incorrect result. consistent. As an intermediate
workaround, only use the firewall health
state to look for status=degraded, not
for status=unhealthy. Port exhaustion
will show as degraded. Not healthy is
reserved for future use when the are
more metrics to impact the firewall
health.
DNAT isn't supported with Forced Firewalls deployed with Forced This is by design because of asymmetric
Tunneling enabled Tunneling enabled can't support routing. The return path for inbound
inbound access from the Internet connections goes via the on-premises
because of asymmetric routing. 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 different
outbound, it randomly selects one of its source IP addresses (see an example for
public IP addresses for the source IP IIS). Alternatively, consider using a single
address. FTP may fail when data and IP address in this situation.
control channels use different source 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 the server to accept data and control
firewall private IP address to ensure channels from different source IP
symmetric routing. FTP may fail when addresses.
data and control channels use different
source IP addresses, depending on your
FTP server configuration.
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 does not If browser or server software does not
filter HTTPS and MSSQL traffic support the Server Name Indicator support SNI, then you may be able to
(SNI) extension, you won't be able to control the connection using a network
connect through Azure Firewall. rule instead of an application rule. See
Server Name Indication for software
that supports SNI.
Custom DNS (preview) doesn't work If force tunneling is enabled, custom A fix is being investigated.
with forced tunneling DNS (preview) doesn't work.
New public IP address support for You can't add a new public IP address This is a public IP address resource
multiple Availability Zones when you deploy a firewall with two limitation.
availability zones (either 1 and 2, 2 and
3, or 1 and 3)
Start/Stop doesn’t work with a firewall Start/stop doesn’t work with Azure Under investigation.
configured in forced-tunnel mode firewall configured in forced-tunnel
mode. Attempting to start Azure As a workaround, you can delete the
Firewall with forced tunneling existing firewall and create a new one
configured results in the following error: with the same parameters.
Set-AzFirewall: AzureFirewall FW-xx

management IP configuration cannot
be added to an existing firewall.
Redeploy with a management IP
configuration if you want to use forced
tunneling support.
StatusCode: 400
ReasonPhrase: Bad Request
Next steps
Tutorial: Deploy and configure Azure Firewall using the Azure portal
Deploy Azure Firewall using a template
Create an Azure Firewall test environment
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, which lets you state what you intend to deploy without having to
write the sequence of programming commands to create it.
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": {
"type": "string",
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_DS1_v2",
"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": {
"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",
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
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,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts',
}
}
}
},
{
"type": "Microsoft.Network/azureFirewalls",
"apiVersion": "2020-06-01",
"name": "[variables('firewallName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/ipGroups', parameters('ipgroups_name1'))]",
"publicIpCopy"
],
"properties": {
"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.
your project. The template uses declarative syntax, which lets you state what you intend to deploy without having
to write the sequence of programming commands to create it.
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.
{
"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",
"metadata": {
}
},
"vmSize": {
"defaultValue": "Standard_B2ms",
"defaultValue": "Standard_B2ms",
"type": "String",
"metadata": {
"description": "Size of the virtual machine."
}
}
},
"variables": {
"virtualMachines_myVM_name": "myVM",
"virtualNetworks_myVNet_name": "myVNet",
"net_interface": "net-int",
"ipconfig_name": "ipconfig",
"ipprefix_name": "public_ip_prefix",
"ipprefix_size": 31,
"publicIPAddress": "public_ip",
"nsg_name": "vm-nsg",
"firewall_name": "FW-01",
"vnet_prefix": "10.0.0.0/16",
"fw_subnet_prefix": "10.0.0.0/24",
"backend_subnet_prefix": "10.0.1.0/24",
[resourceId('Microsoft.Network/virtualNetworks/subnets',variables('virtualNetworks_myVNet_name'),
'AzureFirewallSubnet')]",
"copy": [
{
"count": 2,
"input": {
"name": "[concat('IpConf', copyIndex('azureFirewallIpConfigurations',1))]",
"properties": {
"subnet": "[if(equals(copyIndex('azureFirewallIpConfigurations',1), 1),
"id": "[resourceId('Microsoft.Network/publicIPAddresses', concat(variables('publicIPAddress'),
copyIndex('azureFirewallIpConfigurations',1)))]"
}
}
}
}
]
},
"resources": [
{
"apiVersion": "2020-06-01",
"name": "[concat(variables('nsg_name'), copyIndex(1))]",
"copy": {
"name": "nsg-loop",
"count": 2
},
"properties": {
"securityRules": [
{
"name": "RDP",
"properties": {
"protocol": "TCP",
"access": "Allow",
"priority": 300,
}
}
]
}
},
},
{
"apiVersion": "2020-06-01",
"type": "Microsoft.Network/publicIPPrefixes",
"name": "[variables('ipprefix_name')]",
"properties": {
"prefixLength": "[variables('ipprefix_size')]",
},
"sku": {
"name": "Standard",
"tier": "Regional"
}
},
{
"apiVersion": "2020-06-01",
"name": "[concat(variables('publicIPAddress'), copyIndex(1))]",
"sku": {
"name": "Standard"
},
"copy": {
"name": "publicip-loop",
"count": 2
},
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPPrefixes', variables('ipprefix_name'))]"
],
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPPrefix": {
"id": "[resourceId('Microsoft.Network/publicIPPrefixes',variables('ipprefix_name'))]"
},
"idleTimeoutInMinutes": 4
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('virtualNetworks_myVNet_name')]",
"dependsOn": [
"[resourceId('Microsoft.Network/routeTables', 'rt-01')]"
],
"properties": {
"addressSpace": {
"[variables('vnet_prefix')]"
]
},
"subnets": [
{
"name": "myBackendSubnet",
"properties": {
"addressPrefix": "[variables('backend_subnet_prefix')]",
"routeTable": {
"id": "[resourceId('Microsoft.Network/routeTables', 'rt-01')]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
],
"enableDdosProtection": false,
"enableVmProtection": false
}
},
},
{
"type": "Microsoft.Network/virtualNetworks/subnets",
"apiVersion": "2020-06-01",
"name": "[concat(variables('virtualNetworks_myVNet_name'), '/AzureFirewallSubnet')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworks_myVNet_name'))]"
],
"properties": {
"addressPrefix": "[variables('fw_subnet_prefix')]",
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"apiVersion": "2020-06-01",
"name": "[concat(variables('virtualMachines_myVM_name'), copyIndex(1))]",
"copy": {
"name": "vm-loop",
"count": 2
},
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', concat(variables('net_interface'), 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": "[concat(variables('virtualMachines_myVM_name'), copyIndex(1))]",
"adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVMAgent": true,
"enableAutomaticUpdates": true
},
"allowExtensionOperations": true
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', concat(variables('net_interface'),
copyIndex(1)))]"
}
]
}
}
},
{
"apiVersion": "2020-06-01",
"name": "[concat(variables('net_interface'), copyIndex(1))]",
"copy": {
"name": "int-loop",
"count": 2
},
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworks_myVNet_name'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', concat(variables('nsg_name'), copyIndex(1)))]"
],
"properties": {
{
"name": "[concat(variables('ipconfig_name'), copyIndex(1))]",
"properties": {
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets',
variables('virtualNetworks_myVNet_name'), 'myBackendSubnet')]"
},
"primary": true
}
}
],
"enableAcceleratedNetworking": false,
"enableIPForwarding": false,
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat(variables('nsg_name'),
copyIndex(1)))]"
}
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('firewall_name')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', concat(variables('publicIPAddress'), 1))]",
"[resourceId('Microsoft.Network/publicIPAddresses', concat(variables('publicIPAddress'), 2))]",
"[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworks_myVNet_name'),
'AzureFirewallSubnet')]"
],
"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/',
concat(variables('publicIPAddress'), 1))).ipAddress]" ],
"3389"
]
},
{
"name": "rdp-02",
"protocols": [
"TCP"
],
"translatedAddress": "10.0.1.5",
"translatedPort": "3389",
"*"
],
"destinationAddresses": [ "[reference(resourceId('Microsoft.Network/publicIPAddresses/',
concat(variables('publicIPAddress'), 2))).ipAddress]" ],
"3389"
]
}
]
}
}
]
}
},
{
"apiVersion": "2020-06-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 - ARM template
In this quickstart, you use an Azure Resource Manager template (ARM template) to deploy an Azure Firewall in
three Availability Zones.
your project. The template uses declarative syntax, which lets you state what you intend to deploy without having
to write the sequence of programming commands to create it.
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.
{
"parameters": {
"virtualNetworkName": {
"type": "string",
"defaultValue": "test-vnet",
"metadata": {
"description": "virtual network name"
}
},
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"location": {
"type": "string",
"metadata": {
}
},
"availabilityZones": {
"type": "array",
"defaultValue": [
"1",
"2",
"3"
],
"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"
}
},
"jumpBoxSize": {
"type": "string",
"metadata": {
}
},
"serverSize": {
"type": "string",
"metadata": {
}
}
},
"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",
"publicIPNamePrefix": "publicIP",
[resourceId('Microsoft.Network/virtualNetworks/subnets',parameters('virtualNetworkName'),
variables('azureFirewallSubnetName'))]",
"copy": [
{
"count": "[parameters('numberOfFirewallPublicIPAddresses')]",
"input": {
"name": "[concat('IpConf', copyIndex('azureFirewallIpConfigurations'))]",
"properties": {
"subnet": "[if(equals(copyIndex('azureFirewallIpConfigurations'), 0),
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
concat(variables('publicIPNamePrefix'), add(copyIndex('azureFirewallIpConfigurations'), 1)))]"
}
}
}
}
],
"networkSecurityGroupName": "[concat(variables('serversSubnetName'), '-nsg')]"
},
"resources": [
{
"apiVersion": "2019-06-01",
"name": "[variables('storageAccountName')]",
"sku": {
},
"kind": "Storage",
"properties": {}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('azfwRouteTableName')]",
"properties": {
"routes": [
{
"name": "AzfwDefaultRoute",
"properties": {
"nextHopIpAddress": "[variables('nextHopIP')]"
}
}
]
}
},
{
"comments": "Simple Network Security Group for subnet [variables('serversSubnetName')]",
"apiVersion": "2020-06-01",
"name": "[variables('networkSecurityGroupName')]",
"properties": {}
},
{
"apiVersion": "2020-06-01",
"name": "[parameters('virtualNetworkName')]",
"dependsOn": [
"dependsOn": [
"[resourceId('Microsoft.Network/routeTables', variables('azfwRouteTableName'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"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'))]"
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "[concat(variables('publicIPNamePrefix'), add(copyIndex(), 1))]",
"sku": {
"name": "Standard"
},
"copy": {
"name": "publicIpCopy",
"count": "[parameters('numberOfFirewallPublicIPAddresses')]"
},
"properties": {
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('jumpBoxPublicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('jumpBoxNsgName')]",
"properties": {
"securityRules": [
{
"name": "myNetworkSecurityGroupRuleRDP",
"properties": {
"protocol": "Tcp",
"access": "Allow",
"priority": 1000,
}
}
]
}
},
{
"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": {
{
"properties": {
"id": "
[resourceId('Microsoft.Network/publicIPAddresses',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')]"
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "JumpBox",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('JumpBoxNicName'))]"
],
"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,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/',
}
}
}
},
{
"apiVersion": "2020-06-01",
"name": "Server",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', variables('ServerNicName'))]"
],
"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,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/',
}
}
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('firewallName')]",
"zones": "[if(equals(length(parameters('availabilityZones')), 0), json('null'),
parameters('availabilityZones'))]",
"dependsOn": [
"publicIpCopy"
],
"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"
],
"destinationAddresses": [
"*"
],
"8000-8999"
]
}
]
}
}
]
}
}
]
}

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.
Review deployed resources

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
Next, you can monitor the Azure Firewall logs.
Tutorial: Monitor Azure Firewall logs
Tutorial: Deploy and configure Azure Firewall 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. With Azure
Firewall, 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
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 tutorial 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 Resource group name , enter Test-FW-RG.
4. For Subscription , select your subscription.
5. For Resource group location , select a location. All other resources that you create must be in the same
location.
6. Select Create .
Create a VNet
This VNet will contain three 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 > Vir tual network .
4. For Resource group , select Test-FW-RG .
5. For Name , type Test-FW-VN .
6. For Region , select the same location that you used previously.
7. Select Next: IP addresses .
8. For IPv4 Address space , type 10.0.0.0/16 .
9. Under Subnet , select default .
10. For Subnet name type AzureFirewallSubnet . The firewall will be in this subnet, and the subnet name must
be AzureFirewallSubnet.
11. For Address range , type 10.0.1.0/26 .
12. Select Save .
Next, create a subnet for the workload server.
1. Select Add subnet .
2. For Subnet name , type Workload-SN .
3. For Subnet address range , type 10.0.2.0/24 .
4. Select Add .
5. Select Review + create .
6. Select Create .
Create a virtual machine
Now create the workload virtual machine, and place it in the Workload-SN subnet.
2. Select Compute and then select Vir tual machine .
3. Windows Ser ver 2016 Datacenter in the Featured list.
4. 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 2019 Datacenter
Administrator user name Type a user name
Password Type a password
5. Under Inbound por t rules , Public inbound por ts , select None .

6. Accept the other defaults and select Next: Disks .
7. Accept the disk defaults and select Next: Networking .
8. Make sure that Test-FW-VN is selected for the virtual network and the subnet is Workload-SN .
9. For Public IP , select None .
10. Accept the other defaults and select Next: Management .
11. Select Off to disable boot diagnostics. Accept the other defaults and select Review + create .
12. Review the settings on the summary page, and then select Create .
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 .
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>
Resource group Test-FW-RG
Name Test-FW01
SET T IN G VA L UE
Location Select the same location that you used previously
Choose a virtual network Use existing : Test-FW-VN
Public IP address Add new

Name : fw-pip

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 .
4. For Name , type Firewall-route .
6. For Resource group , select Test-FW-RG .
7. For Location , select the same location that you used previously.
8. Select Create .
9. Select Refresh , and then select the Firewall-route route table.
10. Select Subnets and then select Associate .
11. Select Vir tual network > Test-FW-VN .
12. 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.
13. Select OK .
14. Select Routes and then select Add .
15. For Route name , type fw-dg .
16. For Address prefix , type 0.0.0.0/0 .
17. For Next hop type , select Vir tual appliance .
Azure Firewall is actually a managed service, but virtual appliance works in this situation.
18. For Next hop address , type the private IP address for the firewall that you noted previously.
19. 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 Test-FW01 firewall.
2. On the Test-FW01 page, under Settings , select Rules .
3. Select the Application rule collection tab.
4. Select Add application rule collection .
5. For Name , type App-Coll01 .
6. For Priority , type 200 .
7. For Action , select Allow .
8. Under Rules , Target FQDNs , for Name , type Allow-Google .
9. For Source type , select IP address .
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 .
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 the Network rule collection tab.
2. Select Add network rule collection .
3. For Name , type Net-Coll01 .
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 CenturyLink.
12. For Destination Por ts , type 53 .
13. 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 NAT rule collection tab.
2. Select Add NAT rule collection .
3. For Name , type rdp .
5. Under Rules , for Name , type rdp-nat .
6. For Protocol , select TCP .
8. For Source , type * .
9. For Destination address , type the firewall public IP address.
11. For Translated address , type the Sr v-work private IP address.
12. For Translated por t , type 3389 .
13. 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.
1. On the Azure portal menu, select Resource groups or search for and select Resource groups from any 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
Tutorial: Deploy and configure Azure Firewall 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 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.

Declare the variables
Create the firewall hub virtual network
Create the spoke virtual network
Create the on-premises virtual network
Configure and deploy the firewall
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-
premise networks. The hub-and-spoke architecture has the following requirements:
Set AllowGatewayTransit 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 UseRemoteGateways when you peer VNet-Spoke to VNet-Hub. If UseRemoteGateways is set and
AllowGatewayTransit 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 > 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.
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. For Resource group , select FW-Hybrid-Test .
4. For Name , type VNet-hub .
5. Select Next: IP Addresses .
6. For IPv4 Address space , type 10.5.0.0/16 .
7. Under Subnet name , select default .
8. for Name type AzureFirewallSubnet . The firewall will be in this subnet, and the subnet name must be
AzureFirewallSubnet.
10. Select Save .
12. Select Create .

2. In Networking , select Vir tual network .
4. For Name , type VNet-Spoke .
5. For Region , select (US) East US .
6. Select Next: IP Addresses .
7. For IPv4 address space , type 10.6.0.0/16 .
9. for Name type SN-Workload .
11. Select Save .
13. Select Create .

2. In Networking , select Vir tual network .
4. For Name , type VNet-OnPrem .
5. For Region , select (US) East US .
6. Select Next : IP Addresses
7. For IPv4 address space , type 192.168.0.0/16 .
9. for Name type SN-Corp .
11. Select Save .
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 .

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. 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 .
10. For Source , type 192.168.1.0/24 .
11. For Destination type , select IP address .
12. For Destination address , 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 .
4. For Source , type 192.168.1.0/24 .
5. For Destination type , select IP address .
6. For Destination address , 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
gateway SKU.
2. In the search text box, type vir tual network gateway and press Enter .
3. Select Vir tual network gateway , and select Create .
4. For Name , type GW-Onprem .
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-Onprem .
10. For Public IP address , select Create new , and type VNet-Onprem-GW-pip for the name.
11. Accept the remaining defaults and then select Review + create .
12. Review the configuration, then select Create .
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.
2. Select Connections in the left column.
3. Select Add .
4. For the connection name, type Onprem-to-Hub .
5. Select VNet-to-VNet for Connection type .
6. For the Second vir tual network gateway , select GW-hub .
7. For Shared key (PSK) , type AzureA1b2C3 .
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. For Name , type HubtoSpoke .
5. For the Vir tual network , select VNet-spoke
6. For the name of the peering from VNetSpoke to VNet-hub, type SpoketoHub .
7. Select Allow gateway transit .
8. Select OK .
Configure additional settings for the SpoketoHub peering
You'll need to enable the Allow for warded traffic on the SpoketoHub peering.
1. Open the FW-Hybrid-Test resource group and select the VNet-Spoke virtual network.
2. In the left column, select Peerings .
3. Select the SpoketoHub peering.
4. Under Allow for warded traffic from VNet-hub to VNet-Spoke , select Enabled .
5. Select Save .
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, type 10.6.0.0/16 .
15. For next hop type, select Vir tual appliance .
16. For next hop address, type the firewall's private IP address that you noted earlier.
17. Select OK .
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.
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-DG .
8. For Propagate gateway route , select No .
10. Select Create .
11. After the route table is created, select it to open the route table page.
12. Select Routes in the left column.
13. Select Add .
14. For the route name, type ToHub .
15. For the address prefix, type 0.0.0.0/0 .
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 OK .
Now associate the route to the subnet.
1. On the UDR-DG - Routes page, select Subnets .
2. Select Associate .
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 , select Windows Ser ver 2016 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 .
8. For Public IP , select None .
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
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.
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)
5. Select Next:Disks .
6. Accept the defaults and select Next:Networking .
7. Select VNet-Onprem for virtual network and the subnet is SN-Corp .
8. Select Next:Management .
9. For Boot diagnostics , Select Disable .
10. Select Review+Create , review the settings on the summary page, and then select Create .
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 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 the next tutorial, or if no longer needed, delete the FW-Hybrid-Test
resource group to delete all firewall-related resources.
Next steps
Tutorial: 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 and port to a private IP and port. DNAT
rules implicitly add a corresponding network rule to allow the translated traffic. You can override this behavior by
explicitly adding a network rule collection with deny rules that match the translated traffic. To learn more about
Azure Firewall rule processing logic, see Azure Firewall rule processing logic.
Deploy a firewall
Test the firewall
Prerequisites

2. On the Azure portal home page, select Resource groups , then select Add .
3. For Resource group name , type RG-DNAT-Test .
5. For Resource group location , select a location. All subsequent resources that you create must be in the same
location.
6. 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 Name , type VN-Hub .
5. For Address space , type 10.0.0.0/16 .
7. For Resource group , select Use existing , and then select RG-DNAT-Test .
9. Under Subnet , for Name 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.

11. Use the other default settings, and then select Create .
Create a spoke VNet
2. Under Networking , select Vir tual networks .
3. Select Add .
4. For Name , type VN-Spoke .
5. For Address space , type 192.168.0.0/16 .
9. Under Subnet , for Name type SN-Workload .
The server will be in this subnet.
11. Use the other default settings, and then 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. Type Peer-HubSpoke for the Name of the peering from VN-Hub to VN-Spoke .
5. Select VN-Spoke for the virtual network.
6. Type Peer-SpokeHub for Name of peering from VN-Spoke to VN-Hub .
7. For Allow for warded traffic from VN-Spoke to VN-Hub select Enabled .
8. Select OK .
Create a virtual machine

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
1. For Vir tual network , select VN-Spoke .
2. For Subnet , select SN-Workload .
3. For Public IP address select None .
4. For Public inbound por ts , select None .
5. Leave the other default settings and select Next : Management .
Management
1. For Boot diagnostics , select Off .
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

1. From the portal home page, select Create a resource .
2. Select Networking , and after Featured , select See all .
3. Select Firewall , and then select Create .
SET T IN G VA L UE
Name FW-DNAT-test
Resource group Use existing : RG-DNAT-Test

SET T IN G VA L UE
Location Select the same location that you used previously
Choose a virtual network Use existing : VN-Hub
Public IP address Create new . The Public IP address must be the Standard
SKU type.

This will take a few minutes to deploy.
7. After deployment completes, go to the RG-DNAT-Test resource group, and select the FW-DNAT-test
firewall.
8. Note the private IP address. You'll use it later when you create the default route.

For the SN-Workload subnet, you configure the outbound default route to go through the firewall.
2. Under Networking , select Route tables .
3. Select Add .
4. For Name , type RT-FWroute .
6. For Resource group , select Use existing , and select RG-DNAT-Test .
8. Select Create .
9. Select Refresh , and then select the RT-FWroute route table.
10. Select Subnets , and then select Associate .
11. Select Vir tual network , and then select VN-Spoke .
12. For Subnet , select SN-Workload .
13. Select OK .
14. Select Routes , and then select Add .
15. For Route name , type FW-DG .
16. For Address prefix , type 0.0.0.0/0 .
17. For Next hop type , select Vir tual appliance .
Azure Firewall is actually a managed service, but virtual appliance works in this situation.
18. For Next hop address , type the private IP address for the firewall that you noted previously.
19. Select OK .
Configure a NAT rule
1. Open the RG-DNAT-Test , and select the FW-DNAT-test firewall.
2. On the FW-DNAT-test page, under Settings , select Rules .
3. Select Add NAT rule collection .
4. For Name , type RC-DNAT-01 .
6. Under Rules , for Name , type RL-01 .
8. For Source Addresses , type *.
9. For Destination Addresses type the firewall's public IP address.
10. For Destination por ts , type 3389 .
11. For Translated Address type the private IP address for the Srv-Workload virtual machine.
12. For Translated por t , type 3389 .
13. 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
In this tutorial, you learned how to:
Deploy a firewall
Test the firewall
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 features
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
Outbound SNAT support
Inbound DNAT support
Multiple public IP addresses
Azure Monitor logging
Forced tunneling
Certifications
Built-in high availability

High availability is built in, so no additional 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 an Availability Zone. However, there are additional 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 up 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.
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.
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.
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 - 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 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.
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 rule processing logic
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
Windows Update Allow outbound access to Microsoft Update as described in

How to Configure a Firewall for Software Updates.
Windows Diagnostics Allow outbound access to all Windows Diagnostics endpoints.
Microsoft Active Protection Service (MAPS) Allow outbound access to MAPS.
App Service Environment (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.
Azure Backup Allows outbound access to the Azure Backup services.
Azure HDInsight 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 (WVD) Allows outbound Windows Virtual Desktop platform traffic.

This tag doesn’t cover deployment-specific Storage and
Service Bus endpoints created by WVD. Additionally, DNS and
KMS network rules are required. For more information about
integrating Azure Firewall with WVD, see Use Azure Firewall to
protect Window Virtual Desktop deployments.
F Q DN TA G DESC RIP T IO N
Azure Kubernetes Service (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
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.
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 example:
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/AZUREFI
REWALLS/{resourceName}",
"operationName": "AzureFirewallApplicationRuleLog",
"properties": {
"msg": "HTTPS request from 10.1.0.5:55640 to mydestination.com:443. Action: Allow. Rule
Collection: collection1000. Rule: rule1002"
}
}
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.
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 and domains. The IP addresses and domains are sourced from the Microsoft Threat
Intelligence feed. Intelligent Security Graph powers Microsoft threat intelligence and is used by multiple services
including Azure Security Center.
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/AZUREFIREWALLS
/{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
Configure Azure Firewall rules
You can configure NAT rules, network rules, and applications rules on Azure Firewall. 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.
NOTE
If you enable threat intelligence-based filtering, those rules are highest priority and are always processed first. Threat-
intelligence filtering may deny traffic before any configured rules are processed. For more information, see Azure Firewall
threat intelligence-based filtering.
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 there is no network rule match, and if the protocol is HTTP, HTTPS, or MSSQL, then the packet is then evaluated
by the application rules in priority order. If still no match is found, then the packet is evaluated against the
infrastructure rule collection. If there is still no match, then the packet is denied by default.
Inbound connectivity
NAT 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. You can override this behavior by explicitly adding a network rule collection with deny rules that
match the translated traffic.
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.
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
cannot 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 Security groups for a list of service tags that are available for use in Azure firewall network rules.
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.
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 an on-premises edge firewall or other network virtual
appliance (NVA) to process network traffic before it's passed to the Internet. However, you can't configure an
existing firewall for forced tunneling.
By default, forced tunneling isn't allowed on Azure Firewall to ensure all its outbound Azure dependencies are met.
User Defined Route (UDR) configurations on the AzureFirewallSubnet that have a default route not going directly
to the Internet are disabled.
Forced tunneling configuration

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. The only route allowed on this subnet is a default route to the Internet, and BGP route
propagation must be disabled.
If you have a default route advertised via BGP to force traffic to on-premises, you must create the
AzureFirewallSubnet and AzureFirewallManagementSubnet before deploying your firewall and have a UDR with a
default route to the Internet, and Propagate gateway routes disabled.
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)
HIPPA
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 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 Windows Virtual Desktop support

Windows 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, 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. Windows 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 Windows Virtual Desktop virtual machines
that run in your virtual network. For more information, see Use Azure Firewall to protect Window Virtual Desktop
deployments.
Next steps
Learn more about Windows Virtual Desktop.
Use FQDN filtering in network rules (preview)
IMPORTANT
FQDN filtering in network rules is currently in public preview. This preview version is provided without a service level
agreement, and it's not recommended for production workloads. Certain features might not be supported or might have
constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
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 (preview).
NOTE
By design, FQDN filtering 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.
What’s the difference between using domain names in application rules compared to that of 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.
In application rules, you can use HTTP/S and MSSQL as your selected protocols. In network rules, you can use
any TCP/UDP protocol with your destination FQDNs.
Next steps
Azure Firewall DNS settings
Azure security baseline for Azure Firewall
This security baseline applies guidance from the Azure Security Benchmark to Azure Firewall. The Azure Security
Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is
grouped the security controls defined by the Azure Security Benchmark and the related guidance applicable to
Azure Firewall. Controls not applicable to Azure Firewall have been excluded. To see how Azure Firewall
completely maps to the Azure Security Benchmark, see the full Azure Firewall security baseline mapping file.
Network security
For more information, see the Azure Security Benchmark: Network security.
1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces
Guidance : Azure Firewall is integrated with Azure Monitor for logging of traffic processed by the firewall.
Additionally, use Azure Security Center and follow network protection recommendations to help secure your
network resources related to Azure Firewall.
Understand Network Security provided by Azure Security Center
Azure Security Center monitoring : Yes
Responsibility : Customer
1.4: Deny communications with known-malicious IP addresses
Guidance : Enable Threat intelligence-based filtering to alert and deny traffic from/to known malicious IP addresses
and domains. Threat intelligence-based filtering can be enabled for your firewall to alert and deny traffic from/to-
known malicious IP addresses and domains.
Azure Firewall threat intelligence-based filtering
Understand Azure Security Center Integrated Threat Intelligence
1.8: Minimize complexity and administrative overhead of network security rules
Guidance : In an Azure Firewall, a service tag represents a group of IP address prefixes to help minimize complexity
for security rule creation.
Azure Firewall service tags can be used in the network rules destination field and define network access controls on
Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules.
Additionally, customer-defined tags such as IP groups are also supported and can be used in a network rule or an
application rule. FQDN tags in application rules are supported to allow the required outbound network traffic
through your firewall.
Note that you cannot 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
Available service tags
IP groups in Azure Firewall
FQDN tags overview
Azure Security Center monitoring : Currently not available
1.9: Maintain standard security configurations for network devices
Guidance : Azure policy is not yet fully supported for Azure Firewall. Azure Firewall Manager can be used to
achieve standardization of security configurations.
You may also use Azure Blueprints to simplify large-scale Azure deployments by packaging key environment
artifacts, such as Azure Resources Manager templates, Azure RBAC controls, and policies, in a single blueprint
definition. You can apply the blueprint to new subscriptions, and fine-tune control and management through
versioning.
How to configure and manage Azure Policy
Azure Policy samples for networking
How to create an Azure Blueprint
Azure Security Center monitoring : Not applicable
1.11: Use automated tools to monitor network resource configurations and detect changes
Guidance : Use Azure Activity Log to monitor resource configurations and detect changes to your Azure Firewall
resources. Create alerts within Azure Monitor that will trigger when changes to critical resources take place.
Monitor Azure Firewall logs and metrics
How to view and retrieve Azure Activity Log events
How to create alerts in Azure Monitor
Logging and monitoring

For more information, see the Azure Security Benchmark: Logging and monitoring.
2.1: Use approved time synchronization sources
Guidance : Microsoft maintains time sources for Azure resources for Azure Firewall. Customers need to create a
network rule to allow this access, or for a time server that you use in their environment.
NTP server access
Responsibility : Shared
2.2: Configure central security log management
Guidance : You can enable and on-board log data to Azure Sentinel or a third-party SIEM for central security log
management of various logs.
Activity logs can be used to audit operations on Azure Firewall to and monitor actions on resources. The activity log
contains all write operations (PUT, POST, DELETE) for your resources except read operations (GET). Activity logs can
be used to find an error when troubleshooting or to monitor how a user in your organization modified a resource.
Azure Firewall also provides the following diagnostic logs to provide information on customer applications and
network rules.
Application rule log: Each new connection that matches one of your configured application rules results in a log for
the accepted/denied connection.
Network rule log: Each new connection that matches one of your configured network rules results in a log for the
accepted/denied connection
Note: Both logs can be saved to a storage account, streamed to Event hubs and/or sent to Azure Monitor logs only
if enabled for each Azure Firewall in an environment.
Azure Firewall logs
List of resource actions in activity logs: Azure Resource Manager Resource Provider operations
How to collect platform logs and metrics with Azure Monitor
How to onboard Azure Sentinel
How to get started with Azure Monitor and third-party SIEM integration
2.3: Enable audit logging for Azure resources
Guidance : Activity logs can be used to audit operations on Azure Firewall and monitor actions on resources. The
activity log contains all write operations (PUT, POST, DELETE) for Azure resources except read operations (GET).
Azure Firewall also provides the following diagnostic logs to provide information on customer applications and
network rules.
Application rule log: Each new connection that matches one of your configured application rules results in a log for
the accepted/denied connection.
Network rule log: Each new connection that matches one of your configured network rules results in a log for the
accepted/denied connection
Note that both logs can be saved to a storage account, streamed to Event hubs and/or sent to Azure Monitor logs
but only if enabled for each Azure Firewall in an environment.
Azure Firewall logs
List of resource actions in activity logs
2.5: Configure security log storage retention
Guidance : Log Analytics Workspace retention period can be set according to an organization's compliance
regulations within Azure Monitor. Data retention can be configured from 30 to 730 days (2 years) for all
workspaces depending upon the chosen pricing tier.
There are 3 options for storing log storage retention:
Storage accounts are best used for logs when logs are stored for a longer duration and reviewed when needed.
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 is best used for general real-time monitoring of your application or looking at trends.
Change the data retention period in Log Analytics
How to configure retention policy for Azure Storage account logs
2.6: Monitor and review logs
Guidance : Azure Firewall is integrated with Azure Monitor for viewing and analyzing firewall logs. Logs can be
sent to Log Analytics, Azure Storage, or Event Hubs. They can be analyzed in Log Analytics or by different tools such
as Excel and Power BI. There are a few different types of Azure Firewall logs.
Activity logs can be used to audit operations on Azure Firewall to and monitor actions on resources. The activity log
contains all write operations (PUT, POST, DELETE) for resources except read operations (GET). Activity logs can be
used to find an error when troubleshooting or to monitor how a user in your organization modified a resource.
Azure Firewall also provides diagnostic logs to provide information on customer applications and network rules.
Application rule logs are created when each new connection that matches one of your configured application rules
results in a log for the accepted/denied connection.
Network rule logs are created when each new connection that matches one of your configured network rules
results in a log for the accepted/denied connection
Note that both logs can be saved to a storage account, streamed to Event hubs and/or sent to Azure Monitor logs
but only if enabled it for each Azure Firewall in an environment.
Azure Monitor logs can be used for general real-time monitoring of your application or looking at trends.
Diagnostic Logs
2.7: Enable alerts for anomalous activities
Guidance : Use Azure Security Center with Log Analytics Workspace for monitoring and alerting on anomalous
activity found in security logs and events.
Alternatively, you may enable and on-board data to Azure Sentinel.
How to manage alerts in Azure Security Center
How to alert on log analytics log data
Identity and access control
For more information, see the Azure Security Benchmark: Identity and access control.
3.1: Maintain an inventory of administrative accounts
Guidance : Azure AD has built-in roles that must be explicitly assigned and are queryable. Use the Azure AD
PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups.
How to get a directory role in Azure AD with PowerShell
How to get members of a directory role in Azure AD with PowerShell
3.3: Use dedicated administrative accounts
Guidance : Create standard operating procedures around the use of dedicated administrative accounts. Use Azure
Security Center Identity and Access Management to monitor the number of administrative accounts.
You can also enable a Just-In-Time / Just-Enough-Access by using Azure AD Privileged Identity Management
Privileged Roles for Microsoft Services, and Azure Resource Manager.
Learn more about Privileged Identity Management
3.4: Use Azure Active Directory single sign-on (SSO )
Guidance : Wherever possible, use Azure Active Directory SSO instead of configuring individual stand-alone
credentials per-service. Use Azure Security Center Identity and Access Management recommendations.
Understand SSO with Azure AD
3.5: Use multi-factor authentication for all Azure Active Directory-based access
Guidance : Enable Azure Active Directory multi-factor authentication(MFA) and follow Azure Security Center
Identity and Access Management recommendations.
How to enable MFA in Azure
How to monitor identity and access within Azure Security Center
3.6: Use dedicated machines (Privileged Access Workstations) for all administrative tasks
Guidance : Use PAWs (privileged access workstations) with multi-factor authentication(MFA) configured to log into
and configure Azure Firewall and related resources.
Learn about Privileged Access Workstations
How to enable MFA in Azure
3.7: Log and alert on suspicious activities from administrative accounts
Guidance : Use Azure Active Directory security reports for generation of logs and alerts when suspicious or unsafe
activity occurs in the environment. Use Azure Security Center to monitor identity and access activity.
How to identify Azure AD users flagged for risky activity
How to monitor users' identity and access activity in Azure Security Center
3.8: Manage Azure resources from only approved locations
Guidance : Use Conditional Access Named Locations to allow access from only specific logical groupings of IP
address ranges or countries/regions.
How to configure Named Locations in Azure
3.9: Use Azure Active Directory
Guidance : Use Azure Active Directory (Azure AD) as the central authentication and authorization system. Azure AD
protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely
stores user credentials.
How to create and configure an Azure AD instance
3.10: Regularly review and reconcile user access
Guidance : Azure AD provides logs to help discover stale accounts. In addition, use Azure Identity Access Reviews to
efficiently manage group memberships, access to enterprise applications, and role assignments. User access can be
reviewed on a regular basis to make sure only the right Users have continued access.
Understand Azure AD reporting
How to use Azure Identity Access Reviews
3.11: Monitor attempts to access deactivated credentials
Guidance : You have access to Azure AD Sign-in Activity, Audit and Risk Event log sources, which allow you to
integrate with any SIEM/Monitoring tool.
You can streamline this process by creating Diagnostic Settings for Azure Active Directory user accounts and
sending the audit logs and sign-in logs to a Log Analytics workspace. You can configure desired Alerts within Log
Analytics workspace.
How to integrate Azure Activity Logs into Azure Monitor
3.12: Alert on account sign-in behavior deviation
Guidance : Use Azure AD Risk and Identity Protection features to configure automated responses to detected
suspicious actions related to user identities. You can also ingest data into Azure Sentinel for further investigation.
How to view Azure AD risky sign-ins
How to configure and enable Identity Protection risk policies
Data protection
For more information, see the Azure Security Benchmark: Data protection.
4.1: Maintain an inventory of sensitive Information
Guidance : Use tags to assist in tracking Azure Firewall and related resources that store or process sensitive
information.
How to create and use tags
4.2: Isolate systems storing or processing sensitive information
Guidance : Implement isolation using separate subscriptions and management groups for individual security
domains such as environment type and data sensitivity level. You can restrict the level of access to your Azure
Firewall resources that your applications and enterprise environments demand. You can control access to Azure
resources via Azure role-based access control.
How to create additional Azure subscriptions
How to create Management Groups
4.3: Monitor and block unauthorized transfer of sensitive information
Guidance : Leverage a third-party solution from Azure Marketplace on network perimeters that monitors for
unauthorized transfer of sensitive information and blocks such transfers while alerting information security
professionals.
For the underlying platform which is managed by Microsoft, Microsoft treats all customer content as sensitive and
guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft
has implemented and maintains a suite of robust data protection controls and capabilities.
Understand customer data protection in Azure
4.4: Encrypt all sensitive information in transit
Guidance : Encrypt all sensitive information in transit. Ensure that any clients connecting to your Azure Firewall and
related resources are able to negotiate TLS 1.2 or greater.
Follow Azure Security Center recommendations for encryption at rest and encryption in transit, where applicable.
Understand encryption in transit with Azure
4.5: Use an active discovery tool to identify sensitive data
Guidance : Use a third-party active discovery tool to identify all sensitive information stored in Azure resource
using Azure Firewall and related resources and update the organization's sensitive information inventory.
Understand customer data protection in Azure
4.6: Use Azure RBAC to control access to resources
Guidance : Use Azure role-based access control (Azure RBAC) to control access to Azure Firewall and related
resources.
How to configure Azure RBAC
4.8: Encrypt sensitive information at rest
Guidance : Use encryption at rest on all Azure resources using Azure Firewall and related resources. Microsoft
recommends allowing Azure to manage your encryption keys, however there is the option for you to manage your
own keys in some instances.
Understand encryption at rest in Azure
How to configure customer managed encryption keys
4.9: Log and alert on changes to critical Azure resources
Guidance : Use Azure Monitor with the Azure Activity Log to create alerts for when changes take place in Azure
Firewall.
How to create alerts for Azure Activity Log events
Inventory and asset management

For more information, see the Azure Security Benchmark: Inventory and asset management.
6.2: Maintain asset metadata
Guidance : Apply tags to Azure Firewall and related resources giving metadata to logically organize them into a
taxonomy.
6.3: Delete unauthorized Azure resources
Guidance : Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track
Azure Firewall and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are
deleted from the subscription in a timely manner.
How to create additional Azure subscriptions
How to create Management Groups
How to create and use Tags
6.4: Define and maintain inventory of approved Azure resources
Guidance : Create an inventory of approved Azure Firewall resources including configuration as per your
organizational needs.
6.5: Monitor for unapproved Azure resources
Guidance : Use Azure Policy to put restrictions on the type of resources that can be created in your subscription(s).
Use Azure Resource Graph to query/discover Azure Firewall resources within their subscription(s). Ensure that all
Azure Firewall and related resources present in the environment are approved.
How to create queries with Azure Graph
6.7: Remove unapproved Azure resources and software applications
Guidance : Implement your own process for removing unauthorized Azure Firewall and related resources. You can
also use a third-party solution to identify unapproved Azure Firewall and related resources
6.9: Use only approved Azure services
Guidance : Use Azure Policy to restrict which services you can provision in your environment.
How to deny a specific resource type with Azure Policy
6.11: Limit users' ability to interact with Azure Resource Manager
Guidance : Use Azure Conditional Access to limit users' ability to interact with Azure Resources Manager by
configuring "Block access" for the "Microsoft Azure Management" App.
How to configure Conditional Access to block access to Azure Resources Manager
6.13: Physically or logically segregate high risk applications
Guidance : Applications which may be required for business operations, or environments with differing risk
profiles for the organization, should be isolated and separated with separate Azure Firewall instances.
Deploy and configure Azure Firewall using the Azure portal
How to create a virtual network
How to create an NSG with a security config
Secure configuration
For more information, see the Azure Security Benchmark: Secure configuration.
7.1: Establish secure configurations for all Azure resources
Guidance : Azure Resource Manager has the ability to export the template in JavaScript Object Notation (JSON),
which should be reviewed to ensure that the configurations meet / exceed the security requirements for your
organization.
You can also use recommendations from Azure Security Center as a secure configuration baseline for your Azure
resources.
Azure policy is not fully supported at this time.
Single and multi-resource export to a template in Azure portal
Security recommendations - a reference guide
7.3: Maintain secure Azure resource configurations
Guidance : Use Azure policy [deny] and [deploy if not exist] to enforce secure settings across your Azure Firewall
and related resources. In addition, you may use Azure Resource Manager templates to maintain the security
configuration of your Azure Firewall and related resources required by your organization.
Understand Azure Policy effects
Create and manage policies to enforce compliance
Azure Resource Manager templates overview
7.5: Securely store configuration of Azure resources
Guidance : Use Azure DevOps to securely store and manage your code like custom Azure policies and Azure
Resource Manager templates. To access the resources you manage in Azure DevOps, you can grant or deny
permissions to specific users, built-in security groups, or groups defined in Azure Active Directory (Azure AD) if
integrated with Azure DevOps, or Active Directory if integrated with TFS.
How to store code in Azure DevOps
About permissions and groups in Azure DevOps
7.7: Deploy configuration management tools for Azure resources
Guidance : Define and implement standard security configurations for Azure Firewall and related resources using
Azure Policy. Use Azure Policy aliases to create custom policies to audit or enforce the network configuration of
your Azure Firewall resources. You may also make use of built-in policy definitions related to your specific
resources.
How to use Aliases
7.12: Manage identities securely and automatically
Guidance : Use Managed Identities to provide Azure services with an automatically managed identity in Azure AD.
Managed Identities allows you to authenticate to any service that supports Azure AD authentication to Azure
Resource Manager and can be used with API/Azure Portal/CLI/PowerShell.
How to configure Managed Identities
7.13: Eliminate unintended credential exposure
Guidance : Implement Credential Scanner to identify credentials within code. Credential Scanner will also
encourage moving discovered credentials to more secure locations such as Azure Key Vault.
How to setup Credential Scanner
Data recovery
For more information, see the Azure Security Benchmark: Data recovery.
9.1: Ensure regular automated back-ups
Guidance : Use Azure Resource Manager to export the Azure Firewall and related resources in a JavaScript Object
Notation (JSON) template which can be used as backup for Azure Firewall and related configurations. You can also
export Azure Firewall configuration using Export template feature of Azure Firewall from Azure portal. Use Azure
Automation to run the backup scripts automatically.
Single and multi-resource export to a template in Azure portal
Microsoft Network Azure Firewalls template reference
About Azure Automation
9.2: Perform complete system backups and backup any customer-managed keys
Guidance : Use Azure Resource Manager to export the Azure Firewall and related resources in a JavaScript Object
Notation (JSON) template which can be used as backup for Azure Firewall and related configurations. You can also
export Azure Firewall configuration using Export template feature of Azure Firewall from Azure portal.
9.3: Validate all backups including customer-managed keys
Guidance : Ensure ability to periodically perform restoration using Azure Resource Manager template backed files.
9.4: Ensure protection of backups and customer-managed keys
Guidance : Use Azure DevOps to securely store and manage your code like custom Azure policies, Azure Resource
Manager templates. To protect resources you manage in Azure DevOps, you can grant or deny permissions to
specific users, built-in security groups, or groups defined in Azure Active Directory (Azure AD) if integrated with
Azure DevOps, or Active Directory if integrated with TFS.
How to store code in Azure DevOps
About permissions and groups in Azure DevOps
Incident response
For more information, see the Azure Security Benchmark: Incident response.
10.1: Create an incident response guide
Guidance : Build out an incident response guide for your organization. Ensure that there are written incident
response plans that define all roles of personnel as well as phases of incident handling/management from
detection to post-incident review.
Guidance on building your own security incident response process
Microsoft Security Response Center's Anatomy of an Incident
Leverage NIST's Computer Security Incident Handling Guide to aid in the creation of your own incident
response plan
10.2: Create an incident scoring and prioritization procedure
Guidance : Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated
first. The severity is based on how confident Security Center is in the finding or the analytic used to issue the alert
as well as the confidence level that there was malicious intent behind the activity that led to the alert.
Additionally, clearly mark subscriptions (for ex. production, non-prod) using tags and create a naming system to
clearly identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to
prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the
incident occurred.
Security alerts in Azure Security Center
Use tags to organize your Azure resources
10.3: Test security response procedures
Guidance : Conduct exercises to test your systems’ incident response capabilities on a regular cadence to help
protect your Azure resources. Identify weak points and gaps and revise plan as needed.
NIST's publication - Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
10.4: Provide security incident contact details and configure alert notifications for security incidents
Guidance : Security incident contact information will be used by Microsoft to contact you if the Microsoft Security
Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. Review
incidents after the fact to ensure that issues are resolved.
How to set the Azure Security Center Security Contact
10.5: Incorporate security alerts into your incident response system
Guidance : Export your Azure Security Center alerts and recommendations using the Continuous Export feature to
help identify risks to Azure resources.
Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous
fashion. You may use the Azure Security Center data connector to stream the alerts to Azure Sentinel.
How to configure continuous export
How to stream alerts into Azure Sentinel
10.6: Automate the response to security alerts
Guidance : Use the Workflow Automation feature in Azure Security Center to automatically trigger responses via
"Logic Apps" on security alerts and recommendations to protect your Azure resources.
How to configure Workflow Automation and Logic Apps
Penetration tests and red team exercises

For more information, see the Azure Security Benchmark: Penetration tests and red team exercises.
11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security
findings
Guidance : Follow the Microsoft Rules of Engagement to ensure your Penetration Tests are not in violation of
Microsoft policies. Use Microsoft’s strategy and execution of Red Teaming and live site penetration testing against
Microsoft-managed cloud infrastructure, services, and applications.
Penetration Testing Rules of Engagement
Microsoft Cloud Red Teaming
Next steps
See the Azure security benchmark
Learn more about Azure security baselines
Deploy and configure Azure Firewall using Azure
PowerShell
accessed.
Application rules that define fully qualified domain names (FQDNs) that can be accessed from a subnet.
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.
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.
In this article, you learn how to:

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

and test servers.
The resource group contains all the resources for the deployment.
New-AzResourceGroup -Name Test-FW-RG -Location "East US"
Create a VNet
This virtual network has three subnets:
NOTE
$FWsub = New-AzVirtualNetworkSubnetConfig -Name AzureFirewallSubnet -AddressPrefix 10.0.1.0/26

$Worksub = New-AzVirtualNetworkSubnetConfig -Name Workload-SN -AddressPrefix 10.0.2.0/24
$Jumpsub = New-AzVirtualNetworkSubnetConfig -Name Jump-SN -AddressPrefix 10.0.3.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 $FWsub, $Worksub, $Jumpsub

Now create the jump and workload virtual machines, and place them in the appropriate subnets. When prompted,
type a user name and password for the virtual machine.
Create the Srv-Jump virtual machine.
New-AzVm `
-ResourceGroupName Test-FW-RG `
-Name "Srv-Jump" `
-Location "East US" `
-VirtualNetworkName Test-FW-VN `
-SubnetName Jump-SN `
-OpenPorts 3389 `
-Size "Standard_DS2"
Create a workload virtual machine with no public IP address. When prompted, type a user name and password for
the virtual machine.
#Create the NIC
$NIC = New-AzNetworkInterface -Name Srv-work -ResourceGroupName Test-FW-RG `
-Location "East US" -Subnetid $testVnet.Subnets[1].Id
#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 $NIC.Id
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName 'MicrosoftWindowsServer' -Offer
'WindowsServer' -Skus '2016-Datacenter' -Version latest
#Create the virtual machine

New-AzVM -ResourceGroupName Test-FW-RG -Location "East US" -VM $VirtualMachine -Verbose
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" -VirtualNetworkName
Test-FW-VN -PublicIpName fw-pip
#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
are specific for the platform and can't be used for other purposes. For more information, see Infrastructure FQDNs.

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)
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
general Azure Firewall requirement.
$NIC.DnsSettings.DnsServers.Add("209.244.0.3")
$NIC.DnsSettings.DnsServers.Add("209.244.0.4")
$NIC | Set-AzNetworkInterface
Test the firewall

1. Note the private IP address for the Sr v-Work virtual machine:
$NIC.IpConfigurations.PrivateIpAddress
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:
nslookup www.google.com
nslookup www.microsoft.com
Both commands should return answers, showing that your DNS queries are getting through the firewall.
4. 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
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
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 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:
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 article uses a
VPN gateway connection, and an Azure-located virtual network is used to represent an on-premises network.

Create the routes
Create the virtual machines
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 has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will
continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure
PowerShell.
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
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.
To review the related Azure PowerShell reference documentation, see Azure PowerShell Reference.

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.
# Get a Public IP for the firewall

$FWpip = New-AzPublicIpAddress -Name "fw-pip" -ResourceGroupName $RG1 `
-Location $Location1 -AllocationMethod Static -Sku Standard
# Create the firewall
$Azfw = New-AzFirewall -Name AzFW01 -ResourceGroupName $RG1 -Location $Location1 -VirtualNetworkName
$VNetnameHub -PublicIpName fw-pip
#Save the firewall private IP address for future use
$AzfwPrivateIP = $Azfw.IpConfigurations.privateipaddress
$AzfwPrivateIP
Configure network rules

$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

The hub and on-premises virtual networks are connected via VPN gateways.
Create a VPN gateway for the hub virtual network
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
Now create the VPN gateway for the hub virtual network. Network-to-network configurations require a
gateway SKU.
New-AzVirtualNetworkGateway -Name $GWHubName -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku basic
Create a VPN gateway for the on-premises virtual network

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
Now create the VPN gateway for the on-premises virtual network. Network-to-network configurations require a
gateway SKU.
New-AzVirtualNetworkGateway -Name $GWOnpremName -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf2 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku basic
Create the VPN connections

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

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.
New-AzVirtualNetworkGatewayConnection -Name $ConnectionNameHub -ResourceGroupName $RG1 `

-VirtualNetworkGateway1 $vnetHubgw -VirtualNetworkGateway2 $vnetOnpremgw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
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.
New-AzVirtualNetworkGatewayConnection -Name $ConnectionNameOnprem -ResourceGroupName $RG1 `

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

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

Now peer the hub and spoke virtual networks.
# 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

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
#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 `
-DisableBgpRoutePropagation
#Create a route
Get-AzRouteTable `
-Name UDR-DG `
| Add-AzRouteConfig `
-Name "ToFirewall" `
| Set-AzRouteTable
-VirtualNetwork $VNetSpoke `
-Name $SNnameSpoke `
-AddressPrefix $SNSpokePrefix `
-RouteTable $routeTableSpokeDG | `
Set-AzVirtualNetwork

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, 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
#Define the virtual machine

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

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

Set-AzVMExtension `
-ExtensionName IIS `
-VMName VM-Spoke-01 `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server"}' `
-Location $Location1
Create the on-premises virtual machine

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"
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.
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.
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.
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. 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.
Use Azure Cloud Shell
Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. You can
use either Bash or PowerShell with Cloud Shell to work with Azure services. You can use the Cloud Shell
preinstalled commands to run the code in this article without having to install anything on your local environment.
To start Azure Cloud Shell:
O P T IO N EXA M P L E/ L IN K
Select Tr y It in the upper-right corner of a code block.

Selecting Tr y It doesn't automatically copy the code to Cloud
Shell.
Go to https://shell.azure.com, or select the Launch Cloud

Shell button to open Cloud Shell in your browser.
Select the Cloud Shell button on the menu bar at the upper
right in the Azure portal.
To run the code in this article in Azure Cloud Shell:

1. Start Cloud Shell.
2. Select the Copy button on a code block to copy the code.
3. Paste the code into the Cloud Shell session by selecting Ctrl +Shift +V on Windows and Linux or by
selecting Cmd +Shift +V on macOS.
4. Select Enter to run the code.
Prerequisites
Azure CLI
If you choose to install and use the CLI locally, run Azure CLI version 2.0.4 or later. To find the version, run az --
version . For information about installing or upgrading, see Install Azure CLI.
Install the Azure Firewall extension:
az extension add -n azure-firewall
Set up the network

and test servers.
The resource group contains all the resources for the deployment.
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
az network vnet subnet create \
--name Jump-SN \
--address-prefix 10.0.3.0/24

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
Deploy the firewall
Now deploy the firewall into the virtual network.
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)"
Note the private IP address. You'll use it later when you create the default route.

Create a table, with BGP route propagation disabled
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
are specific for the platform and can't be used for other purposes. For more information, see Infrastructure FQDNs.

The network rule allows outbound access to two IP addresses at port 53 (DNS).
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:
nslookup www.google.com
nslookup www.microsoft.com
Both commands should return answers, showing that your DNS queries are getting through the firewall.
4. Run the following commands:

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
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)
$azFw | Set-AzFirewall
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.
NOTE
The virtual machines in the backend pool will not have outbound internet connectivity with this configuration.
For more information on providing outbound connectivity see:
Outbound connections in Azure
Options for providing connectivity:
Outbound-only load balancer configuration
What is Vir tual Network NAT?
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. Configure an application rule with 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 FWAppRules \
-n srule \
--protocols mssql=1433 \
--target-fqdns sql-serv1.database.windows.net
Configure using the Azure portal

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. 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. Application rules are always applied using a transparent proxy regardless of 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
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.
Configure SNAT private IP address ranges - Azure PowerShell

You can use Azure PowerShell to specify private IP address ranges for the firewall.
New firewall
For a new firewall, the Azure PowerShell command is:
New-AzFirewall -Name $GatewayName -ResourceGroupName $RG -Location $Location -VirtualNetworkName $vnet.Name -
PublicIpName $LBPip.Name -PrivateRange @("IANAPrivateRanges","IPRange1", "IPRange2")
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, use the following Azure PowerShell commands:
$azfw = Get-AzFirewall -ResourceGroupName "Firewall Resource Group name"

$azfw.PrivateRange = @("IANAPrivateRanges","IPRange1", "IPRange2")
Templates
You can add the following to the additionalProperties section:
"additionalProperties": {
"Network.SNAT.PrivateRanges": "IANAPrivateRanges , IPRange1, IPRange2"
},
Configure SNAT private IP address ranges - Azure portal

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 .
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
2. Type IP Groups in the search text box, then select IP Groups .
3. Select Create .
4. Select your subscription.
5. Select a resource group or create a new one.
6. Type a unique name for you IP Group, and then select a region.
7. Select Next: IP addresses .
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 .
Next steps
Learn more about IP Groups
Use Azure Firewall to protect Window Virtual
Desktop deployments
Windows Virtual Desktop is a desktop and app virtualization service that runs on Azure. When an end user
connects to a Windows Virtual Desktop environment, their session is run by a host pool. A host pool is a collection
of Azure virtual machines that register to Windows 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 Windows 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 Windows Virtual Desktop host pool
using Azure Firewall.
Prerequisites
A deployed Windows Virtual Desktop environment and host pool.
For more information, see Tutorial: Create a host pool by using the Azure Marketplace and Create a host
pool with an Azure Resource Manager template.
To learn more about Windows Virtual Desktop environments see Windows Virtual Desktop environment.
Host pool outbound access to Windows Virtual Desktop

The Azure virtual machines you create for Windows Virtual Desktop must have access to several Fully Qualified
Domain Names (FQDNs) to function properly. Azure Firewall provides a Windows Virtual Desktop FQDN Tag to
simplify this configuration. Use the following steps to allow outbound Windows Virtual Desktop platform traffic:
Deploy Azure Firewall and configure your Windows Virtual Desktop host pool subnet User Defined Route
(UDR) to route all traffic via the Azure Firewall. Your default route now points to the firewall.
Create an application rule collection and add a rule to enable the WindowsVirtualDesktop FQDN tag. The
source IP address range is the host pool virtual network, the protocol is https , and the destination is
WindowsVir tualDesktop .
The set of required storage and service bus accounts for your Windows Virtual Desktop host pool is
deployment specific, so it isn't yet captured in the WindowsVirtualDesktop FQDN tag. You can address this
in one of the following ways:
Allow https access from your host pool subnet to *xt.blob.core.windows.net, *eh.servicebus.windows.net
and *xt.table.core.windows.net. These wildcard FQDNs enable the required access, but are less restrictive.
Use the following log analytics query to list the exact required FQDNs, and then allow them explicitly in
your firewall application rules:
AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| search "Deny"
| search "gsm*eh.servicebus.windows.net" or "gsm*xt.blob.core.windows.net" or
"gsm*xt.table.core.windows.net"
| parse msg_s with Protocol " request from " SourceIP ":" SourcePort:int " to " FQDN ":" *
| project TimeGenerated,Protocol,FQDN
Create a network rule collection add the following rules:

Allow DNS – allow traffic from your ADDS private IP address to * for TCP and UDP ports 53.
Allow KMS – allow traffic from your Windows Virtual Desktop virtual machines to Windows Activation
Service TCP port 1688. For more information about the destination IP addresses, see Windows activation
fails in forced tunneling scenario.
NOTE
Some deployments may not need DNS rules, for example Azure Active Directory Domain controllers forward DNS queries to
Azure DNS at 168.63.129.16.
Host pool outbound access to the Internet

Depending on your organization needs, you may want to enable secure outbound Internet access for your end
users. In cases where the list of allowed destinations is well-defined (for example, 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 want to filter outbound user Internet traffic using an existing on-premises secure web gateway, you can
configure web browsers or other applications running on the Windows 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 Windows Virtual Desktop
platform outbound traffic directly via Azure Firewall.
Additional considerations
You may 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 Windows Virtual Desktop: What is Windows Virtual Desktop?
Use Azure Firewall to protect Azure Kubernetes
Service (AKS) Deployments
Azure Kubernetes Service (AKS) offers a managed Kubernetes cluster on Azure. It reduces the complexity and
operational overhead of managing Kubernetes by offloading much of that responsibility to Azure. AKS handles
critical tasks, such as health monitoring and maintenance for you and delivers an enterprise-grade and secure
cluster with facilitated governance.
Kubernetes orchestrates clusters of virtual machines and schedules containers to run on those virtual machines
based on their available compute resources and the resource requirements of each container. Containers are
grouped into pods, the basic operational unit for Kubernetes, and those pods scale to the state that you want.
For management and operational purposes, nodes in an AKS cluster need to access certain ports and fully qualified
domain names (FQDNs). These actions could be to communicate with the API server, or to download and then
install core Kubernetes cluster components and node security updates. 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 Kubernetes cluster using Azure
Firewall.
Prerequisites
A deployed Azure Kubernetes cluster with running application.
For more information, see Tutorial: Deploy an Azure Kubernetes Service (AKS) cluster and Tutorial: Run
applications in Azure Kubernetes Service (AKS).
Securing AKS
Azure Firewall provides an AKS FQDN Tag to simplify the configuration. Use the following steps to allow outbound
AKS platform traffic:
When you use Azure Firewall to restrict outbound traffic and create a user-defined route (UDR) to direct all
outbound traffic, make sure you create an appropriate DNAT rule in Firewall to correctly allow inbound
traffic.
Using Azure Firewall with a UDR breaks the inbound setup because of 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. For example, inbound 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.
Create an application rule collection and add a rule to enable the AzureKubernetesService FQDN tag. The
source IP address range is the host pool virtual network, the protocol is https, and the destination is
AzureKubernetesService.
The following outbound ports / network rules are required for an AKS cluster:
TCP port 443
TCP [IPAddrOfYourAPIServer]:443 is required if you have an app that needs to talk to the API server.
This change can be set after the cluster is created.
TCP port 9000, and UDP port 1194 for the tunnel front pod to communicate with the tunnel end on
the API server.
To be more specific, see the *.hcp..azmk8s.io and addresses in the following table:
DEST IN AT IO N EN DP O IN T P ROTO C O L P O RT USE
*:1194 UDP 1194 For tunneled secure

Or communication between
ServiceTag - the nodes and the control
AzureCloud. plane.
<Region>:1194
Or
Regional CIDRs -
RegionCIDRs:1194
Or
APIServerIP:1194
(only known after
cluster creation)
*:9000 TCP 9000 For tunneled secure

Or communication between
ServiceTag - the nodes and the control
AzureCloud. plane.
<Region>:9000
Or
Regional CIDRs -
RegionCIDRs:9000
Or
APIServerIP:9000
(only known after
cluster creation)
UDP port 123 for Network Time Protocol (NTP) time synchronization (Linux nodes).
UDP port 53 for DNS is also required if you have pods directly accessing the API server.
For more information, see Control egress traffic for cluster nodes in Azure Kubernetes Service (AKS).
Configure AzureMonitor and Storage service tags. Azure Monitor receives log analytics data.
You can also allow your workspace URL individually: <worksapceguid>.ods.opinsights.azure.com , and
<worksapceguid>.oms.opinsights.azure.com . You can address this in one of the following ways:
Allow https access from your host pool subnet to *. ods.opinsights.azure.com , and
*.oms. opinsights.azure.com . These wildcard FQDNs enable the required access but are less restrictive.
Use the following log analytics query to list the exact required FQDNs, and then allow them explicitly in
your firewall application rules:
AzureDiagnostics
| search "Allow"
| search "*. ods.opinsights.azure.com" or "*.oms. opinsights.azure.com"
| parse msg_s with Protocol " request from " SourceIP ":" SourcePort:int " to " FQDN ":" *
| project TimeGenerated,Protocol,FQDN
Next steps
Learn more about Azure Kubernetes Service, see Kubernetes core concepts for Azure Kubernetes Service (AKS).
Azure Firewall DNS settings (preview)
IMPORTANT
Azure Firewall DNS settings is currently in public preview. This preview version is provided without a service level agreement,
and it's not recommended for production workloads. Certain features might not be supported or might have constrained
capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
You can configure a custom DNS server and enable DNS proxy for Azure Firewall. You can configure these settings
when you deploy the firewall or later from the DNS settings page.
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 or multiple servers.
Configure custom DNS servers (preview)
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 Save .
4. The firewall now directs DNS traffic to the specified DNS server(s) for name resolution.
DNS proxy (preview)

You can configure Azure Firewall to act as a DNS proxy. A DNS proxy acts as an intermediary for DNS requests
from client virtual machines to a DNS server. If you configure a custom DNS server, you should enable DNS proxy
to avoid DNS resolution mismatch, and enable FQDN filtering in network rules.
If you don't enable DNS proxy, DNS requests from the client may 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.
DNS Proxy configuration requires three steps:
1. Enable DNS proxy in Azure Firewall DNS settings.
2. Optionally configure your custom DNS server or use the provided default.
3. Finally, you must configure the Azure Firewall’s private IP address as a Custom DNS address in your virtual
network DNS server settings. This ensures DNS traffic is directed to Azure Firewall.
Configure DNS proxy (preview)
To configure DNS proxy, you must configure your virtual network DNS servers setting to use the firewall private IP
address. Then, enable DNS Proxy in Azure Firewall policy DNS settings .
Configure virtual network DNS servers
1. Select the virtual network where the DNS traffic will be routed through the Azure Firewall.
2. Under Settings , select DNS ser vers .
3. Select Custom under DNS ser vers .
4. Enter the firewall’s private IP address.
5. Select Save .
6. Restart the VMs that are connected to the virtual network, so they are assigned the new DNS server settings.
VMs continue to use their current DNS settings until they are restarted.
Enable DNS proxy (preview)
1. Select your Azure Firewall.
2. Under Settings , select DNS settings .
3. By default, DNS Proxy is disabled. When 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 .
Next steps
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 has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will
continue to receive bug fixes until at least December 2020. To learn more about the new Az module and AzureRM
compatibility, see Introducing the new Azure PowerShell Az module. For Az module installation instructions, see Install Azure
PowerShell.
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, four service-specific logs are available:
AzureFirewallApplicationRule
AzureFirewallNetworkRule
AzureFirewallThreatIntelLog
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 ,
AzureFirewallThreatIntelLog , and AzureFirewallDnsProxy to collect the logs.
6. Select Send to Log Analytics to configure your workspace.
7. Select your subscription.
8. Select Save .
Enable logging with 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, use the following steps:
1. Note your storage account's resource ID, where the log data is stored. This value is of the form:
/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Storage/storageAccounts/<storage account name>.
You can use any storage account in your subscription. You can use the Azure portal to find this information.
The information is located in the resource Proper ty page.
2. Note your Firewall's resource ID for which logging is enabled. This value is of the form:
/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Network/azureFirewalls/<Firewall name>.
You can use the portal to find this information.
3. Enable diagnostic logging by using the following PowerShell cmdlet:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group

name>/providers/Microsoft.Network/azureFirewalls/<Firewall name> `
-StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Storage/storageAccounts/<storage account name> `
-Enabled $true
TIP
Diagnostic logs do not require a separate storage account. The use of storage for access and performance logging incurs
service charges.
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.
Azure Sentinel : You can connect Azure Firewall logs to Azure 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 Azure Sentinel is currently in public preview. For more information, see Connect data from
Azure Firewall.
View and analyze the network and application rule logs

Azure Monitor logs collects the counter and event log files. It includes visualizations and powerful search
capabilities to analyze your logs.
For Azure Firewall log analytics sample queries, see Azure Firewall log analytics samples.
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.
Networking monitoring solutions in Azure Monitor logs
Azure Monitor logs for Azure Firewall
The following Azure Monitor logs samples can be used to analyze your Azure Firewall logs. The sample file is built
in View Designer in Azure Monitor, the View Designer in Azure Monitor article has more information about the
View Design concept.
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.
Azure Monitor logs view

Here's how you can configure an example Azure Monitor logs visualization. You can download the example
visualization from the azure-docs-json-samples repository. The easiest way is to right-click the hyperlink on this
page and choose save as and provide a name like AzureFirewall.omsview .
Execute the following steps to add the view to your Log Analytics workspace:
1. Open the Log Analytics workspace in the Azure portal.
2. Open View Designer below General .
3. Click Impor t .
4. Browse and select the AzureFirewall.omsview file you downloaded before.
5. Click Save .
Here's how the view looks for the application rule log data:
And for the network rule log data:

Azure Firewall logs data below AzureDiagnostics with Category as either AzureFirewallApplicationRule or
AzureFirewallNetworkRule . The data containing the details is stored in the msg_s field. Using the parse
operator we can extract the various interesting properties from the msg_s field. The queries below extract the
information for both categories.
Application rules log data query

The query below parses the application rule log data. In the various comment lines there's some guidance as to
how the query was built:
AzureDiagnostics
//using :int makes it easier to pars but later we'll convert to string as we're not interested to do
mathematical functions on these fields
//this first parse statement is valid for all entries as they all start with this format
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " " TempDetails
//case 1: for records that end with: "was denied. Reason: SNI TLS extension was missing."
| parse TempDetails with "was " Action1 ". Reason: " Rule1
//case 2: for records that end with
//"to ocsp.digicert.com:80. Action: Allow. Rule Collection: RC1. Rule: Rule1"
//"to v10.vortex-win.data.microsoft.com:443. Action: Deny. No rule matched. Proceeding with default action"
| parse TempDetails with "to " FQDN ":" TargetPortInt:int ". Action: " Action2 "." *
//case 2a: for records that end with:
//"to ocsp.digicert.com:80. Action: Allow. Rule Collection: RC1. Rule: Rule1"
| parse TempDetails with * ". Rule Collection: " RuleCollection2a ". Rule:" Rule2a
//case 2b: for records that end with:
//for records that end with: "to v10.vortex-win.data.microsoft.com:443. Action: Deny. No rule matched.
Proceeding with default action"
| parse TempDetails with * "Deny." RuleCollection2b ". Proceeding with" Rule2b
| extend
SourcePort = tostring(SourcePortInt)
|extend
TargetPort = tostring(TargetPortInt)
| extend
//make sure we only have Allowed / Deny in the Action Field
Action1 = case(Action1 == "Deny","Deny","Unknown Action")
| extend
Action = case(Action2 == "",Action1,Action2),
Rule = case(Rule2a == "",case(Rule1 == "",case(Rule2b == "","N/A", Rule2b),Rule1),Rule2a),
RuleCollection = case(RuleCollection2b == "",case(RuleCollection2a == "","No rule
matched",RuleCollection2a),RuleCollection2b),
FQDN = case(FQDN == "", "N/A", FQDN),
TargetPort = case(TargetPort == "", "N/A", TargetPort)
| project TimeGenerated, msg_s, Protocol, SourceIP, SourcePort, FQDN, TargetPort, Action ,RuleCollection, Rule
The same query in a more condensed format:

AzureDiagnostics
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " " TempDetails
| parse TempDetails with "was " Action1 ". Reason: " Rule1
| parse TempDetails with "to " FQDN ":" TargetPortInt:int ". Action: " Action2 "." *
| parse TempDetails with * ". Rule Collection: " RuleCollection2a ". Rule:" Rule2a
| parse TempDetails with * "Deny." RuleCollection2b ". Proceeding with" Rule2b
| extend SourcePort = tostring(SourcePortInt)
| extend TargetPort = tostring(TargetPortInt)
| extend Action1 = case(Action1 == "Deny","Deny","Unknown Action")
| extend Action = case(Action2 == "",Action1,Action2),Rule = case(Rule2a == "", case(Rule1 == "",case(Rule2b
== "","N/A", Rule2b),Rule1),Rule2a),
RuleCollection = case(RuleCollection2b == "",case(RuleCollection2a == "","No rule matched",RuleCollection2a),
RuleCollection2b),FQDN = case(FQDN == "", "N/A", FQDN),TargetPort = case(TargetPort == "", "N/A", TargetPort)
| project TimeGenerated, msg_s, Protocol, SourceIP, SourcePort, FQDN, TargetPort, Action ,RuleCollection, Rule
Network rules log data query

The following query parses the network rule log data. In the various comment lines there's some guidance as to
how the query was built:
AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
//using :int makes it easier to pars but later we'll convert to string as we're not interested to do
mathematical functions on these fields
//case 1: for records that look like this:
//TCP request from 10.0.2.4:51990 to 13.69.65.17:443. Action: Deny//Allow
//UDP request from 10.0.3.4:123 to 51.141.32.51:123. Action: Deny/Allow
//TCP request from 193.238.46.72:50522 to 40.119.154.83:3389 was DNAT'ed to 10.0.2.4:3389
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to
" TargetIP ":" TargetPortInt:int *
//case 1a: for regular network rules
//TCP request from 10.0.2.4:51990 to 13.69.65.17:443. Action: Deny//Allow
//UDP request from 10.0.3.4:123 to 51.141.32.51:123. Action: Deny/Allow
| parse msg_s with * ". Action: " Action1a
//case 1b: for NAT rules
//TCP request from 193.238.46.72:50522 to 40.119.154.83:3389 was DNAT'ed to 10.0.2.4:3389
| parse msg_s with * " was " Action1b " to " NatDestination
//case 2: for ICMP records
//ICMP request from 10.0.2.4 to 10.0.3.4. Action: Allow
| parse msg_s with Protocol2 " request from " SourceIP2 " to " TargetIP2 ". Action: " Action2
| extend
SourcePort = tostring(SourcePortInt),
TargetPort = tostring(TargetPortInt)
| extend
Action = case(Action1a == "", case(Action1b == "",Action2,Action1b), Action1a),
Protocol = case(Protocol == "", Protocol2, Protocol),
SourceIP = case(SourceIP == "", SourceIP2, SourceIP),
TargetIP = case(TargetIP == "", TargetIP2, TargetIP),
//ICMP records don't have port information
SourcePort = case(SourcePort == "", "N/A", SourcePort),
TargetPort = case(TargetPort == "", "N/A", TargetPort),
//Regular network rules don't have a DNAT destination
NatDestination = case(NatDestination == "", "N/A", NatDestination)
| project TimeGenerated, msg_s, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, NatDestination
The same query in a more condensed format:

AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to
" TargetIP ":" TargetPortInt:int *
| parse msg_s with * ". Action: " Action1a
| parse msg_s with * " was " Action1b " to " NatDestination
| extend SourcePort = tostring(SourcePortInt),TargetPort = tostring(TargetPortInt)
| extend Action = case(Action1a == "", case(Action1b == "",Action2,Action1b), Action1a),Protocol =
case(Protocol == "", Protocol2, Protocol),SourceIP = case(SourceIP == "", SourceIP2, SourceIP),TargetIP =
case(TargetIP == "", TargetIP2, TargetIP),SourcePort = case(SourcePort == "", "N/A", SourcePort),TargetPort =
case(TargetPort == "", "N/A", TargetPort),NatDestination = case(NatDestination == "", "N/A", NatDestination)
| project TimeGenerated, msg_s, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, NatDestination
Threat Intelligence log data query

The following query parses the Threat Intelligence rule log data:
AzureDiagnostics
| where OperationName == "AzureFirewallThreatIntelLog"
| parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to " TargetIP ":"
TargetPortInt:int *
| parse msg_s with * ". Action: " Action "." Message
| extend SourcePort = tostring(SourcePortInt),TargetPort = tostring(TargetPortInt)
| extend Protocol = case(Protocol == "", Protocol2, Protocol),SourceIP = case(SourceIP == "", SourceIP2,
SourceIP),TargetIP = case(TargetIP == "", TargetIP2, TargetIP),SourcePort = case(SourcePort == "", "N/A",
SourcePort),TargetPort = case(TargetPort == "", "N/A", TargetPort)
| sort by TimeGenerated desc | project TimeGenerated, msg_s, Protocol,
SourceIP,SourcePort,TargetIP,TargetPort,Action,Message
Sample logs
The following log samples show the data included in a log entry.
Next steps
To learn about Azure Firewall monitoring and diagnostics, see Tutorial: Monitor Azure Firewall logs and metrics.
Monitor logs using Azure Firewall Workbook
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. 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.
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:

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
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, see Template deployment overview.
Consistent management layer

When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It
authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the
requested action. 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.
Resource Manager 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.
declarative syntax - Syntax that lets you state "Here is what I intend to create" without having to write the
sequence of programming commands to create it. The Resource Manager template is an example of declarative
syntax. In the file, you define the properties for the infrastructure to deploy to Azure. See Template deployment
overview.
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 the resource group and all its resources. However, another
resource group doesn't have that policy assignment.
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 creating 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 the 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. 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.
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 Azure Resource Manager
(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 (as well 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 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.
Azure Firewall FAQ

resources. It's a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability.
You can centrally create, enforce, and log application and network connectivity policies across subscriptions and
virtual networks.
What capabilities are supported in Azure Firewall?

To learn about Azure Firewall features, see Azure Firewall features.
What is the typical deployment model for Azure Firewall?

You can deploy Azure Firewall on any virtual network, but customers typically deploy it on a central virtual network
and peer other virtual networks to it in a hub-and-spoke model. You can then set the default route from the peered
virtual networks to point to this central firewall virtual network. Global VNet peering is supported, but it isn't
recommended because of potential performance and latency issues across regions. For best performance, deploy
one firewall per region.
The advantage of this model is the ability to centrally exert control on multiple spoke VNETs across different
subscriptions. There are also cost savings as you don't need to deploy a firewall in each VNet separately. The cost
savings should be measured versus the associate peering cost based on the customer traffic patterns.
How can I install the Azure Firewall?

You can set up Azure Firewall by using the Azure portal, PowerShell, REST API, or by using templates. See Tutorial:
Deploy and configure Azure Firewall using the Azure portal for step-by-step instructions.
What are some Azure Firewall concepts?

Azure Firewall supports rules and rule collections. A rule collection is a set of rules that share the same order and
priority. Rule collections are executed in order of their priority. Network rule collections are higher priority than
application rule collections, and all rules are terminating.
There are three types of rule collections:
Application rules: Configure fully qualified domain names (FQDNs) that can be accessed from a subnet.
Network rules: Configure rules that contain source addresses, protocols, destination ports, and destination
addresses.
NAT rules: Configure DNAT rules to allow incoming Internet connections.
Does Azure Firewall support inbound traffic filtering?

Azure Firewall supports inbound and outbound filtering. Inbound protection is typically used for non-HTTP/S
protocols. For example RDP, SSH, and FTP protocols. For best inbound HTTP/S protection, use a web application
firewall such as Azure Web Application Firewall (WAF).
Which logging and analytics services are supported by the Azure
Firewall?
Azure Firewall is integrated with Azure Monitor for viewing and analyzing firewall logs. Logs can be sent to Log
Analytics, Azure Storage, or Event Hubs. They can be analyzed in Log Analytics or by different tools such as Excel
and Power BI. For more information, see Tutorial: Monitor Azure Firewall logs.
How does Azure Firewall work differently from existing services such as
NVAs in the marketplace?
Azure Firewall is a basic firewall service that can address certain customer scenarios. It's expected that you'll have a
mix of third-party NVAs and Azure Firewall. Working better together is a core priority.
What is the difference between Application Gateway WAF and Azure

Firewall?
The Web Application Firewall (WAF) is a feature of Application Gateway that provides centralized inbound
protection of your web applications from common exploits and vulnerabilities. Azure Firewall provides inbound
protection for non-HTTP/S protocols (for example, RDP, SSH, FTP), outbound network-level protection for all ports
and protocols, and application-level protection for outbound HTTP/S.
What is the difference between Network Security Groups (NSGs) and

Azure Firewall?
The Azure Firewall service complements network security group functionality. Together, they provide better
"defense-in-depth" network security. Network security groups provide distributed network layer traffic filtering to
limit traffic to resources within virtual networks in each subscription. Azure Firewall is a fully stateful, centralized
network firewall as-a-service, which provides network- and application-level protection across different
subscriptions and virtual networks.
Are Network Security Groups (NSGs) supported on the

AzureFirewallSubnet?
Azure Firewall is a managed service with multiple protection layers, including platform protection with NIC level
NSGs (not viewable). Subnet level NSGs aren't required on the AzureFirewallSubnet, and are disabled to ensure no
service interruption.
How do I set up Azure Firewall with my service endpoints?

For secure access to PaaS services, we recommend service endpoints. You can choose to enable service endpoints
in the Azure Firewall subnet and disable them on the connected spoke virtual networks. This way you benefit from
both features: service endpoint security and central logging for all traffic.
What is the pricing for Azure Firewall?

See Azure Firewall Pricing.
How can I stop and start Azure Firewall?

You can use Azure PowerShell deallocate and allocate methods.
For example:
# Stop an existing firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"

$azfw.Deallocate()
# Start a firewall
$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))
NOTE
You must reallocate a firewall and public IP to the original resource group and subscription.
What are the known service limits?

For Azure Firewall service limits, see Azure subscription and service limits, quotas, and constraints.
Can Azure Firewall in a hub virtual network forward and filter network
traffic between two spoke virtual networks?
Yes, you can use Azure Firewall in a hub virtual network to route and filter traffic between two spoke virtual
network. Subnets in each of the spoke virtual networks must have a UDR pointing to the Azure Firewall as a default
gateway for this scenario to work properly.
Can Azure Firewall forward and filter network traffic between subnets in
the same virtual network or peered virtual networks?
Yes. However, configuring the UDRs to redirect traffic between subnets in the same VNET requires additional
attention. While using the VNET address range as a target prefix for the UDR is sufficient, this also routes all traffic
from one machine to another machine in the same subnet through the Azure Firewall instance. To avoid this,
include a route for the subnet in the UDR with a next hop type of VNET . Managing these routes might be
cumbersome and prone to error. The recommended method for internal network segmentation is to use Network
Security Groups, which don't require UDRs.
Does Azure Firewall outbound SNAT between private networks?

Azure Firewall doesn't SNAT when the destination IP address is a private IP range per IANA RFC 1918. 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. You can configure Azure Firewall to not SNAT your public IP
address range. For more information, see Azure Firewall SNAT private IP address ranges.
Is forced tunneling/chaining to a Network Virtual Appliance supported?

Forced tunneling is supported when you create a new firewall. You can't configure an existing firewall for forced
tunneling. For more information, see Azure Firewall forced tunneling.
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.
If your configuration requires forced tunneling to an on-premises network and you can determine the target IP
prefixes for your Internet destinations, you can configure these ranges with the on-premises network as the next
hop via a user defined route on the AzureFirewallSubnet. Or, you can use BGP to define these routes.
Are there any firewall resource group restrictions?

Yes. The firewall, VNet, and the public IP address all must be in the same resource group.
When configuring DNAT for inbound Internet network traffic, do I also

need to configure a corresponding network rule to allow that traffic?
No. NAT rules implicitly add a corresponding network rule to allow the translated traffic. You can override this
behavior by explicitly adding a network rule collection with deny rules that match the translated traffic. To learn
more about Azure Firewall rule processing logic, see Azure Firewall rule processing logic.
How do wildcards work in an application rule target FQDN?

Wildcards currently can only be used on the left side of the FQDN. For example, *.contoso.com and
*contoso.com .
If you configure *.contoso.com , it allows anyvalue.contoso.com, but not contoso.com (the domain apex). If you
want to allow the domain apex, you must explicitly configure it as a target FQDN.
What does Provisioning state: Failed mean?

Whenever a configuration change is applied, Azure Firewall attempts to update all its underlying backend instances.
In rare cases, one of these backend instances may fail to update with the new configuration and the update process
stops with a failed provisioning state. Your Azure Firewall is still operational, but the applied configuration may be
in an inconsistent state, where some instances have the previous configuration where others have the updated rule
set. If this happens, try updating your configuration one more time until the operation succeeds and your Firewall is
in a Succeeded provisioning state.
How does Azure Firewall handle planned maintenance and unplanned

failures?
Azure Firewall consists of several backend nodes in an active-active configuration. For any planned maintenance,
we have connection draining logic to gracefully update nodes. Updates are planned during non-business hours for
each of the Azure regions to further limit risk of disruption. For unplanned issues, we instantiate a new node to
replace the failed node. Connectivity to the new node is typically reestablished within 10 seconds from the time of
the failure.
How does connection draining work?

For any planned maintenance, connection draining logic gracefully updates backend nodes. Azure Firewall waits 90
seconds for existing connections to close. If needed, clients can automatically re-establish connectivity to another
backend node.
Is there a character limit for a firewall name?

Yes. There's a 50 character limit for a firewall name.
Why does Azure Firewall need a /26 subnet size?
Azure Firewall must provision more virtual machine instances as it scales. A /26 address space ensures that the
firewall has enough IP addresses available to accommodate the scaling.
Does the firewall subnet size need to change as the service scales?
No. Azure Firewall doesn't need a subnet bigger than /26.
How can I increase my firewall throughput?

Azure Firewall's initial throughput capacity is 2.5 - 3 Gbps and it scales out to 30 Gbps. It scales out automatically
based on CPU usage and throughput.
How long does it take for Azure Firewall to scale out?

Azure Firewall gradually scales when average throughput or CPU consumption is at 60%. A default deployment
maximum throughput is approximately 2.5 - 3 Gbps and starts to scale out when it reaches 60% of that number.
Scale out takes five to seven minutes.
When performance testing, make sure you test for at least 10 to 15 minutes, and start new connections to take
advantage of newly created Firewall nodes.
Does Azure Firewall allow access to Active Directory by default?

No. Azure Firewall blocks Active Directory access by default. To allow access, configure the AzureActiveDirectory
service tag. For more information, see Azure Firewall service tags.
Can I exclude a FQDN or an IP address from Azure Firewall Threat

Intelligence based filtering?
Yes, you can use Azure PowerShell to do it:
# Add a Threat Intelligence allow list to an Existing Azure Firewall
## Create the allow list with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"

$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
-FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)
## Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG

$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)
Set-AzFirewall -AzureFirewall $fw
Why can a TCP ping and similar tools successfully connect to a target
FQDN even when no rule on Azure Firewall allows that traffic?
A TCP ping isn't actually connecting to the target FQDN. This happens because Azure Firewall's transparent proxy
listens on port 80/443 for outbound traffic. The TCP ping establishes a connection with the firewall, which then
drops the packet and logs the connection. This behavior doesn't have any security impact. However, to avoid
confusion we're investigating potential changes to this behavior.
Are there limits for the number of IP addresses supported by IP

Groups?
Yes. For more information, see Azure subscription and service limits, quotas, and constraints
Can I move an IP Group to another resource group?

No, moving an IP Group to another resource group isn't currently supported.
What is the TCP Idle Timeout for Azure Firewall?

A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if
there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't configurable. If a period of
inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. A
common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more
information, see the .NET examples.
Can I deploy Azure Firewall without a public IP address?

No, currently you must deploy Azure Firewall with a public IP address.
Where does Azure Firewall store customer data?

Azure Firewall doesn't move or store customer data out of the region it's deployed in.
Understand the structure and syntax of ARM templates
This article describes the structure of an Azure Resource Manager (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 Azure Resource Manager template.
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 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 VS 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.
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 Azure Resource Manager templates.
Data types
For integers passed as inline parameters, the range of values may be limited by the SDK or command-line tool you use for
deployment. For example, when using PowerShell to deploy a template, integer types can range from -2147483648 to
2147483647. To avoid this limitation, specify large integer values in a parameter file. Resource types apply their own limits
for integer properties.
When specifying boolean and integer values in your template, don't surround the value with quotation marks. Start and
end string values with double quotation marks.
Objects start with a left brace and end with a right brace. Arrays start with a left bracket and end with a right bracket.
When you set a parameter to a secure string or secure object, the value of the parameter isn't saved to the deployment
history and isn't logged. However, if you set that secure value to a property that isn't expecting a secure value, the value
isn't protected. For example, if you set a secure string to a tag, that value is stored as plain text. Use secure strings for
passwords and secrets.
For samples of formatting data types, see Parameter type formats.
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 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 Azure Resource Manager template.
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 Azure Resource Manager template.
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>"
},
"sku": {
"name": "<sku-name>",
"tier": "<sku-tier>",
"size": "<sku-size>",
"family": "<sku-family>",
"capacity": <sku-capacity>
},
"kind": "<type-of-resource>",
"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
Microsoft.Storage/storageAccounts ).
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. 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 Defining
dependencies in Azure Resource Manager
templates.
tags No Tags that are associated with the resource.

Apply tags to logically organize resources
across your subscription.
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.
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.
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 Azure
Resource Manager templates.
For examples of how to use outputs, see Outputs in Azure Resource Manager template.
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 /* ... */ but this syntax doesn't work with all tools. If you add this style
of comment, be sure the tools you use support inline JSON comments.
NOTE
To deploy templates with comments by using Azure CLI with version 2.3.0 or older, you must use 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.Network/networkInterfaces/', variables('nicName'))]"
],
In Visual Studio Code, the Azure Resource Manager Tools extension can automatically detect Resource Manager template
and change the language mode accordingly. If you see Azure Resource Manager Template at the bottom-right corner
of VS Code, you can use the inline comments. The inline comments are no longer marked as invalid.
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.
{
"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.Network/networkInterfaces/', variables('nicName'))]"
],
To deploy templates with multi-line strings by using Azure CLI with version 2.3.0 or older, you must use the
--handle-extended-json-format switch.
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 Azure Resource Manager Template Functions.
To combine several templates during deployment, see Using linked templates with Azure Resource Manager.
For recommendations about creating templates, see Azure Resource Manager template best practices.
For answers to common questions, see Frequently asked questions about ARM templates.

Azure Firewall

Uploaded by

Copyright:

Available Formats

Azure Firewall

Uploaded by

Document Information

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

What are some of the key features of Azure Firewall?

What are some of the key features of Azure Firewall?

What are some known issues with Azure Firewall?

What are some known issues with Azure Firewall?

Contents

Azure Firewall documentation

ISSUE DESC RIP T IO N M IT IGAT IO N

For Azure SQL IaaS:

If you're using non-standard ports, you

Set-AzFirewall: AzureFirewall FW-xx

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:

Validate the deployment

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

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 2019 Datacenter

Administrator user name Type a user name

Password Type a password

5. Under Inbound por t rules , Public inbound por ts , select None .

Deploy the firewall

Subscription <your subscription>

Resource group Test-FW-RG

Location Select the same location that you used previously

Choose a virtual network Use existing : Test-FW-VN

Public IP address Add new

5. Select Review + create .

Create a default route

Configure a network rule

Configure a DNAT rule

Test the firewall

In this tutorial, you learn how to:

Create the firewall hub virtual network

1. From the Azure portal home page, select Create a resource .

Create the spoke virtual network

Create the on-premises virtual network

Configure and deploy the firewall

Subscription <your subscription>

Resource group FW-Hybrid-Test

Choose a virtual network Use existing :

Public IP address Add new:

4. Select Review + create .

Create and connect the VPN gateways

Create the routes

Create virtual machines

Create the on-premises virtual machine

Test the firewall