Azure Virtual Machine (VM) / Instances How to Whitelist IP Addresses in Azure Firewall

Introduction: Your Firewall, But With Better Manners

Azure Firewall is the bouncer at the club. It doesn’t just decide who’s cool—it decides who gets in, who gets told to wait outside, and who gets sent back to wherever they came from with a look that says, “I’m not mad, I’m just disappointed.” The problem is, by default, your firewall is not mind-reading. If you want certain IP addresses to be allowed, you have to tell it clearly.

This article explains how to whitelist IP addresses in Azure Firewall. We’ll cover what “whitelisting” really means in Azure Firewall terms, which rule type to use, how to structure your rule collections so they don’t get stepped on, and how to avoid those classic “why isn’t it working?” moments—usually caused by one tiny detail such as the wrong port, the wrong direction, or forgetting that your source and destination roles matter.

We’ll keep it practical and readable, with a clear structure so you can follow along without having to summon the Azure Portal gods.

Before You Start: What “Whitelisting” Means in Azure Firewall

People say “whitelist” as if it’s a magic button that says, “Allow these IPs.” In Azure Firewall, “allow these IPs” is usually shorthand for a specific network flow match. A rule decides whether a packet or connection is allowed based on criteria such as:

• Direction (source-to-destination, inbound vs outbound logic depending on your topology)
• Protocol (TCP, UDP, or both)
• Destination ports (and sometimes destination addresses)
• Source addresses (for allowing specific clients)
• Destination addresses (for allowing access to specific services)

So when you “whitelist” an IP address, you’re really defining a network rule condition that matches traffic from that IP (or to that IP) and allows it for the required ports.

Choose the Right Firewall Rule Type: Network Rules vs Application Rules

Azure Firewall has different rule collection types depending on what you’re filtering:

• Network rule collections: Best for IP-based and port-based control. This is where most “whitelisting IPs” happens.
• Application rule collections: Best when you need to filter based on FQDN (domain names) and application ports. This is more common for HTTP/HTTPS style traffic.

If your goal is literally “Allow traffic from these IP addresses,” you’re almost certainly looking for Network rule collections. Application rules are useful when you’re trying to allow specific domains rather than raw IPs.

Key Concepts You Should Know (So You Don’t Chase Ghosts Later)

Rule Collections and Priorities

Azure Virtual Machine (VM) / Instances In Azure Firewall, rules live inside rule collections. Each rule collection has a priority. Lower numbers typically mean higher priority (so the firewall checks them first). If multiple rules could match, the priority order and type determine what happens.

If your whitelist rule “isn’t working,” it’s often because:

• Your rule priority is lower than another rule that blocks or doesn’t allow the traffic you need.
• The rule is in the wrong collection type (Network vs Application).
• The matching criteria (source/destination/port/protocol) don’t line up with the actual traffic.

Source vs Destination: The Most Common “Operator Error”

When you’re whitelisting, you must be precise: are you allowing traffic from a specific IP (source) or allowing traffic to a specific IP (destination)?

Example scenarios:

• If you’re allowing a partner office IP to access your service: that partner IP is typically your source.
• Azure Virtual Machine (VM) / Instances If you’re allowing your VMs to reach a specific external endpoint: that endpoint IP is typically your destination.

Azure Firewall rules won’t interpret vibes. It matches fields.

Address Groups: Don’t Repeat Yourself Like a Broken Playlist

Azure provides address groups, which let you bundle IPs and subnets under a single name. This becomes extremely helpful when:

• You have many IPs to whitelist.
• Your IP list changes frequently.
• You want a cleaner rule that doesn’t look like a phone book.

We’ll show how to use address groups, but you can also whitelist using explicit IPs directly in rules.

Azure Virtual Machine (VM) / Instances Prerequisites: Things You Need Before Whitelisting

Before you start clicking around, gather the following:

• The source IP addresses you want to allow (if your clients are coming from fixed IPs).
• The destination IP or subnet of the service you’re protecting (if needed).
• The protocol (TCP/UDP).
• The destination ports (for example 443 for HTTPS).
• Whether the traffic is inbound or outbound in your architecture (Azure Firewall operates within your routing design, typically controlling traffic via forced tunneling or route tables).
• Your Azure Firewall policy type (stateful firewall behavior matters, but mostly the rule configuration is consistent).

If you’re unsure about the flow, it’s worth doing a quick packet/connection review from the client side or from your server logs to confirm what source/destination/port is actually used.

Step-by-Step: Whitelist IPs Using Network Rule Collections

Let’s do the main thing: create a Network rule collection that allows traffic for specified IPs and ports.

Step 1: Identify Your Rule Collection Location (Firewall vs Policy)

Azure Firewall can be managed directly or via an Azure Firewall Policy (depending on your setup). Typically:

• If you use an Azure Firewall Policy, you configure rule collections inside the policy.
• If you configure directly on the firewall, you still create rule collections, but the UI path differs slightly.

In either case, the concept is the same: you’ll add a Network rule collection with an allow action.

Step 2: Create or Decide an Address Group (Optional but Recommended)

Suppose you want to allow access from these partner IPs:

• 203.0.113.10
• 203.0.113.11
• 203.0.113.12

If you plan to reuse this list or expect changes later, create an address group. You’d name it something like partner-allowed-ips.

In the address group, you add those IPs. You can also include CIDR ranges if your partners use subnets instead of single IPs.

If you don’t want address groups, you can list the IPs directly in the rule’s source fields—but that makes updates annoying when the partner changes one address and suddenly you’re manually editing rules like it’s 2007.

Step 3: Add a Network Rule Collection

Now we create the allow rule collection.

In the Azure portal:

• Go to your Azure Firewall (or Firewall Policy).
• Find the section for rule collections.
• Create a new rule collection.
• Select Network rule collection.

Choose:

• Name: something descriptive like Allow-Partner-IP-HTTPS
• Priority: pick a priority that ensures it’s evaluated before any conflicting rules
• Action: choose Allow

Step 4: Configure the Network Rule (The Real “Whitelist” Part)

Inside the network rule collection, you’ll create a rule like:

• Rule name: e.g., Allow-Partner-To-AppServer
• Source: your whitelisted IPs (or address group)
• Destination: the target IP or subnet (optional depending on your needs, but usually you specify it)
• Protocol: TCP
• Destination ports: e.g., 443

Let’s say you’re allowing partner IPs to access an internal web server at 10.1.2.4 on HTTPS port 443. A typical rule would look like:

• Source addresses: partner-allowed-ips (203.0.113.10-12)
• Destination addresses: 10.1.2.4
• Destination ports: 443
• Protocol: TCP

Notice how this is not just “allow an IP.” It’s “allow that IP to reach that destination on that port using that protocol.” This is why wrong ports are such a common source of heartbreak.

Step 5: Save and Deploy

Hit save. Azure may show a brief “deploying” status. Don’t panic—Azure is just doing its thing.

Azure Virtual Machine (VM) / Instances Depending on your policy setup, the rule might take effect quickly, but it’s still smart to give it a minute before testing.

Testing: How to Confirm Your Whitelist Actually Works

Testing is where the firewall either becomes your trusted coworker or your office nemesis. Here are practical checks:

Step 1: Test From the Whitelisted Source IP

From a machine with source IP 203.0.113.10 (or whichever IP you whitelisted), try connecting to the destination/port.

For HTTPS, you might test:

• Browser access (if relevant)
• curl to https endpoint
• PowerShell test-netconnection (Windows)

If the connection fails, it’s usually because either the rule doesn’t match or another control blocks the traffic.

Step 2: Verify the Port and Protocol

Double-check that the service is actually using the destination port you whitelisted. Many apps have “helpful” redirects or alternate ports (or you accidentally whitelisted 80 when the app is listening on 443).

Also confirm TCP vs UDP. Azure Firewall network rules are protocol-specific.

Step 3: Check Logs (Azure Firewall Diagnostics)

Azure Firewall can produce logs for allowed and denied flows (depending on your diagnostics configuration). Make sure diagnostics are enabled to view:

• Whether the flow matched your rule
• Whether it was denied
• What fields were detected (source, destination, port)

Logs are your truth serum. If the logs show your expected source IP but an unexpected destination port, you’ve found the culprit.

Common Mistakes When Whitelisting IPs (AKA: How People Accidentally Summon Chaos)

Here’s a list of mistakes so common they probably deserve their own sitcom title.

1) Whitelisting the Source IP, But the Traffic Is Coming From a NAT Gateway

If your client traffic goes through a NAT device, the firewall sees the NAT’s public IP, not the original internal client IP. So your whitelist might be perfectly correct but for the wrong observed source address.

Fix: whitelist the actual source IP as seen by Azure Firewall.

2) Confusing Destination Subnet with Destination Address

Azure Virtual Machine (VM) / Instances If your rule expects a specific destination IP (like 10.1.2.4) but your traffic targets 10.1.2.5, it won’t match. Similarly, if the traffic targets a different subnet, you need to update the destination field (or broaden it carefully).

Fix: align destination address/subnet with what the traffic actually uses.

3) Wrong Directionality in Your Mental Model

Azure Firewall enforces rules for flows as they traverse it, based on how you route traffic through it. People often assume “inbound rules” behave like a classic server firewall.

Fix: confirm the traffic path and ensure the rule matches the flow the firewall sees.

4) Setting Priority Incorrectly

If you have a deny rule (or a default deny behavior) that’s taking precedence, your allow rule might never get evaluated as you intend.

Fix: adjust rule collection priority and ensure your allow rule is evaluated earlier.

5) Whitelisting the Right IPs, But Wrong Ports

This one is classic. You whitelist port 443 because it’s HTTPS, but your app is actually using 8443 or something else.

Fix: confirm the port, then update destination ports in the rule.

Using Address Groups for Cleaner, Safer Whitelisting

Let’s talk about why address groups are the grown-up option.

Imagine you whitelist 50 IP addresses and then one partner decides to change addresses. Without address groups, you’d edit every rule to update that list. With address groups, you edit the address group once and every rule that references it gets updated automatically.

Also, address groups make your rule collections easier to review. When someone (maybe future you) looks at your configuration, it’s far more readable to see:

• Source: partner-allowed-ips
• Destination: app-subnet
• Port: 443

Instead of:

• Source: 203.0.113.10, 203.0.113.11, 203.0.113.12, ... plus 47 more IPs

Future you will thank you. Future you is always looking for ways to avoid writing apology emails.

Azure Virtual Machine (VM) / Instances Optional: Whitelist Based on FQDN With Application Rules (When IPs Aren’t Friendly)

Sometimes you can’t whitelist IPs reliably because the service you’re allowing uses dynamic IP ranges. In those cases, FQDN-based filtering is often more stable.

Application rule collections allow you to specify:

• Target FQDNs (like api.example.com)
• Protocols (typically HTTP/HTTPS)
• Ports (commonly 80/443)

If your scenario is “allow access to a domain from my whitelisted clients,” you may need a combination:

• Use Network rules to allow the client IPs to reach the firewall/route as needed
• Use Application rules to allow specific domains

But if your primary requirement is “whitelist these IP addresses,” Network rules are the main event.

Example Scenarios: Pick Your Adventure

Let’s walk through a few realistic scenarios so you can map them to your setup.

Scenario A: Allow a Partner Office IP to Access Your Public API

Your partner has a fixed public IP, say 198.51.100.25. Your API is hosted on an internal VM at 10.2.3.4, and it’s reachable on TCP 443.

Your network rule should allow:

• Source: 198.51.100.25
• Destination: 10.2.3.4
• Destination port: 443

Then test from the partner network. If it fails, check whether the partner traffic is being NATed before it reaches Azure Firewall.

Scenario B: Allow Your VMs to Reach an External Service at Specific IPs

Your application servers need outbound access to a vendor’s fixed IP, 203.0.113.77, on TCP 443.

Your rule should allow:

• Source: your VM subnet (or specific source addresses)
• Destination: 203.0.113.77
• Destination port: 443

If the vendor IP changes, you’ll need to update the rule. If the IP is not stable, consider FQDN-based Application rules instead.

Azure Virtual Machine (VM) / Instances Scenario C: Allow Multiple Ports for the Same Whitelisted IPs

Your whitelisted IPs need access to both HTTPS (443) and a custom port (8443). You can include multiple destination ports in the same rule, as supported by the rule configuration.

Just make sure you include the correct protocol. If one port uses TCP and another uses UDP, they may need separate rules.

Operational Tips: Keeping Your Whitelist Healthy Over Time

Whitelists tend to grow like mold on bread: slowly at first, then all at once when someone adds “just one more IP” during a fire drill.

Here are operational tips to keep things under control:

• Use address groups to manage IP lists cleanly.
• Use descriptive rule names (e.g., “Allow-PartnerX-443”).
• Document why each rule exists and who requested it.
• Set a review cadence (quarterly is common) to remove stale IPs.
• Test changes in a non-production environment if possible.

Also, consider that IP whitelisting is inherently brittle if the provider’s IPs change. If the IPs are not guaranteed stable, you may eventually need a more domain-based approach.

Troubleshooting Checklist (When It Still Doesn’t Work)

Here’s a fast checklist you can run through like a mental flowchart.

• Are diagnostics enabled? If you can’t see logs, you’re troubleshooting blind.
• Does the log show the expected source IP? If not, NAT or routing is changing it.
• Does the log show the expected destination IP? If not, your service address differs from what you configured.
• Is the destination port correct? Check application port and any redirects.
• Is protocol correct? TCP vs UDP matters.
• Is rule priority correct? Ensure allow rule is evaluated before any denying/conflicting logic.
• Are you whitelisting in the correct rule collection type? Network for IP/ports; Application for FQDN.
• Is traffic actually traversing Azure Firewall? Sometimes routing isn’t set up as expected, so the firewall never sees the connection.

If you still get stuck, the logs typically point to the missing piece. Azure Firewall is like a chatty coworker: not always comforting, but usually revealing.

Conclusion: Your Whitelist, But Make It Reliable

Whitelisting IP addresses in Azure Firewall is straightforward once you treat it like what it really is: matching network flows based on source/destination, protocol, and ports. Use Network rule collections for IP-based allow lists, consider address groups to keep your configuration maintainable, and pay special attention to rule priority and directionality.

And remember: if it doesn’t work, it’s rarely because Azure Firewall is “buggy.” It’s usually because the packet doesn’t look like you thought it would. Logs, priorities, and port/protocol alignment will get you to the finish line—preferably before the next on-call paged everyone’s phone like a tiny, angry kazoo.