Using Application Security Groups (ASGs) with VNet Peering and Their Limitations

This is a scenario that a client recently asked about, and through my research, I discovered some limitations. The question, in short, is: Can we use/reference Application Security Groups (ASGs) in a Network Security Group (NSG) through VNet Peering?

First, allow me to explain the environment architecture. 

The Environment

Within this environment, there are multiple Azure subscriptions (all using the same Azure AD Tenant), and within each subscription, there is a Virtual Network (VNet). In this case, SubscriptionA is the ‘Core’ services (like AD, DNS, etc.), SubscriptionB is the ‘Production’ services (i.e. apps/services), and SubscriptionC is the ‘NonProduction’ services. 

Each Virtual Network (VNet) is connected to the other via VNet Peering (i.e. SubscriptionA-to-SubscriptionB, and SubscriptionA-toSubscriptionC, but not SubscriptionB-toSubscriptionC). Within each VNet, there is one large Subnet. This particular client is more future-forward thinking and implemented a single large subnet versus the more traditional multi-subnet (i.e. Web/App/Data). This is more future-forward, because, we don’t really have to worry about IP Addresses. This allows us to be more flexible

Side Note: I’ve worked with customers that, unfortunately, have not architected their Azure networking properly, and subsequently created too many Subnets with too few IP Addresses, and found themselves in a very difficult situation.

The Scenario

So with that architecture in mind, the question and scenario to test are: When 2 Virtual Networks (VNets) have peered together, will an Application Security Group (ASG) that exists in one Virtual Network (VNet), be available for reference in the opposite Virtual Network’s (VNet’s) Network Security Group (NSG)?

The reason for this scenario and test, is to restrict traffic through the Network Security Group (NSG), only allowing Virtual Machine Network Interface Cards (NICs) that have an Application Security Group (ASG) applied from one subscription, to communicate with the Domain Controllers, which are deployed as Infrastructure-as-a-Service (IaaS) Virtual Machines (VMs), which also have an associated Application Security Group (ASG) in the other subscription. 

The Test

Virtual Networks (VNets)

So, in my lab, I created 2 Virtual Networks, each with a single Subnet, which has its own Network Security Group (NSG) assigned. Notice that in my example, they both are in the same Resource Group, but are deployed to different locations (Canada Central and West US in my example), and have completely different address spaces.

And, I have both VNets peered together. 

One other note, when I created the Peering, I did not enable any of the additional configurations (i.e. ‘Allow forwarded traffic’, ‘Allow gateway transit’ or ‘Use remote gateways’). Just straight peering. 

Application Security Groups (ASGs)

Now that the Virtual Networks (VNets) have peered together, I created 2 Application Security Groups (ASGs). Notice that they are both contained within the same Resource Group, and the Locations correspond to the Locations used for the Virtual Networks (VNets). 

Network Security Groups (NSGs)

With all of those components in place, I jump over to the Network Security Group (NSG) in Virtual Network (VNet) ‘A’ and attempt to add a new inbound security rule. 

As you can see from the screenshot, the only Application Security Group (ASG) that appears in the list, is the local one. 

Now, if I create a new Application Security Group (ASG), but set its location to ‘Canada Central’ (to match the target Virtual Network’s location), and go back to the Network Security Group (NSG) rules… I am able to use/reference it. 

The Problem

The problem with all of this is, according to the Application Security Group (ASG) documentation …

If you specify an application security group as the source and destination in a security rule, the network interfaces in both application security groups must exist in the same virtual network. For example, if AsgLogic contained network interfaces from VNet1, and AsgDbcontained network interfaces from VNet2, you could not assign AsgLogic as the source and AsgDb as the destination in a rule. All network interfaces for both the source and destination application security groups need to exist in the same virtual network.

This means that you cannot create an Application Security Group (ASG) with its location aligned to the target Virtual Network’s location, and associate any deployed Virtual Machine Network Interface Cards (NICs) that are not within the exact same location.

In short, you cannot use Application Security Groups (ASGs) for Network Security Group (NSG) rules, across Virtual Network (VNet) peerings. Meaning, you cannot have a properly segmented hub-and-spoke network design. 

Conclusion

So, if you want Microsoft to improve upon the current limitations of the Application Security Groups (ASGs), Network Security Group (NSG), and Virtual Network (VNet) peerings, allowing further security granularity in a hub-and-spoke network design (i.e. VNetA-ASG1-to-VNetB-ASG1), you need to vote for the suggestion under the Azure Networking UserVoice.