Networking (UDRs) in Azure: Inserting the VM-Series into an Azure Environment

User-Defined Routes (UDR)

UDR tables allow you, as a user or IT/security administrator, to add additional rules that control traffic flows inside the VNET. You can specify that for subnet1 trying to reach a specific IP address/range/subnet what the next hop should be, which can be a virtual appliance that is a VM-Series firewall. In the diagram above the UDR rules for subnet1 and subnet2 now are forcing packets through the VM-Series firewall. The firewall is deployed with 3 interfaces: eth0 for management (Mgmt), eth1 (E1/1) for Internet facing side (Untrust), and eth2 (E1/2) for internal/private side (Trust) networks. The Trust interface can protect across all the Internal subnets by having UDR force all packets through the VM-Series firewall. According to Microsoft documentation: “Subnets rely on system routes until a route table is associated to the subnet. Once an association exists, routing is done based on Longest Prefix Match (LPM) among both user defined routes and system routes. If there is more than one route with the same lowest prefix match (LPM) match then a route is selected based on its origin in the following order:

1. User-defined route
2. BGP route (when ExpressRoute is used)
3. System route”

This means that the UDR will get higher precedence as long as you create a more specific UDR (say with prefix /24) than the system route policy (/16). You can view the UDR in the Azure Portal > Route Table. To see the system routes and UDR applied on an individual VM: In the Azure Portal > (select your VM) > (select the network interface) > Effective routes.

Now the VM-Series firewall is in the traffic path and can apply the security policies that you configure. When traffic flows between interfaces (and their related Zones), say Untrust to Trust, then inter-zone security policies should be setup. And when it is between subnets protected by a single interface, say between subnet 1 and subnet 2, then an intra-zone security policy should be created. For example, subnet1 (for web apps) à subnet 2 (for database): Allow SQL traffic.