When using a VPN with split tunneling enabled, you might encounter a frustrating "403 Forbidden" error when trying to access Azure resources configured with Private Link. This happens because your traffic is taking the wrong path and hitting public endpoints instead of private ones. Let's break down why this occurs and how to fix it.
How Split Tunneling Works
Split tunneling is a VPN configuration that divides your network traffic into two paths:
- Inside the tunnel: Traffic destined for your corporate domain and internal network
- Outside the tunnel: All other internet traffic (bypassing the VPN)
This approach improves performance for general internet browsing while maintaining secure access to corporate resources. However, it can create unexpected issues with cloud services.
The Azure Private Link Dilemma
Azure Private Link allows you to access Azure services through a private endpoint in your virtual network, using private IP addresses instead of public ones. Here's where the problem arises:
- When your laptop connects to an Azure resource with Private Link enabled
- If the traffic goes outside the VPN tunnel (due to split tunneling)
- Your DNS query goes to public DNS servers
- Public DNS returns the public IP address of the Azure service
- The Azure application rejects the request with a "403 Forbidden" error because it's configured to only accept connections through Private Link
Azure DNS Limitation
⚠️ IMPORTANT: Azure DNS can ONLY be used directly by virtual machines hosted within Azure. This is a fundamental limitation of the Azure platform.
What This Means:
- ✅ Can use Azure DNS: VMs running in Azure Virtual Networks
- ❌ Cannot use Azure DNS: On-premises servers (even with ExpressRoute)
- ❌ Cannot use Azure DNS: Laptops or workstations outside Azure
- ❌ Cannot use Azure DNS: Any infrastructure not hosted in Azure
The Workaround:
Since you cannot query Azure DNS directly from outside Azure, you must:
- Deploy DNS servers as VMs within Azure
- Configure these Azure-based DNS servers to forward to Azure DNS (168.63.129.16)
- Point your on-premises DNS to these Azure-based DNS servers
Solution 1: VPN with Split Tunneling
Step-by-Step Implementation
Identify Your Azure Private Link Resources
- List all Azure services using Private Link
- Document their URLs and domains
Configure VPN Host Groups
- Add these Azure resource URLs to your VPN's host group configuration, I ended up using *.azurewebsites.net to cover all websites this covers current and future versions of websites created
- Mark them as requiring tunnel routing
- This forces all traffic to these destinations through the VPN
Set Up DNS Infrastructure in Azure
- Deploy DNS server VMs in your Azure Virtual Network
- Configure these VMs to forward queries to Azure DNS (168.63.129.16)
- These Azure-based DNS servers can now resolve Private Link addresses
The DNS Resolution Flow
Laptop with VPN Connected
↓
DNS Query for Azure Resource
↓
On-Premises DNS Servers
↓
Forward Query to DNS Servers (VMs in Azure)
↓
Azure-based DNS VMs Forward to Azure DNS (168.63.129.16)
↓
Azure DNS Returns Private IP Address
↓
Traffic Routes to Private Endpoint
↓
✓ Successful Connection
Solution 2: Wi-Fi with Private DNS (No VPN)
If you're using Wi-Fi with private DNS that points to another DNS provider (not Azure DNS) and you're not using a VPN, you have a different challenge.
The Problem
Your private DNS provider doesn't know about your Azure Private Link configurations, so it will return public IP addresses, leading to the same "403 Forbidden" error.
The Solution: Conditional Forwarding
Configure conditional forwarding on your business DNS servers:
Identify Private Link DNS Zones
- Website: magical-priovatelink-bearsite.azurewebsites.net
- Host Group to add : *.azurewebsites.net
Add Conditional Forwarders
- On your business DNS server, create conditional forwarders
- Forward specific Private Link domains to your Azure-based DNS servers
- These Azure DNS servers (VMs in Azure) will resolve to private IPs
Common Pitfalls to Avoid
Trying to Use Azure DNS Directly from On-Premises
- This will never work, even with ExpressRoute
- Always use Azure-based DNS VMs as intermediaries
Forgetting Conditional Forwarders
- Without them, non-VPN users will always hit public endpoints
Incorrect DNS Server Assignment
- Ensure VPN clients receive correct DNS server addresses
Conclusion
Successfully accessing Azure Private Link resources requires understanding the DNS resolution chain and the critical limitation that Azure DNS can only be used by Azure-hosted VMs. Whether you're using a VPN with split tunneling or relying on conditional forwarding for non-VPN scenarios, the key is ensuring your DNS queries ultimately reach Azure DNS through Azure-based DNS servers.
Remember:
- Azure DNS (168.63.129.16) is only accessible from within Azure
- Always use Azure-based DNS VMs as your bridge to Azure DNS
- Configure appropriate forwarding based on your connectivity method
By following these patterns, you'll eliminate those frustrating forbidden errors and ensure reliable access to your Azure Private Link resources, regardless of how users connect to your network.