Virtual Appliance UDR reflects traffic back to VA unless "virtual network" subnet route added

Question

When setting a UDR to override a subnet to a virtual appliance, you have to still include a route for that subnet to "virtual network" or else the return traffic from the virtual appliance goes back to itself. Why? What possible use case is there for this? I also get that the workaround is to use a virtual appliance target not in the same subnet, this just seems really dumb to me. Why not allow the virtual appliance to reply inside the subnet but still allow forcing intra-subnet traffic via the virtual appliance? Is this just "it is how it is" or am I missing something? For additional reference, step 4 here: https://github.com/Huachao/azure-content/blob/master/articles/virtual-network/virtual-networks-dmz-nsg-fw-udr-asm.md#creating-the-local-routes It says a choice can be made, however if you choose NOT to create the rule to route all traffic to the virtual appliance, the virtual appliance cannot talk to anything in the subnet because all traffic it sends to the devices in the subnet get reflected back to the firewall. I get that the routing is stateless and it cannot determine that traffic is a "reply", but what I'm saying is that if there's already a blanket UDR rule to the virtual appliance, the Azure Router could easily infer that the virtual appliance is the target and add a source route that any traffic coming from that interface should go direct to the target within the subnet. Let me know if I'm missing something, basically the second option described in the article doesn't exist. You can't do a virtual appliance with the NIC in the same subnet and have it also intercept all intra-subnet traffic.

Answer 1

@Grote, Justin Just to explain the below route table:

Effective routes :
Address Prefix Next hop type Next hop IP address Status Source
-------------- ------------- ------------------- ------ ------

1. {10.0.1.0/24} VNETLocal Active -----------------> This route is the longest prefix and would match traffic within the subnet 10.0.1.0/24 so that intra subnet traffic does not go to the firewall
2. {10.0.0.0/16} VirtualAppliance 10.0.0.4 Active -------------> This route comes into picture for intra vnet traffic which needs to go the firewall
3. {0.0.0.0/0} VirtualAppliance 10.0.0.4 Active -------------> This route comes into picture for all other traffic which also needs to go the firewall

The reason you have both 10.0.1.0/24 and 10.0.0.0/16 is because for the given scenario they needed to push all non-subnet traffic including same vnet traffic to the firewall but make same subnet traffic directly reach the destination. Hope this helps.