Azure private endpoint resources work outside VDI using VPN, but partially fail inside VDI (Storage Blob, Synapse Studio operations, Synapse Dedicated SQL Pool Database))

Question

Environment details

• Azure Storage Account: Private Endpoint + Selected Networks
• Azure Synapse Workspace: Private Endpoint enabled
• Authentication: Azure AD
• Access method:
  • Works fully outside VDI (VPN)
  • Partially fails inside VDI
• Inside VDI:
  • DNS resolution verified (nslookup returns private IPs)
  • Networking and Private Endpoint connectivity are confirmed as working

What works inside VDI

• Azure Portal loads normally
• Synapse Studio UI opens
• Storage account:
  • Create container works
  • Upload file to container works

What does NOT work inside VDI

• Azure Storage:
  • Creating folders (virtual directories) inside blob container fails
  • Deletion of Folder or container
• Azure Synapse:
  • Unable to execute pipelines
  • Unable to view dedicated SQL pool database tables, etc.
• All of the above actions work correctly outside VDI using the same user and permissions

VDI: Zscaler is installed and running inside VDI

Questions

1. Are there other requirements when accessing Azure Storage, Synapse Studio, Synapse database through VDI environments?
2. Is there anything that needs to be configured at Azure side/VDI side/Zscaler side?
3. already had multiple calls with VDI and Zscaler team but no resolution yet
4. Do we need to whitelist VDI's outbound IP in Azure portal tunnels: but as mentioned earlier network connectivity is there from VDI. TCP test connection and nslookup gave correct output

Answer 1

Hi Shubhangi Nannware,

Thanks for reaching out in Microsoft Q&A forum,

Are there other requirements when accessing Azure Storage, Synapse Studio, Synapse database through VDI environments?

Yes. Beyond basic network connectivity and Private Endpoint setup, VDI environments have three additional requirements that standard desktop setups don't:

1. Proxy bypass configuration – VDI traffic typically routes through a corporate security proxy (like Zscaler). Azure Private Endpoint traffic must bypass this proxy and go DIRECT, because Private Endpoints are private network resources, not internet destinations.
2. SSL inspection exclusion – Security proxies often decrypt and re-encrypt HTTPS traffic for inspection. This breaks Azure services that use certificate pinning (like Azure AD authentication) or require persistent TLS sessions (like Synapse Studio's WebSocket connections).
3. Token acquisition path – Azure AD authentication flows from VDI must reach Microsoft Entra ID endpoints without proxy interference. If the proxy intercepts these calls, token acquisition fails even though DNS and TCP tests pass.

Is there anything that needs to be configured at Azure side/VDI side/Zscaler side?

Azure Side: Nothing additional is needed. Your current setup (Private Endpoints, Azure AD authentication, RBAC roles) is already correct. The fact that operations work outside VDI proves this. Specifically:

• No need to whitelist VDI outbound IPs in Azure Storage firewalls
• No need to change Private Endpoint configurations
• No need to modify Synapse workspace network settings
• Just ensure "Allow Azure Services on the trusted services list" is enabled on the Storage Account (this allows Synapse's managed identity to access storage)

VDI Side: Two things to verify:

• Clear any cached Azure AD tokens and do a fresh sign-in inside VDI (stale tokens can cause weird failures)
• Ensure Conditional Access policies in Azure AD aren't blocking VDI IP ranges or requiring MFA methods that don't work in VDI sessions

Zscaler Side (This is where the fix is): Your Zscaler team must configure:

SSL Inspection Bypass for these FQDNs (do NOT decrypt):

1. SSL Inspection Bypass for these FQDNs (do NOT decrypt):
   • *.dfs.core.windows.net
   • *.blob.core.windows.net
   • *.sql.azuresynapse.net
   • *.dev.azuresynapse.net
   • login.microsoftonline.com
   • *.aadcdn.microsoftonline-p.com
2. Proxy Bypass in the PAC file for:
   • Private IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x) – this covers all Private Endpoint traffic
   • The specific FQDNs listed above
3. WebSocket/WSS allowance – Synapse Studio needs WebSocket upgrades and long-lived HTTPS sessions without idle timeout termination
4. Authorization header passthrough – Don't modify or strip Bearer tokens in requests

This is the critical piece. Zscaler is treating Private Endpoint traffic like internet traffic when it should be treated as internal private network traffic.

already had multiple calls with VDI and Zscaler team but no resolution yet

The issue is that network teams often test connectivity (DNS, TCP ports) and see everything green, so they assume the configuration is correct. But those tests don't validate:

• Whether SSL inspection is breaking certificate pinning
• Whether WebSocket upgrades are being blocked
• Whether Azure AD token flows are being intercepted

What your Zscaler team needs to do is check their transaction logs during a failed operation (like creating a folder). Look for the FQDNs *.dfs.core.windows.net or *.sql.azuresynapse.net and check if the transaction shows SSL_INSPECTED or CERT_REPLACED. If it does, that's your smoking gun SSL inspection is breaking the connection.

Once they add those FQDNs to the SSL inspection bypass list and configure proxy bypass for Private Endpoint IP ranges, everything will start working immediately.

Do we need to whitelist VDI's outbound IP in Azure portal tunnels: but as mentioned earlier network connectivity is there from VDI. TCP test connection and nslookup gave correct output

No, absolutely not. Here's why:

• You've already confirmed network connectivity works (TCP tests pass, nslookup returns correct private IPs)
• Upload operations and container creation already succeed from VDI
• The same user and permissions work outside VDI

If you needed to whitelist VDI IPs in Azure Storage firewalls, nothing would work from VDI – not even uploads or container creation. The fact that some operations work proves the firewall already allows your traffic through the Private Endpoint.

The problem isn't Azure blocking your IP, it's Zscaler intercepting and breaking specific types of connections (persistent TLS sessions, WebSockets, Azure AD token flows) that data-plane operations require. Whitelisting IPs in Azure won't fix proxy interception issues.

Reference:

• Connect to a secure Azure storage account from Synapse
• Zscaler & Azure Traffic Forwarding Deployment Guide
• Azure Private Link with Azure Virtual Desktop
• Manage Azure private endpoints

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

The behavior points to partial network/DNS interference for specific Azure service endpoints from inside the VDI, not to Azure permissions. Because everything works from outside VDI with the same identity and private endpoints, focus on:

1. DNS resolution paths (inside VDI vs. outside)
2. Zscaler interception / tunneling rules
3. Private endpoint + firewall behavior for Storage and Synapse

Below are concrete checks and configuration areas.

---

1. Validate private endpoint and DNS configuration end to end

From a VM in the same virtual network as the private endpoints (or from a test VM that mimics the VDI’s egress path):

1. In the Azure portal, go to Private Link Center → Private endpoints and open each private endpoint (Storage, Synapse workspace, SQL pool if applicable).
   • Confirm Connection state = Approved and the correct virtual network/subnet are used.
   • Confirm a Private IP address is assigned.
   • For Storage, ensure the target sub-resource is correct (Blob / dfs as applicable).
2. Check DNS integration for each private endpoint:
   • On the private endpoint, verify there is a DNS zone group and that it points to a Private DNS zone.
   • Open the Private DNS zone and check Virtual network links: the VNet used by the clients (or the VNet that the VDI traffic ultimately reaches) must be linked.
   • In the zone, verify that the A records exist for the Storage and Synapse FQDNs and that the IPs match the private endpoint IPs.
   • If records are wrong or missing, remove incorrect A records, recreate them, and flush DNS on the client side.

These steps align with the general guidance for private endpoint DNS validation and virtual network links.

2. Confirm that all required endpoints resolve to private IPs from inside VDI

From inside the VDI session, run nslookup for:

• Storage account blob endpoint: <storage-account-name>.blob.core.windows.net
• If using ADLS Gen2: <storage-account-name>.dfs.core.windows.net
• Synapse workspace endpoints (for example, the workspace URL and dedicated SQL pool endpoint).

Expected:

• All resolve to the corresponding privatelink FQDNs and private IPs (for example, <storage-account-name>.privatelink.blob.core.windows.net).

If nslookup already shows private IPs, but operations still fail, Zscaler or browser DNS-over-HTTPS may be bypassing Azure DNS for some calls.

3. Check for DNS-over-HTTPS or local DNS override in the VDI

If the browser or Zscaler client uses DNS-over-HTTPS, some traffic may resolve via public DNS instead of Azure Private DNS, causing:

• UI to load (public endpoints reachable)
• But data-plane operations (blob, dfs, Synapse SQL) to fail because public access is disabled or restricted.

Actions:

• In the browser used for Synapse Studio, disable secure DNS / DNS-over-HTTPS so that Azure DNS and private zones are used.
• Ensure Zscaler isn’t overriding DNS for *.blob.core.windows.net, *.dfs.core.windows.net, and Synapse endpoints.

This aligns with guidance that DNS-over-HTTPS can prevent Azure DNS from returning the private endpoint IP.

4. Validate connectivity to private endpoints from the VDI path

Use Azure Network Watcher and Private Endpoint diagnostics to confirm that the VDI egress path can reach the private endpoints:

1. In Private Link Center → Private endpoints, confirm:
   • The VNet used by the VDI egress (or the peered VNet) has connectivity to the private endpoint VNet.
2. Use Connection troubleshoot in Network Watcher from a test VM that shares the VDI’s network path:
   • Test by FQDN for the Storage and Synapse endpoints on port 443.
   • Validate that DNS resolves to the private IP and that the connection succeeds.
3. Check effective routes on the source VM NIC:
   • Ensure the route to the private endpoint IP has next hop type InterfaceEndpoint.
   • If the route is missing or overridden by UDRs, adjust routing so traffic to the private endpoint IP stays within the VNet/peering and isn’t forced through Zscaler or another appliance.

5. Storage-specific checks (folder create/delete failures)

Given that container creation and file upload work but folder operations fail:

• Confirm that the Storage account’s network rules are consistent:
  • If set to Selected networks, ensure the subnet used by the private endpoint is allowed and that no conflicting firewall rules block specific operations.
• If the VDI traffic sometimes goes via public egress and sometimes via private endpoint, operations that use different endpoints (blob vs dfs) may be split, causing partial failures.
• Ensure that if the Storage account has a private endpoint in one VNet, clients in other VNets with their own private endpoints follow the documented constraint: once a storage account has a private endpoint, clients in VNets with private endpoints must also use private endpoints to access that account.

6. Synapse-specific checks (pipelines and dedicated SQL pool)

For Synapse:

• Verify that the Synapse workspace private endpoint and any dedicated SQL pool private endpoints are correctly configured and have DNS records in the private DNS zone.
• Confirm that from the VDI path, the Synapse workspace and SQL endpoints resolve to private IPs and that Network Watcher tests succeed on port 443 (and SQL port if applicable).
• If Synapse uses linked services to the Storage account via private endpoint, ensure those endpoints are reachable from the same network path used by the VDI.

7. Zscaler / VDI configuration focus areas

On the Zscaler and VDI side, request the following checks:

• Ensure that traffic to the private endpoint IP ranges and *.privatelink.* FQDNs is not forced through Zscaler tunnels or SSL inspection, but instead routed directly to Azure via the private endpoint path.
• Ensure that Zscaler doesn’t perform its own DNS resolution for these FQDNs; DNS queries should go to the resolver that can see the Azure Private DNS zones.
• If Zscaler requires explicit allow rules, add rules for the private endpoint FQDNs and IPs used by Storage and Synapse.

8. Whitelisting outbound IPs

Whitelisting the VDI’s public outbound IP on the Storage/Synapse firewalls is only relevant if those services are being accessed over public endpoints. Because private endpoints and selected networks are already in use and name resolution returns private IPs, the focus should be on ensuring all traffic from the VDI uses the private endpoint path consistently, not on public IP whitelisting.

---

References:

• Troubleshoot connectivity between Azure Synapse Analytics Synapse Studio and storage
• Troubleshoot Azure Private Endpoint connectivity problems
• Troubleshoot network connectivity
• Troubleshooting private endpoint configuration for Microsoft Purview accounts
• Use private endpoints for Azure Storage
• Troubleshoot private endpoint connection problems
• Troubleshoot connection to a project with a private endpoint (classic)