Connect to private AKS via browser

@Celso Silvestre I had the same issue.
What solved it was allowing the Azure Portal in the browser to use my location. This solved the issue.
If that works, please mark it as the solution.

Hello @Celso Silvestre

Thank you for contacting us about the AKS issue.

To summarize the situation:

1. Your AKS cluster is private, meaning the API server is reachable only over the VNet.
2. When the portal tries to load the Workloads / Nodes / Deployments panes, it makes direct API calls from your local machine to the cluster’s private endpoint.
3. If your machine can’t resolve or reach that internal endpoint over the VPN, the Portal UI fails, even though kubectl works (because kubectl uses the kubeconfig endpoint you already authenticated to).
4. Make sure DNS resolution for the AKS private endpoint is working. The portal needs your browser to resolve the cluster’s private FQDN, and if DNS doesn’t go through the VPN, it will use your public ISP DNS, causing it to fail.

• From your machine (while connected to the VPN), run:

nslookup <your-private-cluster-fqdn>

• You should get a 10.x.x.x IP (or whatever range your AKS VNet uses).
• If it resolves to a public IP or fails to resolve, then DNS is the culprit.

1. Make sure your internal DNS servers are configured in your VPN client profile.
2. If you’re using Azure Private DNS Zones, ensure that the DNS forwarder/firewall on‑prem forwards privatelink.<region>.azmk8s.io lookups to Azure.

https://learn.microsoft.com/en-us/azure/architecture/guide/security/access-azure-kubernetes-service-cluster-api-server

2. Confirm the VPN is forwarding Browser Traffic

A VPN tunnel may come up while the split‑tunnel route omits the AKS subnet(s). In that case, CLI access (via kubeconfig IPs) works, but browser access fails.

Ensure your VPN routing table includes:

• The AKS VNet
• The AKS node subnet
• The private AKS API endpoint subnet

If DNS resolves but routing doesn’t, the browser will hang or show the same error as in your screenshot.

Update your VPN routing so all traffic to the AKS VNet(s) is forwarded.
If using split‑tunneling:

• Add the AKS private endpoint subnet, or
• Switch temporarily to full‑tunnel mode to confirm the issue.

3.Test connectivity to the private API server directly

Once DNS looks right, test whether you can reach the API server over port 443:

curl -v https://<private-fqdn>:443

1. Because the AKS Portal tab is rendered using multiple embedded API calls, Chrome/Edge caching can sometimes cause repeated failures.

Try the following:

• Open Chrome/Edge → Incognito (important).
• Navigate to the AKS resource → Workloads.
• If this works in incognito, clear browser cache or disable problematic extensions.

The issue appears to be related to the browser rather than the AKS cluster. Could you please reset your browser settings and attempt the process again

This aligns with cases where:

• kubectl works
• VPN is healthy
• Only the Portal UI fails.

5.If your AKS cluster uses Azure Private DNS (default for private clusters), confirm:**

• The Private DNS zone is still linked to the VNet hosting your VPN gateway
• No accidental unlinking or stale link from recent resource moves

If the VNet link breaks, DNS resolution works only inside Azure but not from on‑prem.

References
https://learn.microsoft.com/en-us/azure/aks/network-isolated?pivots=aks-managed-acr
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-troubleshoot-vpn-point-to-site-connection-problems

Thanks,
Manish