Private Link UDR Support

André van der Goes 1 Reputation point
2022-06-17T06:14:24.81+00:00

I have two questions related to the subject of 'Private Link UDR Support'.

The first and perhaps most important one: Is this currently still in Public Preview or has it been upgraded to GA? Because all the documentation still states it is in Public Preview. However, if I create a private endpoint through the portal this is no longer disabling the 'privateEndpointNetworkPolicies' but as default leaves it enabled. To be clear, this is in subscriptions where the feature 'Microsoft.Network/AllowPrivateEndpointNSG' is not registered.

212307-pep-policy-enabled.png

212343-feature.png

It is also possible to deploy private endpoints through bicep/ARM templates without disabling this policy (Unless my memory deceives me, before you had to disable the policy or the deployment would fail).

The documentation states that because the feature is in preview, this is not covered by SLA. But if that is the case it should not be enabled by default?
https://learn.microsoft.com/en-us/azure/private-link/disable-private-endpoint-network-policy

The second question is for clarification on how the UDRs work in combination with private endpoints. What I can find in the documentation is that pep still do not follow UDR and the preview just relates to routes to the PEP (overriding the interfaceEnpoint routes).

However, when testing this out with 'privateEndpointNetworkPolicies' enabled (still without registering the preview feature!) I have created a test hub/spoke network with the following components:

  • 'Onprem': Connected to the hub vnet via a virtual network gateway. Containing a vm for testing access to private endpoints
  • 'Hub': hub vnet with a linux VM acting as router and a virtual network gateway. The GatewaySubnet has routes for the spoke address ranges pointing to the firewall
  • 'Spoke1' containing a storage account and keyvault connected to a subnet via private endpoint
  • 'Spoke2' containing a vm for testing access to private endpoints
  • Both spokes have a route table sending 0.0.0.0/0 to the router in the hub

All of this works as expected, on the router I see traffic:

  • Bidirectional from onprem to both Spoke1 peps
  • Bidirectional from spoke2 to both Spoke1 peps

Also, if I add a vm to spoke1 (where the peps are) in another subnet and create a separate routetable for each subnet to:

  • Send traffic for the (local) VNet address range to the router in the hub
  • Except for it's own subnet (going to 'VirtualNetwork')

Example: traffic from Spoke1 vm subnet to Spoke1 key vault pep subnet as seen by router:
212377-same-sn-over-fw.png

This also behaves as expected, meaning that I see bidirectional traffic from Spoke1-vm to Spoke1-pep (in different subnets) go over the router in the hub.

The only scenario where it does not quite work is when I add a vm into a different subnet in the hub and set a routetable to force traffic over the firewall:

  • Storage account pep: This actually does work and you see bidirectional traffic go over the router
  • Key vault pep: In this scenario you can see assymetric routing happening, as I see traffic from the vm to the pep on the router, but no return traffic (this also appears to not arrive at the vm either)

Traffic from hub vm to Spoke1 kv pep:
212289-hub-vm-kv.png

This is the only scenario, seemingly, where snat would be required. But in my case this is not an issue as the hub contains nothing more than network related resources (router/fw, vpn, bastion) and all other resources are in spokes.

I have found some third party articles about how it appears to work (though they also contradict each other and what I found in testing), but I cannot find clear documentation from Microsoft on how exactly routing in this scenario works.

Azure Private Link
Azure Private Link
An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.
460 questions