Azure VNet Networking Security Audit

Cloud resource audit for Azure Virtual Network (VNet) architecture,
network security posture, and hybrid connectivity. This skill evaluates
provider-specific Azure networking constructs — VNet design, NSG priority-
based rules, Azure Firewall rule collection groups, ExpressRoute circuits,
VNet Peering topology, UDR forced tunneling, and Application Gateway
placement — not generic cloud networking advice.

Scope covers VNet-layer networking: address space planning, subnet
delegation, NSG filtering, Azure Firewall inspection, hybrid connectivity
via ExpressRoute and VPN Gateway, and route management. Out of scope:
Azure Front Door CDN policies, Azure WAF custom rule authoring,
application-layer routing in Application Gateway path rules, and Azure
DNS zone management. Reference references/cli-reference.md for read-only
Azure CLI commands organized by audit step, and references/vnet-architecture.md
for the VNet packet flow model, NSG evaluation order, and ExpressRoute
routing architecture.

When to Use

• - VNet architecture design review — validating address space allocation, subnet delegation, and service endpoint configuration
• Post-migration networking audit — verifying VNet connectivity, NSG rules, and UDR entries after workload migration
• Security assessment — identifying overly permissive NSG rules, default NSG exposure, and missing Azure Firewall policies
• Connectivity troubleshooting — diagnosing ExpressRoute BGP peering failures, VPN Gateway tunnel drops, or VNet Peering asymmetric routing
• Compliance preparation — documenting VNet segmentation, NSG justification, and Azure Firewall logging for auditors
• Cost optimization review — identifying unused public IPs, orphaned NICs, and underutilized Application Gateway instances

Prerequisites

• - Azure CLI authenticated (az account show succeeds)
• RBAC permissions — Reader role on target subscription, or granular read permissions: Microsoft.Network/virtualNetworks/read, Microsoft.Network/networkSecurityGroups/read, Microsoft.Network/azureFirewalls/read, Microsoft.Network/expressRouteCircuits/read, Microsoft.Network/virtualNetworkGateways/read, Microsoft.Network/routeTables/read, INLINECODE9
• Target scope identified — specific subscription, resource group(s), and VNet name(s). Multi-subscription audits require az account set per subscription
• Network Watcher enabled — NSG Flow Logs and effective security rules require Network Watcher in the target region. If disabled, document as Critical

Procedure

Follow these six steps sequentially. Each step builds on prior findings,
moving from inventory through security analysis to optimization.

Step 1: VNet Inventory and Design Assessment

Enumerate all VNets in the target subscription and assess architectural design.

CODEBLOCK0

For each VNet, evaluate:

• - Address space allocation: Primary and additional address spaces. Check RFC 1918 compliance, overlapping address spaces across peered VNets (blocks VNet Peering), and sufficient space for growth.
• Subnet layout: Identify subnets by purpose — workload subnets, AzureFirewallSubnet (required name for Azure Firewall), GatewaySubnet (required for VPN Gateway and ExpressRoute Gateway), AzureBastionSubnet. Verify required named subnets exist for deployed services.
• Subnet delegation: Check delegations to Azure services (Microsoft.Sql/managedInstances, Microsoft.Web/serverFarms). Delegated subnets restrict which resources can deploy — a subnet delegated to SQL Managed Instance cannot host VMs or other services.
• Service endpoints vs Private Endpoints: Service endpoints route PaaS traffic over Azure backbone but don't remove public endpoints on the PaaS resource. Private Endpoints create a private IP within the VNet for the PaaS service, removing public exposure entirely. Audit whether data services (Storage, SQL, Key Vault) use Private Endpoints (preferred for zero-trust) or service endpoints (legacy approach with broader exposure).
• DDoS Protection: Verify whether DDoS Protection Standard is enabled on the VNet. Basic DDoS protection is automatic for all Azure resources; Standard adds volumetric attack mitigation, cost protection guarantees, and access to the DDoS Rapid Response team.

Step 2: NSG Rule Audit

Audit Network Security Groups using Azure's priority-based evaluation model.

CODEBLOCK1

NSG rules evaluate by priority (lowest number = highest priority, range 100–4096). First match wins.

• - Priority ordering conflicts: An Allow at priority 200 cannot be overridden by a Deny at 300. Verify Deny rules have lower priority numbers than conflicting Allows — inverse of AWS NACL logic.
• Default NSG rules: Azure creates three default inbound rules (AllowVNetInBound 65000, AllowAzureLoadBalancerInBound 65001, DenyAllInBound 65500) and three outbound defaults (AllowVNetOutBound, AllowInternetOutBound, DenyAllOutBound). These cannot be deleted but are overridden by any custom rule with lower priority number.
• Internet inbound: NSG rules permitting inbound from * or the Internet service tag. SSH/RDP from Internet is Critical; HTTPS on an Application Gateway subnet may be acceptable. The Internet service tag covers all public IP space excluding VNet, peered VNet, and on-premises address ranges.
• Effective security rules: NSGs apply at both subnet and NIC level. Azure evaluates subnet NSG first (inbound), then NIC NSG — traffic must pass both. Use az network nic show-effective-nsg to see the combined effective rules with resolved priorities. A rule allowed by subnet NSG but denied by NIC NSG is effectively denied.
• Application Security Groups (ASGs): ASGs group NICs for use as source/destination in NSG rules instead of IP ranges. Audit ASG membership for correctness.
• Unused NSGs: NSGs not associated with any subnet or NIC are cleanup candidates.

Step 3: Azure Firewall and Network Security

Evaluate Azure Firewall policies, rule collection groups, and threat intelligence.

CODEBLOCK2

• - Rule collection group priority: Azure Firewall processes rule collection groups by priority (lowest first). DNAT rules process first, then Network rules, then Application rules.
• DNAT rules: Translate inbound traffic to private IPs. Verify each DNAT rule maps to a valid backend. Stale DNAT rules pointing to decommissioned hosts create exposure.
• Network rules: Permit/deny by IP, port, protocol. Audit for overly broad rules (* source/destination, wide port ranges).
• Application rules: Filter outbound by FQDN/URL. Verify application rules enforce FQDN restrictions for workload internet access.
• Threat intelligence mode: Azure Firewall supports threat intelligence filtering in Alert or Deny mode. Verify production firewalls use Deny mode.
• IDPS: Azure Firewall Premium supports signature-based IDPS. Verify mode (Alert vs Alert and Deny) and that bypass rules are justified.
• Azure Firewall subnet: AzureFirewallSubnet must be /26 or larger with a public IP and UDRs routing traffic through it.

Step 4: Connectivity Analysis

Evaluate hybrid and inter-VNet connectivity through ExpressRoute, VPN Gateway, and VNet Peering.

ExpressRoute:

CODEBLOCK3

• - Circuit status: Verify ExpressRoute circuit shows "Provisioned" (provider side) and "Enabled" (Azure side). "NotProvisioned" means the provider has not completed circuit setup — no traffic will flow.
• BGP peering state: Check Azure Private Peering and Microsoft Peering BGP session state. State should be "Connected" — "Idle" or "Active" without "Connected" indicates peering negotiation failure (ASN mismatch, VLAN ID mismatch, or provider issue).
• Advertised routes: Verify on-premises routes are visible in Azure via az network express-route list-route-tables and Azure VNet routes are advertised back to on-premises. Missing routes cause silent traffic drops.

VPN Gateway:

CODEBLOCK4

• - Connection status: Should show "Connected". "Connecting" indicates IKE/IPsec parameter mismatch.
• Gateway SKU: Basic SKU lacks BGP and zone-redundancy. VpnGw2+ recommended for production.

VNet Peering:

CODEBLOCK5

• - Peering state: Both sides must show "Connected". "Initiated" means reciprocal peering missing.
• Transit settings: AllowGatewayTransit on hub and UseRemoteGateways on spoke enable shared ExpressRoute/VPN. Verify settings match hub-spoke intent.
• Address space overlap: VNet Peering requires non-overlapping address spaces. Compare both VNets.
• Forwarded traffic: AllowForwardedTraffic must be enabled on both peering links for transit routing through Azure Firewall in the hub.

Step 5: UDR and Routing Validation

Audit User-Defined Routes for correctness, forced tunneling, and conflicts.

CODEBLOCK6

• - Forced tunneling: UDRs with 0.0.0.0/0 next-hop to Azure Firewall or NVA force internet traffic through inspection. Verify forced tunneling is NOT applied to AzureFirewallSubnet, GatewaySubnet, or AzureBastionSubnet.
• Asymmetric routing: Inbound via ExpressRoute but return via Azure Firewall UDR causes asymmetry. Verify UDR next-hop addresses match expected traffic paths in both directions.
• Effective routes per NIC: Azure resolves UDR > BGP > system routes. Use az network nic show-effective-route-table for final effective routes.
• BGP route propagation: UDR tables can disable BGP propagation (disableBgpRoutePropagation). When disabled, ExpressRoute/VPN routes are not injected. Verify this matches routing design.
• Next-hop validation: UDR routes to virtual appliance IPs must reference running, healthy NVAs or Azure Firewall. A stopped VM next-hop creates a silent black hole.

Step 6: Report and Optimization

Compile findings and identify resource optimization opportunities.

CODEBLOCK7

• - Orphaned NICs: NICs not attached to a VM — common after deletions. Each may have NSG rules and private IPs consuming address space.
• Unassociated public IPs: Standard SKU public IPs incur charges when unassociated. Release or associate.
• Application Gateway optimization: Application Gateway v2 runs continuously. Verify autoscale min/max matches traffic patterns.
• Azure Advisor recommendations: Check az advisor recommendation list --category Cost for networking optimization opportunities.

Compile the findings report using the Report Template section.

Threshold Tables

NSG Rule Severity

Finding	Severity	Rationale
NSG allows SSH (22) from Internet	Critical	Direct shell access from internet
NSG allows RDP (3389) from Internet

Critical | Remote desktop open to internet | | NSG allows all ports from * source | Critical | No port or source restriction | | NIC with no NSG, subnet NSG allows broad access | High | No NIC-level filtering | | Allow rule at lower priority than conflicting Deny | High | Priority ordering undermines deny intent | | NSG allows database ports from non-app subnets | High | Database access not restricted to app tier | | NSG with >50 custom rules | Medium | Excessive complexity | | NSG not associated with any subnet or NIC | Medium | Unused — cleanup candidate |

ExpressRoute Circuit Health

Metric	Severity	Action
Circuit status NotProvisioned	Critical	No connectivity — engage provider
BGP peering state Idle

High | Negotiation failure — check ASN and VLAN | | Learned routes missing expected prefixes | High | On-prem routes not advertised | | Circuit utilization >80% sustained | Medium | Plan upgrade or second circuit |

Subnet Utilization

Available IPs (% of address space)	Severity	Action
<10% remaining	High	Exhaustion risk — plan expansion
10–25% remaining

Medium | Monitor growth proactively | | >75% unused | Low | Over-provisioned |

Decision Trees

Is This NSG Rule Overly Permissive?

CODEBLOCK8

Is This VNet Design Following Azure Best Practices?

CODEBLOCK9

Report Template

CODEBLOCK10

Troubleshooting

NSG Flow Logs Not Enabled

If Network Watcher NSG Flow Logs are not configured, traffic visibility is
limited to NSG hit counts. NSG Flow Logs require Network Watcher enabled
and a storage account. Version 2 includes throughput data. Document
missing Flow Logs as High.

Effective Security Rules Show Unexpected Allows

Use az network nic show-effective-nsg for combined subnet and NIC NSG
rules. Check for: higher-priority Allow in NIC NSG overriding subnet Deny,
default rules (65000+) permitting VNet-to-VNet traffic, or ASG membership
including unintended NICs.

ExpressRoute BGP Session Not Established

Verify VLAN ID matches between Azure and provider. Check BGP ASN matches
on-premises router. Use az network express-route peering show to compare
settings. Both primary and secondary should show "Connected".

VNet Peering Shows Initiated But Not Connected

Both peering links must be created. "Initiated" means only one side is
configured. Create the reciprocal link. Cross-subscription peering requires
RBAC on both subscriptions.

UDR Causing Asymmetric Routing

When ExpressRoute delivers inbound traffic directly but UDR routes return
traffic through Azure Firewall, asymmetric routing occurs — the firewall
drops return packets with no session state. Ensure UDR routes both
directions through the firewall, or configure Azure Firewall SNAT.