An Azure service that provides a flexible, self-service deployment of fully managed OpenShift clusters.
Hi ,
Thanks for reaching out to Microsoft Q&A.
Your issue is expected behaviour with P2S AAD + Azure VPN Client (OpenVPN), it does not reliably push custom DNS settings to the client, so your machine falls back to public DNS, which is why resolution works only via hosts file.
The recommended approach is: do not depend on the VPN client to inject DNS. Instead, explicitly control DNS resolution on the client side or via a reachable DNS forwarder. The clean pattern is to use Azure DNS Private Resolver with an inbound endpoint (which you already have) plus a DNS forwarder path from the client. Since Azure VPN Client does not enforce DNS, configure one of these:
- Best practice (enterprisegrade): Use a custom DNS forwarder (for example, Windows DNS VM or azure firewall DNS proxy) inside the VNet, forward queries to Private Resolver (10.0.10.4), and configure your client (manually or via corporate policy) to use that DNS server.
Practical workaround: Manually set the VPN adapter DNS server to 10.0.10.4 after connection (or via PowerShell script).
Alternative: Use conditional forwarders on your local machine (or corporate DNS) for cluster.example.com → 10.0.10.4.
- Avoid relying on
<dnsservers>in azurevpnconfig.xml, it is often ignored with AAD/OpenVPN profiles.
For Private ARO access design using azure Redhat openshift: deploy ARO private cluster, create private DNS zones for api and *.apps, link them to the VNet, use Private DNS Resolver, ensure VPN clients can reach the inbound endpoint IP, and enforce DNS resolution via a controlled DNS path (not VPN config). Once DNS is correct, browser access to API and console will work without hosts file.
Overall, your networking is fine; your gap is client-side DNS enforcement, not ARO or Private Resolver.
Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.