Start with connectivity, filtering and inspection
An Azure Virtual Network creates an isolated IP network in Azure. Subnets divide the address space and provide placement boundaries for resources. Routing determines where packets go. Security controls then decide whether the flow is permitted and, depending on the service, how deeply it is inspected.
If the problem is “where can packets travel?”, inspect topology and routes. If it is “is this IP/port flow allowed near the workload?”, inspect NSGs. If it requires centralized inspection, application rules, NAT or consolidated policy, evaluate Azure Firewall.
VNets and subnets define the network boundary
Choose a non-overlapping address space large enough for planned subnets and growth. Resources communicate privately within a VNet, while peering connects separate VNets over the Microsoft backbone. Peering does not automatically create transitive routing between every connected network.
Azure creates system routes, and user-defined routes can override or extend path decisions. A route table associated with a subnet can send traffic to a virtual appliance or Azure Firewall. A firewall rule cannot inspect a flow that routing never sends through the firewall.
Address-space exam checks
- Peered VNet address spaces must not overlap.
- A subnet belongs to one VNet and uses part of its address space.
- Service endpoints and private endpoints solve different access patterns.
- DNS resolution and IP routing are separate; both may need troubleshooting.
NSGs evaluate stateful rules by priority
An NSG rule includes priority, direction, protocol, source, source port, destination, destination port and action. Lower priority numbers are processed first. Evaluation stops when a matching rule is found, followed by default rules when no custom rule matches.
For inbound traffic to a network interface, applicable rules at the subnet and NIC must permit the flow. For outbound traffic, both applicable layers also matter. Use service tags to represent Azure services and application security groups to group network interfaces by workload purpose instead of maintaining long IP lists.
Destination workload
Check subnet NSG, then NIC NSG, effective rules and whether the application listens on the destination port.
Source workload
Check NIC and subnet controls, routes, firewall policy, DNS and destination response.
Established flow
Return traffic for an allowed connection does not need a separate reverse NSG rule.
Independent connection
A new connection initiated in the opposite direction is evaluated against its own rules.
Azure Firewall centralizes network and application policy
Azure Firewall is a managed, stateful service that can apply network rules, application rules and NAT rules. It supports centralized logging and threat-intelligence-based filtering, with capabilities depending on the selected tier and configuration.
In a hub-and-spoke design, user-defined routes commonly direct spoke traffic through the firewall. Network rules handle IP, port and protocol decisions; application rules can control outbound access using fully qualified domain names for supported protocols. DNAT can publish an internal destination through a firewall public IP.
Does routing send the flow through the firewall?
Which rule collection and rule type should match?
Do NSGs at the source and destination also allow it?
What do firewall, NSG flow and application logs show?
Worked scenario: a spoke VM cannot reach an approved update service
Situation: A VM in a spoke subnet must reach an approved HTTPS update endpoint. The architecture routes internet traffic through Azure Firewall, but the connection times out.
Describe the exact flow
Record source NIC and subnet, destination FQDN/IP, TCP 443, outbound direction and expected next hop.
Inspect effective path
Use effective routes or Network Watcher next-hop diagnostics to confirm the subnet UDR sends traffic to Azure Firewall.
Inspect every policy layer
Check outbound NSGs, the matching firewall application or network rule, DNS resolution and firewall logs.
The route reached Azure Firewall, but the application rule allowed a different FQDN. Correct the narrowly scoped destination, retain centralized routing, and verify the logs show an allowed connection. Increasing VM size would not solve this policy mismatch.
Illustrative learning scenario—not a customer incident or production environment.
A repeatable Azure network troubleshooting sequence
- Define the five-tuple: source, destination, protocol, source port and destination port.
- Validate DNS: confirm the name resolves to the expected public or private address.
- Check effective NSG rules: identify the exact allow or deny and its priority.
- Check effective routes and next hop: ensure the flow follows the intended appliance, gateway or system route.
- Inspect Azure Firewall or NVA policy: find the expected matching rule and review diagnostic logs.
- Confirm the endpoint: verify the service is listening and its host firewall allows the connection.
- Test the flow: use Network Watcher tools and compare evidence before and after the change.
Common AZ-104 networking mistakes
- Using an NSG as a route table or expecting a route table to filter ports.
- Creating Azure Firewall rules without routing traffic through the firewall.
- Checking only a NIC NSG and ignoring the subnet NSG.
- Adding reverse NSG rules for return traffic on an established allowed connection.
- Assuming VNet peering is transitive.
- Opening broad address and port ranges instead of diagnosing the matching rule.
- Troubleshooting IP routing while the real failure is DNS or application listening state.
Frequently asked questions
What is the simplest difference between a VNet, an NSG and Azure Firewall?
A VNet provides the private Azure network and address space. An NSG filters inbound and outbound traffic using stateful layer 3 and layer 4 rules at subnet or network-interface scope. Azure Firewall is a managed, centralized firewall service with network, application and NAT capabilities.
Do I need an NSG if I use Azure Firewall?
They solve different layers of control and are often used together. Azure Firewall provides centralized inspection and policy, while NSGs provide distributed filtering near subnets and network interfaces. The design should avoid contradictory rules and include clear traffic routes.
Are NSG rules stateful?
Yes. When an NSG allows a connection, return traffic for that connection is allowed without a separate reverse rule. New connections in the opposite direction still require their own applicable rule.
Does VNet peering make routing transitive?
No. Peering connects the paired virtual networks, but one peering connection does not automatically provide transitive connectivity through another peered VNet. Hub-and-spoke designs require explicit routing and forwarding configuration.
What should I check first when Azure traffic is blocked?
Define the source, destination, protocol, port and direction. Then inspect effective NSG rules, routes and next hop, firewall or appliance policy, DNS resolution and application listening state. Use Azure Network Watcher and logs to test the actual path.
Official Microsoft references
Confirm current objectives in the official AZ-104 study guide. Review Microsoft Learn for Azure Virtual Network, network security groups and Azure Firewall.