⏪
 cloudconsulting.agustin

Zero Trust for Azure Networking - Top 25

Design, operational hardening, troubleshooting checklist and PowerShell snippets for Azure networking components used in a Zero Trust architecture.

🔗

1. VNet Peering

Peering provides low-latency, private connectivity between VNets-useful for segmentation while keeping traffic inside Azure backbone.

Top 5 design recommendations

  1. Use hub-and-spoke peering model: hub for shared services (FW, DNS, security) and spokes per workload.
  2. Plan non-overlapping address spaces and define clear IP segmentation boundaries.
  3. Disable transitive routing in classic peering; prefer user-defined routes (UDRs) or firewall for transit control.
  4. Use peering with Global VNet Peering for multi-region designs and enable gateway transit only when needed.
  5. Tag peerings and VNets for ownership, environment and lifecycle management (automation, cleanup).
Official: VNet peering overview

Top 5 operational best practices

  1. Audit peering connections and route tables regularly; log changes via Activity Log.
  2. Use network watchers/peer diagnostics to validate connectivity and troubleshoot MTU/latency.
  3. Enforce least-privilege RBAC for peering creation and modifications.
  4. Automate peering creation via IaC (ARM/Bicep/Terraform) with approval gates.
  5. Monitor cross-VNet traffic egress for cost and security (NSG, FW logs, flow logs).

🔰

2. Network Security Groups (NSG)

NSGs are the core east-west microsegmentation control - use them as first-line network filters close to NIC/subnet.

5 NSG design recommendations

  1. Prefer subnet-scoped NSGs for predictable policies; use NIC-scoped for exceptions only.
  2. Use deny-by-default model: explicit allows then minimal required ports/protocols.
  3. Combine NSG with Application Security Groups (ASG) instead of IP-based rules for scale and clarity.
  4. Enforce service tags (e.g., Storage, AzureLoadBalancer) instead of broad IP ranges when possible.
  5. Use descriptive rule names, priorities and tags for auditability and automation mapping.
Official: NSG overview

5 NSG operational practices

  1. Enable NSG flow logs (via Network Watcher + Storage/Log Analytics) and review for anomalies.
  2. Use policy-as-code to enforce baseline NSG rules across subscriptions.
  3. Validate rule overlaps and priority drift during deployments; prevent unintended open ports.
  4. Lock down management ports (RDP/SSH) to jump boxes or Just-In-Time (JIT) via Azure Security Center.
  5. Regularly review NSG usage and remove stale rules; maintain CI/CD deployment templates.

💻

3. Application Security Groups (ASG)

ASGs simplify grouping of VMs by application role so NSG rules express intent, not IPs.

5 ASG recommendations

  1. Organize ASGs by function (web, app, db) and environment (prod, stage) for reuse.
  2. Reference ASGs in NSGs rather than IPs to reduce change window mistakes.
  3. Automate ASG membership assignment via tags, naming conventions and IaC.
  4. Limit ASG count per subscription/subnet and document mapping to workload diagrams.
  5. Use ASGs with Azure Firewall or NVA rules to map application flows end-to-end.
Official: ASG docs

5 operational tips

  1. Audit ASG membership and NSG rules referencing them during change review.
  2. Use ASG-friendly naming to reflect roles and environment in telemetry and alerts.
  3. When scaling VMs, ensure assignment automation updates ASG membership immediately.
  4. Test ASG rule changes in a non-production spoke before pushing to production.
  5. Combine ASGs with tags and resource graph queries to build reports for compliance.

🧭

4. User Defined Routes (UDRs) & Route Control

UDRs let you steer traffic (to NGFW, NVA, or to internet via Firewall) - vital for enforcing Zero Trust perimeter/egress controls.

5 design rules for UDRs

  1. Centralize egress through hub firewall using UDRs (0.0.0.0/0) rather than per-spoke internet access.
  2. Ensure system routes to Azure services are preserved (do not override service tags routing unintentionally).
  3. Document route tables, priorities and the intended inspection path for audits.
  4. Limit propagation of UDRs that enable transit; prefer Virtual WAN/Hub transit models when at scale.
  5. Use next-hop to NVAs/Firewall and test for asymmetric routing before production cutover.
Official: UDR overview

5 operational controls

  1. Track route tables assignment to subnets; use policy to prevent accidental detachments.
  2. Use network watcher next hop and effective routes to validate pathing after changes.
  3. Monitor for blackhole routes and conflicting routes introduced by peering or NVAs.
  4. Automate change approvals and runbook validation for route table changes.
  5. Maintain a rollback plan and test in a staging environment before sweeping updates.

🏛

5. Hub and Spoke Topology

Hub-and-spoke centralizes shared services (firewall, DNS, VPN) and enforces consistent security posture across spokes.

5 architecture recommendations

  1. Use a dedicated hub VNet for shared security services, transit and egress controls.
  2. Isolate workloads into spokes mapped by trust level and business unit.
  3. Apply routing/UDRs so traffic to/from spokes traverses hub firewall for inspection.
  4. Use hub to centralize identity-aware services (Azure Bastion, NVA, DNS forwarders).
  5. Govern spoke onboarding with template-based deployment and subscription boundaries.
Official: Hub-spoke reference

5 operational recommendations

  1. Enforce hub security via RBAC, policy and scripted deployment; monitor hub resource consumption.
  2. Tag spokes and VNets for business, owner and environment to drive policy and cost allocation.
  3. Use health probes and monitoring for hub firewall, VPN gateways, and NVAs.
  4. Test failover scenarios for gateway and firewall in hub to ensure resilience.
  5. Document trust boundaries and ensure compliance scans on hub services persistently run.

🛰

6. Azure Virtual WAN

Virtual WAN simplifies large-scale connectivity (branch, VPN, ExpressRoute) with central hub automation and security insertion.

5 design recommendations

  1. Use Virtual WAN when you need global transit, scale and simplified branch connectivity.
  2. Choose Firewall Manager integration for centralized NGFW policies and service chaining.
  3. Architect hub-per-region and apply routing/policies consistently across hubs.
  4. Plan for explicit gateway transit options and allowRemoteGateway/UseRemoteGateway flags carefully.
  5. Define BGP and prefix limits before connecting multiple on-prem peers to avoid route storms.
Official: Virtual WAN overview

5 operational controls

  1. Monitor hub health, VPN throughput and ExpressRoute circuits from the Virtual WAN hub blade.
  2. Use automation for branch VPN lifecycle and certificate rotation for S2S/P2S.
  3. Audit route propagation and BGP sessions for stale prefixes or hijacks.
  4. Restrict who can create Virtual WAN hubs with policy and RBAC.
  5. Run periodic scale and performance tests to validate SLA requirements.

🔐

7. Site-to-Site (S2S) VPN

S2S provides encrypted L3 connectivity for on-prem to Azure; treat it as a critical trust boundary with strict controls.

5 S2S design recommendations

  1. Use IKEv2 with strong cipher suites and rotate pre-shared keys or use certificate-based auth.
  2. Advertise only required prefixes; avoid broad 0.0.0.0/0 advertisements from on-prem.
  3. Plan active-active or active-standby gateways for resilience (ExpressRoute as an option for high throughput).
  4. Use BGP for dynamic routing and proper path failover; set BGP weights and prefix filters.
  5. Limit which subnets are reachable over the tunnel via routes/UDRs to reduce blast radius.
Official: VPN Gateway overview

5 S2S operational tips

  1. Monitor IPSec tunnel health, latency and packet loss; set alerts for tunnel flaps.
  2. Validate MTU and fragmentation settings to avoid application issues.
  3. Keep vendor device configs in sync and version-controlled for reproducibility.
  4. Test rekeying and key rotation during maintenance windows to confirm continuity.
  5. Use diagnostic logs and packet capture (Network Watcher) for tunnel troubleshooting.

👥

8. Point-to-Site (P2S) VPN

P2S is user-level secure connectivity - use certificate or Azure AD authentication and limit access via conditional access.

5 P2S best practices

  1. Prefer Azure AD + certificate or OpenVPN with MFA for strong user authentication.
  2. Use split-tunnel carefully: prefer forced-tunnel for high-risk or compliance workloads.
  3. Assign route lists and NSGs to control what P2S clients can reach in VNets.
  4. Limit P2S to managed devices (Intune) and require device compliance signals.
  5. Implement session timeouts and logging for user sessions and connections.
Official: P2S overview

5 operational controls

  1. Monitor active client count and throughput to scale gateway SKU appropriately.
  2. Audit and revoke client certificates periodically and on offboarding.
  3. Integrate P2S access with Conditional Access and device compliance signals.
  4. Use logging to detect unusual location or multiple concurrent sessions for same identity.
  5. Provide tightly-scoped access via role and NSG rules; avoid broad network exposure.

🔥

9. Azure Firewall

Stateful, cloud-native firewall for central inspection, filtering, and threat intelligence enforcement.

5 Azure Firewall design recommendations

  1. Place Azure Firewall in the hub with UDRs directing spoke egress through it.
  2. Use Threat Intelligence (allow/block list) and integrate with Sentinel for alerts.
  3. Design rule collections with least-privilege, explicit allow lists and prioritized rule order.
  4. Leverage TLS inspection where needed (see section on TLS Inspection) and balance privacy/regulatory concerns.
  5. Combine Firewall with Azure Front Door or App GW for layered edge protection.
Official: Azure Firewall

5 operational best practices

  1. Use FQDN tags and application rules for HTTP/S instead of wide IP ranges.
  2. Export and centralize logs (Diagnostics -> Log Analytics) for rule hits and alerts.
  3. Manage rules via Firewall Manager for orchestration across multiple hubs.
  4. Test rules with simulated traffic and use policy-as-code pipelines for rule changes.
  5. Scale with Firewall autoscale for bursty traffic or choose Premium SKU for TLS-inspect and IDPS.

🔍

10. TLS Inspection and Intrusion Detection/Prevention (IDPS)

TLS inspection and IDPS reveal threats in encrypted traffic and prevent exploitation; weigh privacy, compliance and performance.

5 TLS Inspection / IDPS design recommendations

  1. Use Azure Firewall Premium or third-party NGFW with TLS-inspect capability for enterprise inspection.
  2. Define clear inspection scope (outbound to internet, internal east-west) and exclude sensitive workloads by policy.
  3. Plan certificate management (trusted root) and automate certificate distribution to endpoints.
  4. Combine IDPS signatures with threat intelligence feeds and tuned rules to reduce false positives.
  5. Ensure performance sizing (CPU) and latency SLAs are met; test with representative traffic.
Official: TLS inspection (Azure Firewall Premium)

5 operational tips

  1. Track IDPS alerts and tune signature sensitivity to lower noise; integrate with SIEM for alert triage.
  2. Monitor certificate expiration and automate replacement to avoid inspection failures.
  3. Log decrypted flows only where necessary and secure logs for compliance.
  4. Test bypass scenarios and provide documented exceptions with approvals.
  5. Use staged rollout: monitor in detect-only mode before blocking to measure impact.

🔁

11. NAT Rules and SNAT

NAT and SNAT manage address translation and egress identity; misconfiguration can expose internal workloads.

5 design recommendations

  1. Prefer managed NAT through Azure Firewall or NAT Gateway instead of VM-based SNAT where possible.
  2. Use static public IPs for predictable egress ranges (whitelisting partners) and avoid random SNAT churn.
  3. Map expected source IPs in design docs and document services that depend on egress IPs.
  4. Minimize directly-assigned public IPs to VMs; use load balancers/NAT gateways to centralize egress.
  5. Account for port exhaustion and scale NAT resources appropriately for high connection workloads.
Official: NAT Gateway

5 operational controls

  1. Monitor SNAT port utilization and configure autoscale or additional NAT resources when nearing limits.
  2. Log source translations to help incident response identify origin hosts.
  3. Use tests (curl, external echo services) to validate egress IP behavior after changes.
  4. Automate allocation of reserved public IP prefixes to avoid drift.
  5. Audit direct public IP usage and enforce policies to reduce sprawl.

📜

12. Network Rules and Application Rules

Define clear network-level (IP/port) and application-level (FQDN, URL) rules in firewalls for precise control.

5 rule design recommendations

  1. Use application rules (FQDN) for HTTP/S traffic and network rules for non-HTTP protocols.
  2. Order rules by intent: deny-listed first, then allow-lists for minimal exposure.
  3. Group related endpoints into rule collections to simplify management and auditing.
  4. Use service tags and FQDN tags where appropriate to avoid brittle IP lists.
  5. Implement explicit logging per rule collection for forensic traceability.
Official: Azure Firewall rule processing

5 operational recommendations

  1. Test rule changes in staging; monitor hits before enforcing blocks.
  2. Use analytics to find high-hit allow rules that could be tightened.
  3. Document rationale and expected impact for each allow rule to speed reviews.
  4. Automate rule deployment through pipelines and code reviews to prevent human errors.
  5. Integrate firewall logs with SIEM to detect suspicious access patterns.

🔎

13. Network Watcher and Diagnostics

Network Watcher provides visibility - connection troubleshooters, packet capture, NSG flow logs and topology are key for Zero Trust ops.

5 Network Watcher recommendations

  1. Enable Network Watcher per region and centralize logs in Log Analytics or Storage for analysis.
  2. Use connection troubleshoot and IP flow verify to triage path/NSG issues quickly.
  3. Schedule packet captures for complex intermittent issues and retain short windows for privacy.
  4. Enable NSG flow logs and analyze them to detect east-west anomalies.
  5. Use topology and effective routes to validate expected traffic paths after changes.
Official: Network Watcher

5 operational uses

  1. Integrate flow logs with Sentinel/Log Analytics for pivoting and alerting.
  2. Use automated playbooks to run diagnostics when users report connectivity failures.
  3. Keep a catalog of common troubleshooting commands and packet capture filters.
  4. Rotate and secure diagnostic data; use retention policies for compliance.
  5. Use proactive synthetic tests to validate connectivity SLA from critical spokes to hubs.

🖥

14. VMs, NICs and Public IPs

VM/NIC design and public IP assignment directly influence exposure - enforce least-privilege network attachment.

5 design recommendations

  1. Avoid assigning public IPs to VMs unless necessary; use Load Balancer or Application Gateway for inbound access.
  2. Use multiple NICs for separation of management vs workload traffic where required.
  3. Implement Just-In-Time (JIT) for management access and lock management ports via NSG.
  4. Use managed identities and disable local accounts for control plane security.
  5. Enforce encryption at rest and secure boot for VM hardening.
Official: VM networking

5 operational best practices

  1. Audit public IPs periodically and reclaim unused addresses; centralize allocations via NAT Gateway when possible.
  2. Automate NIC tagging and naming for ownership and policy scoping.
  3. Monitor VM NIC metrics and NSG hits for unusual inbound attempts.
  4. Patch VMs regularly and use image pipelines to reduce drift.
  5. Use VM extensions and Azure Policy to enforce VM baseline configuration.

🔐

15. Azure Private Link

Private Link enables private access to PaaS and SaaS services over the Azure backbone, reducing public ingress exposure.

5 Private Link recommendations

  1. Use Private Endpoints to access Azure PaaS from VNets; avoid public endpoints for sensitive data.
  2. Restrict network access to storage/SQL via Private Link and remove public network access when possible.
  3. Design DNS carefully - use Private DNS zones integrated with VNets for resolution.
  4. Use approval workflows for service consumer assignments to Private Link resources.
  5. Combine Private Link with NSG rules and Firewall to enforce egress/ingress inspection.
Official: Private Link overview

5 operational tips

  1. Monitor private endpoint connections and test DNS resolution from spokes post-deployment.
  2. Log Private Link access and export logs for auditing and forensic use.
  3. Manage lifecycle: revoke endpoints on deprovisioning and verify access ACLs.
  4. Use network policies and NSGs to protect the private endpoint NICs.
  5. Document allowed consumer VNets and review periodically for orphaned endpoints.

📛

16. Azure Private DNS

Private DNS zones are essential to resolve Private Link and internal resources without public DNS leakage.

5 Private DNS recommendations

  1. Create dedicated Private DNS zones for internal and PaaS endpoints and link VNets explicitly.
  2. Automate zone linking/unlinking during VNet onboarding/offboarding to avoid stale records.
  3. Use conditional forwarding to on-prem DNS for hybrid name resolution needs.
  4. Lock down who can modify DNS zones with RBAC and separate owner roles.
  5. Use DNS zones naming conventions and TTL policies appropriate to application change frequency.
Official: Azure Private DNS

5 operational tips

  1. Monitor DNS queries to detect exfiltration attempts and anomalous resolution patterns.
  2. Use auditing to see who changed records and integrate with change control.
  3. Test split-horizon scenarios and ensure internal resolution prefers Private DNS.
  4. Secure zone records by limiting write access and using deployment pipelines for changes.
  5. Document DNS dependencies in runbooks for incident response.

🔗

17. Private Endpoints

Private Endpoints bring service access into your VNet via NICs - treat them as first-class network resources to secure.

5 Private Endpoint recommendations

  1. Lock down endpoint NICs with NSGs and limit which subnets host endpoints.
  2. Use endpoint policies and resource-level access control (RBAC) to govern who can create endpoints.
  3. Apply private DNS integration so clients resolve PaaS service names to private IPs.
  4. Avoid multi-tenant exposures: validate Service Provider access when using cross-tenant Private Link.
  5. Track and remove stale endpoints when service consumers are decommissioned.
Official: Private Endpoints

5 operational controls

  1. Log successful/failed connections and monitor for unusual consumer patterns.
  2. Automate endpoint approval workflows and tag endpoints with consumer metadata.
  3. Run periodic scans to detect endpoints that expose sensitive services inadvertently.
  4. Ensure Endpoint DNS and routing are included in disaster recovery plans.
  5. Use policy to enforce private endpoint creation only in approved subnets.

🔁

18. Private Link Service (PLS)

PLS lets you publish your service privately to other VNets/tenants via private link connections; secure exposure is critical.

5 design recommendations

  1. Restrict which consumer subscriptions/tenants can connect; use approval workflows for consumer requests.
  2. Place PLS in isolated subnets and protect with NSGs; monitor inbound consumer traffic carefully.
  3. Define service quotas and scale targets to avoid resource exhaustion from malicious or accidental floods.
  4. Use mutual authentication and service-layer authorization in addition to network controls.
  5. Maintain clear documentation: consumer inventory, access justification and SLA expectations.
Official: Private Link Service

5 operational controls

  1. Rotate credentials and certificates for the PLS endpoints periodically.
  2. Monitor consumer connections, throughput and error rates to detect misuse.
  3. Use alerts for abnormal connection patterns and automated throttling where supported.
  4. Enforce least-privilege access and remove consumer permissions on deprovisioning.
  5. Perform penetration testing on the published service surface during change windows.

🔁

19. Application Gateway (App GW)

App GW provides L7 load-balancing, WAF (web application firewall) capabilities and is a key layer for Zero Trust edge controls.

5 design recommendations

  1. Use App GW V2 with autoscale and WAF v2 policy for production web workloads.
  2. Enable WAF policies with tuned rulesets and custom exclusions to reduce false positives.
  3. Combine App GW with Azure Front Door for global edge + regional WAF enforcement.
  4. Integrate with Private Link or internal load balancing for non-public web apps.
  5. Design subnets dedicated to App GW with route and NSG controls to limit lateral exposure.
Official: Application Gateway

5 operational practices

  1. Monitor WAF logs and tune rules; funnel alerts into SIEM for application-level threat hunting.
  2. Test WAF policy changes in detection mode before blocking to avoid service disruption.
  3. Use certificate management automation (Key Vault) for TLS certificates used by App GW.
  4. Monitor backend health probes and scale settings to avoid overload-related failures.
  5. Apply change control and runbook for breaking changes to routing and listener configs.

🌐

20. Azure Front Door

Front Door provides global edge routing, WAF and DDoS protection for cloud-native apps - combine with App GW for layered defense.

5 Front Door recommendations

  1. Use Front Door Premium for advanced WAF, private origins and enhanced routing controls.
  2. Place origin validation (managed private endpoints or IP allow-list) to reduce origin exposure.
  3. Leverage caching and health probes to improve resilience and reduce origin load.
  4. Configure WAF custom rules for app-specific patterns and bot management capabilities.
  5. Integrate with DDoS Protection Standard and monitor global traffic anomalies.
Official: Azure Front Door

5 operational practices

  1. Validate origin access restrictions after Front Door changes and test failover scenarios.
  2. Monitor WAF rule hits and front-end metrics for sudden traffic spikes.
  3. Use bot protection features and telemetry to block abusive clients.
  4. Automate certificate renewal for TLS and use managed certs where possible.
  5. Audit routing configuration regularly to avoid unintentionally exposing internal origins.

🧭

21. Azure Traffic Manager and DNS

Traffic Manager provides DNS-based traffic routing (priority, performance, geo) - useful for global failover and distribution.

5 Traffic Manager recommendations

  1. Choose routing method based on objective: failover/priority for DR, performance for latency optimization.
  2. Use Traffic Manager for DNS-level health checks; align with origin health probes to avoid split-brain.
  3. Combine with Front Door or CDN for global performance plus regional failover strategies.
  4. Ensure TTL values balance failover speed and DNS churn/caching.
  5. Secure management access to DNS zones and use RBAC/audit for changes.
Official: Traffic Manager

5 operational tips

  1. Monitor DNS failover events and ensure failback procedures are tested.
  2. Keep DNS records synchronized with infrastructure automation and CI/CD pipelines.
  3. Use diagnostic logs for Traffic Manager to troubleshoot unexpected routing behavior.
  4. Document global vs local DNS records and TTL rationale for operations teams.
  5. Validate geo-based routing with sampling tests from targeted regions.

⚖

22. Azure Load Balancer

Load Balancer provides L4 distribution and is fundamental for scaling stateless services and NAT scenarios.

5 design recommendations

  1. Choose Standard SKU for production: zone-redundant, private and public with more predictable behavior.
  2. Plan health probes and backend pools carefully; use probe ports distinct from application ports where necessary.
  3. Document inbound NAT rules and reserved static public IPs usage for predictable egress/ingress.
  4. Leverage Load Balancer outbound rules with NAT Gateway to scale SNAT resources.
  5. Architect for zones and cross-zone redundancy where SLA requires.
Official: Load Balancer

5 operational tips

  1. Monitor probe failures and backend health metrics to detect load imbalances quickly.
  2. Automate infrastructure changes and run pre-deployment checks on probe reachability.
  3. Use telemetry to detect connection storms or port exhaustion on backend VMs.
  4. Maintain clear mapping between LB rules and application endpoints for troubleshooting.
  5. Test failover scenarios across availability zones to validate continuity.

🚪

23. Transit, Allow Gateway Transit and Use Remote Gateway

Gateway transit flags (allowGatewayTransit/useRemoteGateway) control whether a VNet consumes another's gateway - essential for hub transit design.

5 design recommendations

  1. Only enable allowGatewayTransit on hub peerings and useRemoteGateway on spokes that must use hub gateway.
  2. Avoid transitive routing through peering; make transit explicit via UDRs and firewall/NVA enforcement.
  3. Use virtual WAN or Azure Firewall Manager for large-scale transit rather than ad-hoc gateway transit flags.
  4. Document which VNets are allowed to use hub gateways and why; automate checks to avoid drift.
  5. Limit gateway SKUs and capacity planning to match aggregated spoke demand.
Official: Peering and gateway transit

5 operational tips

  1. Audit peering flags regularly to prevent unintended gateway sharing.
  2. Use effective routes and next hop diagnostics to validate traffic pathing through the hub gateway.
  3. Monitor gateway CPU, throughput and tunnel counts to avoid capacity issues from multiple spokes.
  4. Test failover and rekey behavior for spoke-to-hub connectivity during maintenance windows.
  5. Use RBAC to restrict who can toggle allowGatewayTransit/useRemoteGateway settings.

🌐

24. URL Filtering, IDS/IPS and Threat Intelligence

Blocking known-bad URLs and enabling IDS/IPS reduces exposure to web-based threats - integrate with threat feeds and SIEM.

5 design recommendations

  1. Use URL filtering in Azure Firewall/Application Gateway WAF or NGFW to block malicious domains and categories.
  2. Enable IDS/IPS (Azure Firewall Premium or partner) with tuned rules to reduce false positives.
  3. Integrate threat intelligence (auto-block) to quickly mitigate known malicious endpoints.
  4. Combine URL filtering with DNS-layer protection to block at multiple layers.
  5. Implement explicit allow-lists for critical service integrations to prevent accidental blockages.
Official: Azure Firewall URL filtering

5 operational practices

  1. Monitor blocked URL hits and false positives; provide a fast-track review and exception process.
  2. Use SIEM to correlate IDS/IPS events with user/device identity for root-cause analysis.
  3. Keep threat intelligence feeds updated and tune auto-block settings based on business risk appetite.
  4. Periodically review allowed categories and update filters for new business services.
  5. Test URL filtering impact on CI/CD pipelines and service endpoints to avoid disruption.

🛠

25. Troubleshooting Examples and PowerShell Commands (Network)

Practical triage steps and Graph/Az/Net cmdlets to diagnose common networking issues in Azure.

Troubleshooting checklist (common network failures)

  1. VMs can't reach an internal PaaS endpoint - check Private Endpoint health, Private DNS resolution, effective routes and NSG flow logs (Network Watcher IP flow verify).
  2. Spoke cannot reach internet after UDR change - inspect effective routes, next hop, and NAT gateway configuration; verify Firewall SNAT pool and egress UDRs.
  3. VPN tunnel flapping or BGP not converging - review gateway diagnostics, BGP peer status, pre-shared keys/certificates and MTU settings on on-prem device.
  4. Firewall blocking legitimate traffic - check rule hit counts, application/FQDN rules, TLS inspection exceptions and WAF logs; test in detect mode to gather hits.
  5. DNS resolution inconsistent between regions - validate Private DNS zone links, conditional forwarding, and Front Door origin DNS vs Private Link resolution paths.

PowerShell / Azure CLI snippets (network-focused)

Note: run these with least-privilege accounts and test in a pilot subscription first.
# Login (Az module)
Connect-AzAccount
                                                                                                                                                                                                             
# List VNets and address spaces
Get-AzVirtualNetwork | Select-Object ResourceGroupName,Name,Location,AddressSpace

# Show peering status for a VNet
Get-AzVirtualNetworkPeering -VirtualNetworkName "vnet-name" -ResourceGroupName "rg-name" | Format-Table Name,PeeringState,AllowGatewayTransit,UseRemoteGateways

# Get effective routes for a NIC's subnet (via Network Watcher)
Get-AzEffectiveRouteTable -NetworkInterfaceId "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/networkInterfaces/{nic}"

# NSG rules and flow logs
Get-AzNetworkSecurityGroup -ResourceGroupName "rg" -Name "nsg-name" | Select-Object -ExpandProperty SecurityRules
# Enable NSG flow logs (example)
Set-AzNetworkWatcherConfigFlowLog -NetworkSecurityGroupId "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/networkSecurityGroups/{nsg}" 
-Enabled $true -StorageId "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{sa}" -RetentionDays 30

# Check Azure Firewall rules hit counts (logs via Log Analytics recommended)
# List Azure Firewall public IPs and SKU
Get-AzPublicIpAddress -ResourceGroupName "rg" | Where-Object {$_.IpConfiguration -and $_.Sku -like "*Firewall*"}

# VPN gateway troubleshooting: show connections
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName "rg" | Format-Table Name,ConnectionStatus,IngressBytes,EGressBytes

# Private Endpoint list and connection state
Get-AzPrivateEndpoint -ResourceGroupName "rg" | Select-Object Name,PrivateLinkServiceConnections

# Validate DNS resolution from a VM (run in VM via run-command)
Invoke-AzVMRunCommand -ResourceGroupName "rg" -Name "vmname" -CommandId 'RunShellScript' -ScriptString 'nslookup storageaccount.blob.core.windows.net'
Tip: pilot changes in a segmented test tenant, collect logs (FW, NSG flow, Network Watcher), and keep audit-ready exports of route tables, peerings and firewall rules.
Az PowerShell module Network Watcher diagnostics VNet peering (docs)
Azure Networking docs hub

 This article was originally published on 2025-NOV-16 and last reviewed on 2025-NOV-18.