Skip to main content

NSG and UDR Support for Private Endpoints


Hey Folks,

It's been a while since I blogged about something. This time it's about NSG and UDR support for Private endpoints. This feature is now publicly available. This was one of the most wanted features in Azure Networking.

Before we get into more details. Let's have some general understanding of what are private endpoints and what was the issue before and how this feature fixes all these issues.

What are Private Endpoints?

According to MS documentation, "A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link"

Basically, Private endpoints allow you to connect to Microsoft Services to securely using a private address. So that the traffic will not flow thru MS public networks. This basically creates a network interface card for the services on a selected subnet.

What were the issues/Limitations with Private Endpoints?

Now unlike regular network cards, these types of virtual network cards are a bit different. First:

  • Private Endpoints only support TCP (not ICMP/UDP)
  • They do not support NSG flow logs.
  • Does not support UDR/NSG now (Now it does) :D.

So this particular feature fixed the last limitation in the list. Because private endpoints were unsupported by NSG before, we couldn't control the network traffic from the network layer. The only option we had was either from the service level network restriction or having access controls to limit access to the service. But now with the support, we can restrict the inbound traffic to the public endpoints

UDR issue is a somewhat kind of annoying situation. By default, private endpoints will automatically create a /32 default route which will automatically propagate to the vnet route table it resides in and other peered VNETs



By default, MS routing prioritizes the specific routes and also uses the following flow

  • User-defined routes
  • BGP routes
  • System routes

Because of this if we have any private endpoints sitting in spoke networks, and also when spoke-to-spoke routing is forced via an Azure Firewall or an NVA, Traffic routing will be asymmetric

In a high level,

Traffic from the spoke A to Spoke B (where we have the private endpoint) resources use the UDR to point to the Azure Firewall/NVA

The Azure firewall/NVA sees the destination traffic, processes the Network rules, and will route the traffic based on the published system routes for private endpoints.

But what happens is when PE will respond to the VM directly cause it does not honor the UDRs. and then the Assymatric routing will come into the picture.


But Luckily because of this new feature release, both of the above-mentioned issues are no longer there :D

Enabling NSG and UDR support for Private Endpoints

This feature enhancement will remove the need to create a /32 address prefix when defining custom routes. You will now have the ability to use a wider address prefix in the user-defined route tables for traffic destined to a private endpoint (PE) by way of a network virtual appliance (NVA). In order to leverage this feature, you will need to set a specific subnet-level property, called PrivateEndpointNetworkPolicies, to be enabled on the subnet containing private endpoint resources.

Enable using Powershell


$net = @{ 
Name = 'myVNet' ResourceGroupName = 'myResourceGroup' 
} 
$vnet = Get-AzVirtualNetwork @net 
$sub = @{ 
Name = 'default' VirtualNetwork = $vnet 
AddressPrefix = '10.1.0.0/24' 
PrivateEndpointNetworkPoliciesFlag = 'Enabled' 
} 
Set-AzVirtualNetworkSubnetConfig @sub $vnet | Set-AzVirtualNetwork

Enable Using Bicep

    subnets: [ for subnet in subnets: {
      name: subnet.name
      properties: {
        addressPrefix: subnet.addressPrefix
        networkSecurityGroup: empty(subnet.networkSecurityGroup) ? json('null') : {
          id: subnet.networkSecurityGroup
        }
        routeTable: empty(subnet.routeTable) ? json('null') : {
          id: subnet.routeTable
        }
        privateEndpointNetworkPolicies: 'Enabled'
    }]

Labels:

Comments

Post a Comment

Popular posts from this blog

Deploying an Automation Account with a Runbook and Schedule Using Bicep

Introduction Automation is a key component in many organizations' cloud strategy. Azure Automation allows you to automate the creation, deployment, and management of resources in your Azure environment. In this post, we will walk through the process of deploying an Automation Account with a Runbook and Schedule using Bicep, a new domain-specific language for deploying Azure resources. Intention My intention at the  end is to run a PowerShell  script to start and shutdown Azure VMs based on tag values. PowerShell  script that I have used is from below l ink.  And two  of me   collogue s ( Michael Turnley   and Saudh Mohomad helped to modify the  PowerShell  script. Prerequisites Before we begin, you will need the following: An Azure subscription The Azure CLI installed on your machine. The Azure Bicep extension for the Azure CLI Creating the Automation Account The first step in deploying an Automation Account with a R...
Post a Comment
Read more

Migrating Azure DevOps Variable Groups

Howdy Folks, I was working on an application modernization project. And there was a requirement to migrate application deployments from one project to another in Azure DevOps. deployment pipelines were heavily dependent on variable groups. So, we wanted to migrate these variables group to the new project. Couldn't find any solutions in internet for this, so came up with the below scripts. You can grab the scripts from the below GitHub URL. DaniduWeerasinghe911/Migrate-Azure-DevOps-Variable-Groups: This Repo Include PowerShell Scripts relating to Migrating Azure DevOps Variable Groups (github.com) Azure DevOps Variable Groups Azure DevOps Variable Groups are a way to store and manage sets of variables that can be used across multiple pipelines in Azure DevOps. These variables can include secrets, connection strings, and other sensitive information that is needed for builds and releases. Variable Groups provide a centralized way to manage these variables and ensure that they are cons...
Post a Comment
Read more

Securing Azure Services with Fetian FIDO

Hey Folks  Here again with another security topic with Fetian Fido. And once again Fetian devices proved their excellent quality and stability. For this I choose Fetian K33 -  AllinPass FIDO Security Key – FEITIAN (ftsafe.com) and  K39 -  Single-button FIDO Security Keys | FEITIAN (ftsafe.com) Use case  In an organization following changes needs to be implemented.  1. Update the password policy 2. Update the user session time out to 30 minutes Once these changes being implemented, the following issues need to be addressed 1. Users' complaint new passwords need to be so long 2. Users complain sessions time out makes them work so much slower with the longer passwords 3. Etc... Solution  One of my friends reached out to me to help solve this problem. All I could think of was using passwordless auth with FIDO devices. We have decided to use Fido2 keys for better security and flexibility for the users. The FIDO (Fast IDentity Online) Alliance helps to pro...
Post a Comment
Read more