Roger Carson

Just click it… what’s the worst that could happen?

4 minute read

When your private endpoints are to blocked… why?

The Setting

There is this hip and trendy thing called Zero Trust, and this dictates that, as you rightfully should, … NOT trust anyone or anything. Amongst other things, always be pessimistic and treat everything in your network as radioactive. This has an impact on the your Azure network. If you are using Azure native Resource to manage your network you will most likely end up using a combination of Azure Firewall, Network Security Groups, Private Endpoints. This post will not look into the details of how to create the various components but on one specific detail that caused a bit of headache for me.

The Goal

  • Protect your PaaS services with Private Endpoints by integrating them into you Azure virtual network
  • Use Network Security Groups to micro-segment your virtual network. Note that this for Private Endpoints is a fairly new feature.
  • Force all traffic to your Azure Firewall
  • Use the reccommended Application Firewall rules for PaaS services.

The Problem

Okidoki, this seems straight forward enough. How hard can this be? At this point I’m assuming you have:

  • A PaaS service up and running
  • It has a Private Endpoint with a Private DNS record in a Private DNS zone linked to your vnet (or vnet of your DNS servers that have been configured for the vnet where your PE is located.)
  • Your subnet is configured for XXXXXXXXX to make NSG’s inspect PE traffic.
  • You have an Azure Firewall Application rule that allows you to connect to your PaaS service
  • You have a route table sending traffic to the correct VNet
  • There is an NSG rule allowing traffic from your on-prem IP to the PaaS services
  • connecting to your private endpoint using IP works XXXXXXXXXX test this

Where things start to go wrong:

  • From On-Prem you are not able to connect to your PaaS service.
  • You verify traffic is coming in from On-prem and get an Allow in your Azure Firewall
  • After mulitple attempts you find out that if you set “Virtual network” as source you are able to connect
  • Your NSG flow logs have nothing relating to the PaaS service
  • If you deploy a VM in the same subnet, you create an NSG rule opening traffic between your VM and the PaaS Service, you log on to the VM and are able to connect to the PaaS service just fine. (even without the very much YoloIT virtual network as source rule) Disclaimer, without testing, I’m quite sure you would get the same behaviour if you sent all traffic even internally in your subnet to the FW first. Untested but i don’t know how this will react if your Azure Firewall is configured to be the DNS proxy for your network.

One way to do solve it

Short answer, in your NSG rule, set the Azure Firewall subnet (or if known DNS proxy IP’s ) as source. The clue here is that when you are coming from the other side of an Azure Firewall, Azure Firewall will always SNAT the everything covered by your Application Rules. This results in the Azure Firewall DNS Proxy IP now becoming the source. Read all about it: Azure Firewall SNAT private IP address ranges

Key takeaways:

  • By default, Azure Firewall doesn’t SNAT with Network rules when the destination IP address is in a private IP address range per IANA RFC 1918
  • Internet-bound traffic is SNATed to one of the firewall private IP addresses in AzureFirewallSubnet, hiding the source from your on-premises firewall. Because at this point your are trying to reach your Private Endpoint using a Private DNS Record that has a public address. (This address is in turn resolved to a private IP by your DNS servers in Azure)
  • To configure Azure Firewall to never SNAT regardless of the destination IP address, use 0.0.0.0/0 as your private IP address range. With this configuration, Azure Firewall can never route traffic directly to the Internet. If you are provide internet breakout in Azure, you would need to have a separate FW for that.

When you are connecting from your VM you are not going through your Azure Firewall meaning and the traffic will not go through the Application Firewall rule resulting in Azure Firewall SNAT’ing.

Next question is, how do i know what these IP’s are. Well, you can always check your Azure Firewall DNS proxy logs, you will find them there. Note that these Ip’s are not static and Azure Firewall may start using other IPs. So to be on the safe side you can add the the IP range used for your Azure Firewall subnet.

But I’m using Virtual wan, i don’t know what my AZFW subnet is!!! Yeah, you will need to make an educated guess… Find the IP of your firewall (located on your Firewall Resource tab), we know that Azure Firewall uses a /26 range Why does Azure Firewall need a /26 subnet size so based on this you can figure out what VWAN has used for your AzFW.

An untested solution is that Azure Firewall functions as your DNS proxy to resolve Private DNS records. This however has not been an alternative for me.

This solved it for me.

The Future

Yolo damnit… lets hope flow logs start picking up what is going on for the Private Endpoints. If it was logged this would be fairly easy to solve.

The End

Hope this helps!
Any questions, comments etc. send it to:



i.knew.it.always.blame.teamNetwork@yoloit.no
(Yolo off, never blame team Network, life is hard, be kind, give them a hug instead!)