Outbound connectivity & firewall requirements

What an EIDGuard deployment must be able to reach, and what breaks when it cannot. Written for customers who restrict egress with an Azure Firewall, an NVA, a UDR to an on-premises proxy, or NSG rules.

How to read this page. Every destination below is either

• [code] — traced to a line in this repository, cited as file:line, or
• [MS] — quoted from Microsoft's own documentation, with the link, or
• [unverified] — believed to be needed but not provable from either. These are listed deliberately rather than omitted or asserted.

Nothing here is asserted from memory. If a destination you expect to see is missing, it is missing because it could not be verified — see What this page does not tell you.

Related: private-endpoints.md covers which services get private endpoints and why the Hybrid Worker needs internet at all. This page is the exhaustive destination list behind that summary.

1. Three different things need egress#

They are frequently confused, and a rule set written for one will not work for another.

All destinations in this document are HTTPS on TCP 443 unless stated otherwise. Azure Automation's requirement of 443 is explicit:

Property	Description
Port	443 for outbound internet access
Global URL	*.azure-automation.net
Global URL of US Gov Virginia	*.azure-automation.us

— Azure Automation network configuration details [MS]

The one probable exception is Ubuntu apt traffic during the worker bootstrap; see §4.3.

2. Quick reference#

A = Function App, B = Automation/worker, C = operator — and C is two different machines: an admin's browser and an engineer's workstation running the repo-root engine scripts. They have different requirements and are listed separately.

This table is derived, not written. Every row is transcribed from the per-actor section named in Detail, which is the source of truth. Three review rounds found the same defect — a summary row drifting to "Always" while the section it summarised stayed correct — so the table is now one row per destination per actor. There is deliberately no cell in which several actors share one condition, because that is the shape the errors took. If you change a body section, retranscribe its rows here; if the two disagree, the body section wins.

What a blocked ARM endpoint does to the worker. This needs stating in two halves, because one is provable from the code and the other is not, and an earlier draft of this page collapsed them into a single confident sentence.

Proven — the guards fail open. Three ARM-calling safety guards swallow their own failures by explicit design. If a job reaches them, a blocked ARM endpoint does not stop it; it silently disables the protection:

What that third probe costs when it is blind, stated concretely, because it is the sharpest instance of "no symptom, which is the problem" on this page: the customer runs an export precisely to protect their data before deleting the deployment. With ARM blocked the probe cannot see that their chosen destination sits inside the resource group they are about to delete, so it does not refuse. The export reports success. The data lands in the group that gets deleted. Green job, total loss — and nothing anywhere reports an error.

The one export that does fail closed is the one where the destination is the configured source account: -RequireResourceGroupVerification is bound to exactly that condition at :347, and an unverifiable resource group is then a rejection (:228-230, :234-236), with a pre-check throwing earlier at :341.

Unresolved — whether a job gets that far. Every runbook opens with Connect-AzAccount -Identity (automation/runbook-main.ps1:28, runbook-export.ps1:123, and the equivalent first line in each of the others), which is before any guard above. Connect-AzAccount normally populates its context by enumerating subscriptions over ARM — the -SkipContextPopulation switch exists to suppress that, and no runbook passes it. Whether a blocked ARM endpoint therefore fails that call outright, or is tolerated, has not been tested here and is not provable from this repository. [unverified]

So the two possible behaviours are, and this page does not claim to know which:

• If Connect-AzAccount -Identity tolerates it — jobs run to completion and report green while the guards above are silently off. The failure is invisible in job status.
• If it does not — every runbook fails immediately at its first line, loudly and identically, and never reaches a guard at all. The fail-open table above is then irrelevant to diagnosis.

What to do is the same either way: allowlist ARM for the worker. The two branches differ only in what a block looks like, not in whether to permit it. Do not read the per-job scoping in the table above as a licence to block ARM — it is there so that, once you know which branch you are in, you can tell which jobs should have been affected.

3. Actor A — the Function App (web tier)#

3.1 Why the web tier's egress is special#

In a public deployment the Function App uses platform outbound and your firewall never sees it. In a private networking deployment the site is integrated with the app subnet and runs with vnetRouteAllEnabled = $true, which forces all of its outbound through your VNet. The reasoning is written into the deployment code:

# App (P-01): the site is integrated with the app subnet and runs with
# vnetRouteAllEnabled = $true below, so ALL of its outbound is forced through
# the VNet. Without an explicit egress path it depends on platform-provided
# SNAT, which is not a property to rest an authentication boundary on — the API
# validates bearer tokens against the tenant JWKS at login.microsoftonline.com,
# and it also reaches ARM and the (deliberately public) Automation control
# plane.

— automation/runbook-networking.ps1:384-391 [code]

So: if you deploy private networking, the app subnet needs a working egress path, or the dashboard stops being able to validate sign-ins. The deployment attaches its own NAT gateway to NAT-less subnets by default; existing customer NAT gateways are reused.

3.2 Required — always#

The ARM hostname is never a literal in the API code — it is resolved by the Az modules from the context established by Connect-AzAccount -Identity (web/api/profile.ps1:4-6). The same is true of the storage and Key Vault FQDNs, which Az composes from the account/vault name plus the cloud's DNS suffix.

3.3 Required — conditionally#

3.4 Not needed by the web tier#

• *.azure-automation.net — the web tier talks to Automation through ARM (Get-AzAutomationJob, Start-AzAutomationRunbook, Invoke-AzRestMethod). No Automation data-plane hostname appears anywhere in web/api/. [code]

• Microsoft Graph, outside the setup wizard — by design:

  # Graph modules are deliberately absent:
  # the web API never talks to Microsoft Graph; anything that needs Graph
  # runs inside Automation runbook jobs.
  

  — web/api/requirements.psd1:2-5 [code]

• Application Insights ingestion — web/api/host.json:12-18 configures a sampling policy, but no APPLICATIONINSIGHTS_CONNECTION_STRING is set anywhere in the customer template, so the sink has nowhere to send. [code, negative finding]

4. Actor B — the Automation account and the Hybrid Worker#

Two very different execution environments run the same runbooks:

• Cloud sandbox (the default, and always for the start/stop and encryption-at-host jobs). Microsoft-managed; your firewall rules do not apply to it, and it cannot reach private-only resources.
• Hybrid Runbook Worker VM (created by the private-networking feature). Runs inside your subnet, so every rule in this section applies to it.

The Automation account itself is deliberately left publicly reachable — publicNetworkAccess: true at marketplace/bicep/modules/automation.bicep:22, with the reason at automation/runbook-networking.ps1:822-823:

# 9. Lockdown, LAST. Automation stays public on purpose: the cloud start/stop
#    jobs need it, and the private endpoint carries worker traffic.

4.1 Required by most runbook runs#

Two destinations in this table are not needed by every runbook, and the distinction matters both for the allowlist and for diagnosing a failure. Every runbook opens with Connect-AzAccount -Identity, but that call takes its token from the node-local managed-identity endpoint — IMDS on the worker VM, IDENTITY_ENDPOINT on the Function App — not from a connection to login.microsoftonline.com. What actually reaches Entra over the network is the app-only certificate auth to the customer tenant: Connect-MgGraph -ClientId … -TenantId … -Certificate $cert (modules/ExternalIDBackup.psm1:1276). So:

• Reach Entra and Graph: backup (runbook-main.ps1:112), restore (runbook-restore.ps1:57), cert rotation (runbook-rotate-cert.ps1:71), and snapshot-vs-live compare (runbook-compare.ps1:293).
• Managed identity only — no Entra, no Graph: export (runbook-export.ps1:123 is its only auth call), the networking deploy (runbook-networking.ps1:90 likewise), raising deletion protection (runbook-raise-immutability.ps1:40 likewise), and a drift-mode compare, which takes the $driftMode branch at runbook-compare.ps1:280-284 and never reaches the Connect-BackupGraphFromConfig call in the else.

In practice almost every deployment runs backups, so both destinations belong in the allowlist regardless. The reason to keep the distinction is diagnostic: a blocked login.microsoftonline.com does not explain an export or networking job failing, and those two jobs succeeding does not prove it is reachable.

Microsoft Graph has no private-link path: it does not appear anywhere in Azure Private Link availability, whose service tables list Automation, Key Vault, Storage, App Service and the rest but contain no Microsoft Graph or Microsoft Entra ID entry. [MS, negative] A worker in a subnet with no egress path therefore cannot back anything up, no matter how many private endpoints exist.

4.2 Required only in specific configurations#

Microsoft's contract for the custom-metrics endpoint, verbatim:

curl -X POST 'https://<location>.monitoring.azure.com/<resourceId>/metrics' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <accessToken>' \
-d @custommetric.json

Metrics must be emitted to the same Azure Monitor regional endpoint as the region where the resource is deployed.

When you request a Microsoft Entra token to emit custom metrics, ensure that the audience or resource that the token is requested for is https://monitoring.azure.com/. Be sure to include the trailing slash.

— Send metrics to the Azure Monitor metric database by using a REST API [MS]

4.3 Worker runtime bootstrap (apt once per worker; gallery every deploy)#

A Linux Hybrid Worker ships with neither PowerShell 7 nor the modules the runbooks need, so the networking runbook delivers a shell script by Invoke-AzVMRunCommand (automation/runbook-networking.ps1:741). Verbatim, the network-touching lines:

apt-get update -y
apt-get install -y wget apt-transport-https software-properties-common
. /etc/os-release
wget -q "https://packages.microsoft.com/config/ubuntu/${VERSION_ID}/packages-microsoft-prod.deb" -O /tmp/pmp.deb
dpkg -i /tmp/pmp.deb
apt-get update -y
apt-get install -y powershell

— automation/runbook-networking.ps1:718-724 [code]

Install-Module -Name $_.Key -RequiredVersion $_.Value -Scope AllUsers -Force -AllowClobber -Repository PSGallery

— automation/runbook-networking.ps1:739 [code], pinning Az.Accounts 5.5.1, Az.KeyVault 6.5.1, Az.Storage 9.4.0, Az.Automation 1.11.1, Microsoft.Graph.Authentication 2.25.0.

The image is pinned to Ubuntu 22.04 (Canonical / 0001-com-ubuntu-server-jammy / 22_04-lts-gen2, automation/runbook-networking.ps1:632), so ${VERSION_ID} resolves to 22.04.

So this phase needs:

Microsoft's current list, verbatim:

Required network endpoints#

The Install-* and Update-* cmdlets require internet access to connect to the network endpoints used by the PowerShell Gallery.

Ensure that your network access policies allow you to connect to TCP port 443 of the following endpoints.

Hosts required for package discovery and download:

• cdn.oneget.org
• cdn.powershellgallery.com

Hosts required when using the PowerShell Gallery website:

• *.powershellgallery.com - website
• go.microsoft.com and aka.ms - redirection services

Note

These endpoints have changed. The old endpoints that ended with azureedge.net are no longer supported.

The PowerShell Gallery requires Transport Layer Security (TLS) 1.2 or higher.

— Troubleshooting cmdlets [MS]

The bootstrap Run Command is unconditional on every Mode='deploy' run (automation/runbook-networking.ps1:741 sits outside the "VM does not exist" block). The apt/pwsh half is guarded by if ! command -v pwsh, so a re-run only re-contacts the gallery.

There is a second, latent gallery path: Initialize-AzModuleSet calls Install-Module when a module is missing (modules/ExternalIDBackup.psm1:97-99, :110), and it is reached on every Get-BackupStorageContext and every Key Vault read. On a correctly bootstrapped worker or in the sandbox the guard is false and nothing is fetched — but if a module ever goes missing, a runbook will try to reach the gallery mid-job. It uses the default repository and is not version-pinned.

4.4 Automation service (JRDS / agentsvc)#

The worker registers with the extension Microsoft.Azure.Automation.HybridWorker / HybridWorkerForLinux, configured with the account's own hybrid-service URL, read off ARM rather than composed:

$autoUrl = (Get-AzResource -ResourceId $autoId -ExpandProperties).Properties.automationHybridServiceUrl

— automation/runbook-networking.ps1:688, used at :700-703 [code]

Our code never parses or logs that URL, so its shape comes from Microsoft:

A JRDS endpoint is used by the hybrid worker to start/stop runbooks, download the runbooks to the worker, and to send the job log stream back to the Automation service. After enabling JRDS endpoint, the URL would look like this: https://<automationaccountID>.jrds.<region>.privatelink.azure-automation.net.

The agent service endpoint looks like: https://<automationAccountId>.agentsvc.<region>.azure-automation.net.

The URL for public & private endpoint would be the same, however, it would be mapped to a private IP address when Private link is enabled.

— Use Azure Private Link to securely connect networks to Azure Automation [MS]

If you need to allow-list by name rather than by wildcard, Microsoft publishes the per-region records:

| Region | DNS record | Location Code | | West Europe | https://<accountId>.webhook.we.azure-automation.net https://<accountId>.agentsvc.we.azure-automation.net https://<accountId>.jrds.we.azure-automation.net | we |

Replace <accountId> in the DNS record with GUID representing your Automation Account ID

— Azure Datacenter DNS records used by Azure Automation [MS] (the page lists every region; West Europe shown as the pattern)

Microsoft also names the service tags:

When you create network group security rules or configure Azure Firewall to allow traffic to the Automation service and the Log Analytics workspace, use the service tags GuestAndHybridManagement and AzureMonitor.

— Azure Automation network configuration details [MS]

In EIDGuard's private-networking topology this traffic normally does not leave the VNet. The deploy creates privatelink.azure-automation.net and two Automation private endpoints, DSCAndHybridWorker and Webhook (automation/runbook-networking.ps1:477, :530-531). Allow-list the public names anyway if your firewall filters by FQDN before DNS resolution, and expect registration to be slow the first time — the runbook retries at 0 / 300 / 600 / 900 seconds precisely because "JRDS can take a while to honor a newly approved private link" (automation/runbook-networking.ps1:674-676, :689).

The Azure VM Agent also downloads the extension package itself. That destination is a Microsoft platform detail with no literal in this repository — [unverified].

4.5 What private endpoints do and do not cover#

Created by the deploy (automation/runbook-networking.ps1:477-485, :519-533):

Everything else in this document still needs internet. In particular login.microsoftonline.com, graph.microsoft.com, management.azure.com, packages.microsoft.com and the PowerShell Gallery have no private path here.

Note also this Microsoft limitation, which is why the worker exists at all:

In the current implementation of Private Link, Automation account cloud jobs cannot access Azure resources that are secured using private endpoint. For example, Azure Key Vault, Azure SQL, Azure Storage account, etc. To workaround this, use a Hybrid Runbook Worker instead.

— Use Azure Private Link ... Azure Automation [MS]

5. Actor C — operator machines#

5.1 The admin's browser#

The SPA calls three external origins directly with the signed-in admin's own delegated token. This is not incidental — it is pinned by the shipped Content-Security-Policy, and a test asserts the list:

"connect-src": [
  "'self'",
  "https://login.microsoftonline.com",
  "https://graph.microsoft.com",
  "https://management.azure.com"
],
"frame-src": [
  "https://login.microsoftonline.com"
]

— web/api/csp.json:20-28, asserted by tests/SecurityHeaders.Tests.ps1:89-95 ("permits exactly the three origins the SPA calls") [code]

Plus the dashboard's own hostname (https://<site>.azurewebsites.net, or your private address if the web private endpoint is enabled), and — during the setup wizard only — the device-login page Entra returns as verification_uri, opened in a new tab (web/app/src/pages/SetupWizard.tsx:126; the value is not hardcoded, it comes from web/api/SetupDeviceCode/run.ps1:33).

Fonts are bundled at build time, not loaded from a CDN (web/app/src/main.tsx:12-16). There is no analytics or telemetry origin.

5.2 An engineer running the repo-root engine scripts#

Backup-ExternalID.ps1, Restore-ExternalID.ps1 and Compare-ExternalIDBackup.ps1 are the engine kept for local testing against a test tenant. They are not shipped and never run in a customer deployment (CLAUDE.md), but they are the one place a human machine talks to these services directly.

After a private-networking lockdown, a workstation outside the VNet loses Key Vault and Storage — that is the intended result, not a bug. See the ordering caveat in private-endpoints.md.

6. Sovereign and national clouds#

EIDGuard's endpoint handling is inconsistent across clouds, and this is worth knowing before you plan a Gov or China deployment.

Derived correctly (cloud-aware):

• Storage, Key Vault and ARM FQDNs are composed by the Az modules from the connected environment's DNS suffixes — there is no blob.core.windows.net or vault.azure.net literal in the product code. The single storage-context factory is modules/ExternalIDBackup.psm1:314. [code]

• The run-from-package URL is read off the account, with the reason stated in the template:

  // Read off the account rather than composed from the name: sovereign and
  // national clouds do not use blob.core.windows.net, and WEBSITE_RUN_FROM_PACKAGE
  // is built from this.
  

  — marketplace/bicep/modules/hoststorage.bicep:91-94 [code]. The primaryEndpoints.blob read that produces the value is in the sibling module, marketplace/bicep/modules/storage.bicep:166, consumed at marketplace/bicep/modules/functionapp.bicep:110.

• The Easy Auth issuer: openIdIssuer: '${environment().authentication.loginEndpoint}${webAuthTenantId}/v2.0' — marketplace/bicep/modules/functionapp.bicep:169 [code]

Hardcoded to the global cloud (these would need changing for a sovereign deployment):

No Connect-MgGraph call in this repository passes -Environment, so Graph resolves to the module default. [code]

For reference, Microsoft's endpoints per cloud:

| National cloud | Azure portal endpoint | Microsoft Entra ID endpoint | | Azure global service | https://portal.azure.com | https://login.microsoftonline.com | | Azure US Government | https://portal.azure.us | https://login.microsoftonline.us | | Azure China operated by 21Vianet | https://portal.azure.cn | https://login.chinacloudapi.cn |

| National Cloud | Microsoft Graph | | Microsoft Graph global service | https://graph.microsoft.com | | Microsoft Graph for US Government L4 (GCC High) | https://graph.microsoft.us | | Microsoft Graph for US Government L5 (DOD) | https://dod-graph.microsoft.us | | Microsoft Graph China operated by 21Vianet | https://microsoftgraph.chinacloudapi.cn |

— Microsoft Graph national cloud deployments [MS]

And for Automation:

Private Link support with Azure Automation is available only in Azure Commercial and Azure US Government clouds.

— Use Azure Private Link ... Azure Automation [MS]

One product-level caveat is already recorded elsewhere and belongs here too: authenticationEventsFlows (user flows) is global-cloud only and requires the EnableMsGraphAuthenticationEventListener feature flag.

Bottom line: a sovereign-cloud deployment is not validated. Treat the hardcoded table above as a to-do list, not a configuration option.

7. The publisher-hosted licensing endpoint#

This section previously said the endpoint was not implemented. It is, and it is the only egress destination on this page whose failure mode is delayed and silent for a month before it costs the customer anything.

What calls it, and when#

A marketplace deployment always has it configured#

Both licensingEndpoint and licensingAudience must be present for any licensing call to happen; with either missing the deployment is completely inert: no registration, no heartbeat, no banner, no gate. Every marketplace package stamps both (marketplace/scripts/build-package.ps1, which refuses to build a package without them), so a deployment from the marketplace never runs in that state. It is reachable only by deploying the raw template source with both parameters left empty, which is a development path, not a customer one. A firewall that sees no traffic to activate.vambris.com from a marketplace deployment is therefore observing a problem (the host is blocked, or the principal is missing, below), not a deployment that was never configured.

The one failure a firewall cannot fix#

If the licensing application has no service principal in the tenant the deployment runs in, Entra refuses to mint the token at all (AADSTS500011): no request ever leaves, and the deployment walks the same 30/60-day ladder below. The Setup Wizard provisions that principal itself (reusing one that already exists). If that step failed, or the principal was deleted later, the dashboard banner says so and carries the approval link, the onboarding refusal names consent rather than networking, and the backup runbook's stop message does the same. Do not spend that outage on the firewall.

What a block costs, and when#

Nothing for a week, then progressively. Get-LicenceStandingState (modules/ExternalIDBackup.psm1:723-725) measures days since the last verified exchange:

Restore, compare and export are never gated, at any point on this ladder — a customer breached on day 70 must not meet a licensing error.

Recovery is immediate and needs no re-onboarding: the next successful call resets the clock with no penalty period.

Why this one is easy to get wrong#

Three properties combine badly for a firewall reviewer:

• CreateNatGateway='no' plus a default-deny egress policy blocks it entirely, and nothing fails at deployment time.
• The failure is swallowed by design — a background tick must not surface as a failed invocation, so the only immediate evidence is a warning in the function's logs.
• The customer-visible symptom arrives weeks later and reads as a licensing problem, not a networking one.

A deployment given a licensing endpoint it cannot reach therefore stays silent for a week, warns from day 7, refuses new onboarding from day 30, and stops scheduled backups at day 60. If you are locking down egress, this destination is not optional.

8. Troubleshooting — what each blocked destination looks like#

Blocked egress rarely produces a message naming the firewall. These are the observable symptoms.

Two general rules.

1. A healthy dashboard proves almost nothing about the worker. They are different execution environments with different egress paths. The dashboard never calls Graph; the worker calls it constantly.
2. Bootstrap failures surface a day later. packages.microsoft.com and the PowerShell Gallery are contacted during the networking deploy, but the failure shows up at the next scheduled backup. If the first scheduled backup after a networking deploy fails, suspect the bootstrap. Note the two are not on the same schedule: packages.microsoft.com is contacted once per worker (guarded by if ! command -v pwsh), while the gallery is contacted on every deploy — so a redeploy can reintroduce this failure on a worker that was previously fine.

Useful first checks, from the worker or any host in/peered to the VNet:

# Both should resolve to a private address INSIDE your private-endpoint subnet
# — not to a public one. Do not expect 10.x specifically: that is only the
# dedicated-VNet default (10.60.1.0/24, automation/runbook-networking.ps1:323).
# In existing-VNet mode the range is whatever you passed as PeSubnetPrefix
# (:33), which is legitimately 172.16/12, 192.168/16 or any other RFC1918 space.
nslookup <your-vault>.vault.azure.net
nslookup <your-storage>.blob.core.windows.net
curl -sS -o /dev/null -w '%{http_code}\n' https://graph.microsoft.com/v1.0/$metadata
curl -sS -o /dev/null -w '%{http_code}\n' https://login.microsoftonline.com/common/discovery/v2.0/keys

What this page does not tell you#

Listed honestly rather than guessed at. Each needs verification before it goes into a firewall rule.

• The Azure VM Agent's extension-download endpoint. The Hybrid Worker extension package is fetched by the platform agent; no literal exists in this repository, and the destination is not documented here.
• The Ubuntu apt repository hostnames and ports used by the worker bootstrap. They come from the marketplace image's sources.list, not from our code. Ubuntu's defaults are HTTP (port 80), which matters if you allow 443 only.
• The managed-identity token audiences. Connect-AzAccount -Identity (web/api/profile.ps1:6) requests resources chosen by Az.Accounts, not by this repository. The local identity endpoint itself is node-local and not a firewall concern.
• The Application Insights ingestion endpoint. web/api/host.json:12-18 enables the sink but no connection string is set in the customer template, so no destination is derivable — and, as far as the code shows, nothing is sent.
• IP ranges. This page lists FQDNs only. If you must filter by IP, use Microsoft's service tags (GuestAndHybridManagement, AzureMonitor, AzureActiveDirectory, Storage, AzureKeyVault, AzureResourceManager) or the published Azure IP Ranges and Service Tags JSON. This repository asserts no IP ranges.
• Whether an FQDN-filtering firewall (Azure Firewall application rules, an explicit proxy) is sufficient for all of the above. Not tested here.
• Sovereign-cloud operation — see §6.
• The publisher licensing HOSTNAME. The call is implemented and documented in §7, but the hostname arrives as a deployment parameter and this page still cannot name it.