Andrzej Kaczmarek Infrastructure & Cloud Architect
← All posts
azurenetworkingsecurityfirewall

Azure Firewall explicit proxy (preview): finally an alternative to the UDR dance

Azure Firewall has always intercepted traffic transparently via user-defined routes. A new preview setting lets clients point at the firewall as a real HTTP/HTTPS proxy instead — here is how it works, what it takes to set up, and where the preview still bites.

· 5 min read

Every Azure Firewall deployment I have built starts with the same piece of plumbing: a route table on every subnet, a 0.0.0.0/0 route pointing at the firewall’s private IP, and then a slow trickle of exceptions once someone discovers that a service doesn’t like having its outbound path silently rewritten. Azure Backup agents, certain SaaS installers, anything that pins outbound source IPs or gets confused by asymmetric routing back through a peered hub — they all eventually need a route exception, an SNAT hairpin fix, or a special case in the runbook.

That transparent, UDR-driven design is still the default and still the right choice for most workloads. But Microsoft has now documented a second mode: explicit proxy, currently in preview, which lets you configure the sending application — a browser, a CLI, anything that understands HTTP proxy settings — to send traffic straight to the firewall’s private IP as an actual proxy, no route table involved.

Transparent proxy vs. explicit proxy

In the existing (transparent) mode, the firewall intercepts traffic that a UDR has already routed to it, then forwards it based on network and application rules. In explicit proxy mode, the client is configured — manually, or via a PAC file — to treat the firewall as its HTTP/HTTPS proxy. Traffic goes there directly, so it egresses from the firewall without a UDR in the path at all. It currently supports HTTP and HTTPS only, and both protocols can share a single configured port.

This matters most in a few concrete scenarios I keep running into:

  • Azure Arc-enabled servers and hybrid workloads that need to reach Azure endpoints over a private connection (ExpressRoute or Site-to-Site VPN) without exposing the on-premises network to the public internet, and without retrofitting route tables across an existing on-prem network.
  • VDI and jump-box fleets where you’d rather hand out one proxy address (or one PAC file) via GPO/Intune than maintain routing at the VNet level for every new subnet.
  • Any environment where UDR sprawl has already become unmanageable and a route-free alternative is worth evaluating for new landing zones, even if you don’t migrate existing ones.

What you need before you start

Explicit proxy is configured on the Firewall Policy, not on the firewall resource itself — so if you’re still running classic rules without a policy attached, that’s the first gap to close. If you also want to host a PAC file directly on the firewall (instead of pointing every client at a manually configured IP and port), you need two more pieces:

  • An Azure Storage account with a blob container to hold the PAC file.
  • A user-assigned managed identity granted both Storage Blob Data Contributor and Storage Blob Data Reader on that storage account. Microsoft’s own walkthrough is specific about naming it with the prefix PacFileMSI- — worth following even though nothing enforces it, since it’s the convention their docs and samples use.

Setting it up

Enable explicit proxy in the firewall policy, and — importantly — still create an application rule to allow the traffic through; explicit proxy changes how traffic arrives at the firewall, not whether the policy allows it. Via PowerShell:

$exProxy = New-AzFirewallPolicyExplicitProxy `
    -EnableExplicitProxy `
    -HttpPort 100 `
    -EnablePacFile `
    -PacFilePort 130 `
    -PacFile "https://sampleurlfortesting.blob.core.windows.net/nothing"

$identityId = "/subscriptions/<sub-id>/resourcegroups/testrg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/PacFileMSI-eproxyidentity"

New-AzFirewallPolicy `
    -Name "fp1" `
    -ResourceGroupName "TestRg" `
    -ExplicitProxy $exProxy `
    -UserAssignedIdentityId $identityId

Or with the CLI, if you’re wiring this into a pipeline:

az network firewall policy create \
    --resource-group "testrg" \
    --name "testfwpolicy" \
    --sku Premium \
    --explicit-proxy enable-explicit-proxy=true http-port=9001 enable-pac-file=true \
      pac-file-port=122 \
      pac-file="https://eproxypstestresources.blob.core.windows.net/explicitproxycontainer/proxy.pac" \
    --identity "Identity_ID"

Note the separate pac-file-port from http-port — the firewall serves the PAC file itself on one port, and proxies client HTTP/HTTPS traffic on another. Once the PAC file URL and managed identity are wired into the policy, clients that fetch the PAC file get the proxy address and port without you touching their local configuration again — the usual win of PAC over static settings, now available without your own web server to host it.

Governing it once it’s live

Because explicit proxy is a policy-level setting, it’s also something you can — and should — enforce with Azure Policy rather than trust to tribal knowledge. Microsoft ships two built-in definitions worth assigning to any management group where you plan to standardize on this:

  • Enforce Explicit Proxy Configuration for Firewall Policies — audits or denies policies that don’t have explicit proxy enabled where you expect it.
  • Enable PAC file configuration while using Explicit Proxy — audits that a PAC file is actually configured wherever explicit proxy is turned on, so you don’t end up with a mix of manually configured clients and PAC-driven ones drifting apart.

Where the preview still bites

Don’t plan a production cutover on this yet. It’s HTTP/HTTPS only — no support for other protocols that transparent mode handles today, so this isn’t a wholesale replacement for your UDR-based egress path, just an additional option for the traffic that fits. It’s also in preview, which means it’s covered by Azure’s preview terms, not a GA SLA. And because the PAC file hosting path depends on a managed identity with a specific role assignment, misconfiguring that identity is the most likely first failure mode — test the PAC file URL resolves and downloads correctly before you point any real client population at it.

The takeaway

Explicit proxy doesn’t replace the UDR model most Azure Firewall deployments run today, and it shouldn’t — transparent inspection still covers far more protocols and doesn’t depend on every client being cooperatively configured. But for the specific pain of hybrid and Arc-connected workloads, VDI fleets, and any scenario where you’re fighting route table sprawl just to get HTTP(S) egress inspected, it’s a genuinely useful second option. Worth piloting in a non-production policy now, while it’s still preview and the blast radius of getting the PAC file setup wrong is small.

Sources & further reading: Azure Firewall explicit proxy, Azure Firewall preview features, Use Azure Policy to help secure your Azure Firewall deployments, Azure Firewall features by SKU.