Can you access Microsoft Azure if your firewall is blocking all traffic?

This one is easy. If you block and deny all traffic in your firewall, you cannot access any Azure services.

Someone asked me this question a few months ago, and I wanted to test what happens and how a company can block all traffic except Azure’s necessary traffic. Let’s see how this goes.

Preparing a lab environment

In preparation, I provisioned a fresh Windows 10 Pro virtual machine. Once it was ready, I patched it with the latest Cumulative updates and Feature updates. The version was upgraded to 20H2.

It isn’t domain-joined, and I didn’t configure it beyond bypassing my Pi-Hole filtering in my home network (by pointing to Cloudflare’s 1.1.1.1 solution).

I then went to Windows Defender Firewall and reviewed the outbound rules:

It’s a long list of specific rules that allow traffic out from the VM. I selected all of these and hit delete. The default action for Windows Defender Firewall is to block traffic that doesn’t match a rule.

In effect, all outbound traffic from this Windows 10 VM is now disabled (unless specifically allowed with a firewall rule). Since it’s cumbersome to work with the rules, I installed the Malwarebytes Windows Firewall Control app. It’s a neat app that allows you to configure the firewall in a more agile way.

I set the app to notify me when something gets blocked. Soon enough, I had 10 new rules to have basic local networking – such as acquiring an IP from the DHCP server – working. But effectively, all traffic to the rest of the world – including Azure – is now denied.

The first time I ran the new Microsoft Edge (after Windows Update completed and refreshed my instance to 20H2 with the new Edge), this notification greeted me immediately:

Accessing Azure

We’ve now painted ourselves in the corner. All outbound traffic – except the usual local network services – is blocked. All Windows 10 telemetry is also blocked, so not even Windows Update works anymore. Let’s try to access Azure through Azure Portal!

So, that was an uneventful test – it doesn’t work. Instead of blindly opening a random IP address, let’s try to work on what needs to be allowed for outbound traffic on our firewall.

Microsoft publishes the public IP address ranges for their public cloud services. It’s a hefty-sized JSON file, which you can download here. It’s 83,541 lines – a few decorations here and there, but mostly it’s IP address ranges. Many seem to be smaller blocks, such as /28 or /32 – but over a hundred are larger class B blocks (/16). I didn’t have the interest to add them all up, but it’s hundreds of thousands of IP addresses in total.

Do I need to allow them all? Wouldn’t it then make more sense not to block all outbound traffic? When you allow thousands upon thousands of IP addresses, it quickly becomes unmanageable. You need to keep track of updates to the published IP address ranges and update the deltas to your firewall rules. Daily.

I took a further look at the JSON file. What’s great about it is that the different IP ranges are segregated per service – so IP ranges required for Azure Active Directory are listed separately, for example:

Azure has a lot of services – hundreds, depending on how you tally them up. I wouldn’t see it as an insurmountable task to list all the relevant ranges and then scripting the rules for Windows Defender Firewall based on those.

Let’s try this – Azure Portal has many listed IP ranges that I need to list in an allow rule for outbound traffic. Instead of typing more than a hundred IP ranges manually, I used PowerShell to add them all up:

New-NetFirewallRule -DisplayName "Allow Azure Portal outbound" -Direction Outbound -RemoteAddress 13.67.35.35/32, 13.67.35.77/32, etc. -Action Allow

Once ran, I verified I had the new rule in my outbound rule list. It also has the IP Addresses listed:

Unfortunately, I still couldn’t use Microsoft Edge to access Azure Portal – as it defaults to authenticating me via another service – which is blocked. So I carefully allowed these few additional IP addresses also. And retrying, Azure Portal now opens beautifully in the browser!

Additional thoughts

When I set out to write this post, I wasn’t sure how this would end. Why would anyone block all outbound traffic yet still expect access to Azure? Well, sometimes companies do weird things – like block everything, except traffic marked as trusted or safe.

Perhaps a more viable option would be to build a secure IPSec tunnel to an Azure VNet – but even that isn’t always a viable option. It was interesting to try out this hypothesis that by carefully adding the advertised (trusted) Azure public IP ranges, one can clearly control what portions of Azure are accessible. Obviously, the purpose of this shouldn’t be to deny users from doing certain things but to carefully allow just certain traffic while staying focused on what is needed and what should be blocked.