Allow Network Security Groups (NSGs) to Reference Application Security Groups (ASGs) From Different Location
Remove the limitation of restricting Network Security Groups (NSGs) ability to leverage/associate Application Security Groups (ASGs) that are not within the same location of the target Virtual Network (VNET).
This is especially important, to provide granularity and segregation/isolation in a hub-and-spoke networking model (i.e. VNetA-ASG1-to-VNetB-ASG1), in association with VNet Peering.
Thanks for the feedback, we are working on enabling ASG references across subscriptions/VNets, it’s currently on our plans
Patrik Hansson commented
How is it going with this ? Been in planning for almost two years now.
This is certainly a feature that is needed.
Seems very much like an oversight given the benefits of both hub-and-spoke vNet configuration and ASG's but they can't be used together.
Janke, Joel commented
Any updates on this? It has been 18 months since the last update. This really, really needs to happen.
Andy B commented
1 year since the last MS update and no progress (too busy fiddling with the Azure UI?).
I really need cross-vnet ASG functionality for a current use case.
Please also correct the text in https://docs.microsoft.com/en-us/azure/virtual-network/security-overview: "f 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"
- NSG is assigned to subnet1 in vnet1
- server1 exists in subnet1 in vnet1 and has ASG1 assigned to its NIC
- server2 exists in subnet2 in vnet2 and has ASG2 assigned to its NIC
- vnet1 and vnet2 are peered.
- if NSG rule 1 has ASG1 in vnet1 as source AND ASG2 in vnet2 as destination, then the text above correctly states that the NSG rule won't work.
- If NSG rule 2 has the IP of server1 (which has ASG1 assigned to its NIC) in vnet1 as source and ASG2 in vnet2 as destination, then it no longer meets the conditions of the above text (i.e. does not use ASG as source AND destination), but the NSG still doesn't work, because the destination ASG is still not in the same vnet as the source, or perhaps because the NSG is not attached to the destination vnet too, it's not entirely clear.
please confirm whether the destination asg must be in the same vnet as the source ip / asg, or the same subnet as the NSG is attached to?
ASGs are the nearest thing we can get to objects / object groups (e.g. Cisco ASA) to improve the readability of NSG rulesets. please fix them so we can use them in modern multi-vnet designs. As it is, I have to use terraform to make my NSG rules readable to a human that isn't a walking reverse DNS server.
Sachin Ladde commented
Its been more than a year now and there is no single update on this topic. Is this how MS treats their customer.
Please provide an update on this or at least a workaround.
Kent Peter Gaardmand commented
I just discovered i wanted this today :-), when is it going to be available
Patrick Hitchins commented
Any updates on this request? We are interested in this functionality.
Any update on this? The current implementation of ASG provides limited applicability without cross vNet communication.
Kannan Ganesan commented
Hi Team, we are waiting for this feature.
Team, do we have any updates for the expected timeline for this?
Giuseppe De Nicolò commented
I agree that the ASGs are of limited use in the current state, they need to be able to traverse vnet peerings to be able to create some complex network design
Justin Turver commented
Am assuming this is non-trivial to implement due to e.g. tagging on packets across logical segments, or implementing globally replicated objects of some kind, but it would make Azure network security more in line with on-prem options. Would be a huge uplift in agility and scalability in the network space. Ideally ASGs would span vnets, subscriptions and locations plus be consumable in that format in Azure Firewall rulesets. Hopefully any efforts to implement private routeable PaaS endpoints would also inherit that tagging capability in an easy to consume format.
Benjamin Mitchell commented
Come on guys.. Currently Applications Sec Groups are mostly useless except in limited small deployments. The minute you try to build out a large scale, cross-regional solution, they become useless..
Seif Allah Ben Amara commented
Any update on this ?
we would really need it !
Any update on this?
Currently working on a project that it would be really useful for
No cross site functionality will probably prevent us using NSGs
In our environment, we want to deploy across 2 regions for redundancy, but the app servers in both sites will need to access the db servers at either site. They will be in the same subscription but I can imagine other scenarios where they may not be.
any updates for 2019?
Quinn, Chris commented
We have a complex hub, spoke-hub, spoke network topology to overcome the limitation on the number of VNET peers. We are trying to implement micro-segmentation and the ability to use application security groups between VNETs in the same region would greatly simplify that effort.
Romain HENRY commented
Hi all !
We encouter the same kind of issues in a hub and spoke architecture. I would like to authorize flows between VMs hosted in a subscription and some relays hosted in a transit subscription using "external" ASG and it's not possible.
Can you remove this limitation ? This would be helpful to implement inter subscription dynamic filtering.
Indeed a very important request. Please also remember that in some hub and spoke designs we have to cross subscription boundaries as well!
Workaround until then: Work with two rulesets instead of one. Eg. for outbound connection spoke to hub, set one rule on spoke NSG reducing source to spoke ASG and set another rule on hub NSG, reducing destination to hub ASG. This is ugly, but allows the use of ASGs for SRC and DST.