• Intro
• Decide how Arc Gateway fits the deployment
• Plan the gateway and deployment inputs
• Agree the endpoint policy
  • Which destinations does the firewall need to allow?
  • Examples of destinations outside the gateway tunnel
• Build and review the bypass inputs
• Include workloads in the design
• Turn the endpoint review into a firewall request
• Deployment readiness check
• Outro

Intro

This article is part of a series: Navigate to series page

I would treat Arc Gateway as part of the Azure Local deployment design, not as a firewall-cleanup task to handle after the cluster is running.

This article is about the preparation around a new Azure Local deployment: the topology decisions, network requirements, proxy and bypass inputs, and workload considerations I want settled before registration starts. I am not walking through the Azure portal gateway creation or the post-deployment configuration job here. Those are different tasks; Part 3a will cover the portal workflow for an already-deployed cluster.

Decide how Arc Gateway fits the deployment

Start with the public-path or private-path decision in Part 1. Confirm which Azure Local release and deployment method you are using, and whether the gateway is being configured as part of initial registration or added to an existing instance later.

For releases earlier than 2610, the documented post-deployment workflow is not supported. On 2610 or later it is still a preview, and gateway enablement cannot be reversed through that preview.

For the public path, decide whether the local Arc proxy connects directly through the firewall or through an enterprise proxy. For the private path, prepare the documented ExpressRoute or site-to-site VPN route, Azure Firewall explicit proxy, DNS, and routing. Every Azure Local machine must be able to reach the required next hop; creating a gateway resource alone does not establish that network path.

Use the private path deployment guide for its supported topology. Initial private path deployment requires Azure Local 2608 or later.

Plan the gateway and deployment inputs

Before the deployment window, confirm the Azure Local subscription, tenant, region, and resource groups with the Azure and platform owners. The gateway must be in the same subscription as the Azure Local instance for this infrastructure scenario. Check the current Azure Local Arc Gateway overview for current eligibility and feature requirements.

If initial registration will use Arc Gateway, have the gateway provisioned before registration and record its full resource ID and assigned gateway URL. Agree who creates it and who has the permissions to use it. I am keeping the portal creation walkthrough for Part 3a, which demonstrates creating a gateway and selecting it for an already-deployed cluster; that post-deployment job is not the initial-registration workflow.

For initial registration, use the current Arc Gateway registration workflow. Decide whether the team will use the Configurator app or the initialization script, and collect the documented registration values, including the gateway resource ID and any enterprise proxy settings. Follow the current guidance for authentication, target-version selection, and reboot or resume steps rather than copying parameters from an older deployment.

Agree the endpoint policy

Before registration, give the network team the assigned gateway FQDN and the current non-redirected Azure Local endpoint list.

Make the rules specific to your actual region, Key Vault, and cloud witness storage account. The registration endpoints must work before the agent can establish its normal gateway path. HTTP certificate-validation traffic also needs a permitted route; it will not use the gateway tunnel.

Disable TLS inspection for the required gateway path. A successful TCP connection to port 443 is not enough if an inspecting proxy breaks the tunnel.

Also record OEM update destinations, extensions, monitoring, backup, and application dependencies. Gateway coverage for one service does not prove coverage for the others.

Which destinations does the firewall need to allow?

I would not treat the endpoint list as a list of destinations that all need to be opened directly from the Azure Local hosts. First identify the path each category takes:

Traffic category	Expected path	What the network policy needs to allow
Supported HTTPS, not in a local bypass list or gatewayBypass	Azure Local component → local Arc proxy → Arc Gateway	The host’s approved egress path to the assigned gateway FQDN on TCP 443. The firewall does not need a separate direct rule from the host to each supported service FQDN carried through the gateway tunnel.
HTTPS not supported by Arc Gateway	Arc proxy → configured enterprise proxy or firewall	Allow the destination FQDN and required port through the enterprise proxy, or allow it through the firewall if using direct egress.
HTTP, including required certificate-revocation checks	The configured non-gateway HTTP route	Permit the required HTTP destination on that route; HTTP does not tunnel through Arc Gateway.
Local proxy-bypass destination	Bypasses the local Arc proxy; follows the source’s network route	Permit the destination on the resulting direct or separately configured route. It does not get sent through the gateway.
Supported HTTPS matching gateway-side gatewayBypass	Arc proxy → enterprise proxy or firewall, without the gateway tunnel	Allow the destination FQDN and required port through the enterprise proxy, or allow it through the firewall if using direct egress. This skips only the tunnel; it does not skip a configured enterprise proxy.

This distinction determines whether a destination needs a direct firewall exception or can travel inside the gateway tunnel. If Arc proxy uses an enterprise proxy, the network firewall may only need to allow the host to that proxy, while the enterprise proxy separately allows the gateway FQDN and any required fallback destinations. With direct egress, the firewall needs the corresponding destination rules. Confirm which device enforces each hop in your topology.

Examples of destinations outside the gateway tunnel

The Azure Local overview’s non-redirected endpoint table gives the global baseline. The regional endpoint map adds region, release, feature, and deployment-stage details. For example, the West Europe map lists the following categories:

Protocol	Example destinations in the West Europe map	Notes
HTTPS, TCP 443	aka.ms, azurestackreleases.download.prss.microsoft.com, login.microsoftonline.com, westeurope.login.microsoft.com, management.azure.com, gbl.his.arc.azure.com, weu.his.arc.azure.com, dc.services.visualstudio.com	Bootstrap, Arc registration, management, and monitoring entries marked as not supported by Arc Gateway in the regional map. They need a separately permitted route; some are needed before the gateway tunnel can be used.
HTTPS, TCP 443	<your-gateway-id>.gw.arc.azure.com, <your-key-vault-name>.vault.azure.net	The gateway FQDN is the tunnel destination itself, not a service reached inside that tunnel. The deployment Key Vault is also listed as non-redirected. Substitute your actual resource names.
HTTPS, TCP 8084	westeurope.obo.arc.azure.com	Required for AKS extensions after initial deployment, according to the regional map. Include only if that feature applies.
HTTP, TCP 80	crl3.digicert.com, crl4.digicert.com, crl.microsoft.com/pkiinfra, www.microsoft.com/pkiops, ctldl.windowsupdate.com, oneocsp.microsoft.com, ts-crl.ws.symantec.com, ts-ocsp.ws.symantec.com, s.symcd.com, ocsp.digicert.com, ocsp.globalsign.com, ocsp2.globalsign.com	Certificate-revocation or trust-list checks; these do not use the Arc Gateway tunnel. Apply the region map’s scope and deployment-stage notes.
HTTP, TCP 80	www.msftconnecttest.com/connecttest.txt	Bootstrap outbound-connectivity validation in the regional map.

These are examples, not a complete or evergreen firewall list. The West Europe file currently identifies itself as last updated on 27 November 2025. Before creating a rule request, check the repository for a newer regional mapping and follow the current Learn overview. For each row, confirm the applicable release, feature, and deployment stage; “outside the gateway tunnel” means a separate permitted path, not necessarily direct host-to-internet access. It can be through the configured enterprise proxy or the network’s approved firewall path.

Build and review the bypass inputs

I would review the bypass list with the platform and network teams before running registration on any node.

Include the internal destinations required by your topology: host IPs and names, cluster IP and name, infrastructure network addresses, and the applicable domain. If a private service endpoint must use a direct route, include its exact destination and verify DNS and routing from the source subnet.

The Windows-oriented registration list uses comma-separated entries and wildcard subnet notation such as 192.168.1.*, not CIDR notation. Linux appliance output can represent equivalent subnet exclusions as CIDR ranges. Do not copy the Linux output verbatim into a Windows-format input.

Use localhost, not <local>, and follow the registration script’s rules for Kubernetes service entries. Microsoft says not to add .svc manually to the initial registration input; the script handles the required environment configuration.

In this registration setting, ProxyBypass is not a way to send a destination through Arc Gateway. It means the destination skips the configured proxy path; use it for the internal or other destinations that must follow their own network route. Keep it narrow and confirm that route and its firewall permissions. This is different from the cloud-side gatewayBypass setting, which skips the gateway tunnel for supported HTTPS while still using a configured enterprise proxy.

HINT

A bypass list is part of the routing design. A broad bypass can defeat the intended egress policy, while a missing internal destination can send local infrastructure traffic to an external proxy.

Include workloads in the design

Guest VM Arc connectivity uses the guest’s own Arc proxy and outbound route. A working management-subnet gateway rule does not automatically allow a VM on a separate subnet to connect.

New AKS clusters inherit infrastructure proxy configuration. Existing AKS clusters do not automatically receive later proxy updates. That makes planning before the first AKS deployment particularly valuable.

Agree the routes, firewall sources, registry access, and application proxy requirements before deploying workloads. Treat VM and Kubernetes connectivity as separate validation scopes; the infrastructure gateway configuration alone does not prove that guest workloads use the intended path.

Turn the endpoint review into a firewall request

I would not send the network team only the generic global endpoint table. Microsoft notes that requirements vary by region and points to the regional mappings in the AzureStack-Tools HCI endpoint repository. Open the folder for the Azure region you selected and use its current endpoint file; for example, West Europe. The regional table identifies each FQDN, port, purpose, whether Arc Gateway supports it, and the deployment stages or versions where it applies.

I would prepare the request like this:

1. Confirm the Azure Local region, target solution release, and features in scope, including Azure Arc resource bridge, AKS, monitoring, and any optional services.
2. Review the matching regional endpoint file and retain the rows applicable to that release, deployment stage, and feature set. Include the required endpoints marked as not supported by Arc Gateway; those still need their own permitted route.
3. Compare those rows with the Azure Local endpoints not redirected through Arc Gateway. This overview lists the global defaults and explicitly calls out HTTP certificate-revocation endpoints. HTTP does not use the Arc Gateway tunnel, so include the required HTTP destinations on the intended firewall or proxy path.
4. Replace placeholders with the actual gateway FQDN, Key Vault name, and cloud witness storage account where applicable. Keep the required port and protocol with each destination; do not turn a hostname into a guessed or pinned IP address.
5. Send the network team the endpoint source links and review date, region and release, relevant rows with purpose and protocol/port, source networks for the Azure Local hosts and any workload subnets, plus the required proxy and TLS-inspection behavior. Ask them to confirm the rules are applied to the correct egress path before registration.

Keep the full source list with the deployment record. The exact subset depends on the selected region, release, and enabled features, so I would not copy a static list from another deployment.

Deployment readiness check

Before starting registration, I want the deployment team to be able to answer yes to each of these:

• Have we selected public path or the documented private path and validated DNS and routing to the intended next hop?
• Is the gateway provisioned and eligible for the Azure Local subscription, and do we have its resource ID and URL?
• Have we given the network team the reviewed, region- and release-specific endpoint request, with each destination classified by its actual route (gateway tunnel, fallback proxy/firewall, HTTP, or local bypass)?
• Are TLS inspection exceptions and outbound rules in place for the gateway and required fallback paths?
• Have the proxy server and complete bypass entries been reviewed for the hosts, cluster, appliance, and intended workloads?
• Have we selected the initial-registration method and collected its required inputs and permissions?
• Do we have a plan to validate the host, resource bridge, VM, and AKS paths separately after deployment?

If any answer is no, I would resolve it before beginning registration rather than trying to infer the intended network design during deployment.

Outro

My recommendation is to finish the connectivity design before registration: agree the topology, prepare the gateway and network path, and review the endpoint and bypass inputs with the teams who own them. Then use Microsoft’s current initial-registration procedure and validate the resulting deployment before tightening firewall rules.