When deploying a virtual SBC as a Virtual Machine (VM) in Azure it is advisable to close the network ports that are not strictly required (especially inbound ones) to reduce the attack surface
The scenario I usually see involves AudioCodes VE but the logic is potentially the same for every SBC you plan to deploy in Azure
Just for an example, makes sense to close port 80 – HTTP inbound (unless you plan to expose unencrypted admin access to the Internet)
However, as soon as you disable port TCP 80, you have two different warnings
Warning #1 – This rule denies traffic from AzureLoadBalancer and may affect virtual machine connectivity. To allow access, add an inbound rule with higher priority to allow AzureLoadBalancer to VirtualNetwork.
Warning #2 – This rule denies virtual network access. If you wish to allow access to your virtual network, add an inbound rule with higher priority to Allow VirtualNetwork to VirtualNetwork.
Looking at the rules, you can see that there are two default rules (with the lowest priority available) dedicated to permit Virtual Network traffic and Azure Load Balancer traffic
So, the question that I tried to answer was: does it make sense to create rules with a higher priority just to replicate what the default ones do (and remove the warnings)?
Virtual Network Access
Let’s start with VNet traffic: as for the Microsoft documentation https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq they are used to create virtual networks in the Cloud (or to extend your datacentre network). They are also used for peering VMs https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
If you are deploying virtual SBCs that do not require direct communication with other VMs, you can safely ignore the warning
Azure Load Balancer
Azure Load Balancer operates at layer four of the Open Systems Interconnection (OSI) model and distributes inbound flows to backend pool instances ( https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview )
Talking about a virtual SBC, also this rule does not look like a required one (in a common scenario) and you can safely ignore the warning
