Azure VNet ignores route table

Christian van Eickelen 1

Hello guys, I would like to ask for assistance for an issue, which shouldn't be an issue. ;) I've just deployed a Fortigate Firewall to my Azure infrastructure which relies on a route table. The default route is set "Virtual Appliance" for the next hop and has configured the IP 172.16.0.132 on the internal interface. And there is an additional route for each subnet for inner VNet communication. The subnets use the IP ranges 172.16.1.128/25 and 172.16.2.0/24. And of course the route table is associated to each subnet. Due to the mentioned configuration my expectation was that the VMs can't communicate with each other because no firewall rules were configured. But the machines can ping vice versa and it seems that the traffic doesn't flow through the firewall because I can't see any log entries that show the ping. Here ist an output of the route table configuration: 2023-04-24 15_28_20-vmfgt-RouteTable-VNET_DRaaS_FGT_DMZ - Microsoft Azure and 7 more pages - Persona

Does anyone have any hint or advice? Thank you, Christian

ChaitanyaNaykodi-MSFT 24,666 Reputation points Microsoft Employee

2023-05-02T23:52:00.85+00:00

@Christian van Eickelen

Just checking in to see if the below answer helped. If this answers your query, please don’t forget to click "Accept the answer" which might be beneficial to other community members reading this thread. And, if you have any further query do let us know.

2 answers

Alistair Ross 7,106 Reputation points Microsoft Employee

2023-04-24T14:11:51.9566667+00:00

Hello

When you say your expectation is that the VM's cannot communicate, are these VM's that are all in the same subnet?

By default, virtual machines in the same subnet can communicate based on a default NSG rule allowing intra-subnet traffic. If you want to force two VMs in a subnet to communicate via a firewall and not directly to each other, you can add a rule to the Network Security Group (NSG) that denies all inbound and outbound traffic between the two VMs. This will prevent them from communicating directly with each other.

You can then configure your firewall to route traffic between the two VMs.

I hope this clarifies things

Alistair
Please sign in to rate this answer.
Christian van Eickelen 1 Reputation point

2023-04-24T14:19:49.43+00:00

Thanks your response, Alistair! No, the VMs are on different subnets and the subnets don't have any NSGs associated. I assumed that the route table overrides any NSGs rules. But I will give it try and I will keep you updated. So, this would imply the use of a NSGs to let network traffic flow to the firewall as configured.

Alistair Ross 7,106 Reputation points Microsoft Employee

2023-04-24T14:48:06.03+00:00

Because your VM's are in different subnets and you have applied route tables, then the configuration of the route tables will apply. I can see you have got routes applied for those two subnets and that will be what is taking effect here. You can view the effective routes and validate the routing with the instructions found here. https://learn.microsoft.com/en-us/azure/virtual-network/manage-route-table#view-effective-routes Alistair

Christian van Eickelen 1 Reputation point

2023-04-24T20:39:47.85+00:00

Thank you for your explanation. I'm going to investigate this issue a little bit more. Maybe it's necessary to open a support case.

Alistair Ross 7,106 Reputation points Microsoft Employee

2023-04-25T08:19:30.0733333+00:00

Apologies, let me try explain it again. Highlighted in the image below are the routes and associated subnets that are causing the issue. When routing the network traffic, the system performs a bitwise ANDing of the destination IP address against all the routes.

If there is only one match, the traffic is routed to the relevant next hop.

If there are multiple matches, the traffic is routed to the interface with the longest subnet mask.

Giving an example based on your scenario, we have two virtual machines in different subnets, but within the same vNet. In these scenarios I will focus on traffic flowing from VM 1 to VM2

VM1 = 172.16.1.4

VM2 = 172.16.1.132

Scenario 1. No Route tables. In this scenario, the VM's can communicate directly with each other as Azure applies system routes between the subnets.

Scenario 2. A Route table is applied to the subnets with only 1 route, 0.0.0.0/0. All traffic leaving the subnets will be forced to go via the next hop IP address for routing as the system routes have been overridden. This is the scenario you have said you want.

Scenario 3. A Route table is applied with 0.0.0.0/0 and 172.16.1.128/25. Both the routes will be evaluated, but only one can apply. Because 172.16.1.128/25 has a longer subnet mask, this will apply and all traffic going to that subnet will be routed directly to the next hop for that route. All other traffic leaving the subnet will go via the 0.0.0.0/0 next hop. This is the scenario you have applied

The answer to your issue is that you have routes in place that you do not need. Remove the direct routes and route after the traffic has left your firewall (or within the firewall depending on it's capabilities)

Christian van Eickelen 1 Reputation point

2023-04-25T10:27:17.1266667+00:00

Thanks again for you time. :-) I have removed the routes which causes the behaviour you described. This causes additionally that traffic between VMs in the same subnet flow through the firewall as well. Is this intentional?

Alistair Ross 7,106 Reputation points Microsoft Employee

2023-04-25T11:46:07.13+00:00

Any traffic that is directed at an IP address in the same subnet should stay within the subnet, the routes only apply to traffic leaving the subnet. You can use Network watcher to test what the next hop will be and verify this. https://learn.microsoft.com/en-us/azure/network-watcher/network-watcher-next-hop-overview. You may find that some traffic is looking externally (such as DNS) before connecting to the VM in the same subnet. You can review connectivity with Virtual Machine Insights https://learn.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-maps

Christian van Eickelen 1 Reputation point

2023-04-25T13:05:35.7966667+00:00

Okay, thanks for clarifying. I would get a deeper insight with some tests to make that this is the configuration which is needed. Thank you, Christian

Christian van Eickelen 1 Reputation point

2023-04-25T21:41:59.3166667+00:00

Hey Alistair! I just did some further tests. I my case the VNet doesn't behave like you mentioned. As mentioned earlier after removing the additional virtual network routes, the VMs in that particular subnet can't talk to each other. But now I can see an attempt of a ping to a VM in the same subnet in the firewall log. In my opinion I shouldn't see this traffic on the firewall because it's subnet internal. After configuring an any-any firewall rule where source and destination is the same the ping works again. A tracert show that the traffic first pass through the firewall and arrives at the VMs. This is like that the function of a NSG is moved to firewall. I checked the configuration with the a next hop on network watcher and I receive the expected results.
Sign in to comment
aidanfinn 0 Reputation points

2023-05-03T07:52:16.2933333+00:00

Can you share a diagram of the network(s), including the route tables/user-defined routes? There's a who world of possibilities without knowing exactly what you have.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Share via

Azure VNet ignores route table

2 answers