In this blog post, we will talk about installing and configuring an Azure firewall. We’ll go through the four steps of Azure Firewall configuration: create a virtual network, add firewalls to the virtual network, configure rules for IP address ranges or subnets on your new firewall, and publish those settings so they can be used by other services in your subscription.
The “azure firewall network rule” is a command-line tool that allows users to set up an Azure Firewall. The “azure firewall network rule” can be used as a replacement for NSGS.
You have two options for controlling traffic to your Azure virtual machines: Azure Firewall or Network Security Groups (NSGs). They both serve the same objective, but which one should you choose, or can they be combined? This guide will address those concerns and demonstrate how to set up Azure Firewall from the ground up.
You’ll discover the distinctions between Azure Firewall and NSGs in this post, as well as where each fits in your environment. You’ll also see an Azure Firewall deployment and learn how to configure the firewall and route traffic via it.
Let’s get going!
If you’re new to Azure, you may be unsure about the differences between Azure Firewall and Network Security Groups (NSG), as well as when to employ NSGs against Azure Firewall. While they both filter traffic according to a set of criteria you specify, they each serve a distinct purpose.
Understanding and Configuring Azure NSGs Using PowerShell
Azure Firewall is a network virtual appliance that is controlled by Microsoft (NVA). This appliance enables you to design, implement, and monitor network security rules across Azure subscriptions and virtual networks from a single location (vNets). An NSG is a layer 3-4 Azure service that manages network traffic between vNets.
An NSG, unlike Azure Firewall, may only be linked to subnets or network interfaces inside the same Azure VM subscription. Azure Firewall has far more control over network traffic.
NSGs and Azure Firewall don’t have to function together. They may also collaborate, as indicated in the figure below.
Azure Firewall is located at the subscription level and regulates traffic entering and exiting the vNet. The NSG is then installed at the subnet and network interface levels (not shown). The NSG then handles traffic between virtual machines and subnets.
In this case, you may construct an NSG on the business tier that only allows database connections from the web tier, while setting the web tier to just allow HTTP/HTTPS traffic. The NSG and Azure Firewall both improve network security by providing “defense-in-depth.”
Use of Azure Firewall and NSGs together as an example
Putting Together an Azure Firewall
Enough with the rhetoric; let’s get your hands dirty with a demonstration of Azure Firewall in action! To do so, make sure you’ve met a few conditions before you begin.
Related: How to Get Microsoft Azure for Free: Everything You Need to Know
- Access to a subscription account with Contributor Permissions
Azure Firewall is a fee-based managed service. Check out the Azure Firewall Pricing page for more details.
Assuming you have a ready-to-use environment, you may establish an Azure Firewall by following these steps:
1. Go to the Azure Portal using your preferred web browser.
2. In the Search box, type “firewall” and choose Firewalls to open the Firewalls blade.
Setting up a Firewall Using Global Search
3. Click Create in the Firewalls blade.
4. Fill up all required data, such as the Azure subscription to which Azure Firewall will be deployed, the resource group (create a new one if necessary), and the region.
It is critical that you deploy to this area. The area must be the same as the vNet you wish to safeguard!
Include a Tier level as well. The Standard tier will be used in this lesson. Choose the Premium tier if you want more sophisticated capabilities such as TLS, URL Filtering, and an Intrusion Detection and Prevention System (IDPS).
Standard Tier Selection
5. Choose whether you want to control the firewall using a firewall policy or with conventional rules. To administer the firewall, this article will utilize standard firewall rules.
Unlike traditional rules, firewall policies may be applied to numerous firewalls. Classic rules will serve since the instruction will just be building a single firewall.
Using traditional firewall rules
6. Provide the name of the virtual network where Azure Firewall will be installed. As seen below, Azure needs the virtual network’s name to be precisely “AzureFirewallSubnet.” You can’t install the firewall successfully if the virtual network isn’t named appropriately!
The address space is fairly constrained. Azure firewall needs a minimum of 64 addresses. A CIDR range of 10.0.0.0/26 with 64 accessible IP addresses is shown in the example below.
Adding the Vnet name and the address space
Azure will reveal how many addresses will be accessible for a certain CIDR range if you check at the captions beneath the address space box. This will assist you in calculating the proper network range.
If you use a CIDR prefix that is more than 26, you will get an error message stating that the CIDR prefix must be less than 26.
Incorrect CIDR range error message
Putting the Route Table Together
It’s time to start sending traffic to the firewall now that you’ve finished setting it up. To do so, you’ll need to first establish a route table. The network routes that will guide traffic from devices on the vNet to the firewall will be stored in the route table.
To make the route table, first:
1. Open the Azure Portal’s Route tables blade by searching for “Route tables” in the top search box.
Route Table global search
2. Click Create in the upper right corner of the Route Table blade.
Make a route table.
3. In the Make a route table. blade, provide:
- The resource group to which the route table resource should be added.
- The region to which the route table resource should be added.
- Name — The route table’s name. Any name would suffice.
- Set this option to Yes to propagate gateway routes. In bigger business networks, this configuration will use routing protocols to advertise routes to other routers and gateways.
Entering route table information
4. When complete, click on Review & Create → Create.
Obtaining the Private IP Address of the Azure Firewall
You’ll need to build a default route once you’ve set up the route table. However, you must first locate the Azure Firewall’s private IP address in order to build a default route. Each device on the subnet you’re routing from will use the firewall’s private IP address as their default route or “default gateway” after it’s properly setup.
Navigate to the Azure Firewall you built in the previous step in the Azure Portal to get the Azure Firewall’s private IP. Select the Overview option. The Firewall private IP may be seen on the right side of the page. Make a note of this IP address. It will be required shortly.
Identifying a secret IP address
Creating a Standard Route
Now is the time to design the default route that will be used by all devices on the subnet that the firewall will protect. The default route directs all Internet traffic to the firewall for devices connected to the vNet.
Create the default route as follows:
1. Open the Azure Portal and go to the route table you generated before.
2. From the left menu, choose Routes, then Add.
Create a new route.
3. On the Add Route page, provide the following information:
- Route name – You may name your route anything you like. The name DefaultRoute will be used in this tutorial.
- Input all 0s in CIDR notation since the default route or “default gateway” is always 0.0.0.0/0. This prefix matches any traffic headed for an IP address outside your network from a device on your subnet. A “catch-all” address is 0.0.0.0/0.
- Because the firewall is a virtual appliance, the next hope type is virtual appliance.
- The private IP address of the Azure Firewall that you collected in the previous step is the next hop address.
When you’re finished, click OK.
Adding a Route Specifications
4. Next, on the default route you just created, click on Subnets —> Associate and input the vNet and subnet the devices you’d like the firewall to protect are attached to. This action will associate the default route to the subnet that your devices are using.
Connect a route table to a subnet.
When the subnet is complete, all devices connected to it will start delivering Internet traffic or 0.0.0.0/0 traffic to the firewall.
Creating Firewall Rules in Azure
The firewall and networking should now be configured, and Internet traffic should be routed via the firewall using the default route. Now is the time to set up a firewall rule.
Some devices on your vNet may need to resolve DNS with Google’s DNS servers over the Internet, which they may do across the firewall. Allowing devices to connect to Windows servers in the 10.0.0.0/16 network using the Remote Desktop Protocol may also be necessary (RDP).
As an example of how to create a few of Azure Firewall outbound rules:
1. Open the Azure Portal and go to the firewall.
2. Click on Rules (classic) on the left menu —> Network rule collection —> Add network rule collection. This action will bring up the new rule page.
Setting up a firewall rule
3. To establish the rule collection, provide the following information:
- Name — Give the rule collection a descriptive name. AllowDNS is used in the example below.
- Priority – The order in which the rules shall be applied. Until a match is discovered, the lower numbers will be processed first.
- Allow for action. Deny traffic depending on the pattern that the rule matches.
Create three rules for the traffic you need to let through towards the bottom of the screen, as seen below.
| Protocol | IP Address of Destination | Port of Arrival |
| UDP | 8.8.8.8 | 53 |
| UDP | 8.8.4.4 | 53 |
| TCP | 10.0.0.0/16 | 3389 |
You must define a few attributes for each rule:
- A human-friendly label is called a name.
- The protocol that the firewall will match. This may be TCP, UDP, or ICMP (traceroute or ping).
- If utilizing Firewall Policy, the source type is either the IP address(es) the traffic is originating from (IP Address) or the IP group.
- The IP network from which the traffic originates. A wildcard (*), a single IP address, or a CIDR block may be used as the source.
- Destination type — Only for destination traffic, the Source type.
- Destination Addresses — The traffic’s final destination. A wildcard (*), a single IP address, or a CIDR block may all be used as Destination Addresses.
- Port of Arrivals – The port that the incoming traffic is trying to connect to. For example, the DNS protocol listens on port 53.You should not specify an asterisk () for the source or destination address, if possible. The asterisk allows all source or destination traffic.
If at all possible, avoid using an asterisk (*) for the source or destination address. All source or destination traffic is allowed with the asterisk. If at all feasible, you should always limit your firewall rules to particular networks or IP addresses. If feasible, restrict your firewall rules to particular networks or IP addresses.
The rule page should look like this when finished.
Finished rules
Conclusion
You’ve now constructed an Azure Firewall, as well as all of the required networking and rules to route devices to it. You may now add more devices to your subnet and be certain that they will be protected by the Azure firewall.
Which option will you use next to safeguard your Azure devices now that you’ve set up the Azure Firewall and learnt a bit about NSGs?
The “deploy azure firewall to existing vnet” is a process that can be used to set up an Azure Firewall. The reason why the NSGS is not recommended, is because it would create a new VNet and then deploy the firewall into that VNet.
Related Tags
- azure firewall rules best practices
- azure firewall limitations
- azure firewall url filtering
- in azure firewall enables users on the internet to access a server on a virtual network
- azure firewall dnat
