The Azure Firewall Explicit Proxy Feature.

Exploring Azure Firewall Explicit Proxy Preview Feature

Hello! Welcome to my first project article on LinkedIn!

A few weeks ago, I embarked on a project aimed at routing all internet traffic from an on-premises environment through the Azure Firewall.

In this context, an on-premises environment refers to a physical location or organization that has a virtual private network (VPN) connection to its cloud resources. Specifically, in this scenario, all internet-bound traffic from the physical location must pass through the Azure Firewall already deployed in the cloud.

Below is the diagram illustrating my intended setup:

Yes, it seemed straightforward at first! However, I soon realized it was more detailed than anticipated.

The first challenge was establishing a physical location and creating a VPN tunnel to the cloud resources.

Since I couldn’t set up a physical on-premises environment, I opted to host everything in the cloud, including the on-premises environment itself, as a workaround. Much simpler, right? yeah.

I created three virtual networks (v-nets) in Azure and linked two of them (azvnet and Repro-Secured-Hub) using v-net peering. This setup is illustrated in PIC A and B below.

Pic A: Displays the three v-nets created in Azure.

Pic B: Illustrates the peering between azvnet and Secured-hub vnet.

An interesting aspect is the enabled gateway transit option on the v-net peering. This feature allows traffic from other paired v-nets to use the VPN gateway in the Azure v-net for traffic pass-through.

Next, I enabled connectivity to the third v-net by deploying two virtual network gateways in Azure—one in the Az-vnet and the other in the on-prem v-net. I then set up a site-to-site VPN tunnel between them. This setup is shown in Pic C, D, and E below.

Pic C: Shows the two VPN gateways created in both v-nets (Azvnet and Onprem v-net).

Pic D: Displays the two Local Network Gateways (LNG) that contain the local network address space and the public IPs of the two VPN Gateways to establish a tunnel connection.

Pic E: Shows the two connections on both sides of the v-net, indicating they are connected. One connection is from Azvnet to the on-prem v-net, and the other is from the on-prem v-net to Azvnet.

That took a while, but it looks good! References on how these were created will be included later in the article. Let’s move on! Ahead..ahead!?

Now that we have established all the necessary connectivity for the traffic, we can proceed to deploy the Azure Firewall in the SecureHub Vnet. This firewall will filter our outgoing internet traffic from the on-premises location.

The firewall was deployed with a Premium SKU and a firewall policy. A policy is essentially a rule collection book where rules to either allow or deny traffic are defined. We need this policy because it contains the Explicit Proxy feature I intend to use. Check Pics F and G.

Pic F: Displays the Azure Firewall Premium SKU deployed in the Repro Secured Hub Vnet.

Pic G: Displays the deployed Firewall policy, which is also attached to the firewall in Pic F above. Additionally, any colored shapes in the pictures are there to highlight specific points of interest.

So far, we have successfully achieved the diagram. Now, the routing challenge begins.

Initially, I thought that since we had connectivity to all v-nets and had configured the necessary settings to allow traffic through, the traffic should flow through the tunnel via the VPN gateway, then to the firewall via v-net peering, and finally to the internet.

The intended flow is: Client (PC)/request (e.g., www.gmail.com) >> VPN Tunnel >> V-net Peering >> Firewall >> Internet.

I deployed a single client PC (virtual machine) in the on-premises environment to initiate these internet requests. See Pics H and I below:

Pic H: Shows the client PC deployed in the on-premises network. No public IPs were attached to the virtual machine, as we want to prevent direct communication with the internet. It only has a private IP.

Pic I: Shows the NIC of the VM (client PC) deployed in the on-premises v-net. In the effective routes, I could observe that the client VM knows how to reach the Firewall’s v-net, having learned its route through the VPN gateway in its own v-net as the next hop point. It also knows how to reach any address within Azure’s v-net. This is because of the local network gateway attached to the on-premises VPN gateway, which I had specified these addresses on.

We can see that 0.0.0.0/0 (indicating traffic meant for the internet) is set to go directly to the internet through a public IP. However, since our VM currently has no public IP attached, the internet traffic will be dropped

Pic I: Displays the effective routes on the VM, showing 0.0.0.0/0 as the route to the internet

My primary objective is to gain access to the client VM on the on-premises network to initiate an outbound internet connection. Note that the VM does not have a public IP, but I have successfully established connectivity to the client VM through the firewall’s public IP.

This was how I gained access;

To achieve this, I created a DNAT rule in the firewall policy. This rule maps connections intended for my client VM to the firewall’s public IP. The firewall then translates these addresses and ports connections to the client VM. Consequently, the private IP address of my client VM is masked by the firewall’s public IP for inbound connections, as specified by the rule.

Below is the DNAT rule I created. The source is the public IP (blue circles) I want to use to access the VM. The destination is the firewall’s public IP (red rectangle), and the translated IP and port are the private IP of my VM.

Pic J: Allow Dnat rule to the client VM through the firewall’s public IP

After setting up this rule, I was able to access the VM by connecting to the firewall’s public IP and using port 3389, which is the standard port for Remote Desktop Protocol (RDP). This allowed me to manage the VM remotely from my personal machine.

Shown in PIC K.

Now that we have successfully gained access to the on-premises virtual machine, referred to as Onprem VM or the client PC, we can proceed with the next steps.

We will divide the article into two parts here:

Part A: Routing Internet Traffic Through the Firewall Without Using the New Firewall Feature (Explicit Proxy);

This section will cover the traditional method of routing internet traffic through the firewall.

Part B: Routing Internet Traffic Using the Explicit Proxy Feature;

This section will display how we were able to utilize the explicit proxy feature for routing internet traffic.

—------------------------------------------------------------------------------------------------------

Part A: Routing Internet Traffic Through the Firewall Without Using the New Firewall Feature (Explicit Proxy)

I created a single application rule on the firewall to allow traffic to .gmail.com and .google.com. I discovered that gmail.com redirects to a different hostname within .google.com, as shown in PIC L below. The (*) wildcard includes all subdomains under the specified hostname.

In the rule:

The source IP is my on-premises private IP (highlighted in blue).

The protocols used are 80 and 443 (highlighted in yellow).

The domain names (FQDNs) are highlighted in red.

Pic L: Firewall rule showing allow on application rule to Gmail and Google domains.

When trying to access www.gmail.com in the browser, the request failed. Upon inspecting the request using the developer tools, we found that the Fully Qualified Domain Name (FQDN) did not resolve to any IP address, as illustrated in Pic M below

Pic M: This image depicts the initial attempt to access www.gmail.com, which failed as anticipated

"This outcome is expected. Why? Because the effective route on the VM directs all outbound traffic to 0.0.0.0/0 with the next hop set to the internet, and there is no public IP directly assigned to the VM.

How can we resolve this?

Initially, I created a UDR and linked it to the VM, setting the firewall’s private IP as the next hop for all 0.0.0.0/0 traffic to the internet, knowing that the VM learns the firewall’s IP address space from the VPN gateway. However, as shown in PIC N, this approach did not work.

Pic M: Displaying the route table attached to the VM, directing internet traffic to the firewall.

I wanted to understand why it wasn’t working, so I consulted my colleague Onakorame Dimon , who is quite knowledgeable about routing. After explaining my goals, we concluded that the next hop address should be the virtual network gateway on the on-premises VNet, not the firewall. Why? Because the virtual network gateway knows how to reach the firewall’s VNet due to its learned route.

Additionally, a UDR is needed on the virtual network gateway in Azure’s VNet to direct internet traffic to the firewall as the next hop. If we can route the traffic to the firewall’s VNet through the virtual network gateway in the on-premises VNet, we are one step closer.

I went back to the project environment then changed the quad zero-routes from the firewall to the virtual network gateway as the next hop. This way, the virtual network gateway can push my traffic through the tunnel.

Here is a diagram of my next steps, highlighted in red rectangles. UDR stands for user-defined routes.

Pic N: Illustrating my next steps, which involve adding a UDR on the on-premises VM and on the gateway subnet of the Azure VPN gateway.

“Then another challenge arose!

I successfully pointed all quad zeros to the on-prem VPN gateway. However, on the Azure VPN gateway, a UDR with quad zeros to the firewall as the next hop was not supported, as it would disrupt control plane traffic. Major obstacle!”

Pic N: UDR for all internet traffic on the on-premises VM to the virtual network gateway as the next hop.

Pic O: UDR to be attached to the Gateway subnet, resulting in an error!

My next question was how to bypass this blocker. Olufemi Ogidan came to mind—he is one of my team's go-to person for CCI (complex cool ideas that work), as I like to call it. Feel free to reach out to him as well.

He is one of the few people who gave me a detailed breakdown of how the explicit proxy feature works. Emmanuel Aronmwan , my supervisor and Subject Matter Expert, was the first and who advised I take a deeper look to understand better. They knew the feature was still in preview mode and understood my end goal.

Regarding my blocker, I consulted Femi about the issue of not being able to override quad zero routes on the gateway subnet. Instantly on the spot, he suggested overriding the route with an address prefix that supersedes quad zeros, such as 0.0.0.0/1 and 128.0.0.0/1. I blinked twice, trying to grasp what he meant.

Without further questions, I proceeded to add these routes and attach them to my Azure VPN gateway subnet. Surprisingly, it worked. I successfully attached these routes to the Azure VPN gateway subnet with the firewall private address as next hop.

Pic P: Routes created

Pic Q: Routes added to the gateway subnet on Azure VPN gateway.

At this point, I have established a UDR to the on-prem VPN gateway to route all internet traffic through the gateway and created a UDR on the VPN gateway on Azure to push the internet traffic to the firewall as the next hop.

I then re-initiated a request to www.gmail.com on my on-premises VM again.

Pic R: Hit the FQDN, but it did not respond. No IP addresses were mapped to the request.

At this point, I became more interested because if I am not able to establish outbound connectivity from the on-premises VM with the same firewall I came in with, how do I proceed with Part B using the explicit proxy? These were my thoughts.

Pic S: I checked the firewall logs I had set up but did not see any traffic hitting the application rule.

Then I realized the traffic was not reaching the firewall. However, I wondered how I was able to log in to the VM in the first place using the firewall’s public IP, which confirmed connectivity to the on-premises VM. Despite this, I couldn’t send traffic to the internet. Note that my NSG rules on the VM were wide open for the project.

I then reached out to Dennis Balogun , who is intelligent and skilled at deciphering complex ideas and breaking them down for better understanding. We discussed the architecture in detail, making sure he got a hook of the project, because I knew that once he understood it, he would stay with me on the project until the end. And guess what? He stayed until the very end.

In Dennis’s voice: This architecture is good, but the current configurations might not work because we have a tunnel to manage. Routing all internet traffic in this scenario, through the tunnel requires using a Default site on one of the virtual network gateways. I looked at Dennis with wide eyes and blinked twice.

He understood the signal and shared the documentation about default site configuration, while explaining further. Routing all internet traffic through a gateway is known as forced tunneling, which involves making some CLI configurations on one of the VPN gateways, depending on where we want the traffic to flow from.

Don’t worry, I’ll share the documentation later as a reference.

During our conversation, I mentioned that my intention was for all traffic from the on-premises network to go through the tunnel and head straight for the firewall, as I already have an allow rule in place.

We then agreed that since the on-prem VPN gateway is closest to this traffic, it’s best to create the default site on it as we were concerned with on-prem's traffic and not azures. We got the command below and ran it.

>>The Default site configuration.

$LocalGateway = Get-AzLocalNetworkGateway -Name "OnpremToAzureLNG" -ResourceGroupName "ReproductionRG"

$VirtualGateway = Get-AzVirtualNetworkGateway -Name "OnpremVNG" -ResourceGroupName "ReproductionRG"

Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway

The first two lines is used in retrieving the name of the local network gateway and the virtual network gateway of interest then stores in in the defined variable before we ran a set Default site command.

Pic T: Displays the VPN gateway and the Cloud Shell command executed for the default site.

We proceeded to check the effective routes of the VM and noticed something interesting:

In PIC U, we observed that the UDR we created and attached to the VM to route all quad zeros to the VNG was active and valid. Additionally, we saw a new quad zero entry introduced by the default site, but it was tagged as invalid because the UDR supersedes the default site configuration in this scenario.

In addition, there was a specific VPN gateway address that was specified by default, unlike the UDR we created. You can compare PIC U and PIC N to spot the differences. Therefore, we removed the UDR on the VM and left only the default site configuration which turned active, as shown in PIC V.

Pic U: Displays the effective route after the default route has been added.

Pic V: Displays the effective routes on the VM after removing the UDR on the VM subnet.

Now, we proceeded to hit the FQDN again on the VM. I literally closed one of my eyes while typing the hostname: www.gmail.com on my browser.

Pic W: Picture showing the FQDN hit to www.gmail.com, which responded! Wow!.

Success! We observed the incoming traffic, and the FQDN resolved to one of the servers hosting the service. It was a beautiful sight!

Next, we checked the firewall logs and confirmed that the rule was indeed hitting the firewall.

Pic X: Firewall logs showing rules allowing traffic to www.google.com, initiated from the on-prem

Now, the traffic from the on-prem VM successfully traverses the tunnel and is directed by the UDR on the Azure VNG to route traffic to the firewall, as confirmed by the logs.

PART A COMPLETED

—------------------------------------------------------------------------------------------------------

Part B with the use of Explicit Proxy feature on the firewall.

According to the Microsoft documentation on the Explicit Proxy feature with Azure Firewall, the firewall typically acts as a transparent proxy, responding to UDR configurations for source and destination traffic from Azure. However, with the Explicit Proxy feature enabled, UDR configurations, including the Default Route, are not necessary.

All we need to do on the firewall is to enable the Explicit Proxy feature on the firewall policy and specify the ports for HTTP and HTTPS, as shown in PIC Y below.

PIC Y: Enabled the Explicit Proxy feature in the firewall policy and specified random ports, the HTTP port as 7000 and the HTTPS port as 8000

Next, we followed the documentation by specifying the firewall IP and mapping it to the ports configured for the Explicit Proxy on the firewall.

Here’s how we did it:

On the client machine, we navigated to the network settings and enabled the proxy server feature, as shown in Picture Z below.

Pic Z: Displays the proxy settings on the client VM, where the ports are configured to match the Explicit Proxy ports specified in the firewall proxy settings.

After saving the settings, we tested our FQDN again. This time, it successfully resolved to the firewall’s private IP along with the specified port.

We can also observe the traffic being allowed in the firewall logs.

Now for the most interesting part: we removed all UDRs and the Default Route on the gateway, reverting to our initial architecture. As shown in PIC I, the effective routes were updated after deploying everything mentioned above. We only allowed the FQDN in the rule, initiated the request, and it was successful!.

This means we don’t need to worry about how traffic moves from one hop to another. We just need to ensure connectivity between the VNets and resources while the Explicit Proxy feature works its magic.

Really cool feature!

Furthermore, there are some awesome configurations you might want to try later, such as the auto proxy configuration on the firewall with the use of a script known as the PAC (Proxy auto-configuration), where a SAS link to a PAC file containing the proxy ports is configured.

These scripts are also uploaded on the client machine to sync their connectivity.

You can check the Microsoft documentation for more information. In addition, if you have other features and cool Ideas, regarding this feature you intend taking up with microsoft, a platform that is highly monitored has been created Here: Share your ideas with 微软 (Ideas · Community (azure.com) for any further enhancements you might wish to include, as the feature is still much in its preview mode and not in General Availability.

Thank you all so much for your time on this!

A very BIG shoutout to all my Lovely Team members, whom we thrive on a daily basis to become better, who assisted on this project and one way or the other contributed to our learning. You guys are wonderful, and I appreciate you.

We would love your thoughts, comments, observations, and suggestions on how we could improve the architecture or configurations.

You never know, you might actually help with a big blocker!

Feel free to check out the reference materials below.

Until I come again with another interesting project story…

Stay safe and keep learning!

Warm Regards,

OLUWAFEMI BUSARI.

Reference Materials:

Quickstart: Use the Azure portal to create a virtual network - Azure Virtual Network | Microsoft Learn Tutorial – Create & manage a VPN gateway – Azure portal - Azure VPN Gateway | Microsoft Learn

https://learn.microsoft.com/en-us/azure/vpn-gateway/site-to-site-tunneling?

Azure Firewall Explicit proxy (preview) | Microsoft Learn

Demystifying Explicit proxy: Enhancing Security with Azure Firewall - Microsoft Community Hub

Hub-spoke network topology in Azure - Azure Architecture Center | Microsoft Learn