Vnet internal communication after associating an Azure firewall

Question

Please let me know if mu understanding on Azure Firewall is correct or not.

This is the scenerio;

• I have several VM's (web, api, DB) in same Vnet and but in different subnets.
• No special NSG rules are defined other than the once created by default.
• Web, API and DB machines communicate each other internally over ports, say, 80, 443, 445, 27017, 1433 etc
• I create an Azure Firewall Standard sku, defined no network/application rules.
• I create a new route table to route all traffic (0.0.0.0/0) to virtual appliances firewall (private ip of firewall)
• I associate all subnets to route table.

Please let me know if the below satisfies;

1. Since subnets are associated, all outbound traffic from vm's will be blocked by default. True and confirmed
2. Will the VM's be able to communicate with each other internally over ports say, 80, 443, 445, 27017, 1433 etc by default? or do I have to define the network rules specifically (source-destination-over port-protocol) in Azure Firewall to enable the communication? 2.1 If Yes - is it due to default 'AllowVnetInBound' NSG rule? Do I have to deny and open specific ports in Azure firewall network rules?

Answer 1

@Sachin Vijayan

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you would like to understand about how routing works with Azure Firewall.

I would like to highlight a fact here,

• In case you have a route "0.0.0.0/0" attached to subnets, Subnet-to-Subnet traffic will not go via Azure Firewall.
• This is because System default routes (the address range of the VNet, for e.g. 10.0.0.0/16) have longest prefix match
• In order for Subnet-to-Subnet traffic to flow via Azure Firewall, you should create subnet specific routes, such as 10.0.1.0/24 -----> NVA, 10.0.2.0/24 -----> NVA
• 

Since subnets are associated, all outbound traffic from vm's will be blocked by default. True and confirmed

• By "outbound", if you refer to "Internet" destined traffic, then yes, your observation is correct.
• Also, you should not have any "Allow All" rule in your Azure Firewall, only then the "Deny by default" feature of Azure Firewall will block the traffic.

Will the VM's be able to communicate with each other internally over ports say, 80, 443, 445, 27017, 1433 etc by default? or do I have to define the network rules specifically (source-destination-over port-protocol) in Azure Firewall to enable the communication?

• Make sure the Subnet-to-Subnet traffic is indeed flowing via Azure Firewall
• If so, "No" - traffic will be blocked by default.
• You have to explicitly create network rules specifically to allow traffic in these ports. Else, traffic will be blocked.

Is it due to default 'AllowVnetInBound' NSG rule? Do I have to deny and open specific ports in Azure firewall network rules?

• While default NSG rule allows any subnet-to-subnet traffic, it gets processed after Azure Firewall
• So, if AzFW blocks the traffic, NSG is not even in the picture.
• P.S : You must allow the traffic in NSG as well for traffic to flow.

Thanks,

Kapil

---

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Answer 2

Hello @Sachin Vijayan

Normally all devices in the same vNET can communicate with each other with no additional configuration. Because you have created a route table, you have the ability to override the default system routes that is applied by Azure.

All devices with a subnet should be able to communicate directly with no issue (unless you define NSG rules on the NICS.

When trying to communicate outside of the subnet, the user and system routes will apply, with the user routes taking precedence if there is a conflict. For example if you define the route address prefix with 0.0.0.0/0 and the next hop being your firewall, then all your traffic will be routed to the firewall, and therefore you will need to define the relevant routes out from your firewall back to the other subnets in the vNET. In this scenario, if you want the traffic between subnets to communicate directly, then you will need to define the routes in the route table. Our documentation gives an example of this scenario here [https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#routing-example

I hope this helps provide you with the information you need. If it does, please make sure to mark the question as answered so it helps other people in future.

Kind regards

Alistair

Answer 3

Many thanks for your answers @Alistair Ross @KapilAnanth-MSFT
I made the changes as requested and is fine now.