Contents

Azure Firewall Manager documentation

Overview
What is Azure Firewall Manager?
Quickstarts
Secure virtual hub - ARM template
Deploy firewall with policy - ARM template
Tutorials
Secure your virtual hub - portal
Secure your virtual hub - PowerShell
Secure your hub virtual network - portal
Concepts
Policy overview
What is a secured virtual hub?
General deployment process
Security partner providers
Secure hubs using Check Point Cloudguard Connect
IP Groups
Rule processing logic
Architecture options
Threat intelligence settings
FQDN in network rules
Security
Security baseline
How-to guides
Deploy security partner providers
Secure private endpoints
Migrate to Firewall policy - PowerShell
DNS settings
Deploy multiple public IPs - PowerShell
 Define a rule hierarchy
Reference
Azure CLI
Azure PowerShell
.NET
Java
Node.js
Python
REST
Azure Resource Manager
Resources
Author templates
Azure Roadmap
Community templates
Pricing
Regional availability
 What is Azure Firewall Manager?
4/29/2021 • 4 minutes to read • Edit Online

Azure Firewall Manager is a security management service that provides central security policy and route
management for cloud-based security perimeters.
Firewall Manager can provide security management for two network architecture types:
Secured vir tual hub
An Azure Virtual WAN Hub is a Microsoft-managed resource that lets you easily create hub and spoke
architectures. When security and routing policies are associated with such a hub, it is referred to as a
secured virtual hub.
Hub vir tual network
This is a standard Azure virtual network that you create and manage yourself. When security policies are
associated with such a hub, it is referred to as a hub virtual network. At this time, only Azure Firewall
Policy is supported. You can peer spoke virtual networks that contain your workload servers and services.
You can also manage firewalls in standalone virtual networks that aren't peered to any spoke.
For a detailed comparison of secured virtual hub and hub virtual network architectures, see What are the Azure
Firewall Manager architecture options?.

Azure Firewall Manager features

Azure Firewall Manager offers the following features:
Central Azure Firewall deployment and configuration
You can centrally deploy and configure multiple Azure Firewall instances that span different Azure regions and
subscriptions.
Hierarchical policies (global and local)
You can use Azure Firewall Manager to centrally manage Azure Firewall policies across multiple secured virtual
hubs. Your central IT teams can author global firewall policies to enforce organization wide firewall policy across
teams. Locally authored firewall policies allow a DevOps self-service model for better agility.
Integrated with third-party security-as-a-service for advanced security
In addition to Azure Firewall, you can integrate third-party security as a service (SECaaS) providers to provide
additional network protection for your VNet and branch Internet connections.
This feature is available only with secured virtual hub deployments.
VNet to Internet (V2I) traffic filtering
Filter outbound virtual network traffic with your preferred third-party security provider.
Leverage advanced user-aware Internet protection for your cloud workloads running on Azure.
Branch to Internet (B2I) traffic filtering
Leverage your Azure connectivity and global distribution to easily add third-party filtering for branch to
Internet scenarios.
For more information about security partner providers, see What are Azure Firewall Manager security partner
providers?
Centralized route management
Easily route traffic to your secured hub for filtering and logging without the need to manually set up User
Defined Routes (UDR) on spoke virtual networks.
This feature is available only with secured virtual hub deployments.
You can use third-party providers for Branch to Internet (B2I) traffic filtering, side by side with Azure Firewall for
Branch to VNet (B2V), VNet to VNet (V2V) and VNet to Internet (V2I).

Region availability
Azure Firewall Policies can be used across regions. For example, you can create a policy in West US, and use it in
East US.

Known issues
Azure Firewall Manager has the following known issues:

ISSUE DESC RIP T IO N M IT IGAT IO N

Traffic splitting Microsoft 365 and Azure Public PaaS Investigating traffic splitting at the
traffic splitting isn't currently hub.
supported. As such, selecting a third-
party provider for V2I or B2I also
sends all Azure Public PaaS and
Microsoft 365 traffic via the partner
service.

One secured virtual hub per region You can't have more than one secured Create multiple virtual WANs in a
virtual hub per region. region.
 ISSUE DESC RIP T IO N M IT IGAT IO N

Base policies must be in same region Create all your local policies in the Investigating
as local policy same region as the base policy. You
can still apply a policy that was created
in one region on a secured hub from
another region.

Filtering inter-hub traffic in secure Secured Virtual Hub to Secured Virtual Investigating
virtual hub deployments Hub communication filtering isn't yet
supported. However, hub to hub
communication still works if private
traffic filtering via Azure Firewall isn't
enabled.

Spokes in different region than the Spokes in different region than the Investigating
virtual hub virtual hub aren't supported.
Create a hub per region and peer
VNets in the same region as the hub.

Branch to branch traffic with private Branch to branch traffic isn't supported Investigating.
traffic filtering enabled when private traffic filtering is enabled.
Don't secure private traffic if branch to
branch connectivity is critical.

All Secured Virtual Hubs sharing the This behavior is aligned with Virtual Create multiple Virtual WANs to allow
same virtual WAN must be in the WAN Hubs today. Secured Virtual Hubs to be created in
same resource group. different resource groups.

Bulk IP address addition fails The secure hub firewall goes into a Add smaller public IP address
failed state if you add multiple public increments. For example, add 10 at a
IP addresses. time.

DDoS Protection Standard not DDoS Protection Standard is not Investigating

supported with secured virtual hubs integrated with vWANs.

Activity logs not fully supported Firewall policy does not currently Investigating
support Activity logs.

Next steps
Review Azure Firewall Manager deployment overview
Learn about secured Virtual Hubs.
 Quickstart: Secure your virtual hub using Azure
Firewall Manager - ARM template
4/15/2021 • 6 minutes to read • Edit Online

In this quickstart, you use an Azure Resource Manager template (ARM template) to secure your virtual hub
using Azure Firewall Manager. The deployed firewall has an application rule that allows connections to
www.microsoft.com . Two Windows Server 2019 virtual machines are deployed to test the firewall. One jump
server is used to connect to the workload server. From the workload server, you can only connect to
www.microsoft.com .

An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for
your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment
without writing the sequence of programming commands to create the deployment.
For more information about Azure Firewall Manager, see What is Azure Firewall Manager?.
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 a secured virtual hub using Azure Firewall Manager, along with the necessary resources to
support the scenario.
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": {
"adminUsername": {
"type": "String",
"metadata": {
"description": "Admin username for the servers"
}
},
"adminPassword": {
"type": "SecureString",
"metadata": {
"description": "Password for the admin account on the servers"
}
},
"location": {
"defaultValue": "[resourceGroup().location]",
"type": "String",
"metadata": {
"description": "Location for all resources."
}
},
 "vmSize": {
"type": "string",
"defaultValue": "Standard_D2_v3",
"metadata": {
"description": "Size of the virtual machine."
}
}
},
"resources": [
{
"type": "Microsoft.Network/virtualWans",
"apiVersion": "2020-06-01",
"name": "VWan-01",
"location": "[parameters('location')]",
"properties": {
"disableVpnEncryption": false,
"allowBranchToBranchTraffic": true,
"office365LocalBreakoutCategory": "None",
"type": "Standard"
}
},
{
"type": "Microsoft.Network/virtualHubs",
"apiVersion": "2020-06-01",
"name": "Hub-01",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualWans', 'VWan-01')]"
],
"properties": {
"addressPrefix": "10.1.0.0/16",
"virtualWan": {
"id": "[resourceId('Microsoft.Network/virtualWans', 'VWan-01')]"
}
}
},
{
"type": "Microsoft.Network/virtualHubs/hubVirtualNetworkConnections",
"apiVersion": "2020-06-01",
"name": "Hub-01/hub-spoke",
"dependsOn": [
"[resourceId('Microsoft.Network/azureFirewalls', 'AzfwTest')]",
"[resourceId('Microsoft.Network/virtualHubs', 'Hub-01')]",
"[resourceId('Microsoft.Network/virtualNetworks', 'Spoke-01')]",
"[resourceId('Microsoft.Network/virtualHubs/hubRouteTables', 'Hub-01', 'RT_VNet')]"
],
"properties": {
"remoteVirtualNetwork": {
"id": "[resourceId('Microsoft.Network/virtualNetworks', 'Spoke-01')]"
},
"allowHubToRemoteVnetTransit": true,
"allowRemoteVnetToUseHubVnetGateways": false,
"enableInternetSecurity": true,
"routingConfiguration": {
"associatedRouteTable": {
"id": "[resourceId('Microsoft.Network/virtualHubs/hubRouteTables', 'Hub-01', 'RT_VNet')]"
},
"propagatedRouteTables": {
"labels": [
"VNet"
],
"ids": [
{
"id": "[resourceId('Microsoft.Network/virtualHubs/hubRouteTables', 'Hub-01', 'RT_VNet')]"
}
]
}
}
}
},
{
"type": "Microsoft.Network/firewallPolicies",
"apiVersion": "2020-06-01",
"name": "Policy-01",
"location": "[parameters('location')]",
"properties": {
"threatIntelMode": "Alert"
}
},
{
"type": "Microsoft.Network/firewallPolicies/ruleCollectionGroups",
"apiVersion": "2020-06-01",
"name": "Policy-01/DefaultApplicationRuleCollectionGroup",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/firewallPolicies', 'Policy-01')]"
],
"properties": {
"priority": 300,
"ruleCollections": [
{
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"name": "RC-01",
"priority": 100,
"action": {
"type": "Allow"
},
"rules": [
{
"ruleType": "ApplicationRule",
"name": "Allow-msft",
"sourceAddresses": [
"*"
],
"protocols": [
{
"port": "80",
"protocolType": "http"
},
{
"port": "443",
"protocolType": "https"
}
],
"targetFqdns": [
"*.microsoft.com"
]
}
]
}
]
}
},
{
"type": "Microsoft.Network/azureFirewalls",
"apiVersion": "2020-06-01",
"name": "AzfwTest",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualHubs', 'Hub-01')]",
"[resourceId('Microsoft.Network/firewallPolicies', 'Policy-01')]"
],
"properties": {
"sku": {
"name": "AZFW_Hub",
"tier": "Standard"
},
"hubIPAddresses": {
 "hubIPAddresses": {
"publicIPs": {
"count": 1
}
},
"virtualHub": {
"id": "[resourceId('Microsoft.Network/virtualHubs', 'Hub-01')]"
},
"firewallPolicy": {
"id": "[resourceId('Microsoft.Network/firewallPolicies', 'Policy-01')]"
}
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-06-01",
"name": "Spoke-01",
"location": "[parameters('location')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"10.0.0.0/16"
]
},
"enableDdosProtection": false,
"enableVmProtection": false
}
},
{
"type": "Microsoft.Network/virtualNetworks/subnets",
"apiVersion": "2020-06-01",
"name": "Spoke-01/Workload-SN",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', 'Spoke-01')]"
],
"properties": {
"addressPrefix": "10.0.1.0/24",
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"type": "Microsoft.Network/virtualNetworks/subnets",
"apiVersion": "2020-06-01",
"name": "Spoke-01/Jump-SN",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks/subnets', 'Spoke-01', 'Workload-SN')]",
"[resourceId('Microsoft.Network/routeTables', 'RT-01')]"
],
"properties": {
"addressPrefix": "10.0.2.0/24",
"routeTable": {
"id": "[resourceId('Microsoft.Network/routeTables','RT-01')]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "Jump-Srv",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', 'netInterface-jump-srv')]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
 },
"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": "Jump-Srv",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVMAgent": true,
"enableAutomaticUpdates": true
},
"allowExtensionOperations": true
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', 'netInterface-jump-srv')]"
}
]
}
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "Workload-Srv",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', 'netInterface-workload-srv')]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"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": "Workload-Srv",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]",
 "adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVMAgent": true,
"enableAutomaticUpdates": true
},
"allowExtensionOperations": true
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', 'netInterface-workload-srv')]"
}
]
}
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "netInterface-workload-srv",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks/subnets', 'Spoke-01','Workload-SN')]",
"[resourceId('Microsoft.Network/networkSecurityGroups', 'nsg-workload-srv')]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'Spoke-01', 'Workload-SN')]"
},
"primary": true,
"privateIPAddressVersion": "IPv4"
}
}
],
"enableAcceleratedNetworking": false,
"enableIPForwarding": false,
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', 'nsg-workload-srv')]"
}
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "netInterface-jump-srv",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', 'publicIP-jump-srv')]",
"[resourceId('Microsoft.Network/virtualNetworks/subnets', 'Spoke-01','Jump-SN')]",
"[resourceId('Microsoft.Network/networkSecurityGroups', 'nsg-jump-srv')]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', 'publicIP-jump-srv')]"
},
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'Spoke-01', 'Jump-SN')]"
},
"primary": true,
"privateIPAddressVersion": "IPv4"
 "privateIPAddressVersion": "IPv4"
}
}
],
"enableAcceleratedNetworking": false,
"enableIPForwarding": false,
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', 'nsg-jump-srv')]"
}
}
},
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "nsg-jump-srv",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "RDP",
"properties": {
"protocol": "TCP",
"sourcePortRange": "*",
"destinationPortRange": "3389",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 300,
"direction": "Inbound"
}
}
]
}
},
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "nsg-workload-srv",
"location": "[parameters('location')]",
"properties": {
}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-06-01",
"name": "publicIP-jump-srv",
"location": "[parameters('location')]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Static",
"idleTimeoutInMinutes": 4
}
},
{
"type": "Microsoft.Network/routeTables",
"apiVersion": "2020-06-01",
"name": "RT-01",
"location": "[parameters('location')]",
"properties": {
"disableBgpRoutePropagation": false,
"routes": [
{
"name": "jump-to-inet",
"properties": {
"addressPrefix": "0.0.0.0/0",
"nextHopType": "Internet"
}
 }
}
]
}
},
{
"type": "Microsoft.Network/virtualHubs/hubRouteTables",
"apiVersion": "2020-06-01",
"name": "Hub-01/RT_VNet",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/azureFirewalls', 'AzfwTest')]"
],
"properties": {
"routes": [
{
"name": "Workload-SNToFirewall",
"destinationType": "CIDR",
"destinations": [
"10.0.1.0/24"
],
"nextHopType": "ResourceId",
"nextHop": "[resourceId('Microsoft.Network/azureFirewalls', 'AzfwTest')]"
},
{
"name": "InternetToFirewall",
"destinationType": "CIDR",
"destinations": [
"0.0.0.0/0"
],
"nextHopType": "ResourceId",
"nextHop": "[resourceId('Microsoft.Network/azureFirewalls', 'AzfwTest')]"
}
],
"labels": [
"VNet"
]
}
}
]
}

Multiple Azure resources are defined in the template:

Microsoft.Network/vir tualWans
Microsoft.Network/vir tualHubs
Microsoft.Network/firewallPolicies
Microsoft.Network/azureFirewalls
Microsoft.Network/vir tualNetworks
Microsoft.Compute/vir tualMachines
Microsoft.Storage/storageAccounts
Microsoft.Network/networkInterfaces
Microsoft.Network/networkSecurityGroups
Microsoft.Network/publicIPAddresses
Microsoft.Network/routeTables

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, a virtual WAN and virtual hub, the network infrastructure, and two virtual machines.

2. In the portal, on the Secured vir tual hubs 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 Review + create and then select Create . The deployment can take 10 minutes or longer to
complete.

Validate the deployment

Now, test the firewall rules to confirm that it works as expected.
1. From the Azure portal, review the network settings for the Workload-Sr v virtual machine and note the
private IP address.
2. Connect a remote desktop to Jump-Sr v virtual machine, and sign in. From there, open a remote desktop
connection to the Workload-Sr v private IP address.
3. Open Internet Explorer and browse to www.microsoft.com .
4. Select OK > Close on the Internet Explorer security alerts.
You should see the Microsoft home page.
5. Browse to www.google.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.

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
Learn about security partner providers
 Quickstart: Create an Azure Firewall and a firewall
policy - ARM template
5/11/2021 • 4 minutes to read • Edit Online

In this quickstart, you use an Azure Resource Manager template (ARM template) to create an Azure Firewall and
a firewall policy. The firewall policy has an application rule that allows connections to www.microsoft.com and a
rule that allows connections to Windows Update using the WindowsUpdate FQDN tag. A network rule allows
UDP connections to a time server at 13.86.101.172.
Also, IP Groups are used in the rules to define the Source IP addresses.
An ARM template is a JavaScript Object Notation (JSON) file that defines the infrastructure and configuration for
your project. The template uses declarative syntax. In declarative syntax, you describe your intended deployment
without writing the sequence of programming commands to create the deployment.
For information about Azure Firewall Manager, see What is Azure Firewall Manager?.
For information about Azure Firewall, see What is Azure Firewall?.
For information about IP Groups, see IP Groups in Azure Firewall.
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 a hub virtual network, along with the necessary resources to support the scenario.
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"
}
},
"firewallName": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Azure Firewall name"
}
},
"numberOfPublicIPAddresses": {
"type": "int",
 "type": "int",
"defaultValue": 2,
"minValue": 1,
"maxValue": 100,
"metadata": {
"description": "Number of public IP addresses for the Azure Firewall"
}
},
"availabilityZones": {
"type": "array",
"defaultValue": [
],
"metadata": {
"description": "Zone numbers e.g. 1,2,3."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"infraipgroup": {
"defaultValue": "[concat(parameters('location'),'-infra-ipgroup','-
',uniqueString(resourceGroup().id))]",
"type": "String"
},
"workloadipgroup": {
"defaultValue": "[concat(parameters('location'),'-workload-ipgroup','-
',uniqueString(resourceGroup().id))]",
"type": "String"
},
"firewallPolicyName": {
"defaultValue": "[concat(parameters('firewallName'),'-','firewallPolicy')]",
"type": "String"
}
},
"variables": {
"vnetAddressPrefix": "10.10.0.0/24",
"azureFirewallSubnetPrefix": "10.10.0.0/25",
"publicIPNamePrefix": "publicIP",
"azurepublicIpname": "[variables('publicIPNamePrefix')]",
"azureFirewallSubnetName": "AzureFirewallSubnet",
"azureFirewallSubnetId": "
[resourceId('Microsoft.Network/virtualNetworks/subnets',parameters('virtualNetworkName'),
variables('azureFirewallSubnetName'))]",
"azureFirewallPublicIpId": "
[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPNamePrefix'))]",
"azureFirewallSubnetJSON": "[json(format('{{\"id\": \"{0}\"}}', variables('azureFirewallSubnetId')))]",
"copy": [
{
"name": "azureFirewallIpConfigurations",
"count": "[parameters('numberOfPublicIPAddresses')]",
"input": {
"name": "[concat('IpConf', copyIndex('azureFirewallIpConfigurations'))]",
"properties": {
"subnet": "[if(equals(copyIndex('azureFirewallIpConfigurations'), 0),
variables('azureFirewallSubnetJSON'), json('null'))]",
"publicIPAddress": {
"id": "[concat(variables('azureFirewallPublicIpId'),
add(copyIndex('azureFirewallIpConfigurations'), 1))]"
}
}
}
}
]
},
"resources": [
{
{
"type": "Microsoft.Network/ipGroups",
"apiVersion": "2019-12-01",
"name": "[parameters('workloadipgroup')]",
"location": "[parameters('location')]",
"properties": {
"ipAddresses": [
"10.20.0.0/24",
"10.30.0.0/24"
]
}
},
{
"type": "Microsoft.Network/ipGroups",
"apiVersion": "2019-12-01",
"name": "[parameters('infraipgroup')]",
"location": "[parameters('location')]",
"properties": {
"ipAddresses": [
"10.40.0.0/24",
"10.50.0.0/24"
]
}
},
{
"name": "[parameters('virtualNetworkName')]",
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/virtualNetworks",
"location": "[parameters('location')]",
"tags": {
"displayName": "[parameters('virtualNetworkName')]"
},
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('azureFirewallSubnetName')]",
"properties": {
"addressPrefix": "[variables('azureFirewallSubnetPrefix')]"
}
}
],
"enableDdosProtection": false
}
},
{
"name": "[concat(variables('azurepublicIpname'), add(copyIndex(), 1))]",
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2019-04-01",
"location": "[parameters('location')]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAllocationMethod": "Static",
"publicIPAddressVersion": "IPv4"
},
"copy": {
"name": "publicIpCopy",
"count": "[parameters('numberOfPublicIPAddresses')]"
}
},
{
"apiVersion": "2020-05-01",
"type": "Microsoft.Network/firewallPolicies",
"name": "[parameters('firewallPolicyName')]",
 "name": "[parameters('firewallPolicyName')]",
"location": "[parameters('location')]",
"properties": {
"threatIntelMode": "Alert"
}
},
{
"type": "Microsoft.Network/firewallPolicies/ruleCollectionGroups",
"apiVersion": "2020-05-01",
"name": "[concat(parameters('firewallPolicyName'), '/DefaultNetworkRuleCollectionGroup')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/ipGroups', parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]",
"[resourceId('Microsoft.Network/firewallPolicies',parameters('firewallPolicyName'))]"
],
"properties" : {
"priority": 200,
"ruleCollections": [
{
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"action": {
"type": "Allow"
},
"name": "azure-global-services-nrc",
"priority": 1250,
"rules": [
{
"ruleType": "NetworkRule",
"name": "time-windows",
"ipProtocols": [
"UDP"
],
"destinationAddresses": [
"13.86.101.172"
],
"sourceIpGroups": [
"[resourceId('Microsoft.Network/ipGroups', parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]"
],
"destinationPorts": [
"123"
]
}
]
}
]
}
},
{
"apiVersion": "2020-05-01",
"type": "Microsoft.Network/firewallPolicies/ruleCollectionGroups",
"name": "[concat(parameters('firewallPolicyName'), '/DefaultApplicationRuleCollectionGroup')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/ipGroups', parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]",
"
[resourceId('Microsoft.Network/firewallPolicies/ruleCollectionGroups',parameters('firewallPolicyName'),
'DefaultNetworkRuleCollectionGroup')]"
],
"properties" : {
"priority": 300,
"ruleCollections": [
{
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"name": "global-rule-url-arc",
"priority": 1000,
"action": {
"type": "Allow"
 "type": "Allow"
},
"rules": [
{
"ruleType": "ApplicationRule",
"name": "winupdate-rule-01",
"protocols": [
{
"protocolType": "Https",
"port": 443
},
{
"protocolType": "Http",
"port": 80
}
],
"fqdnTags": ["WindowsUpdate"],
"terminateTLS": false,
"sourceIpGroups": [
"[resourceId('Microsoft.Network/ipGroups',parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]"
]
}
]
},
{
"ruleCollectionType": "FirewallPolicyFilterRuleCollection",
"action": {
"type": "Allow"
},
"name": "Global-rules-arc",
"priority": 1202,
"rules": [
{
"ruleType": "ApplicationRule",
"name": "gobal-rule-01",
"protocols": [
{
"protocolType": "Https",
"port": 443
}
],
"targetFqdns": [
"www.microsoft.com"
],
"terminateTLS": false,
"sourceIpGroups": [
"[resourceId('Microsoft.Network/ipGroups',parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]"
]
}
]
}
]
}
},
{
"apiVersion": "2019-04-01",
"type": "Microsoft.Network/azureFirewalls",
"name": "[parameters('firewallName')]",
"location": "[parameters('location')]",
"zones": "[if(equals(length(parameters('availabilityZones')), 0), json('null'),
parameters('availabilityZones'))]",
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]",
"publicIpCopy",
"[resourceId('Microsoft.Network/ipGroups', parameters('workloadipgroup'))]",
"[resourceId('Microsoft.Network/ipGroups', parameters('infraipgroup'))]",
"[resourceId('Microsoft.Network/firewallPolicies',parameters('firewallPolicyName'))]",
 "
[resourceId('Microsoft.Network/firewallPolicies/ruleCollectionGroups',parameters('firewallPolicyName'),
'DefaultNetworkRuleCollectionGroup')]",
"
[resourceId('Microsoft.Network/firewallPolicies/ruleCollectionGroups',parameters('firewallPolicyName'),
'DefaultApplicationRuleCollectionGroup')]"
],
"properties": {
"ipConfigurations": "[variables('azureFirewallIpConfigurations')]",
"firewallPolicy":{
"id": "[resourceId('Microsoft.Network/firewallPolicies', parameters('firewallPolicyName'))]"
}
}
}
]
}

Multiple Azure resources are defined in the template:

Microsoft.Network/ipGroups
Microsoft.Network/firewallPolicies
Microsoft.Network/firewallPolicies/ruleCollectionGroups
Microsoft.Network/azureFirewalls
Microsoft.Network/vir tualNetworks
Microsoft.Network/publicIPAddresses

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, a virtual WAN and virtual hub, the network infrastructure, and two virtual machines.

2. In the portal, on the Create a Firewall and FirewallPolicy with Rules and 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 .
Region: Select a region.
Firewall Name: type a name for the firewall.
3. Select Review + create and then select Create . The deployment can take 10 minutes or longer to
complete.

Review deployed resources

After deployment completes, you'll see the following similar resources.
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
Azure Firewall Manager policy overview
 Tutorial: Secure your virtual hub using Azure
Firewall Manager
3/19/2021 • 6 minutes to read • Edit Online

Using Azure Firewall Manager, you can create secured virtual hubs to secure your cloud network traffic destined
to private IP addresses, Azure PaaS, and the Internet. Traffic routing to the firewall is automated, so there's no
need to create user defined routes (UDRs).

Firewall Manager also supports a hub virtual network architecture. For a comparison of the secured virtual hub
and hub virtual network architecture types, see What are the Azure Firewall Manager architecture options?
In this tutorial, you learn how to:
Create the spoke virtual network
Create a secured virtual hub
Connect the hub and spoke virtual networks
Route traffic to your hub
Deploy the servers
Create a firewall policy and secure your hub
Test the firewall

Prerequisites
If you don't have an Azure subscription, create a free account before you begin.

Create a hub and spoke architecture

First, create spoke virtual networks where you can place your servers.
Create two spoke virtual networks and subnets
The two virtual networks will each have a workload server in them and will be protected by the firewall.
1. From the Azure portal home page, select Create a resource .
2. Search for Vir tual network , and select Create .
3. For Subscription , select your subscription.
4. For Resource group , select Create new , and type fw-manager-rg for the name and select OK .
5. For Name , type Spoke-01 .
6. For Region , select (US) East US .
7. Select Next: IP Addresses .
8. For Address space , type 10.0.0.0/16 .
 9. Under Subnet name , select default .
10. For Subnet name , type Workload-01-SN .
11. For Subnet address range , type 10.0.1.0/24 .
12. Select Save .
13. Select Review + create .
14. Select Create .
Repeat this procedure to create another similar virtual network:
Name: Spoke-02
Address space: 10.1.0.0/16
Subnet name: Workload-02-SN
Subnet address range: 10.1.1.0/24
Create the secured virtual hub
Create your secured virtual hub using Firewall Manager.
1. From the Azure portal home page, select All ser vices .
2. In the search box, type Firewall Manager and select Firewall Manager .
3. On the Firewall Manager page, select View secured vir tual hubs .
4. On the Firewall Manager | Secured vir tual hubs page, select Create new secured vir tual hub .
5. For Resource group , select fw-manager-rg .
6. For Region , select East US .
7. For the Secured vir tual hub name , type Hub-01 .
8. For Hub address space , type 10.2.0.0/16 .
9. For the new vWAN name, type Vwan-01 .
10. Leave the Include VPN gateway to enable Trusted Security Par tners check box cleared.
11. Select Next: Azure Firewall .
12. Accept the default Azure Firewall Enabled setting and then select Next: Trusted Security Par tner .
13. Accept the default Trusted Security Par tner Disabled setting, and select Next: Review + create .
14. Select Create .
It takes about 30 minutes to deploy.
You can get the firewall public IP address after the deployment completes.
1. Open Firewall Manager .
2. Select Vir tual hubs .
3. Select hub-01 .
4. Select Public IP configuration .
5. Note the public IP address to use later.
Connect the hub and spoke virtual networks
Now you can peer the hub and spoke virtual networks.
1. Select the fw-manager-rg resource group, then select the Vwan-01 virtual WAN.
2. Under Connectivity , select Vir tual network connections .
 3. Select Add connection .
4. For Connection name , type hub-spoke-01 .
5. For Hubs , select Hub-01 .
6. For Resource group , select fw-manager-rg .
7. For Vir tual network , select Spoke-01 .
8. Select Create .
Repeat to connect the Spoke-02 virtual network: connection name - hub-spoke-02

Deploy the servers

1. On the Azure portal, select Create a resource .
2. Select Windows Ser ver 2016 Datacenter in the Popular list.
3. Enter these values for the virtual machine:

SET T IN G VA L UE

Resource group fw-manager-rg

Virtual machine name Sr v-workload-01

Region (US) East US)

Administrator user name type a user name

Password type a password

4. Under Inbound por t rules , for Public inbound por ts , select None .
5. Accept the other defaults and select Next: Disks .
6. Accept the disk defaults and select Next: Networking .
7. Select Spoke-01 for the virtual network and select Workload-01-SN for the subnet.
8. For Public IP , select None .
9. Accept the other defaults and select Next: Management .
10. Select Disable to disable boot diagnostics. Accept the other defaults and select Review + create .
11. Review the settings on the summary page, and then select Create .
Use the information in the following table to configure another virtual machine named Sr v-Workload-02 . The
rest of the configuration is the same as the Sr v-workload-01 virtual machine.

SET T IN G VA L UE

Virtual network Spoke-02

Subnet Workload-02-SN

After the servers are deployed, select a server resource, and in Networking note the private IP address for each
server.
 Create a firewall policy and secure your hub
A firewall policy defines collections of rules to direct traffic on one or more Secured virtual hubs. You'll create
your firewall policy and then secure your hub.
1. From Firewall Manager, select View Azure Firewall policies .
2. Select Create Azure Firewall Policy .
3. For Resource group , select fw-manager-rg .
4. Under Policy details , for the Name type Policy-01 and for Region select East US .
5. Select Next: DNS Settings .
6. Select Next: TLS Inspection (preview) .
7. Select Next : Rules .
8. On the Rules tab, select Add a rule collection .
9. On the Add a rule collection page, type App-RC-01 for the Name .
10. For Rule collection type , select Application .
11. For Priority , type 100 .
12. Ensure Rule collection action is Allow .
13. For the rule Name type Allow-msft .
14. For the Source type , select IP address .
15. For Source , type * .
16. For Protocol , type http,https .
17. Ensure Destination type is FQDN .
18. For Destination , type *.microsoft.com .
19. Select Add .
Add a DNAT rule so you can connect a remote desktop to the Sr v-Workload-01 virtual machine.
1. Select Add/Rule collection .
2. For Name , type dnat-rdp .
3. For Rule collection type , select DNAT .
4. For Priority , type 100 .
5. For the rule Name type Allow-rdp .
6. For the Source type , select IP address .
7. For Source , type * .
8. For Protocol , select TCP .
9. For Destination Por ts , type 3389 .
10. For Destination Type , select IP Address .
11. For Destination , type the firewall public IP address that you noted previously.
12. For Translated address , type the private IP address for Sr v-Workload-01 that you noted previously.
13. For Translated por t , type 3389 .
14. Select Add .
Add a network rule so you can connect a remote desktop from Sr v-Workload-01 to Sr v-Workload-02 .
1. Select Add a rule collection .
2. For Name , type vnet-rdp .
3. For Rule collection type , select Network .
4. For Priority , type 100 .
5. For Rule collection action , select Allow .
6. For the rule Name type Allow-vnet .
 7. For the Source type , select IP address .
8. For Source , type * .
9. For Protocol , select TCP .
10. For Destination Por ts , type 3389 .
11. For Destination Type , select IP Address .
12. For Destination , type the Sr v-Workload-02 private IP address that you noted previously.
13. Select Add .
14. Select Review + create .
15. Select Create .

Associate policy
Associate the firewall policy with the hub.
1. From Firewall Manager, select Azure Firewall Policies .
2. Select the check box for Policy-01 .
3. Select Manage associations/Associate hubs .
4. Select hub-01 .
5. Select Add .

Route traffic to your hub

Now you must ensure that network traffic gets routed through your firewall.
1. From Firewall Manager, select Vir tual hubs .
2. Select Hub-01 .
3. Under Settings , select Security configuration .
4. Under Internet traffic , select Azure Firewall .
5. Under Private traffic , select Send via Azure Firewall .
6. Select Save .
It takes a few minutes to update the route tables.
7. Verify that the two connections show Azure Firewall secures both Internet and private traffic.

Test the firewall

To test the firewall rules, you'll connect a remote desktop using the firewall public IP address, which is NATed to
Sr v-Workload-01 . From there you'll use a browser to test the application rule and connect a remote desktop
to Sr v-Workload-02 to test the network rule.
Test the application rule
Now, test the firewall rules to confirm that it works as expected.
1. Connect a remote desktop to firewall public IP address, and sign in.
2. Open Internet Explorer and browse to https://www.microsoft.com .
3. Select OK > Close on the Internet Explorer security alerts.
You should see the Microsoft home page.
4. Browse to https://www.google.com .
You should be blocked by the firewall.
So now you've verified that the firewall application rule is working:
You can browse to the one allowed FQDN, but not to any others.
Test the network rule
Now test the network rule.
From Srv-Workload-01, open a remote desktop to the Srv-Workload-02 private IP address.
A remote desktop should connect to Srv-Workload-02.
So now you've verified that the firewall network rule is working:
You can connect a remote desktop to a server located in another virtual network.

Clean up resources
When you are done testing your firewall resources, delete the fw-manager-rg resource group to delete all
firewall-related resources.

Next steps
Learn about trusted security partners
 Tutorial: Secure your virtual hub using Azure
PowerShell
3/29/2021 • 10 minutes to read • Edit Online

In this tutorial, you create a Virtual WAN instance with a Virtual Hub in one region, and you deploy an Azure
Firewall in the Virtual Hub to secure connectivity. In this example, you demonstrate secure connectivity between
Virtual Networks. Traffic between virtual networks and site-to-site, point-to-site, or ExpressRoute branches are
supported by Virtual Secure Hub as well.
In this tutorial, you learn how to:
Deploy the virtual WAN
Deploy Azure Firewall and configure custom routing
Test connectivity

Prerequisites
If you don't have an Azure subscription, create a free account before you begin.
PowerShell 7
This tutorial requires that you run Azure PowerShell locally on PowerShell 7. To install PowerShell 7, see
Migrating from Windows PowerShell 5.1 to PowerShell 7.
Az.Network version 3.2.0
If you have Az.Network version 3.4.0 or later, you'll need to downgrade to use some of the commands in
this tutorial. You can check the version of your Az.Network module with the command
Get-InstalledModule -Name Az.Network . To uninstall the Az.Network module, run
Uninstall-Module -name az.network . To install the Az.Network 3.2.0 module, run
Install-Module az.network -RequiredVersion 3.2.0 -force .

Sign in to Azure
Connect-AzAccount
Select-AzSubscription -Subscription "<sub name>"

Initial Virtual WAN deployment

As a first step, you need to set some variables and create the resource group, the virtual WAN instance, and the
virtual hub:
 # Variable definition
$RG = "vwan-rg"
$Location = "westeurope"
$VwanName = "vwan"
$HubName = "hub1"
# Create Resource Group, Virtual WAN and Virtual Hub
New-AzResourceGroup -Name $RG -Location $Location
$Vwan = New-AzVirtualWan -Name $VwanName -ResourceGroupName $RG -Location $Location -AllowVnetToVnetTraffic
-AllowBranchToBranchTraffic -VirtualWANType "Standard"
$Hub = New-AzVirtualHub -Name $HubName -ResourceGroupName $RG -VirtualWan $Vwan -Location $Location -
AddressPrefix "192.168.1.0/24" -Sku "Standard"

Create two virtual networks and connect them to the hub as spokes:

# Create Virtual Network

$Spoke1 = New-AzVirtualNetwork -Name "spoke1" -ResourceGroupName $RG -Location $Location -AddressPrefix
"10.1.1.0/24"
$Spoke2 = New-AzVirtualNetwork -Name "spoke2" -ResourceGroupName $RG -Location $Location -AddressPrefix
"10.1.2.0/24"
# Connect Virtual Network to Virtual WAN
$Spoke1Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -
Name "spoke1" -RemoteVirtualNetwork $Spoke1
$Spoke2Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -
Name "spoke2" -RemoteVirtualNetwork $Spoke2

At this point, you have a fully functional Virtual WAN providing any-to-any connectivity. To enhance it with
security, you need to deploy an Azure Firewall to each Virtual Hub. Firewall Policies can be used to efficiently
manage the virtual WAN Azure Firewall instance. So a firewall policy is created as well in this example:

# New Firewall Policy

$FWPolicy = New-AzFirewallPolicy -Name "VwanFwPolicy" -ResourceGroupName $RG -Location $Location
# New Firewall Public IP
$AzFWPIPs = New-AzFirewallHubPublicIpAddress -Count 1
$AzFWHubIPs = New-AzFirewallHubIpAddress -PublicIP $AzFWPIPs
# New Firewall
$AzFW = New-AzFirewall -Name "azfw1" -ResourceGroupName $RG -Location $Location `
-VirtualHubId $Hub.Id -FirewallPolicyId $FWPolicy.Id `
-Sku AZFW_Hub -HubIPAddress $AzFWHubIPs

Enabling logging from the Azure Firewall to Azure Monitor is optional, but in this example you use the Firewall
logs to prove that traffic is traversing the firewall:

# Optionally, enable looging of Azure Firewall to Azure Monitor

$LogWSName = "vwan-" + (Get-Random -Maximum 99999) + "-" + $RG
$LogWS = New-AzOperationalInsightsWorkspace -Location $Location -Name $LogWSName -Sku Standard -
ResourceGroupName $RG
Set-AzDiagnosticSetting -ResourceId $AzFW.Id -Enabled $True -Category AzureFirewallApplicationRule,
AzureFirewallNetworkRule -WorkspaceId $LogWS.ResourceId

Deploy Azure Firewall and configure custom routing

Now you have an Azure Firewall in the hub, but you still need to modify routing so the Virtual WAN sends the
traffic from the virtual networks and from the branches through the firewall. You do this in two steps:
1. Configure all virtual network connections (and branch connections if there were any) to propagate to the
None Route Table. The effect of this configuration is that other virtual networks and branches won't learn
their prefixes, and so has no routing to reach them.
2. Now you can insert static routes in the Default Route Table (where all virtual networks and branches are
associated by default), so that all traffic is sent to the Azure Firewall.

NOTE
This is the configuration deployed when securing connectivity from the Azure Portal with Azure Firewall Manager

Start with the first step, to configure your virtual network connections to propagate to the None Route Table:

# Configure Virtual Network connections in hub to propagate to None

$VnetRoutingConfig = $Spoke1Connection.RoutingConfiguration # We take $Spoke1Connection as baseline for
the future vnet config, all vnets will have an identical config
$NoneRT = Get-AzVhubRouteTable -ResourceGroupName $RG -HubName $HubName -Name "noneRouteTable"
$NewPropRT = @{}
$NewPropRT.Add('Id', $NoneRT.id)
$PropRTList = @()
$PropRTList += $NewPropRT
$VnetRoutingConfig.PropagatedRouteTables.Ids = $PropRTList
$VnetRoutingConfig.PropagatedRouteTables.Labels = @()
$Spoke1Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -
Name "spoke1" -RoutingConfiguration $VnetRoutingConfig
$Spoke2Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName $HubName -
Name "spoke2" -RoutingConfiguration $VnetRoutingConfig

Now you can continue with the second step, to add the static routes to the Default route table. In this example,
you apply the default configuration that Azure Firewall Manager would generate when securing connectivity in a
Virtual WAN, but you can change the list of prefixes in the static route to fit your specific requirements:

# Create static routes in default Route table

$AzFWId = $(Get-AzVirtualHub -ResourceGroupName $RG -name $HubName).AzureFirewall.Id
$AzFWRoute = New-AzVHubRoute -Name "private-traffic" -Destination @("0.0.0.0/0", "10.0.0.0/8",
"172.16.0.0/12", "192.168.0.0/16") -DestinationType "CIDR" -NextHop $AzFWId -NextHopType "ResourceId"
$DefaultRT = Update-AzVHubRouteTable -Name "defaultRouteTable" -ResourceGroupName $RG -VirtualHubName
$HubName -Route @($AzFWRoute)

Test connectivity
Now you have a fully operational secure hub. To test connectivity, you need one virtual machine in each spoke
virtual network connected to the hub:
 # Create VMs in spokes for testing
$VMLocalAdminUser = "lab-user"
$VMLocalAdminSecurePassword = ConvertTo-SecureString -AsPlainText -Force
$VMCredential = New-Object System.Management.Automation.PSCredential ($VMLocalAdminUser,
$VMLocalAdminSecurePassword);
$VMSize = "Standard_B2ms"
# Spoke1
$Spoke1 = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "spoke1"
Add-AzVirtualNetworkSubnetConfig -Name "vm" -VirtualNetwork $Spoke1 -AddressPrefix "10.1.1.0/26"
$Spoke1 | Set-AzVirtualNetwork
$VM1 = New-AzVM -Name "spoke1-vm" -ResourceGroupName $RG -Location $Location `
-Image "UbuntuLTS" -credential $VMCredential `
-VirtualNetworkName "spoke1" -SubnetName "vm" -PublicIpAddressName "spoke1-pip"
$NIC1 = Get-AzNetworkInterface -ResourceId $($VM1.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke1VMPrivateIP = $NIC1.IpConfigurations[0].PrivateIpAddress
$Spoke1VMPIP = $(Get-AzPublicIpAddress -ResourceGroupName $RG -Name "spoke1-pip")
# Spoke2
$Spoke2 = Get-AzVirtualNetwork -ResourceGroupName $RG -Name "spoke2"
Add-AzVirtualNetworkSubnetConfig -Name "vm" -VirtualNetwork $Spoke2 -AddressPrefix "10.1.2.0/26"
$Spoke2 | Set-AzVirtualNetwork
$VM2 = New-AzVM -Name "spoke2-vm" -ResourceGroupName $RG -Location $Location `
-Image "UbuntuLTS" -credential $VMCredential `
-VirtualNetworkName "spoke2" -SubnetName "vm" -PublicIpAddressName "spoke2-pip"
$NIC2 = Get-AzNetworkInterface -ResourceId $($VM2.NetworkProfile.NetworkInterfaces[0].Id)
$Spoke2VMPrivateIP = $NIC2.IpConfigurations[0].PrivateIpAddress
$Spoke2VMPIP = $(Get-AzPublicIpAddress -ResourceGroupName $RG -Name "spoke2-pip")

The default configuration in the firewall policy is to drop everything. So you need to configure some rules. Start
with DNAT rules, so that the test virtual machines are accessible over the Firewall's public IP address:

# Adding DNAT rules for virtual machines in the spokes

$AzFWPublicAddress = $AzFW.HubIPAddresses.PublicIPs.Addresses[0].Address
$NATRuleSpoke1 = New-AzFirewallPolicyNatRule -Name "Spoke1SSH" -Protocol "TCP" `
-SourceAddress "*" -DestinationAddress $AzFWPublicAddress -DestinationPort 10001 `
-TranslatedAddress $Spoke1VMPrivateIP -TranslatedPort 22
$NATRuleSpoke2 = New-AzFirewallPolicyNatRule -Name "Spoke2SSH" -Protocol "TCP" `
-SourceAddress "*" -DestinationAddress $AzFWPublicAddress -DestinationPort 10002 `
-TranslatedAddress $Spoke2VMPrivateIP -TranslatedPort 22
$NATCollection = New-AzFirewallPolicyNatRuleCollection -Name "SSH" -Priority 100 `
-Rule @($NATRuleSpoke1, $NATRuleSpoke2) -ActionType "Dnat"
$NATGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "NAT" -Priority 100 -RuleCollection $NATCollection
-FirewallPolicyObject $FWPolicy

Now you can configure some example rules. Define a network rule that allows SSH traffic, plus an application
rule that allows Internet access to the Fully Qualified Domain Name ifconfig.co . This URL returns the source IP
address it sees in the HTTP request:

# Add Network Rule

$SSHRule = New-AzFirewallPolicyNetworkRule -Name PermitSSH -Protocol TCP `
-SourceAddress "10.0.0.0/8" -DestinationAddress "10.0.0.0/8" -DestinationPort 22
$NetCollection = New-AzFirewallPolicyFilterRuleCollection -Name "Management" -Priority 100 -ActionType Allow
-Rule $SSHRule
$NetGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "Management" -Priority 200 -RuleCollection
$NetCollection -FirewallPolicyObject $FWPolicy
# Add Application Rul
$ifconfigRule = New-AzFirewallPolicyApplicationRule -Name PermitIfconfig -SourceAddress "10.0.0.0/8" -
TargetFqdn "ifconfig.co" -Protocol "http:80","https:443"
$AppCollection = New-AzFirewallPolicyFilterRuleCollection -Name "TargetURLs" -Priority 300 -ActionType Allow
-Rule $ifconfigRule
$NetGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "TargetURLs" -Priority 300 -RuleCollection
$AppCollection -FirewallPolicyObject $FWPolicy
Before actually sending any traffic, you can inspect the effective routes of the virtual machines. They should
contain the prefixes learned from the Virtual WAN ( 0.0.0.0/0 plus RFC1918), but not the prefix of the other
spoke:

# Check effective routes in the VM NIC in spoke 1

# Note that 10.1.2.0/24 (the prefix for spoke2) should not appear
Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC1.Name | ft
# Check effective routes in the VM NIC in spoke 2
# Note that 10.1.1.0/24 (the prefix for spoke1) should not appear
Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC2.Name | ft

Now generate traffic from one Virtual Machine to the other, and verify that it's dropped in the Azure Firewall. In
the following SSH commands you need to accept the virtual machines fingerprints, and provide the password
that you defined when you created the virtual machines. In this example, you're going to send five ICMP echo
request packets from the virtual machine in spoke1 to spoke2, plus a TCP connection attempt on port 22 using
the Linux utility nc (with the -vz flags it just sends a connection request and shows the result). You should see
the ping failing, and the TCP connection attempt on port 22 succeeding, since it's allowed by the network rule
you configured previously:

# Connect to one VM and ping the other. It shouldnt work, because the firewall should drop the traffic,
since no rule for ICMP is configured
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "ping $Spoke2VMPrivateIP -c 5"
# Connect to one VM and send a TCP request on port 22 to the other. It should work, because the firewall is
configured to allow SSH traffic (port 22)
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "nc -vz $Spoke2VMPrivateIP 22"

You can also verify Internet traffic. HTTP requests via the utility curl to the FQDN you allowed in the firewall
policy ( ifconfig.co ) should work, but HTTP requests to any other destination should fail (in this example you
test with bing.com ):

# This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP
of the FW
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 ifconfig.co"
# This HTTP request should fail, since the FQDN bing.com is not in any app rule in the firewall policy
ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 bing.com"

The easiest way to verify the packets are dropped by the firewall is to check the logs. Since you configured the
Azure Firewall to send logs to Azure Monitor, you can use the Kusto Query Language to retrieve the relevant
logs from Azure Monitor:

NOTE
It can take around 1 minute for the logs to appear to be sent to Azure Monitor
 # Getting Azure Firewall network rule Logs
$LogWS = Get-AzOperationalInsightsWorkspace -ResourceGroupName $RG
$LogQuery = 'AzureDiagnostics
| where Category == "AzureFirewallNetworkRule"
| where TimeGenerated >= ago(5m)
| 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
| 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),SourcePort = case(SourcePort == "", "N/A", SourcePort),TargetPort
= case(TargetPort == "", "N/A", TargetPort),NatDestination = case(NatDestination == "", "N/A",
NatDestination)
| project TimeGenerated, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, NatDestination, Resource
| take 25 '
$(Invoke-AzOperationalInsightsQuery -Workspace $LogWS -Query $LogQuery).Results | ft

In the previous command you should see different entries:

Your SSH connection being DNAT'ed
Dropped ICMP packets between the VMs in the spokes (10.1.1.4 and 10.1.2.4)
Allowed SSH connections between the VMs in the spokes
Here a sample output produced by the command above:

TimeGenerated Protocol SourceIP SourcePort TargetIP TargetPort Action

NatDestination Resource
------------- -------- -------- ---------- -------- ---------- ------ ------------
-- --------
2020-10-04T20:53:02.41Z TCP 109.125.122.99 62281 51.105.224.44 10001 DNAT'ed 10.1.1.4:22
AZFW1
2020-10-04T20:53:07.045Z TCP 10.1.1.4 35932 10.1.2.4 22 Allow N/A
AZFW1
2020-10-04T20:53:50.119Z TCP 109.125.122.99 62293 51.105.224.44 10001 DNAT'ed 10.1.2.4:22
AZFW1
2020-10-04T20:52:47.475Z TCP 109.125.122.99 62273 51.105.224.44 10001 DNAT'ed 10.1.2.4:22
AZFW1
2020-10-04T20:51:04.682Z TCP 109.125.122.99 62200 51.105.224.44 10001 DNAT'ed 10.1.2.4:22
AZFW1
2020-10-04T20:51:17.031Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A
AZFW1
2020-10-04T20:51:18.049Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A
AZFW1
2020-10-04T20:51:19.075Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A
AZFW1
2020-10-04T20:51:20.097Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A
AZFW1
2020-10-04T20:51:21.121Z ICMP Type=8 10.1.1.4 N/A 10.1.2.4 N/A Deny N/A
AZFW1
2020-10-04T20:52:52.356Z TCP 10.1.1.4 53748 10.1.2.4 22 Allow N/A
AZFW1

If you want to see the logs for the application rules (describing allowed and denied HTTP connections) or change
the way that the logs are displayed, you can try with other KQL queries. You can find some examples in Azure
Monitor logs for Azure Firewall.

Clean up resources
To delete the test environment, you can remove the resource group with all contained objects:
 # Delete resource group and all contained resources
Remove-AzResourceGroup -Name $RG

Next steps
Learn about trusted security partners
 Tutorial: Secure your hub virtual network using
Azure Firewall Manager
3/5/2021 • 13 minutes to read • Edit Online

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.
Using Azure Firewall Manager, you can create a hub virtual network to secure your hybrid network traffic
destined to private IP addresses, Azure PaaS, and the Internet. You can use Azure Firewall Manager to control
network access in a hybrid network using policies that define allowed and denied network traffic.
Firewall Manager also supports a secured virtual hub architecture. For a comparison of the secured virtual hub
and hub virtual network architecture types, see What are the Azure Firewall Manager architecture options?
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.

In this tutorial, you learn how to:

Create a firewall policy
Create the virtual networks
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

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 need a User Defined route (UDR) that
points to the firewall with the Vir tual network gateway route propagation setting disabled. This
option prevents route distribution to the spoke subnets. This prevents learned routes from conflicting
with your UDR.
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.

If you don't have an Azure subscription, create a free account before you begin.

Create a Firewall Policy

1. Sign in to the Azure portal at https://portal.azure.com.
2. In the Azure portal search bar, type Firewall Manager and press Enter .
3. On the Azure Firewall Manager page, select View Azure firewall policies .
 4. Select Create Azure Firewall Policy .
5. Select your subscription, and for Resource group, select Create new and create a resource group named
FW-Hybrid-Test .
6. For the policy name, type Pol-Net01 .
7. For Region, select East US .
8. Select Next : DNS Settings .
9. Select Next : TLS inspection (preview)
10. Select Next:Rules .
11. Select Add a rule collection .
12. For Name , type RCNet01 .
13. For Rule collection type , select Network .
14. For Priority , type 100 .
15. For Action , select Allow .
16. Under Rules , for Name , type AllowWeb .
17. For Source , type 192.168.1.0/24 .
18. For Protocol , select TCP .
19. For Destination Por ts , type 80 .
20. For Destination Type , select IP Address .
21. For Destination , type 10.6.0.0/16 .
22. On the next rule row, enter the following information:
Name: type AllowRDP
Source: type 192.168.1.0/24 .
Protocol, select TCP
Destination Ports, type 3389
Destination Type, select IP Address
 For Destination, type 10.6.0.0/16
23. Select Add .
24. Select Review + Create .
25. Review the details and then select Create .

Create the firewall hub virtual network

NOTE
The size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall FAQ.

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

2. Search for Vir tual network and then select Vir tual network .
3. Select Create .
4. For Subscription , select your subscription.
5. For Resource group , select FW-Hybrid-Test .
6. For Name , type VNet-hub .
7. For Region , select East US .
8. Select Next : IP Addresses .
9. For IPv4 address space , type 10.5.0.0/16 .
10. Under Subnet name , select default .
11. Change the Subnet name to AzureFirewallSubnet . The firewall is in this subnet, and the subnet name
must be AzureFirewallSubnet.
12. For Subnet address range , type 10.5.0.0/26 .
13. Accept the other default settings, and then select Save .
14. Select Review + create .
15. Select Create .

Create the spoke virtual network

1. From the Azure portal home page, select Create a resource .
2. Search for Vir tual network and then select Vir tual network .
3. Select Create .
4. For Subscription , select your subscription.
5. For Resource group , select FW-Hybrid-Test .
6. For Name , type VNet-Spoke .
7. For Region , select East US .
8. Select Next : IP Addresses .
 9. For IPv4 address space , type 10.6.0.0/16 .
10. Under Subnet name , select default .
11. Change the Subnet name to SN-Workload .
12. For Subnet address range , type 10.6.0.0/24 .
13. Accept the other default settings, and then select Save .
14. Select Review + create .
15. Select Create .

Create the on-premises virtual network

1. From the Azure portal home page, select Create a resource .
2. Search for Vir tual network and then select Vir tual network .
3. Select Create .
4. For Subscription , select your subscription.
5. For Resource group , select FW-Hybrid-Test .
6. For Name , type VNet-OnPrem .
7. For Region , select East US .
8. Select Next : IP Addresses .
9. For IPv4 address space , type 192.168.0.0/16 .
10. Under Subnet name , select default .
11. Change the Subnet name to SN-Corp .
12. For Subnet address range , type 192.168.1.0/24 .
13. Accept the other default settings, and then select Save .
14. Select Add Subnet .
15. For Subnet name , type GatewaySubnet .
16. For Subnet address range type 192.168.2.0/24 .
17. Select Add .
18. Select Review + create .
19. Select Create .

Configure and deploy the firewall

When security policies are associated with a hub, it's referred to as a hub virtual network.
Convert the VNet-Hub virtual network into a hub virtual network and secure it with Azure Firewall.
1. In the Azure portal search bar, type Firewall Manager and press Enter .
2. On the Azure Firewall Manager page, under Add security to vir tual networks , select View hub
vir tual networks .
 3. Under Vir tual Networks , select the check box for VNet-hub .
4. Select Manage Security , and then select Deploy a Firewall with Firewall Policy .
5. On the Conver t vir tual networks page, under Firewall Policy , select the check box for Pol-Net01 .
6. Select Next : Review + confirm
7. Review the details and then select Confirm .
This takes a few minutes to deploy.
8. After deployment completes, go to the FW-Hybrid-Test resource group, and select the firewall.
9. Note the Firewall private IP address on the Over view page. You'll use it later when you create the
default route.

Create and connect the VPN gateways

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.
1. From the Azure portal home page, select Create a resource .
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-hub .
5. For Region , select (US) East US .
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
RouteBased VpnType. Creating a VPN gateway can often take 45 minutes or more, depending on the selected
VPN gateway SKU.
1. From the Azure portal home page, select Create a resource .
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 (US) East US .
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. It takes some time to create the connection.
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. For 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. The 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 .

Peer the hub and spoke virtual networks

Now peer the hub and spoke virtual networks.
1. Open the FW-Hybrid-Test resource group and select the VNet-hub virtual network.
2. In the left column, select Peerings .
3. Select Add .
4. Under This vir tual network :

SET T IN G N A M E VA L UE

Peering link name HubtoSpoke

Traffic to remote virtual network Allow (default)

Traffic forwarded from remote virtual network Allow (default)

Virtual network gateway or route server Use this virtual network's gateway

5. Under Remote vir tual network :

SET T IN G N A M E VA L UE

Peering link name SpoketoHub

Virtual network deployment model Resource Manager

Subscription <your subscription>

Virtual network VNet-Spoke

Traffic to remote virtual network Allow (default)

Traffic forwarded from remote virtual network Allow (default)

Virtual network gateway Use the remote virtual network's gateway

6. Select Add .
Create the routes
Next, create a couple routes:
A route from the hub gateway subnet to the spoke subnet through the firewall IP address
 A default route from the spoke subnet through the firewall IP address
1. From the Azure portal home page, select Create a resource .
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.
6. For Region , select East US .
7. For the name, type UDR-Hub-Spoke .
8. Select Review + Create .
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.
1. From the Azure portal home page, select Create a resource .
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.
6. For Region , select East US .
7. For the name, type UDR-DG .
8. For Propagate gateway routes , select No .
9. Select Review + create .
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.
1. From the Azure portal home page, select Create a resource .
2. Under Popular , select Windows Ser ver 2016 Datacenter .
3. Enter these values for the virtual machine:
Resource group - Select FW-Hybrid-Test
Vir tual machine name : VM-Spoke-01
Region - (US) East US
User name : type a user name
Password : type a password
4. Select Next:Disks .
5. Accept the defaults and select Next: Networking .
6. Select VNet-Spoke for the virtual network and the subnet is SN-Workload .
7. For Public inbound por ts , select Allow selected por ts , and then select HTTP (80) , and RDP (3389)
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 .
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.
 1. From the Azure portal home page, select Create a resource .
2. Under Popular , select Windows Ser ver 2016 Datacenter .
3. Enter these values for the virtual machine:
Resource group - Select existing, and then select FW-Hybrid-Test
Vir tual machine name - VM-Onprem
Region - (US) East US
User name : type a user name
Password : type your password
4. Select Next:Disks .
5. Accept the defaults and select Next:Networking .
6. Select VNet-Onprem for virtual network and verify the subnet is SN-Corp .
7. For Public inbound por ts , select Allow selected por ts , and then select RDP (3389)
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 on the VM-Spoke-01 Overview page.
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.
So now you've verified that the firewall rules are working:
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. Open the FW-Hybrid-Test resource group and select the Pol-Net01 firewall policy.
2. Under Settings , select Rule Collections .
3. Select the RCNet01 rule collection.
4. For Rule collection action , select Deny .
5. Select Save .
Close any existing remote desktops and browsers on VM-Onprem before testing the changed rules. After the
rule collection update is complete, run the tests again. They should all fail to connect this time.

Clean up resources
You can keep your firewall resources for further investigation, or if no longer needed, delete the FW-Hybrid-
Test resource group to delete all firewall-related resources.

Next steps
Tutorial: Secure your virtual WAN using Azure Firewall Manager
 Azure Firewall Manager policy overview
3/5/2021 • 2 minutes to read • Edit Online

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. Policies work across regions and subscriptions.

Policy creation and association

A policy can be created and managed in multiple ways, including the Azure portal, REST API, templates, Azure
PowerShell, and CLI.
You can also migrate existing rules from Azure Firewall using the portal or Azure PowerShell to create policies.
For more information, see How to migrate Azure Firewall configurations to Azure Firewall policy.
Policies can be associated with one or more virtual hubs or VNets. The firewall can be in any subscription
associated with your account and in any region.

Hierarchical policies
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 created with non-empty parent policies inherit all rule collections from the parent policy. Network rule
collections inherited from a parent policy are always prioritized above network rule collections defined as part
of a new policy. The same logic also applies to application rule collections. However, network rule collections are
always processed before application rule collections regardless of inheritance.
Threat Intelligence mode is also inherited from the parent policy. You can set your threat Intelligence mode to a
different value to override this behavior, but you can't turn it off. It's only possible to override with a stricter
value. For example, if your parent policy is set to Aler t only , you can configure this local policy to Aler t and
deny .
Like Threat Intelligence mode, the Threat Intelligence allow list is inherited from the parent policy. The child
policy can add additional IP addresses to the allow list.
NAT rule collections aren't inherited because they're specific to a given firewall.
With inheritance, any changes to the parent policy are automatically applied down to associated firewall child
policies.

Traditional rules and policies

Azure Firewall supports both traditional rules and policies. The following table compares policies and rules:

SUB JEC T P O L IC Y RUL ES

Contains NAT, Network, Application rules, NAT, Network, and Application rules,
custom DNS and DNS proxy settings, custom DNS and DNS proxy settings,
IP Groups, and Threat Intelligence IP Groups, and Threat Intelligence
settings (including allow list) settings (including allow list)

Protects Virtual hubs and Virtual Networks Virtual Networks only

Portal experience Central management using Firewall Standalone firewall experience

Manager

Multiple firewall support Firewall Policy is a separate resource Manually export and import rules, or
that can be used across firewalls using third-party management
solutions

Pricing Billed based on firewall association. See Free

Pricing.

Supported deployment mechanisms Portal, REST API, templates, Azure Portal, REST API, templates, PowerShell,
PowerShell, and CLI and CLI.

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.

Next steps
To learn how to deploy an Azure Firewall, see Tutorial: Secure your cloud network with Azure Firewall Manager
using the Azure portal.
 What is a secured virtual hub?
11/2/2020 • 2 minutes to read • Edit Online

A virtual hub is a Microsoft-managed virtual network that enables connectivity from other resources. When a
virtual hub is created from a Virtual WAN in the Azure portal, a virtual hub VNet and gateways (optional) are
created as its components.
A secured virtual hub is an Azure Virtual WAN Hub with associated security and routing policies configured by
Azure Firewall Manager. Use secured virtual hubs to easily create hub-and-spoke and transitive architectures
with native security services for traffic governance and protection.
You can use a secured virtual hub to filter traffic between virtual networks (V2V), virtual networks and branch
offices (B2V) and traffic to the Internet (B2I/V2I). A secured virtual hub provides automated routing. There's no
need to configure your own UDRs (user defined routes) to route traffic through your firewall.
You can choose the required security providers to protect and govern your network traffic, including Azure
Firewall, third-party security as a service (SECaaS) providers, or both. Currently, a secured hub doesn’t support
Branch to Branch (B2B) filtering and filtering across multiple hubs. To learn more, see What is Azure Firewall
Manager?.

Create a secured virtual hub

Using Firewall Manager in the Azure portal, you can either create a new secured virtual hub, or convert an
existing virtual hub that you previously created using Azure Virtual WAN.

Next steps
To create a secured virtual hub and use it to secure and govern a hub and spoke network, see Tutorial: Secure
your cloud network with Azure Firewall Manager using the Azure portal.
 Azure Firewall Manager deployment overview
11/2/2020 • 2 minutes to read • Edit Online

There's more than one way to deploy Azure Firewall Manager, but the following general process is
recommended.

General deployment process

Hub virtual networks
1. Create a firewall policy
Create a new policy
or
Derive a base policy and customize a local policy
or
Import rules from an existing Azure Firewall. Make sure to remove NAT rules from policies that should
be applied across multiple firewalls
2. Create your hub and spoke architecture
Create a Hub Virtual Network using Azure Firewall Manager and peer spoke virtual networks to it
using virtual network peering
or
Create a virtual network and add virtual network connections and peer spoke virtual networks to it
using virtual network peering
3. Select security providers and associate firewall policy. Currently, only Azure Firewall is a supported
provider.
This is done while you create a Hub Virtual Network
or
Convert an existing virtual network to a Hub Virtual Network. It is also possible to convert multiple
virtual networks.
4. Configure User Define Routes to route traffic to your Hub Virtual Network firewall.
Secured virtual hubs
1. Create your hub and spoke architecture
Create a Secured Virtual Hub using Azure Firewall Manager and add virtual network connections.
or
Create a Virtual WAN Hub and add virtual network connections.
2. Select security providers
Done while creating a Secured Virtual Hub.
or
Convert an existing Virtual WAN Hub to Secure Virtual Hub.
3. Create a firewall policy and associate it with your hub
Applicable only if using Azure Firewall.
Third-party security as a service (SECaaS) policies are configured via partners management
experience.
4. Configure route settings to route traffic to your secured hub
Easily route traffic to your secured hub for filtering and logging without User Defined Routes (UDR) on
spoke Virtual Networks using the Secured Virtual Hub Route Setting page.

NOTE
You can't have more than one hub per virtual wan per region. But you can add multiple virtual WANs in the region to
achieve this.
You can't have overlapping IP spaces for hubs in a vWAN.
Your hub VNet connections must be in the same region as the hub.
For more known issues, see What is Azure Firewall Manager?

Convert virtual networks

The following information applies if you convert an existing virtual network to a hub virtual network:
If the virtual network has an existing Azure Firewall, you select a Firewall Policy to associate with the existing
firewall. The firewall provisioning status will be updating while the firewall policy replaces firewall rules.
During the provisioning state, the firewall continues processing traffic and has no downtime. You can import
existing rules to a Firewall Policy using Firewall Manager or Azure PowerShell.
If the virtual network doesn't have an associated Azure Firewall, a firewall is deployed and the Firewall Policy
is associated with the new firewall.

Next steps
Tutorial: Secure your cloud network with Azure Firewall Manager using the Azure portal
 What are security partner providers?
3/30/2021 • 3 minutes to read • Edit Online

Security partner providers in Azure Firewall Manager allow you to use your familiar, best-in-breed, third-party
security as a service (SECaaS) offerings to protect Internet access for your users.
With a quick configuration, you can secure a hub with a supported security partner, and route and filter Internet
traffic from your Virtual Networks (VNets) or branch locations within a region. You can do this with automated
route management, without setting up and managing User Defined Routes (UDRs).
You can deploy secured hubs configured with the security partner of your choice in multiple Azure regions to
get connectivity and security for your users anywhere across the globe in those regions. With the ability to use
the security partner’s offering for Internet/SaaS application traffic, and Azure Firewall for private traffic in the
secured hubs, you can now start building your security edge on Azure that is close to your globally distributed
users and applications.
The supported security partners are Zscaler , Check Point , and iboss .

Key scenarios
You can use the security partners to filter Internet traffic in following scenarios:
Virtual Network (VNet)-to-Internet
Use advanced user-aware Internet protection for your cloud workloads running on Azure.
Branch-to-Internet
 Use your Azure connectivity and global distribution to easily add third-party NSaaS filtering for branch to
Internet scenarios. You can build your global transit network and security edge using Azure Virtual WAN.
The following scenarios are supported:
Two security providers in the hub
VNet/Branch-to-Internet via a security partner provider and the other traffic (spoke-to-spoke, spoke-to-
branch, branch-to-spoke) via Azure Firewall.
Single provider in the hub
All traffic (spoke-to-spoke, spoke-to-branch, branch-to-spoke, VNet/Branch-to-Internet) secured by
Azure Firewall
or
VNet/Branch-to-Internet via security partner provider

Best practices for Internet traffic filtering in secured virtual hubs

Internet traffic typically includes web traffic. But it also includes traffic destined to SaaS applications like
Microsoft 365 and Azure public PaaS services like Azure Storage, Azure Sql, and so on. The following are best
practice recommendations for handling traffic to these services:
Handling Azure PaaS traffic
Use Azure Firewall for protection if your traffic consists mostly of Azure PaaS, and the resource access for
your applications can be filtered using IP addresses, FQDNs, Service tags, or FQDN tags.
Use a third-party partner solution in your hubs if your traffic consists of SaaS application access, or you
need user-aware filtering (for example, for your virtual desktop infrastructure (VDI) workloads) or you
need advanced Internet filtering capabilities.
Handling Microsoft 365 traffic
In globally distributed branch location scenarios, you should redirect Microsoft 365 traffic directly at the branch
before sending the remaining Internet traffic your Azure secured hub.
For Microsoft 365, network latency and performance are critical for successful user experience. To achieve these
goals around optimal performance and user experience, customers must implement Microsoft 365 direct and
local escape before considering routing the rest of Internet traffic through Azure.
Microsoft 365 network connectivity principles call for key Microsoft 365 network connections to be routed
locally from the user branch or mobile device and directly over the Internet into nearest Microsoft network point
of presence.
Furthermore, Microsoft 365 connections are encrypted for privacy and use efficient, proprietary protocols for
performance reasons. This makes it impractical and impactful to subject those connections to traditional
network level security solutions. For these reasons we strongly recommend that customers send Microsoft 365
traffic directly from branches, before sending rest of the traffic through Azure. Microsoft has partnered with
several SD-WAN solution providers, who integrate with Azure and Microsoft 365 and make it easy for
customers to enable Microsoft 365 direct and local Internet breakout. For details, see What is Azure Virtual
WAN?

Next steps
Deploy a security partner offering in a secured hub, using Azure Firewall Manager.
 Secure virtual hubs using Check Point Cloudguard
Connect
11/2/2020 • 2 minutes to read • Edit Online

Check Point CloudGuard Connect is a Trusted Security Partner in Azure Firewall Manager. It protects globally
distributed branch office to Internet (B2I) or virtual network to Internet (V2I) connections with advanced threat
prevention.
With a simple configuration in Azure Firewall Manager, you can route branch hub and virtual network
connections to the Internet through the CloudGuard Connect security as a service (SECaaS). Traffic is protected
in transit from your hub to the Check Point cloud service in IPsec VPN tunnels.
When you enable auto-sync in the Check Point portal, any resource marked as secured in the Azure portal is
automatically secured. You don't have to manage your assets twice. You simply choose to secure them once in
the Azure portal.
Check Point unifies multiple security services under one umbrella. Integrated security traffic is decrypted once
and inspected in a single pass. Application Control, URL Filtering, and Content Awareness (DLP) enforce safe
web use and protect your data. IPS and Antivirus protect users from known network exploits. Anti-Bot blocks
connections to Command and Control servers and alerts you if a host is infected.
Threat Emulation (sandboxing) protects users from unknown and zero-day threats. Check Point SandBlast Zero-
Day Protection is a cloud-hosted sand-boxing technology where files are quickly quarantined and inspected. It
runs in a virtual sandbox to discover malicious behavior before it enters your network. It prevents threats before
the damage is done to save staff valuable time responding to threats.

Deployment example
Watch the following video to see how to deploy Check Point CloudGuard Connect as a trusted Azure security
partner.

Next steps
Deploy a security partner provider
 IP Groups in Azure Firewall policy
3/9/2021 • 2 minutes to read • Edit Online

IP Groups allow you to group and manage IP addresses for Azure Firewall policy in the following ways:
As a source type in DNAT rules
As a source or destination type in network rules
As a source type 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 a
policy with DNAT, application, or network rules.

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-AzFirewallPolicyNetworkRule
New-AzFirewallPolicyApplicationRule
New-AzFirewallPolicyNatRule

Next steps
Tutorial: Secure your virtual WAN using Azure Firewall Manager
 Azure Firewall rule processing logic
11/2/2020 • 2 minutes to read • Edit Online

Azure Firewall has NAT rules, network rules, and applications rules. The rules are processed according to the rule
type.

Network rules and applications rules

Network rules are applied first, then application rules. The rules are terminating. So if a match is found in
network rules, then application rules aren't processed. If no network rule matches, and if the packet protocol is
HTTP/HTTPS, the packet is then evaluated by the application rules. If still no match is found, then the packet is
evaluated against the infrastructure rule collection. If there's still no match, then the packet is denied by default.

NAT rules
Inbound 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. DNAT rules are
applied first. 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. No application rules are applied for these connections.

Inherited rules
Network rule collections inherited from a parent policy are always prioritized above network rule collections
that are defined as part of your new policy. The same logic also applies to application rule collections. However,
network rule collections are always processed before application rule collections regardless of inheritance.
By default, your policy inherits its parent policy threat intelligence mode. You can override this by setting your
threat Intelligence mode to a different value in the policy settings page. It's only possible to override with a
stricter value. For example, if you parent policy is set to Alert only, you can configure this local policy to Alert
and deny, but you can't turn it off.

Next steps
Learn more about Azure Firewall Manager
 What are the Azure Firewall Manager architecture
options?
11/2/2020 • 2 minutes to read • Edit Online

Azure Firewall Manager can provide security management for two network architecture types:
secured vir tual hub
An Azure Virtual WAN Hub is a Microsoft-managed resource that lets you easily create hub and spoke
architectures. When security and routing policies are associated with such a hub, it's referred to as a
secured virtual hub.
hub vir tual network
This is a standard Azure virtual network that you create and manage yourself. When security policies are
associated with such a hub, it is referred to as a hub virtual network. At this time, only Azure Firewall
Policy is supported. You can peer spoke virtual networks that contain your workload servers and services.
You can also manage firewalls in standalone virtual networks that are not peered to any spoke.

Comparison
The following table compares these two architecture options and can help you decide which one is right for your
organization's security requirements:

H UB VIRT UA L N ET W O RK SEC URED VIRT UA L H UB

Underlying resource Virtual network Virtual WAN Hub

Hub & Spoke Uses Virtual network peering Automated using hub virtual network
connection

On-prem connectivity VPN Gateway up to 10 Gbps and 30 More scalable VPN Gateway up 20
S2S connections; ExpressRoute Gbps and 1000 S2S connections;
Express Route

Automated branch connectivity Not supported Supported

using SDWAN

Hubs per region Multiple Virtual Networks per region Single Virtual Hub per region. Multiple
hubs possible with multiple Virtual
WANs

Azure Firewall – multiple public Customer provided Auto generated

IP addresses

Azure Firewall Availability Zones Supported Not yet available

Advanced Internet security with Customer established and managed Automated via security partner
third-par ty Security as a Ser vice VPN connectivity to partner service of provider flow and partner
par tners choice management experience
 H UB VIRT UA L N ET W O RK SEC URED VIRT UA L H UB

Centralized route management to Customer-managed User Defined Supported using BGP

route traffic to the hub Route

Multiple security provider Supported with manually configured Automated support for two security
suppor t forced tunneling to third-party providers: Azure Firewall for private
firewalls traffic filtering and third party for
Internet filtering

Web Application Firewall on Supported in Virtual Network Currently supported in spoke network
Application Gateway

Network Vir tual Appliance Supported in Virtual Network Currently supported in spoke network

Azure DDoS Protection Standard Yes No

suppor t

Next steps
Review Azure Firewall Manager deployment overview
Learn about secured Virtual Hubs.
 Azure Firewall threat intelligence configuration
3/5/2021 • 2 minutes to read • Edit Online

Threat intelligence-based filtering can be configured for your Azure Firewall policy to alert and deny traffic from
and 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 configured threat intelligence-based filtering, the associated rules are processed before any of the NAT
rules, network rules, or application rules.

Threat intelligence mode

You can configure threat intelligence in one of the three modes that are described in the following table. By
default, threat intelligence-based filtering is enabled in alert mode.

M O DE DESC RIP T IO N

Off The threat intelligence feature is not enabled for your

firewall.

Alert only You will receive high-confidence alerts for traffic going
through your firewall to or from known malicious IP
addresses and domains.

Alert and deny Traffic is blocked and you will receive high-confidence alerts
when traffic is detected attempting to go through your
firewall to or from known malicious IP addresses and
domains.

NOTE
Threat intelligence mode is inherited from parent policies to child policies. A child policy must be configured with the same
or a stricter mode than the parent policy.
Allowlist addresses
Threat intelligence might trigger false positives and block traffic that actually is valid. You can configure a list of
allowed IP addresses so that threat intelligence won't filter any of the addresses, ranges, or subnets that you
specify.

You can update the allowlist with multiple entries at once by uploading a CSV file. The CSV file can only contain
IP addresses and ranges. The file can't contain headings.

NOTE
Threat intelligence allowlist addresses are inherited from parent policies to child policies. Any IP address or range added to
a parent policy will apply for all child policies as well.

Logs
The following log excerpt shows a triggered rule for outbound traffic to a malicious site:

{
"category": "AzureFirewallNetworkRule",
"time": "2018-04-16T23:45:04.8295030Z",
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWAL
LS/{resourceName}",
"operationName": "AzureFirewallThreatIntelLog",
"properties": {
"msg": "HTTP request from 10.0.0.5:54074 to somemaliciousdomain.com:80. Action: Alert. ThreatIntel:
Bot Networks"
}
}

Testing
Outbound testing - Outbound traffic alerts should be a rare occurrence, as it means that your
environment has been compromised. To help test outbound alerts are working, a test FQDN has been
created that triggers an alert. Use testmaliciousdomain.eastus.cloudapp.azure.com for your
outbound tests.
Inbound testing - You can expect to see alerts on incoming traffic if DNAT rules are configured on the
firewall. This is true even if only specific sources are allowed on the DNAT rule and traffic is otherwise
denied. Azure Firewall doesn't alert on all known port scanners; only on scanners that are known to also
engage in malicious activity.

Next steps
Review the Microsoft Security intelligence report
 FQDN filtering in network rules (preview)
11/2/2020 • 2 minutes to read • Edit Online

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 policy DNS settings
(preview).

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
 Deploy a security partner provider
3/31/2021 • 4 minutes to read • Edit Online

Security partner providers in Azure Firewall Manager allow you to use your familiar, best-in-breed third-party
security-as-a-service (SECaaS) offerings to protect Internet access for your users.
To learn more about supported scenarios and best practice guidelines, see What are security partner providers?
Integrated third-party Security as a service (SECaaS) partners are now available:
Zscaler
Check Point
iboss

Deploy a third-party security provider in a new hub

Skip this section if you are deploying a third-party provider into an existing hub.
1. Sign in to the Azure portal at https://portal.azure.com.
2. In Search , type Firewall Manager and select it under Ser vices .
3. Navigate to Getting Star ted . Select View secured vir tual hubs .
4. Select Create new secured vir tual hub .
5. Enter you subscription and resource group, select a supported region, and add your hub and virtual WAN
information.
6. Select Include VPN gateway to enable Security Par tner Providers .
7. Select the Gateway scale units appropriate for your requirements.
8. Select Next: Azure Firewall

NOTE
Security partner providers connect to your hub using VPN Gateway tunnels. If you delete the VPN Gateway, the
connections to your security partner providers are lost.

9. If you want to deploy Azure Firewall to filter private traffic along with third-party service provider to filter
Internet traffic, select a policy for Azure Firewall. See the supported scenarios.
10. If you want to only deploy a third-party security provider in the hub, select Azure Firewall:
Enabled/Disabled to set it to Disabled .
11. Select Next: Security Par tner Provider .
12. Set Security Par tner Provider to Enabled .
13. Select a partner.
14. Select Next: Review + create .
15. Review the content and then select Create .
The VPN gateway deployment can take more than 30 minutes.
To verify that the hub has been created, navigate to Azure Firewall Manager->Secured Hubs. Select the hub-
>Overview page to show the partner name and the status as Security Connection Pending .
Once the hub is created and the security partner is set up, continue on to connect the security provider to the
hub.
Deploy a third-party security provider in an existing hub
You can also select an existing hub in a Virtual WAN and convert that to a secured virtual hub.
1. In Getting Star ted , select View secured vir tual hubs .
2. Select Conver t existing hubs .
3. Select a subscription and an existing hub. Follow rest of the steps to deploy a third-party provider in a new
hub.
Remember that a VPN gateway must be deployed to convert an existing hub to secured hub with third-party
providers.

Configure third-party security providers to connect to a secured hub

To set up tunnels to your virtual hub’s VPN Gateway, third-party providers need access rights to your hub. To do
this, associate a service principal with your subscription or resource group, and grant access rights. You then
must give these credentials to the third party using their portal.
Create and authorize a service principal
1. Create Azure Active Directory (AD) service principal: You can skip the redirect URL.
How to: Use the portal to create an Azure AD application and service principal that can access resources
2. Add access rights and scope for the service principal. How to: Use the portal to create an Azure AD
application and service principal that can access resources

NOTE
You can limit access to only your resource group for more granular control.

Visit partner portal

1. Follow your partner provided instructions to complete the setup. This includes submitting AAD
information to detect and connect to the hub, update the egress policies, and check connectivity status
and logs.
Zscaler: Configure Microsoft Azure Virtual WAN integration.
Check Point: Configure Microsoft Azure Virtual WAN integration.
iboss: Configure Microsoft Azure Virtual WAN integration.
2. You can look at the tunnel creation status on the Azure Virtual WAN portal in Azure. Once the tunnels
show connected on both Azure and the partner portal, continue with the next steps to set up routes to
select which branches and VNets should send Internet traffic to the partner.

Configure security with Firewall Manager

1. Browse to the Azure Firewall Manager -> Secured Hubs.
2. Select a hub. The hub status should now show Provisioned instead of Security Connection Pending .
Ensure the third-party provider can connect to the hub. The tunnels on the VPN gateway should be in a
Connected state. This state is more reflective of the connection health between the hub and the third-
party partner, compared to previous status.
3. Select the hub, and navigate to Security Configurations .
When you deploy a third-party provider into the hub, it converts the hub into a secured virtual hub. This
ensures that the third-party provider is advertising a 0.0.0.0/0 (default) route to the hub. However, VNet
 connections and sites connected to the hub don’t get this route unless you opt-in on which connections
should get this default route.
4. Configure virtual WAN security by setting Internet Traffic via Azure Firewall and Private Traffic via a
trusted security partner. This automatically secures individual connections in the Virtual WAN.

5. Additionally, if your organization uses public IP ranges in virtual networks and branch offices, you need to
specify those IP prefixes explicitly using Private Traffic Prefixes . The public IP address prefixes can be
specified individually or as aggregates.

Branch or VNet Internet traffic via third-party service

Next, you can check if VNet virtual machines or the branch site can access the Internet and validate that the
traffic is flowing to the third-party service.
After finishing the route setting steps, the VNet virtual machines as well as the branch sites are sent a 0/0 to the
third-party service route. You can't RDP or SSH into these virtual machines. To sign in, you can deploy the Azure
Bastion service in a peered VNet.

Next steps
Tutorial: Secure your cloud network with Azure Firewall Manager using the Azure portal
 Secure traffic destined to private endpoints in Azure
Virtual WAN
4/9/2021 • 6 minutes to read • Edit Online

NOTE
This article applies to secured virtual hub only. If you want to inspect traffic destined to private endpoints using Azure
Firewall in a hub virtual network, see Use Azure Firewall to inspect traffic destined to a private endpoint.

Azure Private Endpoint is the fundamental building block for Azure Private Link. Private endpoints enable Azure
resources deployed in a virtual network to communicate privately with private link resources.
Private endpoints allow resources access to the private link service deployed in a virtual network. Access to the
private endpoint through virtual network peering and on-premises network connections extend the connectivity.
You may need to filter traffic from clients either on premises or in Azure destined to services exposed via private
endpoints in a Virtual WAN connected virtual network. This article walks you through this task using secured
virtual hub with Azure Firewall as the security provider.
Azure Firewall filters traffic using any of the following methods:
FQDN in network rules for TCP and UDP protocols
FQDN in application rules for HTTP, HTTPS, and MSSQL.
Source and destination IP addresses, port, and protocol using network rules
Use application rules over network rules to inspect traffic destined to private endpoints. A secured virtual hub is
managed by Microsoft and it cannot be linked to a Private DNS Zone. This is required to resolve a private link
resource FQDN to its corresponding private endpoint IP address.
SQL FQDN filtering is supported in proxy-mode only (port 1433). 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 FQDN in firewall network rules.

Filter traffic using FQDN in network and application rules

The following steps enable Azure Firewall to filter traffic using FQDN in network and application rules:
1. Deploy a DNS forwarder virtual machine in a virtual network connected to the secured virtual hub and
linked to the Private DNS Zones hosting the A record types for the private endpoints.
2. Configure custom DNS settings to point to the DNS forwarder virtual machine IP address and enable
DNS proxy in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub.
3. Configure custom DNS servers for the virtual networks connected to the secured virtual hub to point to
the private IP address associated with the Azure Firewall deployed in the secured virtual hub.
4. Configure on premises DNS servers to forward DNS queries for the private endpoints public DNS zones
to the private IP address associated with the Azure Firewall deployed in the secured virtual hub.
5. Configure an application rule or network rule as necessary in the firewall policy associated with the Azure
Firewall deployed in the secured virtual hub with Destination Type FQDN and the private link resource
public FQDN as Destination.
6. Navigate to Secured virtual hubs in the firewall policy associated with the Azure Firewall deployed in the
secured virtual hub and select the secured virtual hub where traffic filtering destined to private endpoints
will be configured.
7. Navigate to Security configuration , select Send via Azure Firewall under Private traffic .
8. Select Private traffic prefixes to edit the CIDR prefixes that will be inspected via Azure Firewall in
secured virtual hub and add one /32 prefix for each private endpoint as follows:

IMPORTANT
If these /32 prefixes are not configured, traffic destined to private endpoints will bypass Azure Firewall.

These steps only work when the clients and private endpoints are deployed in different virtual networks
connected to the same secured virtual hub and for on premises clients. If the clients and private endpoints are
deployed in the same virtual network, a UDR with /32 routes for the private endpoints must be created.
Configure these routes with Next hop type set to Vir tual appliance and Next hop address set to the
private IP address of the Azure Firewall deployed in the secured virtual hub. Propagate gateway routes must
be set to Yes .
The following diagram illustrates the DNS and data traffic flows for the different clients to connect to a private
endpoint deployed in Azure virtual WAN:
Troubleshooting
The main problems that you might have when you attempt to filter traffic destined to private endpoints via
secured virtual hub are:
Clients are unable to connect to private endpoints.
Azure Firewall is bypassed. This symptom can be validated by the absence of network or application rules
log entries in Azure Firewall.
In most cases, these problems are caused by one of the following issues:
Incorrect DNS name resolution
Incorrect routing configuration
Incorrect DNS name resolution
1. Verify the virtual network DNS servers are set to Custom and the IP address is the private IP address of
Azure Firewall in secured virtual hub.
Azure CLI:

az network vnet show --name <VNET Name> --resource-group <Resource Group Name> --query
"dhcpOptions.dnsServers"

2. Verify clients in the same virtual network as the DNS forwarder virtual machine can resolve the private
endpoint public FQDN to its corresponding private IP address by directly querying the virtual machine
configured as DNS forwarder.
Linux:
 dig @<DNS forwarder VM IP address> <Private endpoint public FQDN>

3. Inspect AzureFirewallDNSProxy Azure Firewall log entries and validate it can receive and resolve DNS
queries from the clients.

AzureDiagnostics
| where Category contains "DNS"
| where msg_s contains "database.windows.net"

4. Verify DNS proxy has been enabled and a Custom DNS server pointing to the IP address of the DNS
forwarder virtual machine IP address has been configured in the firewall policy associated with the Azure
Firewall in the secured virtual hub.
Azure CLI:

az network firewall policy show --name <Firewall Policy> --resource-group <Resource Group Name> --
query dnsSettings

Incorrect routing configuration

1. Verify Security configuration in the firewall policy associated with the Azure Firewall deployed in the
secured virtual hub. Make sure under the PRIVATE TRAFFIC column it shows as Secured by Azure
Firewall for all the virtual network and branches connections you want to filter traffic for.

2. Verify Security configuration in the firewall policy associated with the Azure Firewall deployed in the
secured virtual hub. Make sure there's a /32 entry for each private endpoint private IP address you want
to filter traffic for under Private traffic prefixes .
3. In the secured virtual hub under virtual WAN, inspect effective routes for the route tables associated with
the virtual networks and branches connections you want to filter traffic for. Make sure there are /32
entries for each private endpoint private IP address you want to filter traffic for.

4. Inspect the effective routes on the NICs attached to the virtual machines deployed in the virtual networks
you want to filter traffic for. Make sure there are /32 entries for each private endpoint private IP address
you want to filter traffic for.
Azure CLI:

az network nic show-effective-route-table --name <Network Interface Name> --resource-group <Resource

Group Name> -o table

5. Inspect the routing tables of your on premises routing devices. Make sure you're learning the address
spaces of the virtual networks where the private endpoints are deployed.
Azure virtual WAN doesn't advertise the prefixes configured under Private traffic prefixes in firewall
policy Security configuration to on premises. It's expected that the /32 entries won't show in the
routing tables of your on premises routing devices.
6. Inspect AzureFirewallApplicationRule and AzureFirewallNetworkRule Azure Firewall logs. Make
sure traffic destined to the private endpoints is being logged.
AzureFirewallNetworkRule log entries don't include FQDN information. Filter by IP address and port
when inspecting network rules.
 When filtering traffic destined to Azure Files private endpoints, AzureFirewallNetworkRule log entries
will only be generated when a client first mounts or connects to the file share. Azure Firewall won't
generate logs for CRUD operations for files in the file share. This is because CRUD operations are carried
over the persistent TCP channel opened when the client first connects or mounts to the file share.
Application rule log query example:

AzureDiagnostics
| where msg_s contains "database.windows.net"
| where Category contains "ApplicationRule"

Next steps
Use Azure Firewall to inspect traffic destined to a private endpoint
 Migrate Azure Firewall configurations to Azure
Firewall policy using Powershell
3/19/2021 • 3 minutes to read • Edit Online

You can use an Azure PowerShell script to migrate existing Azure Firewall configurations to an Azure Firewall
policy resource. You can then use Azure Firewall Manager to deploy the policy.
The AZFWMigrationScript.ps1 script creates a FirewallPolicy with three RuleCollectionGroup objects for
ApplicationRuleCollections, NetworkRuleCollections, and NatRuleCollections respectively.
A RuleCollectionGroup is a new top-level grouping for rule collections for future extensibility. Using the above
defaults is recommended and is done automatically from the Portal.
The beginning of the script defines the source firewall name and resource group and the target policy name and
location. Change these values as appropriate for your organization.

Migration script
Modify the following script to migrate your firewall configuration.

#Input params to be modified as needed

$FirewallResourceGroup = "AzFWMigrateRG"
$FirewallName = "azfw"
$FirewallPolicyName = "fwpolicy"
$FirewallPolicyLocation = "WestEurope"

$DefaultAppRuleCollectionGroupName = "ApplicationRuleCollectionGroup"
$DefaultNetRuleCollectionGroupName = "NetworkRuleCollectionGroup"
$DefaultNatRuleCollectionGroupName = "NatRuleCollectionGroup"
$ApplicationRuleGroupPriority = 300
$NetworkRuleGroupPriority = 200
$NatRuleGroupPriority = 100

#Helper functions for tanslatating ApplicationProtocol and ApplicationRule

Function GetApplicationProtocolsString
{
Param([Object[]] $Protocols)
$output = ""
ForEach ($protocol in $Protocols) {
$output += $protocol.ProtocolType + ":" + $protocol.Port + ","
}
return $output.Substring(0, $output.Length - 1)
}

Function GetApplicationRuleCmd
{
Param([Object] $ApplicationRule)

$cmd = "New-AzFirewallPolicyApplicationRule"
$cmd = $cmd + " -Name " + $ApplicationRule.Name
$cmd = $cmd + " -SourceAddress " + $ApplicationRule.SourceAddresses

if ($ApplicationRule.Description) {
$cmd = $cmd + " -Description " + $ApplicationRule.Description
}
if ($ApplicationRule.TargetFqdns) {
$protocols = GetApplicationProtocolsString($ApplicationRule.Protocols)
$cmd = $cmd + " -Protocol " + $protocols
$cmd = $cmd + " -TargetFqdn " + $ApplicationRule.TargetFqdns
 $cmd = $cmd + " -TargetFqdn " + $ApplicationRule.TargetFqdns
}
if ($ApplicationRule.FqdnTags) {
$cmd = $cmd + " -FqdnTag " + $ApplicationRule.FqdnTags
}

return $cmd
}

If(!(Get-AzResourceGroup -Name $FirewallResourceGroup))

{
New-AzResourceGroup -Name $FirewallResourceGroup -Location $FirewallPolicyLocation
}

$azfw = Get-AzFirewall -Name $FirewallName -ResourceGroupName $FirewallResourceGroup

Write-Host "creating empty firewall policy"
$fwp = New-AzFirewallPolicy -Name $FirewallPolicyName -ResourceGroupName $FirewallResourceGroup -Location
$FirewallPolicyLocation -ThreatIntelMode $azfw.ThreatIntelMode
Write-Host $fwp.Name "created"
Write-Host "creating " $azfw.ApplicationRuleCollections.Count " application rule collections"

#Translate ApplicationRuleCollection
If ($azfw.ApplicationRuleCollections.Count -gt 0) {
$firewallPolicyAppRuleCollections = @()
ForEach ($appRc in $azfw.ApplicationRuleCollections) {
If ($appRc.Rules.Count -gt 0) {
Write-Host "creating " $appRc.Rules.Count " application rules for collection " $appRc.Name
$firewallPolicyAppRules = @()
ForEach ($appRule in $appRc.Rules) {
$cmd = GetApplicationRuleCmd($appRule)
$firewallPolicyAppRule = Invoke-Expression $cmd
Write-Host "Created appRule " $firewallPolicyAppRule.Name
$firewallPolicyAppRules += $firewallPolicyAppRule
}
$fwpAppRuleCollection = New-AzFirewallPolicyFilterRuleCollection -Name $appRC.Name -Priority
$appRC.Priority -ActionType $appRC.Action.Type -Rule $firewallPolicyAppRules
Write-Host "Created appRuleCollection " $fwpAppRuleCollection.Name
}
$firewallPolicyAppRuleCollections += $fwpAppRuleCollection
}
$appRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name $DefaultAppRuleCollectionGroupName -Priority
$ApplicationRuleGroupPriority -RuleCollection $firewallPolicyAppRuleCollections -FirewallPolicyObject $fwp
Write-Host "Created ApplicationRuleCollectionGroup " $appRuleGroup.Name
}

#Translate NetworkRuleCollection
Write-Host "creating " $azfw.NetworkRuleCollections.Count " network rule collections"
If ($azfw.NetworkRuleCollections.Count -gt 0) {
$firewallPolicyNetRuleCollections = @()
ForEach ($rc in $azfw.NetworkRuleCollections) {
If ($rc.Rules.Count -gt 0) {
Write-Host "creating " $rc.Rules.Count " network rules for collection " $rc.Name
$firewallPolicyNetRules = @()
ForEach ($rule in $rc.Rules) {
If($rule.SourceAddresses){
If($rule.DestinationAddresses)
{
$firewallPolicyNetRule = New-AzFirewallPolicyNetworkRule -Name $rule.Name -
SourceAddress $rule.SourceAddresses -DestinationAddress $rule.DestinationAddresses -DestinationPort
$rule.DestinationPorts -Protocol $rule.Protocols
}
elseif($rule.DestinationIpGroups)
{
$firewallPolicyNetRule = New-AzFirewallPolicyNetworkRule -Name $rule.Name -
SourceIpGroup $rule.SourceIpGroups -DestinationAddress $rule.DestinationAddresses -DestinationPort
$rule.DestinationPorts -Protocol $rule.Protocols
}
}
elseif($rule.SourceIpGroups){
If($rule.DestinationAddresses)
 If($rule.DestinationAddresses)
{
$firewallPolicyNetRule = New-AzFirewallPolicyNetworkRule -Name $rule.Name -
SourceAddress $rule.SourceAddresses -DestinationIpGroup $rule.DestinationIpGroups -DestinationPort
$rule.DestinationPorts -Protocol $rule.Protocols
}
elseif($rule.DestinationIpGroups)
{
$firewallPolicyNetRule = New-AzFirewallPolicyNetworkRule -Name $rule.Name -
SourceIpGroup $rule.SourceIpGroups -DestinationIpGroup $rule.DestinationIpGroups -DestinationPort
$rule.DestinationPorts -Protocol $rule.Protocols
}
}
Write-Host "Created network rule " $firewallPolicyNetRule.Name
$firewallPolicyNetRules += $firewallPolicyNetRule
}
$fwpNetRuleCollection = New-AzFirewallPolicyFilterRuleCollection -Name $rc.Name -Priority $rc.Priority -
ActionType $rc.Action.Type -Rule $firewallPolicyNetRules
Write-Host "Created NetworkRuleCollection " $fwpNetRuleCollection.Name
}
$firewallPolicyNetRuleCollections += $fwpNetRuleCollection
}
$netRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name $DefaultNetRuleCollectionGroupName -Priority
$NetworkRuleGroupPriority -RuleCollection $firewallPolicyNetRuleCollections -FirewallPolicyObject $fwp
Write-Host "Created NetworkRuleCollectionGroup " $netRuleGroup.Name
}

#Translate NatRuleCollection
# Hierarchy for NAT rule collection is different for AZFW and FirewallPOlicy. In AZFW you can have a
NatRuleCollection with multiple NatRules
# where each NatRule will have its own set of source , dest, tranlated IPs and ports.
# In FirewallPolicy a NatRuleCollection has a a set of rules which has one condition (source and dest IPs
and Ports) and the translated IP and ports
# as part of NatRuleCollection.
# So when translating NAT rules we will have to create separate ruleCollection for each rule in AZFW and
every ruleCollection will have only 1 rule.

Write-Host "creating " $azfw.NatRuleCollections.Count " network rule collections"

If ($azfw.NatRuleCollections.Count -gt 0) {
$firewallPolicyNatRuleCollections = @()
$priority = 100
ForEach ($rc in $azfw.NatRuleCollections) {
$firewallPolicyNatRules = @()
If ($rc.Rules.Count -gt 0) {
Write-Host "creating " $rc.Rules.Count " nat rules for collection " $rc.Name
ForEach ($rule in $rc.Rules) {
$firewallPolicyNatRule = New-AzFirewallPolicyNatRule -Name $rule.Name -SourceAddress
$rule.SourceAddresses -TranslatedAddress $rule.TranslatedAddress -TranslatedPort $rule.TranslatedPort -
DestinationAddress $rule.DestinationAddresses -DestinationPort $rule.DestinationPorts -Protocol
$rule.Protocols
Write-Host "Created nat rule " $firewallPolicyNatRule.Name
$firewallPolicyNatRules += $firewallPolicyNatRule
}
$natRuleCollectionName = $rc.Name+$rule.Name
$fwpNatRuleCollection = New-AzFirewallPolicyNatRuleCollection -Name $natRuleCollectionName -
Priority $priority -ActionType $rc.Action.Type -Rule $firewallPolicyNatRules
$priority += 1
Write-Host "Created NatRuleCollection " $fwpNatRuleCollection.Name
$firewallPolicyNatRuleCollections += $fwpNatRuleCollection
}
}
$natRuleGroup = New-AzFirewallPolicyRuleCollectionGroup -Name $DefaultNatRuleCollectionGroupName -Priority
$NatRuleGroupPriority -RuleCollection $firewallPolicyNatRuleCollections -FirewallPolicyObject $fwp
Write-Host "Created NatRuleCollectionGroup " $natRuleGroup.Name
}
Next steps
Learn more about Azure Firewall Manager deployment: Azure Firewall Manager deployment overview.
 Azure Firewall policy DNS settings
3/5/2021 • 2 minutes to read • Edit Online

You can configure a custom DNS server and enable DNS proxy for Azure Firewall policies. 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
1. Select your firewall policy.
2. Under Settings , select DNS Settings .
3. Under DNS ser vers , you can type or add existing DNS servers that have been previously specified in your
Virtual Network.
4. Select Save .
5. The firewall now directs DNS traffic to the specified DNS server(s) for name resolution.

DNS proxy
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
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 .
Enable DNS proxy
1. Select your Azure Firewall policy.
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
 Deploy an Azure Firewall with multiple public IP
addresses
11/2/2020 • 2 minutes to read • Edit Online

If you want to protect a virtual hub using Azure Firewall, you can deploy the firewall with multiple public IP
addresses using 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.

Deploy the firewall

Use the following Azure PowerShell example to deploy an Azure Firewall with multiple public IP addresses to
protect a virtual hub.
 Select-AzSubscription -SubscriptionId <subscription ID>

$rgName = <resource group name>

$vHub = Get-AzVirtualHub -Name <hub name>
$vHubId = $vHub.Id
$fwpips = New-AzFirewallHubPublicIpAddress -Count 3
$hubIpAddresses = New-AzFirewallHubIpAddress -PublicIPs $fwpips
$fw = New-AzFirewall -Name <firewall name> -ResourceGroupName $rgName `
-Location <location> -Sku AZFW_Hub -HubIPAddresses $hubIpAddresses `
-VirtualHubId $vHubId

Update a public IP address

You can use Azure PowerShell to update a public IP address for an Azure Firewall. The following example deletes
one public IP address from a firewall. It starts with three public IP addresses.

Select-AzSubscription -SubscriptionId <subscription ID>

$azfw = get-azfirewall -Name <firewall name> -ResourceGroupName <resource group name>

$ip1 = New-AzFirewallPublicIpAddress -Address <first ip address to keep>
$ip2 = New-AzFirewallPublicIpAddress -Address <second ip address to keep>
$ipAddresses = $ip1,$ip2
$azfw.HubIPAddresses.publicIPs.Addresses = $ipAddresses
$azfw.HubIPAddresses.publicIPs.count = 2
Set-AzFirewall -AzureFirewall $azfw

Next steps
What is a secured virtual hub?
 Use Azure Firewall policy to define a rule hierarchy
11/2/2020 • 4 minutes to read • Edit Online

Security administrators need to manage firewalls and ensure compliance across on-premise and cloud
deployments. A key component is the ability to provide application teams with flexibility to implement CI/CD
pipelines to create firewall rules in an automated way.
Azure Firewall policy allows you to define a rule hierarchy and enforce compliance:
Provides a hierarchical structure to overlay a central base policy on top of a child application team policy. The
base policy has a higher priority and runs before the child policy.
Use an Azure custom role definition to prevent inadvertent base policy removal and provide selective access
to rule collection groups within a subscription or resource group.

Solution overview
The high-level steps for this example are:
1. Create a base firewall policy in the security team resource group.
2. Define IT security-specific rules in the base policy. This adds a common set of rules to allow/deny traffic.
3. Create application team policies that inherit the base policy.
4. Define application team-specific rules in the policy. You can also migrate rules from pre-existing firewalls.
5. Create Azure Active Directory custom roles to provide fine grained access to rule collection group and add
roles at a Firewall Policy scope. In the following example, Sales team members can edit rule collection groups
for the Sales teams Firewall Policy. The same applies to the Database and Engineering teams.
6. Associate the policy to the corresponding firewall. An Azure firewall can have only one assigned policy. This
requires each application team to have their own firewall.

Create the firewall policies

A base firewall policy.
Create policies for each of the application teams:
A Sales firewall policy. The Sales firewall policy inherits the base firewall policy.
A Database firewall policy. The Database firewall policy inherits base firewall policy.
An Engineering firewall policy. The Engineering firewall policy also inherits the base firewall policy.
Create custom roles to access the rule collection groups
Custom roles are defined for each application team. The role defines operations and scope. The application
teams are allowed to edit rule collection groups for their respective applications.
Use the following high-level procedure to define custom roles:
1. Get the subscription:
Select-AzSubscription -SubscriptionId xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx

2. Run the following command:

Get-AzProviderOperation "Microsoft.Support/*" | FT Operation, Description -AutoSize

3. Use theGet-AzRoleDefinitioncommand to output theReaderrole in JSON format.

Get-AzRoleDefinition -Name "Reader" | ConvertTo-Json | Out-File C:\CustomRoles\ReaderSupportRole.json

4. Open theReaderSupportRole.jsonfile in an editor.

The following shows the JSON output. For information about the different properties, seeAzure custom
roles.

{
"Name": "Reader",
"Id": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"IsCustom": false,
"Description": "Lets you view everything, but not make any changes.",
"Actions": [
"*/read"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}

5. Edit the JSON file to add the

*/read", "Microsoft.Network/*/read", "Microsoft.Network/firewallPolicies/ruleCollectionGroups/write

operation to theActions property. Be sure to include a comma after the read operation. This action allows
the user to create and update rule collection groups.
6. InAssignableScopes , add your subscription ID with the following format:
/subscriptions/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx

You must add explicit subscription IDs, otherwise you won't be allowed to import the role into your
subscription.
7. Delete theId property line and change theIsCustom property totrue.
8. Change theName andDescription properties to AZFM Rule Collection Group Author and Users in this
role can edit Firewall Policy rule collection groups
Your JSON file should look similar to the following example:

"Name": "AZFM Rule Collection Group Author",

"IsCustom": true,
"Description": "Users in this role can edit Firewall Policy rule collection groups",
"Actions": [
"*/read",
"Microsoft.Network/*/read",
"Microsoft.Network/firewallPolicies/ruleCollectionGroups/write"
],
"NotActions": [
],
"DataActions": [
],
"NotDataActions": [
],
"AssignableScopes": [
"/subscriptions/xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxx"]
}

9. To create the new custom role, use theNew-AzRoleDefinitioncommand and specify the JSON role
definition file.
New-AzRoleDefinition -InputFile "C:\CustomRoles\RuleCollectionGroupRole.json

List custom roles

To list all the custom roles, you can use the Get-AzRoleDefinitioncommand:
Get-AzRoleDefinition | ? {$_.IsCustom -eq $true} | FT Name, IsCustom

You can also see the custom roles in the Azure portal. Go to your subscription, select Access control (IAM) ,
Roles .
For more information, see Tutorial: Create an Azure custom role using Azure PowerShell.
Add users to the custom role
On the portal, you can add users to the AZFM Rule Collection Group Authors role and provide access to the
firewall policies.
1. From the portal, select the Application team firewall policy (for example, SalesAppPolicy).
2. Select Access Control .
3. Select Add role assignment .
4. Add users/user groups (for example, the Sales team) to the role.
Repeat this procedure for the other firewall policies.
Summary
Firewall Policy with custom roles now provides selective access to firewall policy rule collection groups.
Users don’t have permissions to:
Delete the Azure Firewall or firewall policy.
Update firewall policy hierarchy or DNS settings or threat intelligence.
Update firewall policy where they are not members of AZFM Rule Collection Group Author group.
Security administrators can use base policy to enforce guardrails and block certain types of traffic (for example
ICMP) as required by their enterprise.

Next steps
Learn more about Azure Firewall policy.
 What is Azure Resource Manager?
3/26/2021 • 6 minutes to read • Edit Online

Azure Resource Manager is the deployment and management service for Azure. It provides a management layer
that enables you to create, update, and delete resources in your Azure account. You use management features,
like access control, locks, and tags, to secure and organize your resources after deployment.
To learn about Azure Resource Manager templates (ARM templates), see the 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 to 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. For more information, see resource group limits.
Some resources can exist outside of a resource group. These resources are deployed to the subscription,
management group, or tenant. Only specific resource types are supported at these scopes.
To create a resource group, you can use the portal, PowerShell, Azure CLI, or an ARM template.

Resiliency of Azure Resource Manager

The Azure Resource Manager service is designed for resiliency and continuous availability. Resource Manager
and control plane operations (requests sent to management.azure.com ) in the REST API are:
Distributed across regions. Some services are regional.
Distributed across Availability Zones (as well as regions) in locations that have multiple Availability Zones.
Not dependent on a single logical data center.
Never taken down for maintenance activities.
This resiliency applies to services that receive requests through Resource Manager. For example, Key Vault
benefits from this resiliency.
Next steps
To learn about limits that are applied across Azure services, see Azure subscription and service limits,
quotas, and constraints.
To learn about moving resources, see Move resources to new resource group or subscription.
To learn about tagging resources, see Use tags to organize your Azure resources.
To learn about locking resources, see Lock resources to prevent unexpected changes.
 Understand the structure and syntax of ARM
templates
3/26/2021 • 13 minutes to read • Edit Online

This article describes the structure of an Azure Resource Manager template (ARM template). It presents the
different sections of a template and the properties that are available in those sections.
This article is intended for users who have some familiarity with ARM templates. It provides detailed
information about the structure of the template. For a step-by-step tutorial that guides you through the process
of creating a template, see Tutorial: Create and deploy your first ARM template. To learn about ARM templates
through a guided set of modules on Microsoft Learn, see Deploy and manage resources in Azure by using ARM
templates.

Template format
In its simplest structure, a template has the following elements:

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "",
"apiProfile": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}

EL EM EN T N A M E REQ UIRED DESC RIP T IO N

EL EM EN T N A M E REQ UIRED DESC RIP T IO N

$schema Yes Location of the JavaScript Object

Notation (JSON) schema file that
describes the version of the template
language. The version number you use
depends on the scope of the
deployment and your JSON editor.

If you're using Visual Studio Code with

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

Other editors (including Visual Studio)

may not be able to process this
schema. For those editors, use:
https://schema.management.azure.com/schemas/2015-
01-01/deploymentTemplate.json#

For subscription deployments, use:

https://schema.management.azure.com/schemas/2018-
05-01/subscriptionDeploymentTemplate.json#

For management group deployments,

use:
https://schema.management.azure.com/schemas/2019-
08-01/managementGroupDeploymentTemplate.json#

For tenant deployments, use:

https://schema.management.azure.com/schemas/2019-
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.
 EL EM EN T N A M E REQ UIRED DESC RIP T IO N

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>"
}
}
}

EL EM EN T N A M E REQ UIRED DESC RIP T IO N

parameter-name Yes Name of the parameter. Must be a

valid JavaScript identifier.

type Yes Type of the parameter value. The

allowed types and values are string ,
securestring , int , bool, object ,
secureObject , and array . See Data
types in ARM templates.

defaultValue No Default value for the parameter, if no

value is provided for the parameter.

allowedValues No Array of allowed values for the

parameter to make sure that the right
value is provided.

minValue No The minimum value for int type

parameters, this value is inclusive.

maxValue No The maximum value for int type

parameters, this value is inclusive.

minLength No The minimum length for string, secure

string, and array type parameters, this
value is inclusive.

maxLength No The maximum length for string, secure

string, and array type parameters, this
value is inclusive.

description No Description of the parameter that is

displayed to users through the portal.
For more information, see Comments
in templates.

For examples of how to use parameters, see Parameters in ARM templates.

Variables
In the variables section, you construct values that can be used throughout your template. You don't need to
define variables, but they often simplify your template by reducing complex expressions. The format of each
variable matches one of the data types.
The following example shows the available options for defining a variable:
 "variables": {
"<variable-name>": "<variable-value>",
"<variable-name>": {
<variable-complex-type-value>
},
"<variable-object-name>": {
"copy": [
{
"name": "<name-of-array-property>",
"count": <number-of-iterations>,
"input": <object-or-value-to-repeat>
}
]
},
"copy": [
{
"name": "<variable-array-name>",
"count": <number-of-iterations>,
"input": <object-or-value-to-repeat>
}
]
}

For information about using copy to create several values for a variable, see Variable iteration.
For examples of how to use variables, see Variables in ARM template.

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>"
}
}
}
}
],
 EL EM EN T N A M E REQ UIRED DESC RIP T IO N

namespace Yes Namespace for the custom functions.

Use to avoid naming conflicts with
template functions.

function-name Yes Name of the custom function. When

calling the function, combine the
function name with the namespace.
For example, to call a function named
uniqueName in the namespace
contoso, use
"[contoso.uniqueName()]" .

parameter-name No Name of the parameter to be used

within the custom function.

parameter-value No Type of the parameter value. The

allowed types and values are string ,
securestring , int , bool, object ,
secureObject , and array .

output-type Yes Type of the output value. Output

values support the same types as
function input parameters.

output-value Yes Template language expression that is

evaluated and returned from the
function.

For examples of how to use custom functions, see User-defined functions in ARM template.

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>",
"scope": "<target-scope-for-extension-resources>",
"copy": {
"name": "<name-of-copy-loop>",
"count": <number-of-iterations>,
"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>"
]
}
]

EL EM EN T N A M E REQ UIRED DESC RIP T IO N

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.
EL EM EN T N A M E REQ UIRED DESC RIP T IO N

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

name Yes Name of the resource. The name must

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

comments No Your notes for documenting the

resources in your template. For more
information, see Comments in
templates.

location Varies Supported geo-locations of the

provided resource. You can select any
of the available locations, but typically
it makes sense to pick one that is close
to your users. Usually, it also makes
sense to place resources that interact
with each other in the same region.
Most resource types require a location,
but some types (such as a role
assignment) don't require a location.
See Set resource location.
EL EM EN T N A M E REQ UIRED DESC RIP T IO N

dependsOn No Resources that must be deployed

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

tags No Tags that are associated with the

resource. Apply tags to logically
organize resources across your
subscription.

sku No Some resources allow values that

define the SKU to deploy. For example,
you can specify the type of
redundancy for a storage account.

kind No Some resources allow a value that

defines the type of resource you
deploy. For example, you can specify
the type of Cosmos DB to create.

scope No The scope property is only available for

extension resource types. Use it when
specifying a scope that is different than
the deployment scope. See Setting
scope for extension resources in ARM
templates.

copy No If more than one instance is needed,

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

plan No Some resources allow values that

define the plan to deploy. For example,
you can specify the marketplace image
for a virtual machine.
 EL EM EN T N A M E REQ UIRED DESC RIP T IO N

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": {
"count": <number-of-iterations>,
"input": <values-for-the-variable>
}
}
}

EL EM EN T N A M E REQ UIRED DESC RIP T IO N

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 .
 EL EM EN T N A M E REQ UIRED DESC RIP T IO N

type Yes Type of the output value. Output

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

value No Template language expression that is

evaluated and returned as output
value. Specify either value or copy .

copy No Used to return more than one value

for an output. Specify value or copy .
For more information, see Output
iteration in ARM templates.

For examples of how to use outputs, see Outputs in ARM template.

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.

{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[parameters('location')]", //defaults to resource group location
"dependsOn": [ /* storage account and network interface must be deployed first */
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],

In Visual Studio Code, the Azure Resource Manager Tools extension can automatically detect an ARM template
and change the language mode. If you see Azure Resource Manager Template at the bottom-right corner of
Visual Studio Code, you can use the inline comments. The inline comments are no longer marked as invalid.
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.

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"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": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2018-07-01",
"name": "[concat('storage', uniqueString(resourceGroup().id))]",
"comments": "Storage account used to store VM disks",
"location": "[parameters('location')]",
"metadata": {
"comments": "These tags are needed for policy compliance."
},
"tags": {
"Dept": "[parameters('deptName')]",
"Environment": "[parameters('environment')]"
},
"sku": {
"name": "Standard_LRS"
},
"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.

{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]", // to customize name, change it in variables
"location": "[
parameters('location')
]", //defaults to resource group location
/*
storage account and network interface
must be deployed first
*/
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],

NOTE
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 ARM template functions.
To combine several templates during deployment, see Using linked and nested templates when deploying
Azure resources.
For recommendations about creating templates, see ARM template best practices.
For answers to common questions, see Frequently asked questions about ARM templates.