AKS enabled by Azure Arc on Azure Local — cluster created successfully but stays in "Connecting", azure-arc agents never deploy

Yes. The supported evidence points to an outbound connectivity problem from the AKS control plane and worker VM network, not just from the Azure Local hosts or Arc Resource Bridge.

Key points:

1. With Arc gateway enabled, AKS control plane and worker VMs do not use the node-local proxy path used by the host OS. They reach the Arc proxy through the cluster IP on port 40343.
2. New AKS clusters on Azure Local inherit the Arc Resource Bridge proxy and bypass-list configuration.
3. If the AKS VM logical network is separate, that network still needs outbound connectivity for infrastructure services. The proxy bypass guidance explicitly says to include at least the IPs defined for the infrastructure network, because Arc resource bridge, AKS, and future infrastructure services using these IPs require outbound connectivity.
4. If the proxy endpoint is unreachable from the workload-node logical network, cluster creation can stall or fail. The documented symptom is a cluster stuck in Creating or moving to Failed after proxy configuration; the same underlying condition is consistent with a cluster that completes creation but never finishes Arc onboarding.

For this scenario, verify these paths specifically from the AKS VM logical network:

• HTTPS to the cluster IP:40343 used by Arc proxy when Arc gateway is enabled.
• Any required direct paths created by the proxy bypass list for infrastructure IPs/names.
• Proxy allow-list coverage for required Microsoft endpoints. If image pulls are involved, allow *.mcr.microsoft.com and nccacheacr.azurecr.io.

On logs and diagnostics to collect:

1. Determine the AKS control plane VM IP from an Azure Local node:

invoke-command -computername (get-clusternode) -script {get-vmnetworkadapter -vmname *} | Where-Object {$_.Name -like "$cluster_name*control-plane-*"} | select vmname, ipaddresses

• If there is 1 IPv4 address, use it as vmIP.
• If there are 2 IPv4 addresses, use either one as vmIP.

2. Run the AKS diagnostic checker against that control plane VM IP. The documented sample output includes tests such as:

• cloud-agent-connectivity-test
• gateway-icmp-ping-test
• http-connectivity-required-url-test

A failure on required-URL connectivity indicates the logical network IPs do not have the needed outbound internet access, or that firewall/proxy rules are blocking required AKS URLs.

3. If using a customer HTTPS proxy for AKS, collect the node-local proxy logs:

kubectl logs -n nc-system -l app=node-local-proxy

That is the documented log location when proxy reachability or proxy-address changes cause cluster issues.

4. For Arc gateway traffic troubleshooting, inspect Arc proxy logs on the node that currently owns the cluster IP, because Azure Resource Bridge and AKS VM HTTPS traffic flows through that owner node.

On additional cross-VLAN ports:

The provided documentation supports one specific additional path beyond standard HTTPS/proxy egress: the AKS control plane and worker VMs must be able to reach the cluster IP on port 40343 for Arc proxy when Arc gateway is enabled. The documentation provided does not list any other required cross-VLAN ports for Arc onboarding to complete.

If the issue persists after validating reachability to cluster IP:40343 and required outbound URLs, the next supported step is to use the diagnostic checker results and, if the control plane VM is missing or has no IPv4 address, file a support request.

References:

• Use the diagnostic checker to diagnose and fix environment issues for AKS cluster creation failure (preview)
• Network considerations for cloud deployments of Azure Local
• Use private endpoints to connect to Azure Local for proxy with Arc gateway scenario
• Configure a customer HTTPS proxy for AKS on Azure Local for multi-rack deployments
• Register Azure Local with Azure Arc using Arc gateway (register-proxy)