Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Controlling outbound network access is an important part of an overall network security plan. For example, you might want to limit access to web sites. Or, you might want to limit the outbound IP addresses and ports that can be accessed.
One way you can control outbound network access from an Azure subnet is with Azure Firewall. With Azure Firewall, you can configure:
- Application rules that define fully qualified domain names (FQDNs) that can be accessed from a subnet.
- Network rules that define source address, protocol, destination port, and destination address.
Network traffic is subjected to the configured firewall rules when you route your network traffic to the firewall as the subnet default gateway.
For this article, you create a simplified single virtual network with two subnets for easy deployment.
For production deployments, a hub and spoke model is recommended, where the firewall is in its own virtual network. The workload servers are in peered virtual networks in West US with one or more subnets.
- AzureFirewallSubnet - the firewall is in this subnet.
- Workload-SN - the workload server is in this subnet. This subnet's network traffic goes through the firewall.
In this article, you learn how to:
- Set up a test network environment
- Deploy a firewall
- Create a default route
- Configure an application rule to allow access to www.google.com
- Configure a network rule to allow access to external DNS servers
- Deploy Azure Bastion for secure VM access
- Test the firewall
Note
This article uses classic Firewall rules to manage the firewall. The preferred method is to use Firewall Policy. To complete this procedure using Firewall Policy, see Tutorial: Deploy and configure Azure Firewall and policy using the Azure portal
If you prefer, you can complete this procedure using Azure PowerShell.
Prerequisites
If you don't have an Azure subscription, create a free account before you begin.
Set up the network
First, create a resource group to contain the resources needed to deploy the firewall. Then create a virtual network, subnets, and a test server.
Create a resource group
The resource group contains all the resources used in this procedure.
- Sign in to the Azure portal.
- On the Azure portal menu, select Resource groups or search for and select Resource groups from any page. Then select Create.
- For Subscription, select your subscription.
- For Resource group name, type Test-FW-RG.
- For Region, select West US. All other resources that you create must be in West US.
- Select Review + create.
- Select Create.
Create a virtual network
This virtual network has two subnets.
Note
The size of the AzureFirewallSubnet subnet is /26. For more information about the subnet size, see Azure Firewall FAQ.
On the Azure portal menu or from the Home page, search for and select Virtual networks.
Select Create.
On the Basics tab, configure the following settings:
Setting Value Subscription Select your subscription Resource group Test-FW-RG Virtual network name Test-FW-VN Region West US Select Next.
On the Security tab, configure the following settings:
Setting Value Enable Azure Firewall Selected Azure Firewall name Test-FW01 Tier Standard Policy None (Use classic firewall rules) Azure Firewall public IP address Select Create a public IP address, type fw-pip for the name, and select OK Select Next.
On the IP addresses tab, configure the following settings:
Setting Value Address space Accept the default 10.0.0.0/16 Subnets Select default, change Name to Workload-SN, and set Starting address to 10.0.2.0/24. Select Save. Select Review + create.
Select Create.
Note
Azure Firewall uses public IPs as needed based on available ports. After randomly selecting a public IP to connect outbound from, it will only use the next available public IP after no more connections can be made from the current public IP. In scenarios with high traffic volume and throughput, it's recommended to use a NAT Gateway to provide outbound connectivity. SNAT ports are dynamically allocated across all public IPs associated with NAT Gateway. To learn more, see Scale SNAT ports with Azure NAT Gateway.
Create a virtual machine
Now create the workload virtual machine, and place it in the Workload-SN subnet.
On the Azure portal menu or from the Home page, select Create a resource.
Select Ubuntu Server 22.04 LTS.
Enter these values for the virtual machine:
Setting Value Resource group Test-FW-RG Virtual machine name Srv-Work Region West US Image Ubuntu Server 22.04 LTS - x64 Gen2 Size Standard_B2s Authentication type SSH public key Username azureuser SSH public key source Generate new key pair Key pair name Srv-Work_key On the Networking tab, configure the following settings:
Setting Value Virtual network Test-FW-VN Subnet Workload-SN Public IP None Accept the other defaults and select Next: Management.
Accept the defaults and select Next: Monitoring.
For Boot diagnostics, select Disable. Accept the other defaults and select Review + create.
Review the settings on the summary page, and then select Create.
On the Generate new key pair dialog, select Download private key and create resource. Save the key file as Srv-Work_key.pem.
After the deployment is complete, select Go to resource and note the Srv-Work private IP address that you'll need to use later.
Note
Azure provides a default outbound access IP for VMs that either aren't assigned a public IP address or are in the backend pool of an internal basic Azure load balancer. The default outbound access IP mechanism provides an outbound IP address that isn't configurable.
The default outbound access IP is disabled when one of the following events happens:
- A public IP address is assigned to the VM.
- The VM is placed in the backend pool of a standard load balancer, with or without outbound rules.
- An Azure NAT Gateway resource is assigned to the subnet of the VM.
VMs that you create by using virtual machine scale sets in flexible orchestration mode don't have default outbound access.
For more information about outbound connections in Azure, see Default outbound access in Azure and Use Source Network Address Translation (SNAT) for outbound connections.
Examine the firewall
- Go to the resource group and select the firewall.
- Note the firewall private and public IP addresses. You use these addresses later.
Create a default route
When you create a route for outbound and inbound connectivity through the firewall, a default route to 0.0.0.0/0 with the virtual appliance private IP as a next hop is sufficient. This directs any outgoing and incoming connections through the firewall. As an example, if the firewall is fulfilling a TCP-handshake and responding to an incoming request, then the response is directed to the IP address who sent the traffic. This is by design.
As a result, there's no need to create another user defined route to include the AzureFirewallSubnet IP range. This might result in dropped connections. The original default route is sufficient.
For the Workload-SN subnet, configure the outbound default route to go through the firewall.
On the Azure portal, search for and select Route tables.
Select Create.
On the Basics tab, configure the following settings:
Setting Value Subscription Select your subscription Resource group Test-FW-RG Region West US Name Firewall-route Propagate gateway routes Select your preference Select Review + create.
Select Create.
After deployment completes, select Go to resource.
On the Firewall-route page, select Settings > Subnets and then select Associate.
For Virtual network, select Test-FW-VN.
For Subnet, select Workload-SN. Make sure that you select only the Workload-SN subnet for this route, otherwise your firewall won't work correctly.
Select OK.
Select Routes and then select Add.
Configure the route with the following settings:
Setting Value Route name fw-dg Destination type IP Addresses Destination IP addresses/CIDR ranges 0.0.0.0/0 Next hop type Virtual appliance. Azure Firewall is actually a managed service, but virtual appliance works in this situation. Next hop address The private IP address for the firewall that you noted previously Select Add.
Configure an application rule
This is the application rule that allows outbound access to www.google.com.
Open the Test-FW-RG resource group and select the Test-FW01 firewall.
On the Test-FW01 page, under Settings, select Rules (classic).
Select the Application rule collection tab.
Select Add application rule collection.
Configure the rule collection with the following settings:
Setting Value Name App-Coll01 Priority 200 Action Allow Under Rules, Target FQDNs, configure the following settings:
Setting Value Name Allow-Google Source type IP address Source 10.0.2.0/24 Protocol:port http, https Target FQDNs www.google.comSelect Add.
Azure Firewall includes a built-in rule collection for infrastructure FQDNs that are allowed by default. These FQDNs are specific for the platform and can't be used for other purposes. For more information, see Infrastructure FQDNs.
Configure a network rule
This is the network rule that allows outbound access to two IP addresses at port 53 (DNS).
Select the Network rule collection tab.
Select Add network rule collection.
Configure the rule collection with the following settings:
Setting Value Name Net-Coll01 Priority 200 Action Allow Under Rules, IP addresses, configure the following settings:
Setting Value Name Allow-DNS Protocol UDP Source type IP address Source 10.0.2.0/24 Destination type IP address Destination address 209.244.0.3,209.244.0.4 (public DNS servers operated by Level3) Destination Ports 53 Select Add.
Deploy Azure Bastion
Now deploy Azure Bastion to provide secure access to the virtual machine.
On the Azure portal menu, select Create a resource.
In the search box, type Bastion and select it from the results.
Select Create.
On the Basics tab, configure the following settings:
Setting Value Subscription Select your subscription Resource group Test-FW-RG Name Test-Bastion Region West US Tier Developer Virtual network Test-FW-VN Subnet Select Edit subnet In the Edit subnet page, configure the following settings:
Setting Value Starting address 10.0.4.0/26 Size /26 Select Save and close the subnets page.
Select Review + create.
After validation passes, select Create.
Note
The Bastion deployment takes about 10 minutes to complete. The Developer tier is intended for test and evaluation purposes. For production deployments, review the Azure Bastion SKU options in Azure Bastion SKU comparison.
Change the primary and secondary DNS address for the Srv-Work network interface
For testing purposes, configure the server's primary and secondary DNS addresses. This isn't a general Azure Firewall requirement.
On the Azure portal menu, select Resource groups or search for and select Resource groups from any page. Select the Test-FW-RG resource group.
Select the network interface for the Srv-Work virtual machine.
Under Settings, select DNS servers.
Under DNS servers, select Custom.
Configure the following DNS servers:
DNS server Value Primary 209.244.0.3 Secondary 209.244.0.4 Select Save.
Restart the Srv-Work virtual machine.
Test the firewall
Now, test the firewall to confirm that it works as expected.
In the Azure portal, navigate to the Srv-Work virtual machine.
Select Connect, then select Connect via Bastion.
Select Use SSH Private Key from Local File.
For Username, type azureuser.
Select the folder icon and browse to the Srv-Work_key.pem file you downloaded earlier.
Select Connect.
At the bash prompt, run the following commands to test DNS resolution:
nslookup www.google.com nslookup www.microsoft.comBoth commands should return answers, showing that your DNS queries are getting through the firewall.
Run the following commands to test the application rule:
curl https://www.google.com curl https://www.microsoft.comThe
www.google.comrequest should succeed, and you should see the HTML response.The
www.microsoft.comrequest should fail, showing that the firewall is blocking the request.
So now you verified that the firewall rules are working:
- You can connect to the virtual machine using Bastion and SSH.
- You can browse to the one allowed FQDN, but not to any others.
- You can resolve DNS names using the configured external DNS server.
Clean up resources
You can keep your firewall resources to continue testing, or if no longer needed, delete the Test-FW-RG resource group to delete all firewall-related resources.