Azure Virtual Networks for Network Engineers

Overview: familiar words, different machinery

If you have built physical networks, an Azure virtual network (VNet) will feel familiar. It has an address space, subnets, routes, filtering rules, firewalls, VPNs and load balancers. Microsoft says VNets deliver "the scale, availability, and isolation benefits of Azure infrastructure while maintaining the familiar networking concepts you use in traditional datacenters."

The words are the same, but the machinery underneath is not. There are no switches to cable, no VLANs to trunk, and no router to log in to. Everything is a software object that you create through a portal, a command line or a template, and the platform enforces it for you.

This article is a translation guide. For each physical-network idea (VLAN, VRF, ACL, router, firewall and more) it names the Azure object that does the closest job, and it says where the comparison stops working. Where an Azure feature has no real physical equivalent, the article says so instead of forcing a match.

Five shifts to make before you start

1. There is no Layer 2. Microsoft's FAQ states that virtual networks are "Layer 3 overlays" and that "Azure does not support any Layer 2 semantics." No VLAN tags, no broadcast, no multicast.

2. Routing is on by default. "By default, Azure routes traffic between subnets." You do not configure a router for subnets in the same VNet to reach each other.

3. A subnet is not a security boundary. Because subnets can reach each other by default, you separate them with filtering rules, not with the subnet itself.

4. Filtering is distributed. Network security groups (NSGs) are attached to subnets or network interfaces. There is no single choke point unless you build one with a firewall and routes.

5. Everything is scoped. A VNet lives in one region (and spans all availability zones in it) and belongs to one subscription. Connecting scopes together is a design decision, not a given.

There is also good news: Microsoft states that "there's no charge for using Azure Virtual Network." You pay for the resources you attach to it, such as VMs, gateways and firewalls.

Scope note: this article follows Microsoft Learn documentation. Limits, SKUs and defaults change over time, so check the current documentation before you design against a specific number.

The translation table

Use this table as a map. Each row is expanded in the sections that follow. The third column is the important one: it says where the Azure object behaves differently from the device you know.

Read each arrow as the closest match, not an exact equivalent.

The VNet: your site, as a software object

A VNet is the closest thing Azure has to a site network or a data-centre LAN. You give it one or more address ranges (CIDR blocks), and you carve subnets out of them.

What you choose and what you do not

• Address space. You pick it. Microsoft recommends the RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The range 100.64.0.0/10 (RFC 6598) is also supported and is treated as private address space in Azure.

• Ranges you cannot use. 224.0.0.0/4 (multicast), 255.255.255.255/32 (broadcast), 127.0.0.0/8 (loopback), 169.254.0.0/16 (link local) and 168.63.129.16/32 (internal DNS).

• Changing it later. You can add, remove and modify the CIDR blocks of a VNet. A subnet can only be added, removed, expanded or shrunk if no VMs or services are deployed in it.

• Overlap. Subnets in one VNet cannot overlap. You also cannot peer two VNets whose address spaces overlap, and you cannot link a VNet to another VNet or an on-premises network if the CIDR blocks overlap. Plan your address space like you would for a merged enterprise network.

• Scope. A VNet is limited to a single region, but it spans all availability zones in that region. It belongs to one subscription.

• Moving a VM. To move a VM to another VNet, you delete and recreate it in the new VNet.

Isolation between VNets

Two VNets cannot reach each other over private addresses until you connect them. Microsoft's overview describes peering as the way to connect VNets, after which "the resources in either virtual network can then communicate with each other." A VPN gateway can also connect VNets.

For a network engineer, this is the first useful comparison: each VNet behaves like a separate routed network that only meets other networks where you add a connection.

What a VNet gives you automatically

• Routing between subnets with no configuration (section 5).

• DHCP and DNS for VMs. Azure provides both.

• Outbound access in older VNets, through an implicit platform behaviour. Section 9 explains why this is being phased out.

• No cost for the VNet itself.

The VNet gives you addressing and routing; filtering and connectivity are things you add.

Subnets versus VLANs

This is the translation that causes the most confusion. In a physical network, a VLAN is a Layer 2 broadcast domain, usually with one IP subnet mapped to it and a switch interface (SVI) as the gateway. Azure has the IP subnet and the gateway, but not the Layer 2 part.

What a subnet is in Azure

A subnet is a range of addresses inside the VNet address space, written in CIDR notation. It must fall inside the VNet address space and must not overlap another subnet in the same VNet. A VM's network interface takes its private address from a subnet.

Microsoft is direct about the limits: "Virtual networks are Layer 3 overlays. Azure does not support any Layer 2 semantics." Multicast and broadcast are not supported, and IP-in-IP and GRE packets are blocked. TCP, UDP, ESP, AH and ICMP are supported, and so is unicast.

In practice, treat a subnet as an addressing and policy unit. It is where you attach an NSG, a route table, a NAT gateway and (for some services) a service endpoint. It is not a broadcast domain.

The five reserved addresses

Azure reserves the first four addresses and the last address in every subnet. For a 192.168.1.0/24 subnet, Microsoft lists them like this:

The smallest supported IPv4 subnet is /29. That is 8 addresses, so only 3 are usable after the 5 reserved ones. IPv6 subnets must be exactly /64. The Azure-provided default gateway does not respond to ping, so do not use it as a reachability test.

Plan subnet sizes with the five reserved addresses already subtracted.

Special-purpose subnets

Some Azure services need a subnet of their own, and some need an exact name:

A NAT gateway cannot be deployed in a gateway subnet or in a subnet that contains SQL managed instances.

How to think about it

Two more details matter for engineers who like fixed identities. First, you can choose a static private address for a network interface with Azure Resource Manager. Second, the MAC address of a network interface stays the same until you delete the interface or change the private IP of its primary IP configuration, and it is kept when the VM is deallocated.

Design note: because a subnet can only be resized while it is empty, leave spare room when you size it.

Separation that a VLAN gave you at Layer 2 now comes from subnets and NSG rules.

Routing: the router you never see

In Azure there is no router device to configure. Routing is a platform function, and what you control is a set of routes that the platform applies to each subnet. Microsoft puts it plainly: "By default, Azure routes traffic between subnets. You don't need to define route tables or gateways for Azure to route traffic between subnets."

System routes

Azure creates these routes for every subnet. You cannot create or remove them, but you can override some of them with custom routes.

If you assign one of the reserved private ranges to your VNet, Azure changes the next hop for that range from None to Virtual network. That is why a private range you did not assign goes nowhere: the platform drops it.

Azure adds more default routes when you turn on certain features:

• Virtual network peering: a route for each address range of each peered VNet, applied to all subnets.

• Virtual network gateway: routes learned by BGP or defined for a local network gateway, applied to all subnets.

• Service endpoint: routes with the next hop type VirtualNetworkServiceEndpoint, applied only to the subnet where the endpoint is enabled.

Route tables and user-defined routes

A route table is a standalone object. You create custom routes in it, called user-defined routes (UDRs), and associate it with one or more subnets. Each subnet can have zero or one route table.

A UDR can use these next hop types:

You cannot use Virtual network peering or VirtualNetworkServiceEndpoint as the next hop type in a UDR.

By default, one route table can hold up to 400 UDRs. With the Azure Virtual Network Manager routing configuration, that grows to 1,000. You can create 25 or fewer routes with service tags in each route table.

How Azure picks a route

1. Longest prefix match. Azure selects the route whose prefix is the most specific match for the destination. A packet to 10.0.0.5 uses 10.0.0.0/24 in preference to 10.0.0.0/16.

2. If prefixes are identical, the order is: user-defined route, then BGP route, then system route.

3. One exception. System routes for the VNet, for peerings and for service endpoints are preferred, even if a BGP route is more specific. A route with a service endpoint as the next hop cannot be overridden, even with a route table.

The service endpoint rule has a practical effect. Traffic to the service bypasses a 0.0.0.0/0 route, because the service endpoint routes are more specific.

When a route behaves unexpectedly, walk these three steps in order.

BGP route propagation

VPN and ExpressRoute gateways can learn on-premises routes by BGP and add them to subnet route tables. A route table has a setting to turn this propagation off. When it is off, connectivity to on-premises depends on your own routes with the next hop type Virtual network gateway. Do not turn propagation off on the GatewaySubnet: Microsoft warns that the gateway will not function. ExpressRoute requires BGP, and you cannot use a UDR to force traffic to an ExpressRoute gateway.

The VRF question

Microsoft's VNet documentation does not describe a VRF object, so there is no one-to-one match. These are analogies, not equivalents:

The lesson for VRF users is to design address space first. Where you would have used VRFs to keep overlapping ranges apart, in Azure you plan non-overlapping ranges for any VNets that will ever connect.

NSGs versus ACLs

A network security group (NSG) is the Azure object closest to an access list. It holds a list of allow and deny rules, and you associate it with a subnet, a network interface, or both.

How an NSG rule works

Each rule has a name (unique within the NSG, up to 80 characters), a priority, a source, a destination, a protocol, a direction (inbound or outbound), a port range and an action (allow or deny).

• Priority is a number from 100 to 4096. Lower numbers are processed first, and processing stops at the first match. Two rules cannot share the same priority and direction.

• Matching uses the five-tuple: source, source port, destination, destination port and protocol.

• Source and destination can be Any, a single IP address, a CIDR block, a service tag or an application security group.

• Protocol can be TCP, UDP, ICMP, ESP, AH or Any. ESP and AH are available only through ARM templates, not the portal.

• Stateful. If a connection is allowed in one direction, the return traffic does not need its own rule. Rule changes affect only new connections: deleting an allow rule does not drop sessions that already exist.

The default rules

Every NSG is created with these rules. You cannot delete them, but any rule with a lower priority number overrides them.

VirtualNetwork, AzureLoadBalancer and Internet are service tags, not IP addresses. Read the published definition of each tag before you rely on it in a design.

Your rules sit above the defaults, so a rule with a lower number always wins.

Where the NSG is applied

You can attach an NSG at the subnet, at the network interface, or both. Microsoft's FAQ gives the order of evaluation:

• Inbound traffic: the subnet NSG first, then the interface NSG.

• Outbound traffic: the interface NSG first, then the subnet NSG.

When both exist, traffic must be allowed by both.

The order reverses with direction, but both NSGs always have a vote.

Side by side with a classic ACL

Service tags, ASGs and augmented rules

• Service tag: a named group of IP prefixes for an Azure service. Microsoft maintains the list, so your rules do not need updating when the prefixes change.

• Application security group (ASG): a group of network interfaces that you reference in a rule. It lets you write rules by application role (for example web servers) instead of by IP address.

• Augmented security rules: one rule can hold several ports, explicit IP addresses and ranges. A single rule cannot combine multiple service tags or multiple ASGs. Augmented rules are available only for NSGs created through Azure Resource Manager.

Gotchas for engineers

1. Subnets can reach each other by default. AllowVNetInBound at priority 65000 allows traffic that matches the VirtualNetwork tag. Add your own deny rule with a priority number below 65000 to separate tiers.

2. Outbound internet is allowed by default. AllowInternetOutBound permits it unless you add a deny rule. Section 9 explains how default outbound access is changing.

3. Standard load balancers and standard public IPs are closed to inbound traffic by default. An NSG must explicitly allow the traffic, and traffic is blocked if no NSG exists on the subnet or interface.

4. Platform addresses. 168.63.129.16 and 169.254.169.254 serve infrastructure services. NSGs do not restrict them unless you deny them with specific service tags.

5. Outbound port 25 (SMTP) depends on your subscription type. Microsoft recommends an authenticated SMTP relay.

6. Central admin rules. Azure Virtual Network Manager security admin rules are evaluated before NSG rules. An Allow admin rule passes the traffic on to the NSG, but an Always allow or a Deny admin rule ends the evaluation.

Azure Firewall versus a physical firewall

An NSG filters on addresses, ports and protocols. When you need more, such as filtering by domain name, central policy across many VNets, or threat intelligence, you add a firewall. In Azure that means Azure Firewall or a network virtual appliance (NVA), which is a VM that performs a network function such as a firewall.

Microsoft describes Azure Firewall as "a managed, cloud-based network security service that protects your Azure Virtual Network resources", a "fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability."

NSG or firewall?

Use both. Microsoft's FAQ says Azure Firewall "complements NSGs to provide better defense-in-depth network security." NSGs give distributed Layer 3 and Layer 4 filtering inside VNets in each subscription. Azure Firewall gives centralised, fully stateful network and application-level protection across subscriptions and VNets. For internal segmentation, Microsoft recommends NSGs, which do not need UDRs.

Where it sits

• Dedicated subnet. Azure Firewall goes in a subnet named AzureFirewallSubnet, with a minimum size of /26. Do not deploy anything else in it. A /26 leaves room for the firewall to scale out.

• Typically in the hub. It can be deployed in any VNet, but it is usually placed in a central hub VNet. The default route of the peered spoke VNets points to it.

• It only sees traffic you send to it. Traffic reaches the firewall because you attach a route table with a UDR whose next hop is the firewall. Section 12 shows an example.

• No subnet NSG needed. Subnet-level NSGs are not required on AzureFirewallSubnet and are disabled to prevent service interruptions.

SKUs

All three SKUs support forced tunneling and availability zones.

Rule processing

This is the part that surprises engineers used to a single ordered rule list. Azure Firewall is a deny-by-default device: "By default, Azure Firewall denies all traffic until you manually configure rules to allow traffic."

1. Threat intelligence first, if enabled. It can block traffic before any rule is evaluated.

2. Rule collection groups and rule collections are processed by priority. The range is 100 (highest) to 65,000 (lowest) for both. Rule collection groups in a parent policy always take precedence over those in a child policy.

3. By rule type, not just by number. The system processes DNAT rules, then network rules, then application rules, regardless of the priority of the group or collection that holds them.

4. A match ends processing. A DNAT match translates the traffic and allows it, without further network rule processing.

5. Application rules are evaluated only if no network rule matched and the protocol is HTTP, HTTPS or MSSQL. HTTP is matched by the Host header and HTTPS by the SNI, unless TLS inspection is on.

6. Infrastructure rule collection. A built-in collection allows platform FQDNs, and it is processed after application rules and before the final deny.

7. Default deny if nothing matches.

Application rules do not apply to inbound connections. For inbound HTTP and HTTPS filtering, Microsoft says to use a web application firewall.

Type order matters more than priority numbers, which surprises engineers used to one ordered list.

NAT behaviour

Azure Firewall supports both DNAT (inbound) and SNAT (outbound). By default it does not SNAT when the destination is a private range under RFC 1918 or RFC 6598. If your organisation uses public ranges for private networks, it does SNAT that traffic, and you can configure it not to. Application rule traffic is always SNATed.

What to know about NVAs

An NVA is a VM from a vendor that you place in the traffic path with a UDR (next hop type Virtual appliance). It gives you the vendor's features and management style, but you operate it yourself, unlike a managed service. Microsoft's hub-and-spoke guidance notes the flexibility NVAs give, such as control over the number of NICs, instances and compute size.

Connecting networks together

Most real designs have more than one VNet, plus an on-premises network. These are the building blocks.

VNet peering

Peering connects two VNets so that they "appear as one for connectivity purposes." Resources can connect directly, and traffic stays on the Microsoft backbone: no public internet, gateways or encryption are required between the VNets.

• Latency and bandwidth. Latency between VMs in peered VNets in the same region is the same as latency inside one VNet. Throughput depends on the VM size, and peering adds no extra bandwidth restriction.

• Reach. Peering works within a region or across regions (global peering), across subscriptions and across Microsoft Entra tenants.

• No overlap. You cannot peer VNets whose address spaces overlap.

• Two links. Each side needs its own peering link. With only one link the connection stays in the Initiated state, and deleting one link moves it to Disconnected.

• Nontransitive. If VNet A is peered with B, and B with C, A cannot reach C through B. Microsoft's FAQ says: "Transitive peering is not supported. You must manually peer VNetA to VNetC."

• Gateway transit. One VNet can use another VNet's gateway as a transit point to on-premises. A VNet can have only one gateway, and a VNet that uses a remote gateway cannot have its own.

• Resizing. You can change the address space of a peered VNet without downtime, but peers must then be synced with the change.

• Moving. You cannot move a VNet that has a peering connection. Delete the peering first.

Gateway transit lets spokes share the hub gateway, but it does not let spokes reach each other.

VPN gateway

A VPN gateway is a type of virtual network gateway. It sends encrypted traffic between your VNet and an on-premises location across a public connection, and it can also connect VNets.

• IPsec. Site-to-site VPNs use IPsec with IKEv1 and IKEv2 on the route-based SKUs. The Basic SKU supports only IKEv2 for route-based gateways.

• Route-based. Since October 1, 2023 you cannot create a policy-based gateway in the Azure portal. New gateways are route-based. VNet-to-VNet and multi-site connections need route-based gateways.

• BGP. The default Azure ASN is 65515. If you use BGP, your on-premises ASN must be different from the Azure ASN.

• GatewaySubnet. The subnet must be named exactly GatewaySubnet. The minimum is /29, and /27 or larger is recommended. Do not put VMs in it.

• Active-active. Each gateway instance has its own public IP address and tunnel, which allows redundant tunnels.

• Point-to-site. A VPN between a VNet and a single computer, sent through an encrypted tunnel over the internet.

ExpressRoute

ExpressRoute is a connection between your network and Azure through an ExpressRoute partner. It is private, and traffic does not go over the internet. It requires BGP to advertise your on-premises routes. A VNet can connect to an ExpressRoute circuit and also have IPsec VPNs, as a coexisting configuration. To route between an ExpressRoute branch and a VPN branch, Microsoft recommends Azure Route Server.

Both options end at a virtual network gateway in the GatewaySubnet.

Hub and spoke

Microsoft's Cloud Adoption Framework recommends the hub-and-spoke pattern. A hub VNet is the central point of connectivity to many spoke VNets. The spokes isolate workloads and connect to the hub by peering.

• In the hub: the cross-premises gateway (VPN or ExpressRoute), the firewall, and shared services such as DNS, NTP or Active Directory Domain Services.

• In the spokes: workloads. Spokes can be in different subscriptions and represent different environments.

• A hub is regional. If your workloads are in several regions, place one hub in each region.

• Main purpose. A core purpose of the topology is to send outbound internet traffic through the control mechanisms in the hub.

• Gateway transit settings. On the hub peering, allow gateway transit. On each spoke peering, use the remote network's gateway. Allow forwarded traffic on all peerings.

• Spoke to spoke. Peering is nontransitive, so spokes do not reach each other through the hub on their own. Either peer the spokes directly, or use UDRs that send spoke traffic to an Azure Firewall or NVA in the hub. Microsoft notes that direct connectivity between spokes adds no extra hop and is recommended to minimise latency.

The hub holds what every workload shares; each spoke holds one workload.

Managed alternatives

• Azure Virtual WAN is the Microsoft-managed alternative to a hub you build and run yourself. A customer-managed hub gives you more control over the NVAs, and lets you use NVAs that Virtual WAN does not support.

• Azure Virtual Network Manager helps you group, configure and manage VNets at scale across subscriptions, regions and Microsoft Entra directories. Its network groups can provide connectivity between VNets as if they were peered by hand.

Internet access, NAT, load balancing and PaaS access

In a physical network, the internet edge is one place: a border router and a firewall with a NAT policy. In Azure, internet access is a set of separate choices.

Outbound: default outbound access is going away

When a VM is deployed in a VNet without an explicit outbound method, Azure automatically gives it an outbound public IP address. Microsoft calls this default outbound access. The IP address is owned by Microsoft and can change without notice, and the behaviour relies on implicit platform behaviour.

Microsoft now recommends against relying on it. Its reasons are that default internet access contradicts Zero Trust principles, that explicit connectivity is clearer than implicit access, and that the address is not yours and can change.

The current position, per Microsoft Learn:

• For the API released after March 31, 2026, new VNets default to private subnets. The Azure portal already defaults to private subnets. A private subnet has the property defaultOutboundAccess set to false.

• This is not a blanket shutdown. Existing VNets are unchanged unless you make a subnet private.

• In a private subnet, some services do not work without an explicit egress method. Microsoft names Windows activation and Windows updates as examples.

The explicit outbound options are:

NAT gateway

A NAT gateway is a managed NAT service for outbound traffic. It lets every instance in a subnet connect to the internet while staying private.

• Outbound only. It does not permit unsolicited inbound connections. Only reply packets pass back.

• Association. It attaches to subnets in the same VNet, and several subnets can share one NAT gateway. A subnet cannot have more than one. A NAT gateway cannot span VNets.

• Addresses. A Standard NAT gateway can use up to 16 IPv4 public addresses. SNAT ports are allocated dynamically.

• Protocols. TCP, UDP and ICMP (echo request and reply).

• Timers. The TCP idle timeout defaults to 4 minutes and can be raised to 120. The UDP idle timeout is 4 minutes and cannot be changed.

• Precedence. For new connections it takes precedence over load balancer outbound rules, instance-level public IPs and Azure Firewall. A UDR sending 0.0.0.0/0 to a virtual appliance or gateway overrides it.

• Where it cannot go. A gateway subnet, or a subnet containing SQL managed instances. It also does not work with subnets that have Basic load balancers or Basic public IPs.

Pick one explicit method per subnet instead of relying on the platform default.

Inbound and load balancing

Resources in a VNet can be reached from the internet by giving them a public IP address or by placing them behind a public load balancer.

• Azure Load Balancer works at Layer 4 and distributes TCP and UDP traffic by load-balancing rules and health probes. A public load balancer can provide inbound and outbound connectivity. An internal load balancer balances traffic inside the VNet.

• Closed by default. Standard load balancers and public IP addresses are closed to inbound connections. An NSG must allow the traffic.

• Basic is gone. The Basic load balancer SKU was retired on September 30, 2025. The current SKUs are Standard and Gateway.

• Internal only means no outbound. If you use only an internal Standard load balancer, outbound connectivity is not available until you define it with an instance-level public IP or a public load balancer.

• Application Gateway is the Azure service for Layer 7 HTTP and HTTPS load balancing. On the Premium Azure Firewall, inbound TLS termination is done through Application Gateway.

Reaching Azure PaaS services from a VNet

There are two different mechanisms. Do not treat them as the same thing.

A private endpoint gives the service a private address, but does not by itself restrict public network access to the service.

The private endpoint brings the service into your address space; the service endpoint does not.

DHCP and DNS in a VNet

In a physical network you run DHCP scopes and DNS servers, or you point at the ones your team runs. Azure provides both for VMs, and lets you replace the DNS part.

DHCP

Azure provides DHCP to the VMs in a VNet. You can run your own DHCP server in an Azure VM to serve on-premises clients through a relay agent. Direct DHCP traffic between on-premises clients and Azure (UDP 68 to UDP 67) is not supported.

Azure-provided DNS

Azure-provided name resolution is at the static address 168.63.129.16, and you do not need to configure anything. It is basic:

• DNS lookup is scoped to one VNet. Names created for one VNet cannot be resolved from another VNet.

• VMs get an internal DNS suffix ending in internal.cloudapp.net. You cannot modify it, and you cannot specify a custom DNS suffix for a VNet.

• You cannot register your own records in it.

• DNS query traffic is throttled for each VM.

• It provides "only basic authoritative DNS capabilities."

Custom DNS servers

You can set DNS server IP addresses on the VNet, or on a single network interface. The interface setting takes precedence. If you choose custom DNS you must give at least one server address, or the VNet ignores the setting. After a change, VMs need a DHCP lease renewal to pick it up.

A DNS server inside a VNet can forward queries to the Azure recursive resolvers through 168.63.129.16. Because the DNS suffix differs in every VNet, you can use conditional forwarding rules to send queries to the right VNet. If you use a VPN gateway together with custom DNS, add 168.63.129.16 to the list, or service may be disrupted.

Private DNS zones and Private Resolver

• Azure Private DNS zones are described by Microsoft as the preferred solution for managing your own zones and records. Private zones are global, so one zone can serve several VNets that you link to it.

• Autoregistration. Only one private zone can be linked to a VNet with autoregistration enabled.

• Azure DNS Private Resolver replaces the need for VM-based DNS servers in a VNet. It is used for on-premises to Azure resolution, cross-VNet resolution and App Service scenarios.

Why this matters for design

If a private endpoint exists but the name still resolves to a public address, traffic goes to the wrong place. Microsoft's private endpoint guidance says DNS settings "must resolve to the private IP address of the private endpoint." Plan DNS together with the address plan.

Azure-provided DNS, your own servers and private zones can be combined.

What you cannot do in a VNet

Some habits from physical networks simply do not work. This section lists the ones that surprise engineers most. Where a statement comes from Microsoft's documentation it says so, and where it is an inference, it says that too.

Spanning tree is not discussed in the Microsoft documents used for this article. Because there is no Layer 2 segment to loop, there is nothing for it to protect.

One more useful point: ESP and AH are supported in virtual networks, alongside TCP, UDP and ICMP. Azure Firewall, however, does not natively support ESP. Microsoft says you can allow ESP by creating a network rule with the protocol set to Any, but the firewall does not inspect ESP payloads. Microsoft also notes that Azure Firewall does not natively support BGP peering.

Worked example: a three-tier design, translated

Take a common physical design: an edge firewall, three VLANs for web, application and database servers, ACLs between the VLANs, and an IPsec VPN to a branch office. Here is how it maps to Azure. All addresses are examples only.

The physical design

• A border router and firewall at the edge.

• A web VLAN, an application VLAN and a database VLAN, each with one IP subnet and an SVI on a core switch.

• ACLs on the SVIs that allow only web to application and application to database.

• A site-to-site IPsec VPN to a branch.

The Azure design

The hub address range (10.0.0.0/24) and the spoke range (10.1.0.0/16) do not overlap, which peering requires. The AzureFirewallSubnet is a /26 and the GatewaySubnet is a /27, in line with the minimums and recommendations in section 4.

This is the physical three-tier design from section 12.1, redrawn as Azure objects.

Route tables

1. Spoke subnets. Attach a route table with one UDR: 0.0.0.0/0 to the firewall's private IP, with the next hop type Virtual appliance. Traffic between the three spoke subnets still uses the system route for the VNet address space, so it does not hairpin through the firewall. Microsoft recommends NSGs for internal segmentation, because they do not need UDRs.

2. Branch traffic. With the gateway transit settings on the peering, the spoke learns the branch prefixes through the hub gateway.

3. Firewall rules. The firewall denies everything until you add rules, so add the outbound rules the workloads need before you switch the default route.

NSG rules for the database subnet

The NSG on the database subnet might hold these custom rules. The default rules stay in place at 65000 and below.

The rule at priority 200 is needed because AllowVNetInBound (65000) would otherwise let the web subnet in. To close the rest of the VNet as well, add a broader deny with a priority below 65000, and then check the result with IP flow verify and the effective security rules (section 13).

Port 1433 is just an example database port. Use the port your database uses.

What you gain and give up

• Gained: no cabling, no VLAN trunks, and the whole design can be written as a template and rebuilt.

• Gained: the firewall, gateway and NAT are managed services.

• Given up: broadcast, multicast and Layer 2 tricks (section 11).

• Given up: the ability to log in to the router. Routing is something you declare and then verify with tools.

Troubleshooting: Azure's version of ping, traceroute and show commands

You cannot log in to the network, so Azure gives you diagnostic tools that ask the platform what it would do. They live in Azure Network Watcher.

Tool map

Three questions, in order

1. Where does the packet go? Use Next hop to see which route Azure picks, and check the effective routes of the network interface. This catches a wrong UDR, a missing peering route or a BGP route that wins.

2. Is it allowed? Use IP flow verify, then the effective security rules. Remember that a subnet NSG and an interface NSG can both apply, and traffic must pass both.

3. Does the other end answer? Use Connection troubleshoot for a quick test, and packet capture when you need to see packets.

Each question has a matching tool, so you can work through a failure without guessing.

Things to remember

• Do not use the gateway as a probe. The Azure-provided default gateway does not answer ping.

• Flow logs are changing. NSG flow logs retire on September 30, 2027, and creating new ones is no longer possible. Existing NSG flow log resources are deleted at retirement, but records already in storage are kept under their retention policy. Microsoft recommends virtual network flow logs instead.

• Private endpoints have blind spots. Effective routes and security rules are not shown for the private endpoint's network interface in the portal, and NSG flow logs are not available for inbound traffic to a private endpoint.

• Both ends matter. If an on-premises firewall blocks the return path, Azure tools will show a healthy Azure side. Test from both sides.

Quick reference

Values are as stated in Microsoft Learn when this article was written. Limits and SKUs change, so check the current documentation before you design against a number.

Defaults and numbers

Dates worth knowing

Which tool answers which question

Glossary

References

All references are Microsoft Learn pages.

• What is Azure Virtual Network?

• Azure Virtual Network frequently asked questions

• Create subnets (training module)

• Virtual network traffic routing

• Network security groups overview

• Virtual network peering overview

• Default outbound access in Azure

• Name resolution for resources in Azure virtual networks

• Azure NAT Gateway overview

• Azure Firewall features by SKU

• Azure Firewall rule processing logic

• Azure Firewall FAQ

• Azure Firewall management NIC

• Secure your Azure Firewall deployment

• VPN Gateway FAQ

• Hub-spoke network topology in Azure

• What is Azure Load Balancer?

• What is a private endpoint?

• Azure Network Watcher overview