Azure Firewall UDR and DNS Design: Prove the Traffic Path Before Writing Rules

An Azure Firewall can be healthy, its policy can contain the correct rule, and the application can still bypass it completely. A client can also use the firewall for the first packet but return through another path, resolve a name differently from the firewall, or reach a Private Endpoint through a more specific platform route. In each case, changing another rule is unlikely to solve the real problem.

The useful unit of design is not the firewall resource. It is the complete conversation:

name resolution
→ selected route
→ firewall decision
→ address translation, if any
→ destination listener
→ symmetric return path
→ timestamped evidence

This is the seventh detailed note in the 12-topic Module 1 study plan for Coursera’s Azure Cybersecurity Solutions and Microsoft Defender course. The Module 1 review provides the wider security map. The preceding Azure Firewall SKU comparison selected a capability and performance boundary. This article begins after that decision and builds the path that makes the selected firewall relevant.

These are independent study notes, not a course transcript, assessment answer, production change record, or universal landing-zone template. Route behavior, DNS behavior, platform defaults, and known issues were reviewed against official Microsoft sources on August 11, 2026.

Explicitly out of scope

The worked example uses Azure Firewall Standard, IPv4, and one customer-managed hub in one region. It does not repeat the Basic, Standard, and Premium comparison. It also does not provide a complete portal walkthrough, Bicep or Terraform module, multi-region hub design, Virtual WAN routing intent, TLS inspection, IDPS tuning, SNAT scale design, or inbound web architecture. Detailed rule collections, structured KQL queries, and reusable validation commands are reserved for the next planned note, azure-firewall-rules-logging-validation; no URL is created for that planned article.

1. The decision this article helps you make

The decision is:

How should a small hub-spoke deployment place Azure Firewall, route each required flow through it, keep DNS answers aligned, preserve the return path, and prove the result before the team invests in detailed rules?

By the end, you should be able to:

• distinguish deployment success from data-path success;
• describe what VNet peering does and why it is not transitive routing;
• read the effective route for a real destination rather than trusting a route-table screenshot;
• explain longest-prefix matching before route-source preference;
• build separate route records for outbound, east-west, hybrid, and inbound traffic;
• identify where each direction’s return route must be controlled;
• separate VNet DNS settings, Azure Firewall DNS Proxy, custom upstream DNS, Azure Private DNS, and Azure DNS Private Resolver;
• explain why FQDN network rules require aligned client and firewall resolution;
• identify Direct Peering, Service Endpoint, and Private Endpoint bypasses;
• distinguish a Management NIC from true forced tunneling;
• explain why NAT Gateway does not process a flow whose selected next hop is a virtual appliance;
• diagnose a failed connection in a fixed order; and
• produce positive, negative, bypass, and recovery evidence for every required path.

The output is a path record, not a diagram alone:

address and subnet plan
+ traffic contract
+ peering settings
+ route-table associations and effective routes
+ DNS client, proxy, upstream, and private-zone chain
+ forward and return-path proof
+ NAT expectation
+ required allow and adjacent deny tests
+ diagnostic destination and timestamps
+ cutover, rollback, and reassessment triggers

2. Use one fixed topology from start to finish

The example is intentionally small. Azure Firewall Standard has already been selected because this workload needs DNS Proxy, custom DNS, and FQDNs in network rules. The goal is not to defend the SKU again. The goal is to make one design understandable enough that a beginner can predict every hop.

                         Internet and approved partner
                         ↑ outbound       ↓ inbound DNAT
                                      data public IP
                              ┌──────────────────┐
                              │ Azure Firewall   │
                              │ Standard         │
                              │ private 10.0.0.4 │
                              └────────┬─────────┘
                                       │
                    Hub VNet 10.0.0.0/16
          ┌────────────────────┼─────────────────────┐
          │                    │                     │
    DNS Private          VPN/ExpressRoute      management path
    Resolver             Gateway               platform only
    static inbound                              when enabled
    10.0.1.4
          │
          ├──────────── hub-to-spoke peerings ────────────┐
          │                                               │
App Spoke 10.10.0.0/16                         Data Spoke 10.20.0.0/16
app subnet 10.10.1.0/24                        service subnet 10.20.1.0/24
app VM 10.10.1.4                               API VM 10.20.1.4
          │                                               │
          └──── no direct App-to-Data peering ────────────┘

On-premises: 172.20.0.0/16 through the hub gateway

The public addresses used later are documentation placeholders, not deployment values. The application VMs have no public IPs. Administrative access follows the private management pattern from the earlier VM design note and is not routed through an invented public SSH rule.

The Management NIC is enabled in this worked deployment so the forced-tunnel branch can be discussed without rebuilding the firewall. That setting alone does not force traffic on-premises. The baseline path still sends tenant Internet traffic directly from the firewall’s data path.

3. Write the traffic contract before creating a route

A route is correct only for a named connection. Start with the five-tuple, the name-resolution expectation, the translation expectation, and the return owner.

ID	Initiator	Requested destination	Protocol	Expected path and result
DNS-PUBLIC	App VM 10.10.1.4	Firewall DNS Proxy 10.0.0.4	UDP/TCP 53	Proxy forwards to approved upstream and returns a public answer
OUT-HTTPS	App VM 10.10.1.4	packages.vendor.example	TCP 443	App UDR → firewall → data-path public SNAT → Internet; allow
EW-API	App VM 10.10.1.4	api.internal.contoso.com → 10.20.1.4	TCP 8443	App UDR → firewall → Data Spoke; symmetric return; allow
HYB-API	App VM 10.10.1.4	On-premises API 172.20.10.20	TCP 443	App UDR → firewall → hub gateway; gateway return → firewall → App Spoke
IN-PARTNER	Documentation partner range 198.51.100.0/24	Firewall data public IP, port 9443	TCP 9443	Narrow DNAT → 10.10.1.4:9443; allow only the approved source
NEG-OUT	App VM 10.10.1.4	Nearby unapproved vendor name	TCP 443	Same firewall path; deny
NEG-EW	App VM 10.10.1.4	Data VM, port 9444	TCP 9444	Same firewall path; deny
NEG-IN	Unapproved public source	Firewall data public IP, port 9443	TCP 9443	No DNAT match; deny

The table deliberately says “same firewall path” for negative tests. A failed connection that bypasses the firewall does not prove the firewall denied it. A positive test without a matching route and firewall record does not prove the intended control allowed it.

Detailed rule names and collection priorities will be implemented in the next note. For now, retain an intent identifier for each flow so route, DNS, policy, and evidence records can refer to the same requirement.

4. Keep five planes separate in the mental model

Beginners often ask one overloaded question: “Does the firewall allow this URL?” Break it into five smaller systems.

Plane	Question	Evidence
Name	Which resolver answered, and which IPv4 address did it return?	Client resolver configuration and timestamped query result
Forward route	Which next hop did Azure select for that returned IP?	Source NIC effective routes and Network Watcher Next Hop
Enforcement	Which policy and rule action processed the connection?	Effective Firewall Policy and matching firewall event
Translation	Were source or destination addresses changed?	SNAT/DNAT expectation, firewall record, and destination observation
Return route	Does the response cross the same stateful firewall?	Destination-side effective route, gateway route, and response evidence

The order matters:

DNS can return the right address while routing bypasses the firewall.
Routing can reach the firewall while policy denies the connection.
Policy can allow the request while the backend has no listener.
The backend can receive the request while the response takes a different route.

This separation prevents random rule changes from hiding a DNS, routing, or application failure.

5. Reserve platform subnets before deploying the firewall

The hub must have nonoverlapping space for every dedicated service. Do not place a firewall into an ordinary workload subnet or assume a small lab subnet will scale safely later.

VNet or subnet	Example range	Purpose	Important constraint
Hub VNet	10.0.0.0/16	Shared routing, security, DNS, and hybrid services	Must not overlap either Spoke or on-premises
AzureFirewallSubnet	10.0.0.0/26	Azure Firewall tenant data path	Exact reserved name; /26 minimum
AzureFirewallManagementSubnet	10.0.0.64/26	Separate platform management path	Exact reserved name; /26 minimum; required when Management NIC is enabled
Resolver inbound subnet	10.0.1.0/28	Private Resolver static inbound endpoint 10.0.1.4	Dedicated and delegated subnet; /28 minimum
Resolver outbound subnet	10.0.1.16/28	Private Resolver outbound endpoint and ruleset	Separate dedicated and delegated /28 subnet
GatewaySubnet	10.0.2.0/27	VPN or ExpressRoute gateway	Exact reserved name; never attach a route table containing 0.0.0.0/0
App Spoke	10.10.0.0/16	Application workload	Peered only with Hub in this example
App subnet	10.10.1.0/24	App VM 10.10.1.4	Receives rt-app
Data Spoke	10.20.0.0/16	Internal service workload	Peered only with Hub in this example
Service subnet	10.20.1.0/24	API VM 10.20.1.4	Receives rt-data
On-premises	172.20.0.0/16	Hybrid dependency	Advertised and filtered explicitly

Do not create a route for the Hub VNet prefix that points back to the firewall private IP. Spoke-to-Hub peering must make 10.0.0.4 reachable as the next hop. Redirecting the next hop toward itself can create a loop or dropped connection.

Account for the 2026 private-subnet default

For API versions released after March 31, 2026, Microsoft documents defaultOutboundAccess=false as the default for subnets in new VNets. The portal already defaults new subnets to private. Existing VNets are not changed automatically, and older deployment API versions can still leave the property unset and implicitly allow default outbound access.

This design does not depend on implicit outbound access. Every workload egress path is explicit through Azure Firewall. Record the API version and the actual defaultOutboundAccess value instead of assuming that the portal, Terraform provider, and an older template create identical behavior. Also remember that an Internet next-hop exception on a private subnet fails without an explicit outbound method; “the route says Internet” does not create a public source address by itself.

6. Deploy in an order that preserves a rollback point

The safest sequence keeps traffic on its existing path until the new firewall, DNS chain, policy intent, and evidence destinations are ready.

1. Freeze the address plan, traffic contract, owners, maintenance window, and rollback criteria.
2. Create the diagnostic destination and decide which structured firewall and DNS categories will be retained.
3. Create the Hub and Spoke VNets with all reserved subnets before placing services in them.
4. Create the data-path public IP, management public IP, Firewall Policy, and Standard firewall with the Management NIC enabled.
5. Wait for a healthy deployment and record the actual firewall private IP, data public IP, management public IP, and resource IDs.
6. Deploy the Private Resolver endpoints and forwarding rules, then prove the upstream name path without involving workload clients.
7. Create both Hub-to-Spoke peerings and validate their settings.
8. Configure the firewall’s upstream DNS and enable DNS Proxy, but do not switch every client yet.
9. Create route tables without associating them to production subnets.
10. Prepare only the minimum policy intent needed for the test flows; detailed rule implementation remains the next article’s scope.
11. Select one canary workload subnet, change its VNet DNS setting, restart or renew the client, and associate its route table.
12. Run positive, negative, bypass, DNS, and return-path tests before extending the association to another subnet.

Associating the route table last is important. A 0.0.0.0/0 UDR can turn an otherwise healthy subnet into a black hole if the firewall is not ready, the private next hop is wrong, the peering is incomplete, or policy has no approved bootstrap flow.

Azure Firewall private addresses are assigned dynamically from AzureFirewallSubnet. A documented known issue says deallocating and reallocating a firewall can change that address. After any allocation event, compare the actual private IP with every UDR next hop and every VNet DNS-server setting before reopening traffic. “The resource name did not change” is not sufficient evidence.

7. Configure peering for forwarded traffic, not automatic transit

VNet peering creates direct reachability between two VNets. It does not make a Hub a router between every Spoke. App Spoke cannot reach Data Spoke merely because both are peered with Hub.

Peering direction	Allow VNet access	Allow forwarded traffic	Gateway setting
Hub → App	Yes	Yes	Allow gateway transit only when the Hub gateway is used
App → Hub	Yes	Yes	Use remote gateways only for the approved Hybrid design
Hub → Data	Yes	Yes	Allow gateway transit only when required
Data → Hub	Yes	Yes	Use remote gateways only when required
App ↔ Data	No direct peering	Not applicable	Central inspection would be bypassed if added without route review

Allow forwarded traffic matters because a packet leaving Azure Firewall did not originate on the firewall’s own private address in ordinary private routing. It is traffic forwarded from another VNet. Configure and verify the setting in both directions relevant to the path.

Direct App-to-Data peering would create a more specific system route for the remote VNet. That can be useful in a design that intentionally values direct low-latency connectivity. It is not used here because the traffic contract requires central inspection. If someone adds it later, the effective route must be reviewed again.

8. Apply longest-prefix match before route-source preference

Azure does not read a route table from top to bottom. It first selects the most specific address prefix that contains the destination IP. /32 is more specific than /24, /16, and 0.0.0.0/0. Only when candidate routes use the same prefix does the ordinary source preference apply:

longest matching prefix first
→ for the same prefix: User-defined route > BGP route > system route

There are platform exceptions. System routes for traffic related to the local VNet or VNet peering are preferred over BGP routes even when the BGP route is more specific. A VirtualNetworkServiceEndpoint route cannot be overridden by a UDR. Always inspect the effective result for the real destination rather than applying one slogan to every Azure service.

Destination from App VM	Candidate routes	Selected result	Lesson
Public vendor IP	System 0.0.0.0/0 → Internet; UDR 0.0.0.0/0 → 10.0.0.4	UDR to firewall	Same prefix; UDR wins
Firewall 10.0.0.4	UDR 0.0.0.0/0; Hub peering 10.0.0.0/16	Hub peering	The more-specific route makes the next hop reachable
Data VM 10.20.1.4	UDR 10.20.0.0/16 → 10.0.0.4; possible equal-prefix peering route	UDR to firewall	Explicit equal-prefix UDR prevents a future direct-peering bypass
Private Endpoint 10.20.2.7	UDR 10.20.0.0/16; if propagated to this NIC, system 10.20.2.7/32 → InterfaceEndpoint	The /32 wins only when it appears in the source NIC’s effective routes	Check the actual source: App and Data have no direct peering in this topology
Azure service with Service Endpoint	UDR 0.0.0.0/0; service-prefix route	VirtualNetworkServiceEndpoint	Service Endpoint is a deliberate bypass class

The practical rule is:

A default route is a catch-all only after Azure has eliminated every more-specific route.

9. Build route tables by path and association

The route name is less important than its prefix, next-hop type, next-hop address, propagation behavior, and associated subnet. This example uses explicit remote prefixes even though the default route could carry them today. That choice protects the inspection intent if a more-specific peering or BGP route appears later.

Route table and association	Prefix	Next-hop type	Next-hop address	Purpose
rt-app → App subnet	0.0.0.0/0	Virtual appliance	10.0.0.4	Public outbound through firewall
rt-app → App subnet	10.20.0.0/16	Virtual appliance	10.0.0.4	App-to-Data through firewall
rt-app → App subnet	172.20.0.0/16	Virtual appliance	10.0.0.4	App-to-on-premises through firewall
rt-data → Service subnet	0.0.0.0/0	Virtual appliance	10.0.0.4	Data workload public outbound through firewall
rt-data → Service subnet	10.10.0.0/16	Virtual appliance	10.0.0.4	Data-to-App return through firewall
rt-data → Service subnet	172.20.0.0/16	Virtual appliance	10.0.0.4	Data-to-on-premises through firewall
rt-gateway → GatewaySubnet	10.10.0.0/16	Virtual appliance	10.0.0.4	Hybrid inbound and return traffic reaches firewall before App
rt-gateway → GatewaySubnet	10.20.0.0/16	Virtual appliance	10.0.0.4	Hybrid inbound and return traffic reaches firewall before Data

In the worked Hybrid design, the Spoke route tables do not depend on gateway-propagated on-premises routes; the explicit on-premises prefix goes to the firewall. The firewall data subnet must still learn or receive a valid route from firewall to the Hub gateway. Treat BGP propagation as an explicit decision, not a default checkbox copied between all route tables.

Do not put 0.0.0.0/0 on GatewaySubnet. Microsoft documents that this configuration can break gateway operation. Use exact Spoke prefixes there. Do not attach the workload route table to AzureFirewallSubnet, and never use the firewall public IP as a virtual-appliance next hop. UDRs target the firewall private IP.

After association, export the effective routes from each source and destination NIC. A route-table resource shows intended inputs; an effective route table shows the combined result of system, peering, BGP, and user-defined routes.

10. Trace the outbound path one decision at a time

The OUT-HTTPS flow starts with a name, not a packet to a known IP.

1. App VM asks its configured resolver, 10.0.0.4, for packages.vendor.example.
2. Azure Firewall DNS Proxy forwards the query to the approved upstream resolver.
3. The client receives the same answer the firewall can use for FQDN policy.
4. The App VM opens TCP 443 to the returned public IPv4 address.
5. rt-app selects 0.0.0.0/0 → Virtual appliance 10.0.0.4.
6. Hub peering makes the private next hop reachable.
7. Azure Firewall evaluates the intended policy and permits the connection.
8. The firewall SNATs the private source to its data-path public IP.
9. The Internet service replies to that public IP.
10. Stateful connection tracking maps the response back to 10.10.1.4.

The DNS query to 10.0.0.4 is not sent in a circle by the workload’s default UDR. The more-specific Hub peering route makes the firewall private address reachable, and the DNS Proxy terminates the query on the firewall. The later data connection uses the default UDR because its destination is public.

Prove the flow with four independent observations:

• the client names 10.0.0.4 as the resolver and receives the expected answer;
• Network Watcher reports VirtualAppliance and 10.0.0.4 for the returned destination IP;
• the expected firewall decision appears at the test timestamp; and
• the destination observes the approved egress public IP and the application response succeeds.

Also attempt NEG-OUT. It should resolve and follow the same route but receive a firewall deny. A DNS failure or route bypass is not an acceptable substitute for negative policy evidence.

11. Trace east-west traffic in both directions

The EW-API flow is a private conversation whose source should normally remain visible to the destination.

Forward
App VM 10.10.1.4
  → DNS Proxy resolves api.internal.contoso.com to 10.20.1.4
  → rt-app: 10.20.0.0/16 → 10.0.0.4
  → Hub peering → Azure Firewall
  → private policy decision
  → Hub-to-Data peering
  → API VM 10.20.1.4:8443

Return
API VM 10.20.1.4
  → rt-data: 10.10.0.0/16 → 10.0.0.4
  → Azure Firewall state table
  → Hub-to-App peering
  → App VM 10.10.1.4

This example deliberately uses a network rule for TCP 8443. Azure Firewall does not SNAT network-rule traffic to RFC 1918 private destinations by default. The API VM therefore sees the App VM’s private source, and its routing decision matters. Application-rule traffic is always SNATed, including traffic sent to a private destination, so an application-rule version of this flow would have a different observed source and translation record. If the response bypasses the stateful firewall, the connection can still fail even when the request reached the API.

The design needs four separate allows: the peering must carry forwarded traffic, the source NSG must permit egress, Azure Firewall Policy must permit the intended flow, and the destination NSG and guest listener must accept it. They are not duplicates. They enforce different boundaries.

If direct App-to-Data peering is added later, a peering system route for 10.20.0.0/16 becomes a bypass candidate. The explicit equal-prefix UDR in rt-app keeps the selected next hop at the firewall because UDR has preference for the same prefix. Re-export the effective route after every peering or address-space change.

12. Treat Hybrid traffic as two routed halves

The HYB-API flow crosses both the firewall and a VPN or ExpressRoute gateway. A successful tunnel alone does not place Azure Firewall in the path.

Azure to on-premises
App VM
  → rt-app: 172.20.0.0/16 → Azure Firewall 10.0.0.4
  → firewall private decision
  → route learned or defined toward Hub gateway
  → VPN/ExpressRoute
  → on-premises API 172.20.10.20

On-premises response
On-premises API
  → on-premises route to 10.10.0.0/16 through VPN/ExpressRoute
  → Azure GatewaySubnet
  → rt-gateway: 10.10.0.0/16 → Azure Firewall 10.0.0.4
  → firewall state table
  → Hub-to-App peering
  → App VM

The gateway route table contains exact Spoke prefixes, not 0.0.0.0/0. On-premises routing must also know the exact Azure prefixes. A route in Azure cannot repair a missing route on the branch router.

For each direction, retain:

• the App NIC’s effective route to 172.20.10.20;
• the firewall’s route toward the Hub gateway;
• the on-premises route to 10.10.0.0/16;
• the GatewaySubnet UDR toward 10.0.0.4;
• the firewall allow decision and stateful response; and
• the expected absence of private-path SNAT unless the organization’s SNAT ranges deliberately change it.

This is private Hybrid transit, not yet forced Internet tunneling. True forced tunneling begins only when the firewall’s data path sends 0.0.0.0/0 to the on-premises edge.

13. Keep inbound DNAT narrow and separate from web ingress

The IN-PARTNER flow publishes one non-HTTP/S service to one documented partner range. Public web applications should normally terminate at an approved WAF or reverse proxy. This example uses Azure Firewall DNAT only to teach the inbound network path.

Approved partner 198.51.100.0/24
  → Azure Firewall data public IP:9443
  → DNAT match for the specific source, protocol, and port
  → translated destination 10.10.1.4:9443
  → App-subnet NSG and guest listener
  → response returns to Azure Firewall state
  → public client

A DNAT match translates and implicitly permits the translated connection. Do not compensate with a broad Any source. Record the actual partner range, purpose, owner, expiry, and a neighboring source that must fail. Rule-collection implementation remains in the next article, but the path contract must already reject an unexplained wildcard.

Azure Firewall SNATs inbound DNAT connections to one of its private addresses to maintain symmetric routing. The backend therefore does not receive the original public client address as its packet source. If an HTTP application requires original-client attribution, use an architecture that preserves it through an application-aware proxy header and protects that header’s trust boundary. Azure Firewall DNAT is not an inbound WAF or an original-source preservation feature.

The return should be validated even though inbound source translation helps keep it symmetric. Confirm the backend listener, subnet NSG, guest firewall, firewall NAT event, response, and observed source. An internal VM also cannot assume it can reach a DNAT backend through the firewall’s own public IP; Azure Firewall documents that hairpin pattern as a known limitation.

This inbound branch belongs to the baseline direct-Internet data path. Do not carry it unchanged into the true forced-tunnel branch in Section 20. Microsoft documents public Internet DNAT as unsupported when the firewall data path is forced on-premises because the resulting route can be asymmetric.

14. Predict translation before reading application logs

Address translation changes what each participant can observe. Write the expected source and destination before testing.

Flow	Default translation behavior	What the destination normally sees	Return requirement
DNS client → Firewall DNS Proxy	No customer data-path SNAT assumption needed; query terminates on proxy	Firewall is the resolver	Proxy must reach a healthy upstream
Spoke → public Internet	Firewall SNATs the private source to a data-path public IP	Firewall public IP	Reply returns to the same firewall state
App Spoke → Data Spoke using a network rule	No SNAT for RFC 1918 destination by default	App VM 10.10.1.4	rt-data sends 10.10.0.0/16 back through firewall
Spoke → RFC 1918 on-premises using a network rule	No SNAT by default	Original Spoke private IP	On-premises and GatewaySubnet routes return through firewall
Private destination using an application rule	Always SNATed by Azure Firewall	Firewall private address	Return enters the firewall state through the translated source
Public client → DNAT backend	Destination is translated and inbound source is SNATed	Firewall private address	Firewall state translates the response back to the public flow
Firewall → on-premises Internet edge in forced tunnel	Internet flow can be SNATed to a firewall private IP	Firewall private address unless private-range behavior is deliberately changed	On-premises edge owns Internet egress and the return route

These are defaults, not permission to skip validation. For network rules, Azure Firewall’s default private ranges include the RFC 1918 ranges and the RFC 6598 shared address space 100.64.0.0/10. An organization using other internal prefixes must record its customized private-range configuration. Setting 0.0.0.0/0 as a private range prevents SNAT for destinations processed by network rules and means those flows cannot egress directly to the Internet; it does not disable SNAT for application rules, which always SNAT. Treat this as a forced-tunnel design decision, not a casual optimization.

If NAT Gateway is later associated with AzureFirewallSubnet in a supported direct-egress design, the Internet destination observes a NAT Gateway public IP instead. That change belongs in the traffic contract, partner allowlists, cost model, and evidence. It does not remove Azure Firewall from the inspection path when the integration is configured on the firewall subnet.

15. Give every DNS component one clear job

“We use Azure DNS” is not a complete DNS architecture. The client, proxy, upstream resolver, forwarding rules, and zone links are different objects.

Component	Job in this example	Common mistake
Spoke VNet DNS setting	Gives workload clients 10.0.0.4 as their resolver	Changing the VNet setting but not restarting or renewing existing VMs
Azure Firewall DNS Proxy	Listens on port 53, forwards queries, and aligns client/firewall resolution	Treating it as an authoritative Private DNS zone
Firewall or Firewall Policy DNS setting	Names the upstream server, 10.0.1.4 in this example	Pointing to an unreachable server or building a forwarding loop
Private Resolver inbound endpoint	Receives recursive queries inside Hub at the statically assigned 10.0.1.4	Expecting on-premises clients to query Azure’s platform resolver directly
Private Resolver outbound endpoint and ruleset	Sends selected namespaces such as corp.contoso.com to on-premises DNS	Creating a . rule that sends the query back to Firewall Proxy
Azure Private DNS zone and VNet link	Makes private records visible to an authorized VNet resolver path	Linking a broad Microsoft-owned default domain to the firewall Hub
On-premises DNS	Remains authoritative for approved corporate namespaces	Failing to return Azure Spoke records through a defined conditional path

The normal sequence is:

Client asks the resolver configured by its VNet and DHCP state.
Firewall DNS Proxy forwards rather than inventing an answer.
The configured upstream finds the applicable private, corporate, or public namespace.
The answer returns through the proxy.
The client then starts a separate data connection to the returned IP.
Routing evaluates that IP independently of the DNS path.

A DNS answer does not create a UDR, and a UDR does not guarantee the right DNS answer. Preserve both pieces of evidence.

Record the current policy-inheritance conflict

Microsoft’s DNS settings guide says a child Firewall Policy inherits parent DNS settings and can override them. The current Azure Firewall known-issues page says child policies do not reliably inherit those settings and can fail to resolve rule FQDNs after a parent change. Until Microsoft resolves that conflict in the target environment, configure and verify DNS settings directly on each child policy instead of relying on inheritance. Record both document dates in the production decision.

16. Configure DNS Proxy as one complete chain

DNS Proxy configuration has three required control points:

1. configure and validate the upstream resolver that Azure Firewall will use;
2. enable DNS Proxy on the applicable firewall or Firewall Policy; and
3. configure each client VNet to use the firewall private IP as its custom DNS server.

Existing VMs keep their current DHCP-provided DNS configuration until it is renewed. Microsoft explicitly directs customers to restart connected VMs after changing the VNet DNS servers. A portal setting that says 10.0.0.4 while the guest still queries an old resolver is not a completed change.

Correct
App VM → Firewall Proxy 10.0.0.4 → Private Resolver 10.0.1.4
                                      ├─ Azure/private answer
                                      └─ conditional on-premises forward

Loop to avoid
Firewall Proxy → Private Resolver → default forward → Firewall Proxy

Allow both UDP and TCP 53 where the path requires them. DNS commonly begins with UDP, but large responses and other conditions can use TCP. Test reachability from the firewall data path to every upstream and ensure the resolver response can return.

Azure Firewall supports up to 15 custom DNS server addresses. When multiple servers are configured, the service selects one randomly rather than treating the list as a client-ordered primary/secondary sequence. DNS Proxy monitors unhealthy upstreams and can move to another available server, but if every configured upstream is unavailable, it does not silently fall back to Azure DNS. Design real redundancy and test the all-upstream-failed condition.

The proxy caches successful responses according to their TTL up to one hour and negative responses up to 30 minutes. It does not prefetch a record before expiry. This explains why a corrected DNS record can appear broken for a while and why “retry every second” is not a useful recovery plan. Record the query time, responding server, answer, TTL, and cache expectations.

17. Put Private Resolver upstream of the proxy for Hybrid names

The worked design uses a central Azure DNS Private Resolver because clients need three namespaces:

App VM, resolver = 10.0.0.4
  → Azure Firewall DNS Proxy
  → custom upstream = Private Resolver static inbound endpoint 10.0.1.4
       ├─ api.internal.contoso.com
       │    → Private DNS zone linked to the Hub resolver path
       ├─ service.corp.contoso.com
       │    → outbound endpoint and forwarding rule
       │    → on-premises DNS
       └─ packages.vendor.example
            → Azure-provided/public resolution

Private Resolver inbound and outbound endpoints use separate dedicated subnets. In this centralized design, the forwarding ruleset that contains corp.contoso.com → on-premises DNS is linked to the Hub VNet. The firewall proxy sends its queries to the Resolver inbound endpoint, and the Hub VNet context applies the linked forwarding rules. The on-premises DNS service uses the inbound endpoint for Azure-hosted private namespaces rather than attempting to query 168.63.129.16; Azure’s platform resolver address is reachable only from inside an Azure VNet.

The inbound address 10.0.1.4 is explicitly assigned as static because the firewall stores it as a custom upstream. A dynamically assigned inbound endpoint address can change after the endpoint is reprovisioned; if dynamic allocation is used instead, every reprovision becomes a DNS drift event that requires the firewall setting and resolution tests to be revalidated.

Linking this ruleset to Hub is safe because its corporate rule forwards to on-premises DNS, not back to the same inbound endpoint. A different design that forwards a private namespace to the Hub inbound endpoint must not also link that forwarding ruleset to the Hub VNet, or it can create a DNS resolution loop.

A subtle boundary matters. Linking a Private DNS zone to the firewall’s VNet lets Azure Firewall itself resolve names from that zone for its own rule processing. It does not mean the DNS Proxy merges that zone into every downstream client response. The proxy forwards downstream queries to its configured upstream. That upstream must also have access to the private zone. In this example, the Private Resolver provides that access.

Do not create and link a broad zone that overrides a Microsoft-owned default domain such as blob.core.windows.net in the firewall Hub. Microsoft warns that doing so can prevent Azure Firewall from resolving endpoints needed for management, logging, monitoring, and updates. Use the documented Private Link zone and zone-group pattern for the workload service, a unique owned subdomain where appropriate, or a separate VNet design that does not contaminate the firewall’s platform resolution.

Validate each namespace independently:

• a public name returns the intended public address;
• api.internal.contoso.com returns 10.20.1.4;
• a corporate name returns the on-premises answer through the forwarding rule;
• a nonexistent name produces the expected negative result; and
• none of the upstreams forwards the same query back into a cycle.

18. Align FQDN network rules with the client’s answer

Azure Firewall Standard can use FQDN destinations in network rules for TCP and UDP protocols that are not handled as application rules. DNS Proxy is required for this design because the firewall implements the rule with resolved IP addresses.

Suppose the rule names time.vendor.example:

Firewall upstream resolves time.vendor.example → IP1
Firewall updates the network rule's address set with IP1

Client bypasses Firewall Proxy and resolves the same name → IP2
Client connects to IP2
Result: route reaches firewall, but the FQDN network rule does not match

The repair is not a broad IP allow. Configure the client to use the firewall proxy so both observations share the same resolution path.

Microsoft documents that Azure Firewall refreshes FQDN-to-IP mappings for network rules every 15 seconds. New addresses are added as resolution changes; old addresses that are no longer returned expire after 15 minutes. Network-rule FQDNs do not support wildcards. Multiple A records, geo-distributed answers, short TTLs, and resolver location can therefore affect a test even when a hostname appears stable.

Application rules work differently for supported HTTP/S and MSSQL scenarios: they use application-layer information such as the Host header or SNI and can distinguish names that share an IP. Detailed rule selection belongs to the next article. The path lesson here is narrower:

For an FQDN network rule, prove the client’s resolver, the firewall’s upstream, the returned IP set, and the route to the actual selected IP at the same time.

19. Inventory routes that intentionally or accidentally bypass 0.0.0.0/0

A default UDR is useful, but it is not an “inspect everything” guarantee.

Bypass class	Why it wins or avoids the default UDR	Safe treatment
Hub peering route	Hub prefix is more specific than 0.0.0.0/0	Required so the firewall private next hop and resolver remain reachable
New direct Spoke peering	Remote Spoke prefix is more specific than the default	Add an equal-prefix UDR to firewall or accept and document direct bypass
Virtual Network Service Endpoint	Platform service route has special preference and cannot be overridden by UDR	Record the bypass; use endpoint policy or a different access design if inspection is mandatory
Private Endpoint	An effective /32 InterfaceEndpoint system route wins over a broader UDR by longest-prefix match	First verify whether that /32 is present on the source NIC, then accept direct access or configure supported inspection
Local VNet destination	VNet system prefix is more specific	Put the enforcement boundary in NSG, supported endpoint policy, or a deliberately routed topology
DNS answer changes public to private	The data connection now matches a different route class	Test route selection after resolution; DNS privacy does not imply firewall inspection

Private Endpoint deserves special care. By default, network policies are disabled for Private Endpoints in their hosting subnet. Azure can expose the endpoint as a /32 InterfaceEndpoint route to a source that has applicable network reachability. When that /32 actually appears in the source NIC’s effective routes, a broad 0.0.0.0/0 or 10.0.0.0/8 UDR cannot override it merely because it is user-defined. Do not assume every source receives that route: in this fixed topology, App and Data have no direct peering, so the App NIC’s effective routes are the deciding evidence.

If the approved architecture requires Private Endpoint traffic to traverse the firewall, enable the applicable route-table network policy on the subnet hosting the Private Endpoint and use a supported UDR whose prefix is not broader than the VNet address space. For a /16 VNet, that means an eligible prefix length from /16 through /32, not 0.0.0.0/0; an explicit /32 route to the firewall is the clearest narrow example. Then validate both directions, the endpoint service’s support boundary, NSGs, and effective routes. Do not mass-deploy /32 routes before deciding who updates them when endpoint addresses change.

The UDR alone does not guarantee a usable inspected connection. Microsoft recommends Azure Firewall application rules for Private Endpoint inspection because application-rule traffic is always SNATed and therefore returns to the firewall. If the design instead uses Azure Firewall network rules or another NVA, configure explicit SNAT so the Private Endpoint’s response cannot take a direct asymmetric path. Prove the translated source and both effective routes during validation.

The bypass inventory is an expected artifact:

destination or service
+ selected effective route
+ bypass intentional? yes/no
+ compensating control
+ owner and review date
+ positive and negative evidence

20. Separate a Management NIC from true forced tunneling

The Management NIC feature was originally coupled to forced tunneling but is now a separate capability. Enabling it creates a protected platform-management path; it does not by itself change where tenant Internet traffic exits.

State	Management NIC	Data-path default route	Result
Baseline in this article	Enabled	Firewall’s ordinary direct Internet path	Management and tenant data paths are separate; not forced tunneling
True forced tunnel	Enabled	UDR to a VPN gateway or NVA, or a BGP-learned default from ExpressRoute	Firewall-inspected Internet traffic exits through on-premises or another approved edge
Split path	Enabled	Specific prefixes go on-premises; remaining Internet destinations use direct path	Each exception needs an explicit route and SNAT record

The management path is intentionally constrained:

AzureFirewallManagementSubnet
  → management public IP
  → Internet for Azure platform operations

Allowed route model:
  0.0.0.0/0 → Internet
  gateway-route propagation disabled

Microsoft advises avoiding customer route tables on AzureFirewallManagementSubnet. If one is associated, the only allowed route is the default Internet path, and gateway propagation must remain disabled. The management public IP is for the Azure platform, not customer ingress.

True forced tunneling changes the tenant path:

Spoke workload
  → Spoke UDR → Azure Firewall data path
  → Firewall Policy
  → AzureFirewallSubnet default route
  → VPN gateway/NVA through UDR, or ExpressRoute through a BGP-learned default
  → on-premises security edge
  → Internet

The next-hop mechanism depends on the gateway type. A 0.0.0.0/0 UDR with the Virtual network gateway next hop can target a VPN Gateway. Azure does not support using that UDR next-hop type to force traffic to an ExpressRoute gateway. For ExpressRoute, the default route must be advertised and learned through BGP, or the UDR must target an approved NVA as a virtual appliance instead.

The on-premises edge must know the Azure source ranges, perform the required Internet egress, and return the flow through the same path. Azure Firewall may SNAT Internet-bound forced-tunnel traffic to a private firewall address unless private-range behavior is deliberately changed. Prove what the edge observes rather than assuming it receives the original workload IP.

Microsoft’s current known-issues guidance says public Internet DNAT is unsupported with true forced tunneling because the return can go through an on-premises device that did not see the connection state. Enabling a Management NIC is not a reason to disregard that data-path limitation. Keep the direct-ingress DNAT example and the forced-Internet-egress example as separate tested architectures unless Microsoft confirms the exact target configuration.

NAT Gateway follows the selected Internet next hop

NAT Gateway is not a UDR next-hop type. It performs outbound SNAT when the selected route uses the Internet next hop. Therefore:

• a workload 0.0.0.0/0 → Virtual appliance 10.0.0.4 route bypasses a NAT Gateway attached only to the workload subnet;
• a direct-egress firewall can use NAT Gateway on AzureFirewallSubnet in a supported integration because the firewall’s selected outbound next hop remains Internet; and
• a firewall 0.0.0.0/0 → Virtual network gateway/NVA forced route bypasses NAT Gateway.

The rule of thumb is not “NAT Gateway is attached, so it will translate.” It is “first determine the selected next hop; NAT Gateway participates only in the Internet path.”

21. Map symptoms to the first layer worth testing

Troubleshooting should narrow the failed plane instead of changing DNS, UDRs, NSGs, and Firewall Policy together.

Symptom	Likely layer	First useful evidence
Client times out resolving every name	Client DNS, port 53, proxy, or upstream	Resolver shown inside guest, TCP/UDP 53 reachability, proxy and upstream health
Public names work but private name returns NXDOMAIN	Private zone visibility or forwarding rule	Upstream used, zone link, resolver ruleset link, authoritative record
Client and firewall resolve one FQDN differently	Client bypasses proxy, geo answer, cache, or upstream mismatch	Timestamped answers from the client path and firewall upstream
FQDN network rule works intermittently after an address change	DNS TTL, 15-second refresh, 15-minute old-address expiry, or multiple A records	Answer set and timestamps, not one remembered IP
Application succeeds but no firewall event exists	More-specific route, direct peering, Service Endpoint, Private Endpoint, or diagnostics gap	Effective route to the resolved destination plus diagnostic setting
App-to-Data SYN arrives but connection times out	Missing return UDR, forwarded-traffic setting, NSG, or guest listener	Data NIC route to App prefix and backend listener evidence
Azure-to-on-premises works but on-premises-initiated return fails	GatewaySubnet route or on-premises prefix advertisement	Exact routes on on-premises edge and GatewaySubnet
Firewall public IP accepts no partner connection	DNAT match, source prefix, port, forced-tunnel mode, backend path	NAT intent, source test address, firewall mode, backend listener
Backend sees firewall private IP instead of public client IP	Expected inbound DNAT source SNAT	Translation design; use an application proxy if original web client attribution is mandatory
VM in a Spoke cannot reach the firewall public IP’s own DNAT backend	Unsupported hairpin pattern	Compare internal destination with firewall known limitations
NAT Gateway public IP never appears	Selected route is Virtual Appliance or Gateway, not Internet	Effective next hop from the component that owns egress
Private Endpoint resolves privately but bypasses firewall	/32 InterfaceEndpoint route and disabled endpoint network policy	Source effective route and Private Endpoint subnet policy
Health, logs, or updates disappear after forced-tunnel work	Management subnet or platform DNS path was changed	Management NIC health, management route, DNS override inventory
All Spoke routes fail after firewall restart	Firewall private IP changed after deallocate/allocate	Current private IP compared with UDRs and VNet DNS settings

Absence of a firewall log has two meanings that must be separated: the traffic might not have reached the firewall, or diagnostic delivery might not be configured or healthy. Prove the route and the telemetry pipeline independently.

22. Diagnose and validate in a fixed order

Use the same sequence for a successful test and a failed test.

1. Record the source IP, requested FQDN, resolved destination IP, protocol, port, direction, and exact UTC timestamp.
2. Confirm which DNS server the client actually used and capture the full answer set and TTL.
3. Use Network Watcher Next Hop for the resolved destination IP, not only the hostname.
4. Export the source NIC’s effective routes and identify the exact winning prefix, source, next-hop type, and next-hop address.
5. Verify peering state, forwarded-traffic settings, and gateway settings.
6. Review effective NSG rules at source and destination without treating them as Firewall Policy.
7. Confirm Azure Firewall health, private IP, applied policy, DNS settings, and diagnostic delivery.
8. Find the expected firewall decision or NAT event at the test timestamp.
9. Prove the destination listener and guest firewall independently.
10. Export the destination-side or GatewaySubnet return route and prove that it crosses the same firewall.
11. Compare the destination-observed source address with the planned SNAT behavior.
12. Run the adjacent deny and bypass tests before declaring success.

Network Watcher Connection Troubleshoot can help separate routing, filtering, and in-guest causes. Next Hop identifies the selected Azure next-hop type and route-table ID. Effective routes show the combined system, peering, BGP, and UDR state. None of these alone proves the Firewall Policy decision, so preserve the matching firewall evidence too.

Minimum validation matrix

Test	Expected DNS result	Expected next hop	Expected outcome	Required evidence
Public DNS positive	Public IPv4 via Firewall Proxy	Query to proxy; data to firewall	Resolve	Client resolver, answer, TTL
Private DNS positive	10.20.1.4	Query to proxy	Resolve	Zone/upstream and client answer
Private DNS negative	NXDOMAIN	Query to proxy	No data flow	Negative-cache-aware query result
Outbound allow	Approved vendor IP	VirtualAppliance 10.0.0.4	Connect	Effective route, allow event, egress IP
Outbound deny	Unapproved nearby name	Same firewall next hop	Deny	Effective route and deny event
East-west allow	10.20.1.4	Firewall in both directions	Connect	Both NIC routes, allow, listener response
East-west deny	10.20.1.4 on 9444	Same firewall path	Deny	Both routes and deny event
Hybrid allow	172.20.10.20	Firewall then gateway	Connect	App, firewall, gateway, on-premises routes
Inbound partner allow	Data public IP	Firewall DNAT	Connect	Source restriction, NAT event, backend response
Inbound neighboring deny	Data public IP	Firewall	Deny	No matching DNAT and timestamped evidence
Direct Internet bypass	Public test address	Must not be Internet from Spoke	Fail as a bypass	Next Hop and effective route
Private Endpoint route	Private /32	Approved direct endpoint or firewall	Match design	Endpoint policy and effective route

Run the canary tests before broad route-table association. A rollback should restore both the prior route association and prior DNS setting; rolling back only the UDR while leaving clients on an unavailable proxy is incomplete.

23. Finish with checklists, self-review, and a memory card

Architecture and deployment checklist

• Standard, IPv4, single-region, customer-managed Hub assumptions are recorded.
• Hub, both Spokes, and on-premises prefixes do not overlap.
• AzureFirewallSubnet uses the exact name and at least /26.
• AzureFirewallManagementSubnet uses the exact name and at least /26 where the Management NIC is enabled.
• Private Resolver endpoints use separate dedicated subnets of at least /28.
• GatewaySubnet contains no 0.0.0.0/0 UDR.
• Firewall private and public addresses were recorded after deployment.
• Peering permits the required forwarded traffic.
• Direct Spoke peering is absent or its bypass is explicitly accepted.
• Route tables are associated only with intended subnets.
• Every required private flow has a return-path route.
• Effective routes, not only route definitions, were exported.

DNS and bypass checklist

• Workload clients actually use the firewall private IP as DNS server.
• Existing VMs were restarted or renewed after the VNet DNS change.
• Firewall DNS Proxy is enabled on the effective policy or resource.
• The upstream resolver is reachable over UDP and TCP 53.
• All-upstream failure behavior is accepted; no hidden Azure DNS fallback is assumed.
• The upstream can resolve required public, private, and corporate namespaces.
• No forwarding rule sends queries back into a proxy loop.
• Child-policy DNS is configured and verified directly while the inheritance issue remains.
• Broad Microsoft-owned default DNS zones are not linked to the Firewall Hub.
• FQDN network-rule tests retain answer sets and timestamps.
• Service Endpoint and Private Endpoint routes are listed in the bypass register.
• Private Endpoint network policy and UDR behavior match the approved inspection decision.

Operations and cutover checklist

• Diagnostic delivery is healthy before traffic cutover.
• One canary subnet is tested before wider association.
• Allow and adjacent deny tests follow the same intended path.
• Outbound, east-west, Hybrid, and inbound return paths have separate evidence.
• NAT expectations match what each destination observes.
• Management NIC is not mislabeled as active forced tunneling.
• A true forced-tunnel design preserves the Management subnet’s Internet route.
• Public Internet DNAT is not promised for the true forced-tunnel path.
• NAT Gateway participation is based on the selected Internet next hop.
• Firewall deallocate/allocate procedures verify private-IP route and DNS drift.
• Rollback restores both route associations and client DNS settings.
• Owners and reassessment triggers exist for peering, BGP, endpoints, DNS, and routes.

Self-review questions

1. Why can a healthy Azure Firewall with a correct rule process none of a workload’s traffic?
2. What does VNet peering provide, and why is it not transitive routing?
3. Why does Azure compare prefix length before UDR, BGP, and system route source?
4. Why can a direct Spoke peering bypass a 0.0.0.0/0 firewall UDR?
5. Why is the Hub peering route to the firewall private IP a necessary exception?
6. Which route evidence proves the path actually selected by a VM?
7. Why does east-west private traffic require a route on both Spokes?
8. Why must GatewaySubnet use exact Spoke routes instead of a default UDR?
9. Why is Firewall DNS Proxy not the same object as Azure DNS Private Resolver?
10. What happens after all configured custom DNS upstreams become unavailable?
11. Why can a linked Private DNS zone fail to answer a downstream proxy client?
12. Why can an FQDN network rule fail when the client and firewall use different resolvers?
13. How do Service Endpoint and Private Endpoint routes bypass a broad default UDR?
14. What must be enabled before a supported UDR can override Private Endpoint routing?
15. Why does enabling a Management NIC not create true forced tunneling?
16. When does NAT Gateway participate in route selection and SNAT?
17. Why does a DNAT backend normally observe a firewall private source address?
18. Which two settings must a rollback restore after a combined route and DNS cutover?

One-minute memory card

Name → Forward route → Policy → NAT → Return route → Evidence

DNS tells the client which IP to use.
Longest prefix chooses the route before route-source preference.
Peering provides reachability, not automatic transit.
A firewall rule matters only after traffic reaches the firewall.
Private traffic needs an explicit symmetric return path.
DNS Proxy aligns the client and firewall view of FQDNs.
Service Endpoint and Private Endpoint routes can bypass a default UDR.
Management NIC ≠ forced tunneling.
NAT Gateway participates only when the selected next hop is Internet.

Route definition ≠ effective route.
Connection success ≠ firewall-path proof.
No log ≠ confirmed firewall deny.

The final memory line is:

Before writing more firewall rules, prove the resolved address, winning route, firewall decision, translation, and return path for one real connection in both the allow and deny cases.

The next planned Module 1 note, azure-firewall-rules-logging-validation, will implement rule collections, structured logging, queries, and repeatable validation commands. It remains plain text until the complete English and Korean article pair is ready; no empty route is linked.

References

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Azure Firewall and traffic inspection
• Microsoft Learn: Deploy and configure Azure Firewall using the Azure portal
• Microsoft Learn: Hub-and-spoke network topology
• Microsoft Learn: Azure virtual networks and subnets
• Microsoft Learn: Azure virtual network traffic routing
• Microsoft Learn: Route network traffic with a route table
• Microsoft Learn: Virtual network peering
• Microsoft Learn: Diagnose a virtual machine routing problem
• Microsoft Learn: Network Watcher Next Hop
• Microsoft Learn: Network Watcher Connection Troubleshoot
• Microsoft Learn: Azure Firewall DNS settings
• Microsoft Learn: Azure Firewall DNS Proxy details
• Microsoft Learn: FQDN filtering in Azure Firewall network rules
• Microsoft Learn: Azure DNS Private Resolver architecture
• Microsoft Learn: Azure DNS Private Resolver endpoints and rulesets
• Microsoft Learn: Azure DNS Private Resolver in a hub-spoke network
• Microsoft Learn: What is Azure Private DNS?
• Microsoft Learn: Azure Private Endpoint DNS integration
• Microsoft Learn: Manage network policies for Private Endpoints
• Microsoft Learn: Troubleshoot Private Endpoint connectivity
• Microsoft Learn: Inspect Private Endpoint traffic with Azure Firewall
• Microsoft Learn: Azure Virtual Network Service Endpoints
• Microsoft Learn: Azure Firewall forced tunneling
• Microsoft Learn: Azure Firewall Management NIC
• Microsoft Learn: Azure Firewall destination NAT rules
• Microsoft Learn: Azure Firewall SNAT private IP address ranges
• Microsoft Learn: Azure Firewall known issues and limitations
• Microsoft Learn: Monitor Azure Firewall
• Microsoft Learn: Design virtual networks with Azure NAT Gateway
• Microsoft Learn: Integrate Azure Firewall with NAT Gateway
• Microsoft Learn: Default outbound access in Azure