Skip to main content

Appendix C: AVD Firewall Reference

This appendix provides the Azure Firewall rule reference for Azure Virtual Desktop deployments in GCC High. Rules are organized by function tier, from infrastructure baseline to customer-specific application access. For architecture context and the network topology, see Scenario: Azure Virtual Desktop.

Rule Structure and Priority Model​

Rules are organized into application rule collections and network rule collections. Within each collection, rules are evaluated top-to-bottom. Collections are evaluated lowest-priority-number first. The deny-all catch-all at priority 4096 terminates any traffic not matched by an explicit allow.

Application rules and network rules have separate priority namespaces

In the Azure Firewall UI, Application rule collections and Network rule collections are configured in separate tabs with independent priority numbering. A network rule at Priority 200 and an application rule at Priority 200 do not conflict — they are evaluated independently. Network rules are evaluated before application rules for matching traffic. The tables below use the same priority range (200) for both customer application rules and network rules; this is intentional and correct in Azure Firewall's data model.

Application rule collections (FQDN-based, for TCP/HTTP/HTTPS traffic):

PriorityCollectionScope
100AVD-Control-PlaneAVD gateway, broker, agent endpoints (sovereign)
110Identity-And-AuthEntra ID, ADFS, MSA, certificate services
120M365-GCC-HighExchange, Teams, SharePoint, Office clients
130Windows-ManagementWindows Update, telemetry, activation, NTP
140Defender-For-EndpointMDE cloud submission, threat intel, portal
200–299Customer-*Customer-specific application rules (see template)
4096Deny-All-LogCatch-all deny with logging

Network rule collections (IP/port-based, evaluated before application rules for matching traffic):

PriorityCollectionScope
200Essential-PortsDNS, IMDS, Azure health probe, KMS, FSLogix SMB (pooled host pools only — omit for personal/assigned)
210Teams-MediaTeams audio/video UDP ports
220Azure-ServicesService tag-based rules for Azure platform traffic

Application Rule Collections​

Priority 100: AVD-Control-Plane​

These FQDNs are required for session host registration, agent updates, and user session brokering. None of these can be removed without breaking AVD functionality.

AVD agent packages are delivered through blob storage (AVD-Storage) and the CDN (AVD-Infra-CDN) — no separate wildcard *.microsoft.com rule is needed here. Windows OS updates and MDE endpoints are handled by their own collections at Priority 130 and 140, where they can be audited and managed independently.

Rule NameProtocolTarget FQDNsPurpose
AVD-GatewayHTTPS:443*.wvd.microsoft.usSession brokering and gateway
AVD-Service-BusHTTPS:443*.servicebus.usgovcloudapi.netAgent-to-control-plane messaging
AVD-StorageHTTPS:443*.blob.core.usgovcloudapi.netAgent package and session host image downloads
AVD-KVHTTPS:443*.vault.usgovcloudapi.netKey Vault access for disk encryption
AVD-ARMHTTPS:443management.usgovcloudapi.netAzure Resource Manager
AVD-GraphHTTPS:443graph.microsoft.usMicrosoft Graph (Intune policy sync)
AVD-Infra-CDNHTTPS:443agenthubprod.azureedge.usAgent hub CDN
AVD-RD-BrokerHTTPS:443rdbroker.wvd.microsoft.us, rdbroker2.wvd.microsoft.usRD broker (direct)
FQDN tag alternative for AVD control plane

Azure Firewall supports the WindowsVirtualDesktop FQDN tag, which automatically includes the Microsoft-managed list of required AVD FQDNs and is kept current by Microsoft. If your firewall supports FQDN tags, use the tag for Priority 100 instead of maintaining individual FQDNs. In GCC High, confirm the tag resolves to .us endpoints.

If session hosts fail agent registration after removing the wildcard, use the KQL deny queries

The previous *.microsoft.com wildcard was a catch-all that may have been covering undocumented agent endpoints. If you observe agent registration failures after deploying these specific rules, run Query 1 (All Denied Traffic) to identify the specific FQDNs being blocked. Add them to the appropriate tier (AVD-Control-Plane for agent endpoints, Windows-Management for OS functions) and document the rationale.

Priority 110: Identity-And-Auth​

Required for Entra ID authentication, token issuance, MFA, and certificate validation.

Rule NameProtocolTarget FQDNsPurpose
Entra-AuthHTTPS:443login.microsoftonline.usOAuth2/OIDC token endpoint
Entra-Auth-AltHTTPS:443login.microsoftonline.comFallback (some SDKs use .com first)
MSFTAuthHTTPS:443*.msftauth.net, *.msauth.netAuth redirect endpoints
Auth-CDNHTTPS:443*.aadcdn.msftauth.netAzure AD login page UI assets — if blocked, sign-in page renders broken with no visible error
Entra-ADFSHTTPS:443*.microsoftonline-p.comADFS federation
Cert-ServicesHTTP:80, HTTPS:443*.entrust.net, *.digicert.com, *.globalsign.comCRL/OCSP for certificate validation
Windows-AuthHTTPS:443device.login.microsoftonline.usDevice registration
PRT-RefreshHTTPS:443enterpriseregistration.windows.netPRT (Primary Refresh Token)

Priority 120: M365-GCC-High​

Required for Microsoft 365 services. In GCC High, all M365 traffic uses .us endpoints. The .com fallback rules handle a subset of services (Teams presence, Outlook mobile sync) that still route through commercial endpoints in GCC High tenants.

Rule NameProtocolTarget FQDNsPurpose
EXOHTTPS:443*.mail.protection.office365.us, *.outlook.office365.usExchange Online
Teams-SignalingHTTPS:443*.teams.microsoft.us, teams.microsoft.usTeams signaling (sovereign)
Teams-CDNHTTPS:443*.skype.com, *.sfbassets.comTeams static assets (via commercial CDN)
Teams-CDN-StaticHTTPS:443statics.teams.cdn.office.net, *.teams.cdn.office.netTeams static content CDN
Teams-LegacyHTTPS:443*.lync.comLegacy Lync/Teams endpoints — presence, federation, Live Events
Teams-LiveEventsHTTPS:443*.broadcast.skype.comTeams Live Events streaming
SharePointHTTPS:443*.sharepoint.usSharePoint Online
Office-AppsHTTPS:443*.office365.us, *.office.comOffice web apps
M365-CommonHTTPS:443*.microsoftonline.comM365 auth subdomains not covered by Priority 110
Intune-PortalHTTPS:443*.manage.microsoft.usIntune GCC High
Intune-DiscoveryHTTPS:443enrollment.manage.microsoft.usMDM enrollment discovery
Office-CDNHTTPS:443*.officeapps.live.com, *.cdn.office.netOffice click-to-run CDN
Teams media traffic goes through network rules, not application rules

Teams audio and video (real-time media) use UDP ports 3478–3481 and 49152–53247 (ephemeral). These cannot be matched by FQDN-based application rules because UDP traffic is evaluated by Azure Firewall network rules only. See Network Rules: Teams-Media below.

Priority 130: Windows-Management​

Required for Windows Update, telemetry, license activation, and NTP. These FQDNs are common to all Windows session hosts regardless of AVD.

Rule NameProtocolTarget FQDNsPurpose
Windows-UpdateHTTPS:443*.update.microsoft.com, update.microsoft.comWindows Update
WU-DeliveryHTTPS:443*.delivery.mp.microsoft.comDelivery Optimization CDN
WU-CatalogHTTPS:443catalog.update.microsoft.comWSUS catalog
NCSIHTTP:80www.msftconnecttest.comNetwork connectivity indicator
TelemetryHTTPS:443*.events.data.microsoft.com, settings-win.data.microsoft.comDiagnostic telemetry
ActivationHTTPS:443*.activation.sls.microsoft.com, licensing.mp.microsoft.comWindows/Office license activation
SmartScreenHTTPS:443*.smartscreen.microsoft.com, *.urs.microsoft.comSmartScreen reputation
WatsonHTTPS:443*.watson.microsoft.comError reporting
OCSP-MicrosoftHTTP:80ocsp.msocsp.com, mscrl.microsoft.comMicrosoft certificate revocation

Priority 140: Defender-For-Endpoint​

Required for MDE sensor communication, cloud-delivered protection, and threat intelligence updates.

Rule NameProtocolTarget FQDNsPurpose
MDE-PortalHTTPS:443*.security.microsoft.usDefender portal (GCC High)
MDE-ATP-WestHTTPS:443*.winatp-gw-usw.microsoft.comMDE cloud west
MDE-ATP-EastHTTPS:443*.winatp-gw-use.microsoft.comMDE cloud east
MDE-CNCHTTPS:443*.oms.opinsights.azure.usMDE → Log Analytics (GCC High)
MDE-Cloud-ProtHTTPS:443*.wdcp.microsoft.com, *.wdcpalt.microsoft.comCloud-delivered protection
MDE-SmartScreenHTTPS:443*.smartscreen-prod.microsoft.comSmartScreen cloud
MDE-NISHTTPS:443*.updates.microsoft.comNIS signature updates
MDE-CertHTTP:80crl.microsoft.com, ctldl.windowsupdate.comCertificate revocation
MDE requires more FQDNs than this table lists — use the official URL list for restrictive configurations

The rules above cover the most commonly needed MDE endpoints. Microsoft's full list of required MDE URLs is significantly longer (covering streaming telemetry, advanced hunting, automated investigation, and threat intelligence feeds). The *.microsoft.com wildcard in AVD-Agent-Update (Priority 100) provides implicit coverage for many of these, but that wildcard is broad by design.

If your security posture requires narrower rules (no wildcard *.microsoft.com), consult the official MDE URL list for your environment:

For most AVD deployments, the Priority 140 rules plus the Priority 100 *.microsoft.com wildcard provide working coverage. Use the deny-log KQL queries to identify any gaps after deployment.

Network Rule Collections​

Priority 200: Essential-Ports​

These rules allow traffic that cannot be expressed as FQDNs (IP-based or protocol-based infrastructure requirements).

Rule NameProtocolSourceDestinationDestination PortPurpose
DNSUDP, TCPSession host subnetAny53DNS resolution (use Azure DNS or your DNS resolver IP)
IMDSTCPSession host subnet169.254.169.25480Azure Instance Metadata Service — required for VM identity tokens
Azure-HealthProbeTCPSession host subnet168.63.129.1680Azure load balancer health probe — required for VM reachability
NTPUDPSession host subnetAny123NTP time sync
KMSTCPSession host subnetAzureCloud.USGovVirginia, AzureCloud.USGovArizona1688Windows license activation (KMS path, GCC High)
FSLogix-SMBTCPSession host subnetStorage.USGovVirginia, Storage.USGovArizona445FSLogix profile container mount — SMB to Azure Files (GCC High). Pooled host pools only — omit for personal/assigned pools.
IMDS and Azure health probe must be allowed

169.254.169.254 (IMDS) and 168.63.129.16 (health probe) are link-local addresses that Azure uses for internal platform communication. If your UDR sends all traffic to the firewall and these destinations are blocked by the deny-all rule, VMs will lose their managed identity tokens and health probe responses — causing enrollment failures, Intune policy application errors, and VM unavailability in the load balancer.

FSLogix-SMB is required for pooled (multi-session) host pools — omit it for personal/assigned pools

FSLogix mounts profile containers as VHDs over SMB (TCP 445) from the session host to an Azure Files share. The Priority 220 Storage-Gov service tag rule covers HTTPS:443 (REST API) but not SMB. This rule is only needed if you are deploying a pooled (multi-session) host pool with FSLogix.

For personal (assigned) pools, FSLogix is not used — user profiles persist on the VM's OS disk. Remove or omit the FSLogix-SMB rule from the firewall policy to keep the rule set tight.

If you are using a pooled deployment and FSLogix-SMB is missing:

  • FSLogix cannot mount the profile container at user login
  • Windows falls back to a local temporary profile — silently, with no user-visible error
  • Any work saved to Documents, Desktop, or other redirected paths during the session is lost when the session host is replaced or rebooted
  • In a multi-session pool where multiple users share a host, local profile accumulation also causes disk pressure

For Commercial pooled deployments, replace the service tags with Storage.EastUS / Storage.WestUS (or the regions matching your storage account).

Priority 210: Teams-Media​

Teams real-time audio and video require UDP. Azure Firewall cannot inspect UDP by FQDN — these ports must be opened by IP range or service tag.

Rule NameProtocolSourceDestinationDestination PortsPurpose
Teams-STUN-TURNUDPSession host subnetAzureCloud.usgovvirginia, AzureCloud.usgovariz3478–3481STUN/TURN for Teams media relay
Teams-Media-EphemeralUDPSession host subnetAzureCloud49152–53247Teams audio/video media streams
Why such a wide port range?

Teams uses ephemeral UDP ports (49152–53247) for peer-to-peer and relay media. The Microsoft transport relay selects from this range based on session negotiation. Narrowing the range causes intermittent audio/video failures that are difficult to diagnose because HTTPS signaling continues to work.

Priority 220: Azure-Services​

Service tag-based rules for Azure platform services that do not have corresponding FQDN application rules. Network rules evaluate before application rules, so service tag rules here are only added where no FQDN rule in Priority 100–140 already covers the same traffic.

Storage (TCP:443) and ServiceBus (TCP:443) are not included here — they are covered by the FQDN application rules AVD-Storage and AVD-Service-Bus in Priority 100. Adding service tag rules for those services would cause the network rule to intercept the traffic before the FQDN rule is reached, making the FQDN rules non-functional.

AzureActiveDirectory and AzureMonitor are included here as service tags because their IP ranges extend beyond what a single FQDN wildcard reliably covers — Entra ID and Azure Monitor route through a broad set of Microsoft infrastructure IPs that can vary by region.

Rule NameProtocolSourceDestination (Service Tag)Destination PortsPurpose
AzureActiveDirectoryTCPSession host subnetAzureActiveDirectory443Entra ID IP range coverage (supplements FQDN rules in Priority 110)
AzureMonitorTCPSession host subnetAzureMonitor443Log Analytics, diagnostics, Azure Monitor

Customer Application Rule Template​

Customer-specific applications are added at Priority 200–299. Each customer deployment adds its own collection with a unique priority number within that range.

Assessment Checklist​

Before deploying, inventory the applications your AVD users will access and categorize each:

  • Government portals — agency-specific web applications (common: SAM.gov, USASpending.gov, MAX.gov)
  • File sharing / transfer — SFTP servers, managed file transfer services, large file upload portals
  • Line-of-business SaaS — CRM, ERP, project management, HR systems
  • Authentication chains — OAuth providers for those SaaS apps (may require additional auth FQDNs)
  • Vendor-specific tooling — specialized software with cloud licensing or telemetry (e.g., engineering software license servers, GIS platforms)
  • Video conferencing (non-Teams) — Zoom, Webex, Google Meet each have their own FQDN/port requirements
  • Print/scan services — cloud print services if local printing is required from AVD sessions

Template Structure​

Collection: Customer-[AppName]
Priority: 200 (increment by 1 for each additional collection)
Action: Allow

Rules:
  [AppName]-Primary    HTTPS:443    [primary FQDNs]       Primary application
  [AppName]-Auth       HTTPS:443    [auth FQDNs]          OAuth/SAML auth chain
  [AppName]-CDN        HTTPS:443    [CDN FQDNs]           Static assets / CDN
  [AppName]-API        HTTPS:443    [API FQDNs]           API endpoints

Common Categories and Known FQDNs​

CategoryCommon FQDNs to AddNotes
Salesforce*.salesforce.com, *.force.com, *.my.salesforce.comThe *.my.salesforce.com entry is required — the base *.salesforce.com does not cover custom subdomain auth redirects
ServiceNow*.service-now.com, *.servicenow.comTwo domains used across product versions
Zoom*.zoom.us, *.zoomgov.com, *.zoom.comUDP 8801–8802 may be needed for media; add network rule if required
Workday*.workday.com, *.myworkday.com, *.wd[n].myworkday.comwd[n] varies by tenant; identify your tenant's subdomain first
Adobe Acrobat (cloud)*.acrobat.com, *.arclabs.com, *.adobelogin.comLicense activation uses *.adobelogin.com — if missing, Acrobat starts in trial mode
Esri / ArcGIS*.arcgis.com, *.esri.com, *.arcgisonline.comGIS platform with many CDN subdomains; start with wildcard, narrow after logging
Identify unknown FQDNs before deny-all goes live

Before adding the deny-all rule, run the firewall in allow-with-logging mode for 2–4 weeks with session hosts in production use. Export the firewall logs, extract the unique FQDNs, and use them to build your customer-specific rule collections. The KQL queries in the Troubleshooting section below are designed for this workflow.

Firewall Troubleshooting KQL​

These queries run against the Log Analytics workspace connected to your Azure Firewall diagnostic settings. The firewall must have diagnostic settings configured to send AzureFirewallApplicationRule and AzureFirewallNetworkRule logs to the workspace.

Query 1: All Denied Traffic (Triage)​

Use this first to surface every denied connection — both application and network rule denials — sorted by frequency. High-frequency denials are the most impactful to investigate.

AzureDiagnostics
| where Category in ("AzureFirewallApplicationRule", "AzureFirewallNetworkRule")
| where msg_s contains "Deny"
| extend
    RuleCollection = extract(@"Rule Collection:\s*([^.]+)", 1, msg_s),
    SourceIP = extract(@"from\s+([\d.]+):\d+", 1, msg_s),
    DestFQDN = extract(@"to\s+([\S]+):\d+", 1, msg_s),
    DestPort = extract(@"to\s+[\S]+:(\d+)", 1, msg_s),
    Protocol = extract(@"Protocol:\s*(\S+)", 1, msg_s)
| summarize DenyCount = count(), LastSeen = max(TimeGenerated) by SourceIP, DestFQDN, DestPort, Protocol, RuleCollection
| order by DenyCount desc
| take 100

Query 2: Single Host Investigation​

When a user reports a specific application is broken, filter to their session host IP to see only their denied connections.

// Replace with the session host private IP of the affected user's session
let TargetIP = "10.x.x.x";
AzureDiagnostics
| where Category in ("AzureFirewallApplicationRule", "AzureFirewallNetworkRule")
| where msg_s contains "Deny"
| where msg_s contains TargetIP
| extend
    SourceIP = extract(@"from\s+([\d.]+):\d+", 1, msg_s),
    DestFQDN = extract(@"to\s+([\S]+):\d+", 1, msg_s),
    DestPort = extract(@"to\s+[\S]+:(\d+)", 1, msg_s),
    Protocol = extract(@"Protocol:\s*(\S+)", 1, msg_s)
| where SourceIP == TargetIP
| project TimeGenerated, SourceIP, DestFQDN, DestPort, Protocol
| order by TimeGenerated desc

Query 3: FQDN Baseline (Before Deny-All Activation)​

Run this during the allow-with-logging validation period to build your customer application rule list. This query shows every unique FQDN reached by session hosts — sorted by frequency — which becomes the input for building Priority 200+ customer collections.

// Set time range to cover representative business usage (1–2 weeks recommended)
AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| where msg_s contains "Allow"
| extend
    DestFQDN = extract(@"to\s+([\S]+):\d+", 1, msg_s),
    DestPort = extract(@"to\s+[\S]+:(\d+)", 1, msg_s),
    SourceIP = extract(@"from\s+([\d.]+):\d+", 1, msg_s)
| where isnotempty(DestFQDN)
// Exclude already-documented infrastructure FQDNs to focus on unknown destinations
| where DestFQDN !endswith ".microsoft.com"
    and DestFQDN !endswith ".microsoft.us"
    and DestFQDN !endswith ".windows.net"
    and DestFQDN !endswith ".usgovcloudapi.net"
| summarize
    HitCount = count(),
    UniqueHosts = dcount(SourceIP),
    LastSeen = max(TimeGenerated)
    by DestFQDN, DestPort
| order by HitCount desc
Export and categorize the baseline

Export the results of Query 3 to CSV and sort by HitCount. The top entries by hit count are the applications your users depend on most heavily. Group the FQDNs by application (often recognizable by domain) and build one customer rule collection per application. Low-frequency FQDNs that appear from only one or two hosts are candidates for closer review before allowing.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.