Comprehensive Azure Firewall Setup and Configuration Guide for SMBs
As a growing SMB, ensuring robust network security for your Azure cloud environment is paramount. Uncontrolled outbound access or inadequate threat protection can expose your critical applications and data to significant risks. This is where Azure Firewall comes in, acting as your cloud-native, intelligent network security service to provide top-tier threat protection.
At SkyCore Solutions, we frequently guide Montreal-based SMBs through enhancing their Azure security posture. This comprehensive Azure Firewall setup and configuration guide is designed to walk you through deploying and configuring Azure Firewall to control both inbound and outbound network traffic, securing your valuable Azure workloads, and achieving compliance. By the end of this guide, you will have a fully functional Azure Firewall protecting a sample workload, with custom rules dictating network access.
Prerequisites
- An active Azure subscription with 'Contributor' or 'Owner' role assigned.
- Azure CLI installed and authenticated (version 2.40.0 or later recommended).
- Basic understanding of IP networking concepts (Virtual Networks, subnets, routing).
- Estimated monthly cost: Azure Firewall Standard, along with a Public IP address, can incur costs of approximately $700 USD/month, before considering data processing charges. This is a significant investment for an SMB, but critical for robust security.
- A custom domain name (optional, but recommended for advanced testing).
Step 1: Set up the Network Environment for Azure Firewall
Before deploying Azure Firewall, we need a dedicated network infrastructure. This involves creating a resource group to logically organize all our resources, a virtual network (VNet), and specific subnets: one for the Azure Firewall itself (AzureFirewallSubnet) and another for our workload servers (Workload-SN). The AzureFirewallSubnet requires a specific naming convention and a minimum size of /26 for proper functionality.
az group create --name Test-FW-RG --location westus
az network vnet create \
--name Test-FW-VN \
--resource-group Test-FW-RG \
--location westus \
--address-prefix 10.0.0.0/16 \
--subnet-name AzureFirewallSubnet \
--subnet-prefix 10.0.0.0/26
az network vnet subnet create \
--name Workload-SN \
--vnet-name Test-FW-VN \
--resource-group Test-FW-RG \
--address-prefix 10.0.2.0/24
--name Test-FW-RG: Defines the name of your resource group.--location westus: Specifies the Azure region for all resources. Consistency here is key.--address-prefix 10.0.0.0/16: The overall IP address range for your virtual network.--subnet-name AzureFirewallSubnet: The mandatory name for the subnet hosting Azure Firewall.--subnet-prefix 10.0.0.0/26: The required minimum size for the Azure Firewall subnet.--subnet-name Workload-SN: The subnet where your application servers will reside.
Portal alternative: Navigate to 'Resource groups' > 'Create', then 'Virtual networks' > 'Create'. During VNet creation, you can add subnets under the 'IP addresses' tab. Ensure to name the Firewall subnet exactly AzureFirewallSubnet.
Run this to verify:
az network vnet show --name Test-FW-VN --resource-group Test-FW-RG --query "subnets[].name" -o tsv
You should see AzureFirewallSubnet and Workload-SN listed.
Step 2: Deploy Azure Firewall Standard with a Firewall Policy
Now that our network is ready, we'll deploy the Azure Firewall itself. For SMBs, we highly recommend the Azure Firewall Standard SKU. It provides L3-L7 filtering, incorporates Microsoft's real-time threat intelligence feeds, and offers superior protection compared to Basic, without the additional cost of Premium's IDPS features which might be overkill for many SMBs initially. We will also create a Firewall Policy, which is the preferred method for managing rules, even for a single firewall.
az network public-ip create \
--name fw-pip \
--resource-group Test-FW-RG \
--location westus \
--sku Standard \
--allocation-method Static
az network firewall create \
--name Test-FW01 \
--resource-group Test-FW-RG \
--location westus \
--sku Standard \
--tier Standard \
--virtual-network Test-FW-VN \
--public-ip-address fw-pip \
--firewall-policy null # This will create a classic firewall, we will attach a policy later if we want.
# Note: The above command deploys using classic rules directly. Let's adapt to use Firewall Policy from the start, as it's the preferred method.
# First, create the Firewall Policy, then associate it during firewall creation (or update if already created).
az network firewall policy create \
--name Test-FW-Policy \
--resource-group Test-FW-RG \
--location westus
# Now, deploy the firewall and associate the policy.
# If you already ran the 'firewall create' command above, you can update it:
az network firewall update \
--name Test-FW01 \
--resource-group Test-FW-RG \
--firewall-policy Test-FW-Policy
# Or, if starting fresh (preferred for policy management):
# az network firewall create \
# --name Test-FW01 \
# --resource-group Test-FW-RG \
# --location westus \
# --sku Standard \
# --tier Standard \
# --virtual-network Test-FW-VN \
# --public-ip-address fw-pip \
# --firewall-policy Test-FW-Policy
az network public-ip create ...: Creates a Standard SKU public IP address that the firewall will use for outbound connections. Static allocation ensures the IP doesn't change.az network firewall policy create ...: Creates an empty Firewall Policy that we will attach to our firewall. Policies allow for centralized rule management and inheritance.az network firewall update ...(orcreatewith--firewall-policy): Deploys or updates the Azure Firewall.--name Test-FW01: The name of your Azure Firewall instance.--sku Standard --tier Standard: Specifies the Azure Firewall Standard SKU, recommended for SMBs due to its feature set (L3-L7, Microsoft Threat Intel) and balanced cost.--virtual-network Test-FW-VN: Associates the firewall with the virtual network created earlier.--public-ip-address fw-pip: Links the firewall to the newly created public IP.--firewall-policy Test-FW-Policy: Associates the firewall with the dedicated Firewall Policy for rule management.
Portal alternative: Go to 'Firewalls' > 'Create'. Fill in the basics, choose 'Standard' for SKU, 'West US' for region. For 'Firewall Policy', select 'Create new' and provide a name (e.g., Test-FW-Policy). For 'Public IP address', select 'Create new' and name it fw-pip. Ensure the VNet is Test-FW-VN.
Run this to verify: Get the private IP of your firewall, which will be needed for routing.
FIREWALL_PRIVATE_IP=$(az network firewall show -g Test-FW-RG -n Test-FW01 --query "ipConfigurations[0].privateIpAddress" -o tsv)
echo "Azure Firewall Private IP: $FIREWALL_PRIVATE_IP"
Step 3: Deploy a Workload Virtual Machine for Testing
To demonstrate Azure Firewall's capabilities, we'll deploy a simple Ubuntu Linux virtual machine into the Workload-SN subnet. Crucially, this VM will *not* have a public IP address. This ensures that all its outbound internet traffic is forced through the Azure Firewall, allowing us to enforce our security rules effectively.
az vm create \
--name Srv-Work \
--resource-group Test-FW-RG \
--image Ubuntu2204 \
--vnet-name Test-FW-VN \
--subnet Workload-SN \
--size Standard_B2s \
--admin-username azureuser \
--generate-ssh-keys \
--no-wait # Continue without waiting for VM creation to complete
# Deploy Azure Bastion for secure access to the VM
az network public-ip create --resource-group Test-FW-RG --name Bastion-PIP --sku Standard --allocation-method Static
az network vnet subnet create --resource-group Test-FW-RG --vnet-name Test-FW-VN --name AzureBastionSubnet --address-prefix 10.0.1.0/27
az network bastion create --name Test-Bastion --public-ip-address Bastion-PIP --resource-group Test-FW-RG --vnet-name Test-FW-VN --location westus
--name Srv-Work: The name of your test virtual machine.--image Ubuntu2204: Specifies an Ubuntu Server 22.04 LTS image.--vnet-name Test-FW-VN --subnet Workload-SN: Places the VM in the correct subnet within our VNet.--size Standard_B2s: A cost-effective VM size suitable for testing.--generate-ssh-keys: Creates SSH keys for secure access.--no-wait: Allows the CLI to return immediately while the VM deployment continues in the background.az network bastion create ...: Deploys Azure Bastion, which provides secure RDP/SSH connectivity to your VMs directly through the Azure portal, eliminating the need for public IPs on your VMs. TheAzureBastionSubnetalso requires a specific name and a minimum /27 prefix.
Portal alternative: Go to 'Virtual machines' > 'Create'. Select 'Ubuntu Server 22.04 LTS'. On the 'Networking' tab, ensure 'Virtual network' is Test-FW-VN and 'Subnet' is Workload-SN. For 'Public IP', select '(None)'. For Bastion, search 'Bastion' in the portal, then 'Create', choosing Test-FW-VN and Bastion-PIP for the public IP. Ensure the Bastion subnet is AzureBastionSubnet.
Run this to verify: Wait for the VM to finish deploying (can take a few minutes). Then verify its network interface has no public IP.
az vm show --resource-group Test-FW-RG --name Srv-Work --query "networkProfile.networkInterfaces[0].id" -o tsv
# (Wait for the above command to return the NIC ID, then run:)
az network nic show --ids $(az vm show --resource-group Test-FW-RG --name Srv-Work --query "networkProfile.networkInterfaces[0].id" -o tsv) --query "ipConfigurations[0].publicIpAddress" -o tsv
This last command should return 'null' or an empty string, indicating no public IP.
Step 4: Configure User-Defined Route (UDR) to Direct Traffic to Azure Firewall
For your Workload-SN subnet to send all its outbound traffic through the Azure Firewall, we need to implement a User-Defined Route (UDR). This UDR will instruct the subnet to forward all traffic destined for 0.0.0.0/0 (i.e., the internet) to the private IP address of your Azure Firewall. This is a critical step to ensure the firewall inspects and filters all traffic.
FIREWALL_PRIVATE_IP=$(az network firewall show -g Test-FW-RG -n Test-FW01 --query "ipConfigurations[0].privateIpAddress" -o tsv)
az network route-table create \
--name RT-FW \
--resource-group Test-FW-RG \
--location westus
az network route-table route create \
--name FW-Route \
--resource-group Test-FW-RG \
--route-table-name RT-FW \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address $FIREWALL_PRIVATE_IP
az network vnet subnet update \
--name Workload-SN \
--vnet-name Test-FW-VN \
--resource-group Test-FW-RG \
--route-table RT-FW
FIREWALL_PRIVATE_IP=...: Retrieves the private IP address of your deployed Azure Firewall.az network route-table create ...: Creates a new route table namedRT-FW.az network route-table route create ...: Adds a default route to the route table.--address-prefix 0.0.0.0/0: Represents all IP addresses (the internet).--next-hop-type VirtualAppliance: Specifies that the next hop is a network virtual appliance, in this case, our Azure Firewall.--next-hop-ip-address $FIREWALL_PRIVATE_IP: The specific private IP of your firewall that traffic should be directed to.az network vnet subnet update ...: Associates the newly created route table with theWorkload-SNsubnet.
Portal alternative: Search for 'Route tables' > 'Create'. After creation, open the route table, select 'Routes' > 'Add'. Set 'Route name' to FW-Route, 'Address prefix' to 0.0.0.0/0, 'Next hop type' to 'Virtual appliance', and 'Next hop address' to your firewall's private IP. Then, go to 'Subnets' > 'Associate' and select Test-FW-VN and Workload-SN.
Run this to verify:
az network vnet subnet show -g Test-FW-RG -n Workload-SN --vnet-name Test-FW-VN --query "routeTable.name" -o tsv
This should output RT-FW.
Step 5: Define Azure Firewall Rules with Firewall Policy
Azure Firewall, by default, denies all traffic. We must explicitly define rules to allow specific outbound (and potentially inbound) connections. We'll use the Firewall Policy created earlier to define both Application Rules (for FQDNs) and Network Rules (for IP addresses, protocols, and ports). Remember that rule processing prioritizes DNAT rules, then Network rules, and finally Application rules.
# Define a variable for the Firewall Policy name
FIREWALL_POLICY_NAME="Test-FW-Policy"
# Create an Application Rule Collection
az network firewall policy rule-collection-group collection add-application-collection \
--name AppCollection01 \
--policy-name $FIREWALL_POLICY_NAME \
--resource-group Test-FW-RG \
--priority 100 \
--action Allow
# Add an Application Rule to allow access to www.google.com
az network firewall policy rule-collection-group collection rule add-application-rule \
--collection-name AppCollection01 \
--name AllowGoogle \
--policy-name $FIREWALL_POLICY_NAME \
--resource-group Test-FW-RG \
--source-addresses '*' \
--protocols Http Https \
--target-fqdns www.google.com
# Create a Network Rule Collection
az network firewall policy rule-collection-group collection add-network-collection \
--name NetCollection01 \
--policy-name $FIREWALL_POLICY_NAME \
--resource-group Test-FW-RG \
--priority 200 \
--action Allow
# Add a Network Rule to allow outbound DNS access (port 53 UDP/TCP)
# This is crucial for FQDN resolution
az network firewall policy rule-collection-group collection rule add-network-rule \
--collection-name NetCollection01 \
--name AllowDNS \
--policy-name $FIREWALL_POLICY_NAME \
--resource-group Test-FW-RG \
--protocols UDP TCP \
--source-addresses '*' \
--destination-addresses '*' \
--destination-ports 53
az network firewall policy rule-collection-group collection add-application-collection ...: Creates an application rule collection.--name AppCollection01: Name for your application rule collection.--priority 100: Rule collections are processed by priority (lower number is higher priority).--action Allow: Specifies that rules in this collection will allow traffic.az network firewall policy rule-collection-group collection rule add-application-rule ...: Adds a rule to the application rule collection.--target-fqdns www.google.com: Allows access to the Fully Qualified Domain Name (FQDN) of Google.az network firewall policy rule-collection-group collection add-network-collection ...: Creates a network rule collection.--destination-addresses '*': Allows DNS queries to any external DNS server. For production, you might restrict this to known DNS servers.
Portal alternative: Go to your Firewall Policy (Test-FW-Policy) > 'Rule collections'. Select '+ Add a rule collection'. For Application rule: 'Name' AppCollection01, 'Priority' 100, 'Action' Allow. Under 'Rules', 'Name' AllowGoogle, 'Source type' IP Address, 'Source' *, 'Protocol' http, https, 'Target FQDNs' www.google.com. For Network rule: Select '+ Add a rule collection'. 'Name' NetCollection01, 'Priority' 200, 'Action' Allow. Under 'Rules', 'Name' AllowDNS, 'Source type' IP Address, 'Source' *, 'Protocol' UDP, TCP, 'Destination type' IP Address, 'Destination' *, 'Destination ports' 53.
Run this to verify:
az network firewall policy rule-collection-group collection show -n AppCollection01 --policy-name Test-FW-Policy -g Test-FW-RG --query "rules[0].name" -o tsv
az network firewall policy rule-collection-group collection show -n NetCollection01 --policy-name Test-FW-Policy -g Test-FW-RG --query "rules[0].name" -o tsv
You should see AllowGoogle and AllowDNS respectively.
Step 6: Test the Azure Firewall Configuration
With the firewall deployed, UDR configured, and rules in place, it's time to test if our Azure Firewall setup and configuration guide has been successful. We'll connect to the Srv-Work VM using Azure Bastion and attempt to access allowed and blocked resources.
Connect to the VM:
# Get the SSH private key you downloaded when creating the VM
# For example, if you saved it as Srv-Work_key.pem:
chmod 400 Srv-Work_key.pem
# Get the private IP of the Workload VM
VM_PRIVATE_IP=$(az vm list-ip-addresses -g Test-FW-RG -n Srv-Work --query "[0].virtualMachine.network.privateIpAddresses[0]" -o tsv)
echo "Workload VM Private IP: $VM_PRIVATE_IP"
# Use Azure CLI to connect via Bastion (this will open a browser tab for SSH)
az network bastion ssh --name Test-Bastion --resource-group Test-FW-RG --target-ip $VM_PRIVATE_IP --auth-type SshKey --username azureuser --ssh-key Srv-Work_key.pem
Portal alternative: Go to 'Virtual machines' > Srv-Work. Select 'Connect' > 'Bastion'. Provide your username (azureuser) and the path to your SSH private key file (Srv-Work_key.pem). This will open a new browser tab with an SSH session.
Once connected to Srv-Work, run the following commands:
# Update package list (requires internet access - should be allowed by firewall)
sudo apt update
# Install curl for web testing
sudo apt install -y curl
# Test access to www.google.com (should succeed due to Application Rule)
curl -I www.google.com
# Test access to a known blocked site (e.g., www.microsoft.com - should fail, as no rule explicitly allows it)
curl -I www.microsoft.com
# Test DNS resolution (should succeed due to Network Rule for port 53)
dig www.google.com
Expected outcomes:
sudo apt update: Should complete successfully, demonstrating outbound access.curl -I www.google.com: Should return an HTTP 200 OK status or similar response, confirming access to Google.curl -I www.microsoft.com: Should time out or return an error, as this FQDN is not explicitly allowed by an application rule, and all other outbound traffic is denied by default.dig www.google.com: Should successfully resolve the IP address forwww.google.com, confirming DNS is working through the firewall.
When to bring in a consultant
While this guide covers a fundamental Azure Firewall setup, real-world SMB environments often have complexities that benefit from expert guidance. Consider engaging SkyCore Solutions if you're dealing with:
- Integrating Azure Firewall with existing on-premises networks (hybrid connectivity).
- Advanced security hardening, including intrusion detection/prevention systems (IDPS) or specific compliance requirements (e.g., PCI DSS, HIPAA).
- Complex application dependencies requiring intricate NAT, Network, and Application rule configurations.
- Optimizing Azure Firewall policies for cost, performance, and multi-subscription management (using Azure Firewall Manager).
- Automating deployments and rule changes using Infrastructure as Code (e.g., Bicep, Terraform).
- Incident response planning and advanced logging/monitoring with Azure Sentinel.
Our team of Azure architects specializes in tailoring cloud security solutions to the unique needs of SMBs, ensuring your infrastructure is secure, efficient, and compliant.
Book a free consultationBy following this Azure Firewall setup and configuration guide, you've successfully deployed a critical security component in your Azure environment. You've learned how to leverage Azure Firewall Standard, enforce outbound traffic rules using Firewall Policies, and ensure your workloads communicate securely. This foundational setup provides a strong starting point for protecting your SMB's cloud infrastructure against a wide range of network threats.
Remember that security is an ongoing process. Regularly review your firewall rules, keep an eye on Microsoft's threat intelligence updates, and consider advanced features as your security needs evolve. SkyCore Solutions is always here to help you navigate these complexities and ensure your cloud strategy remains robust and secure.