When using PaaS services in a hub-and-spoke architecture a best-practice approach is to use Private Endpoints for accessing those services. This allows us to ensure that these services are only available internally in the Azure VNET and not publicly available. Private Endpoints is a virtual NIC (Network Interface Card) which is placed within a virtual network and is attached to a PaaS service.
Unlike regular NICs, private endpoints are a bit more special
- Private Endpoints only support TCP (not ICMP/UDP).
- They do not support NSG flow logs. So, this means that traffic analysis is not going to work.
- They will automatically use a /32 default route that will be propagated across its own virtual network and other peered virtual networks.
- You can now configure a UDR or NSG for a private endpoint but that requires that certain network policies are in place to allow communication.
By default, a private endpoint will automatically create a /32 default route which will automatically propagate to the VNET it resides in and other peered VNETs. This means that if you have a hub-and-spoke model where you have a Private Endpoint in one of the spokes then the private endpoint default route will be also propagated into the hub network as well.
Unfortunately, as well there is no option to see these routes directly on one of the private endpoints, therefore if you want to see the routes you need to do it from a virtual network card in the Azure portal that is attached to a virtual machine. If you check the system routes on one of the endpoints, you will see something like this. It should also be noted that this route is only working for TCP-based traffic.
Azure will route traffic based upon the following longer prefix wins so for instance 10.0.0.0/24 wins over 10.0.0.0/16. If you have a route on the same prefix, Microsoft will use the following priority.
- User-defined routes
- BGP routes
- System routes
The example you see below is for a normal VM where there are two private endpoints without any network policies enabled and traffic will then go directly the the private endpoint. The ONLY way I could override this before is if I had a /32 route to override the other one coming from the private endpoint to force traffic to a centralized point such like an Azure Firewall.
Now what if we enable network policies for a subnet which contains the Private endpoint (10.0.2.0/24)? You can now see that the UDR has now been prioritized (Even if it has a lower bit range defined). Meaning that if you have network policies enabled, is just means that you can override the default routes without the need of a /32 route set.
Changing the network policies is done on a subnet level so when you open the subnet settings within a virtual network you have this option at the bottom as seen in the screenshot above.
And as with most private endpoint connections if you want to make sure that traffic flow works you still need to have a SNAT connection between them if not you will have a split routing situation. The most common use there is to make sure that you are using Application rules in Azure Firewall between your services and private endpoints. Since application rules are doing SNAT, which means that the private endpoint will then route traffic back to the Azure Firewall instead of trying to go directly to the VM.