Forum Discussion
Private Endpoints - Public Access Disabled
Since we have blocked Public Access, I am not able to see my vnet data gateway anymore. It is also unable to load a license. The data gateway is there and it works (copy job succeeded). Furthermore sometimes the lakehouse does not show the data and only shows two red errors. This error however only appears occationally. Can you please help me finding a fix?
Thank you for your responses v-abhinavmu, jubinsoni and AvdBerg - we tried it yesterday after our network analysis came to the same solution and it worked. The last link you provide is now the official confirmation.
So to sum it up for everyone having TENENT Level private links enabled AND block public access enabled and are experiencing one or multiple of the following issues: Manage Connections and Gateways: only show three tabs and now connections or gateways although they do exist and are functioning, lakehouses show red error signs and you are unable to open the file or table explorer although files are there (you get a permission denied error), mirroring can be set up but is not replicating, copy jobs can be started and are working - but the run details and the run itself is not showing or only showing sometimes), nslookup sometimes shows the private IPs and sometimes the public ones - adding fabric.microsoft.com and powerbi.com resolved ALL these issues for us.
9 Replies
For the lakehouse the error says "private link validatin failed due to deniedbypolicy".
- AvdBerg
Resolver III
Hi KristinaP
A couple of things you could check:
Confirm the call goes directly to the private endpoint using the documentation in this link
https://learn.microsoft.com/en-us/fabric/onelake/onelake-manage-inbound-access
Check if the DNS configuration in you private endpoint containse there zones:|- privatelink.analysis.windows.net
- privatelink.pbidedicated.windows.net
- privatelink.prod.powerquery.microsoft.com
privatelink.fabric.microsoft.com
Check if internet fallback is enabled on the virtual network link, if it is try turning it of. That way you should get a better failure message.
Last, if you are running on a newly created Capacity it can take upto 24 hours until the endpoint reaches the private DNS zone. And if you are running a trial capacity, private links dont work at all, https://learn.microsoft.com/en-us/fabric/security/security-private-links-overview#other-considerations-and-limitations
Hopefully this helps you.
Did I answer your question, please mark the post as a solution or consider a like.
After a ipconfig /flushdns the onelake.dfs.fabric.microsoft.com goes via the private endpoint. We have tenant level private links. We have only the first three in place, because my understanding was that with tenant level private links the last one is not needed. Is that correct or could this be the reason?
- AvdBerg
You are correct, the last one is for workspace level private links. Could it be that there is cache playing a role here? You could try to look at the connections and gateways from a private browser, just to make sure.
jubinsoniMemorable Member
Hi KristinaP,
Echoing AvdBerg: with public access blocked, nearly every symptom you describe (gateway not visible, license not loading, intermittent red errors, "private link validation failed due to deniedbypolicy") is a question of whether each client resolves and reaches Fabric over the private path, and whether the policy matches the type of private link in use. I cannot see your tenant, so this is a checklist to work through rather than a diagnosis. The fact that DNS flush and a new browser did not help makes the DNS-zone and network-path rows below the most likely places to look.
Checklist
Check What to confirm Why it matters Where you open the page from The browser used for Manage connections and gateways is on a network that can reach the private endpoint (inside the VNet, peered network or VPN) With public access blocked, the portal feature pages that need the private path fail from other networks Private DNS zones The zones listed earlier in the thread exist and are linked to the VNet (analysis, pbidedicated, powerquery and fabric zones) A missing zone resolves to a public address that is now blocked Resolution from the client Names resolve to the private IP of the endpoint from the same machine that has the problem A different DNS server on that machine (for example one that does not forward to the private zone) gives public answers Internet fallback on the VNet link Check whether fallback is enabled on the link and test with it toggled Fallback can hide a missing record in testing and surface later Tenant vs workspace private links Know which type you configured; workspace-level links use their own endpoint and DNS names The "deniedbypolicy" message points at a policy that does not match the connection path the request used VNet data gateway The delegated subnet can reach Fabric endpoints and the data sources; the gateway shows healthy in the portal The copy job works, so data movement is fine; the portal view is a separate path A quick resolution test
Run this from the machine that shows the errors, and again from a VM inside the VNet. The two answers should both be private addresses:
nslookup app.fabric.microsoft.com nslookup api.fabric.microsoft.com nslookup api.powerbi.com nslookup <your-workspace-specific-fabric-host> # if you use workspace-level private linksReading the results
Result Meaning Next step Public IP returned DNS is not using the private zone Fix zone link or DNS forwarding for that machine Private IP from the VM but public from your PC Your PC uses a resolver outside the private DNS path Point it at the DNS that forwards to the private zone, or work from inside the VNet Private IP everywhere but errors remain Resolution is fine Check the network policy side: the private link and policy configuration, then open a support case with the error and timestamps The intermittent lakehouse error fits a request sometimes going by the private path and sometimes by another, for example because of two resolvers or a cached answer, so the nslookup comparison is a good first step. If both machines resolve privately and the error still appears, collect the error text, time, workspace ID and the private link type and send those to support.
So my overall approach would be:
Resolve -> compare DNS answers from the failing machine and from inside the VNet Zones -> confirm all private DNS zones exist and are linked; test with fallback toggled Path -> open the portal from a network that reaches the endpoint Escalate -> error text, timestamps, workspace ID and link type to supportAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Thank you for the detailed reply jubinsoni - one question before we start investigating more.
I have written in a previous reply that we use "Tenant Level Private Links". As from my understanding and what also AvdBerg wrote "You are correct, the last one is for workspace level private links. " the fourth mentioned zone "fabric" is not needed in our case - becasue this one is missing and this one will always give me a public ip. Since you mentioned it again in your checklist I am again confused, do I need it or not?
v-abhinavmuCommunity Support
Hi KristinaP,
Thanks for reaching out to the Microsoft Fabric Community forum.
Your understanding is correct. The distinction is between tenant-level and workspace-level private links.
According to Microsoft's documentation:
Tenant-level private links use these three private DNS zones:
• privatelink.analysis.windows.net
• privatelink.pbidedicated.windows.net
• privatelink.prod.powerquery.microsoft.com
Workspace-level private links specify:
• privatelink.fabric.microsoft.com
The workspace-level private link setup documentation specifies privatelink.fabric.microsoft.com, whereas the tenant-level setup documentation lists only the other three DNS zones.
Therefore, if you have configured only tenant-level private links, the fourth DNS zone is not listed as part of that configuration.One additional distinction from Microsoft's documentation is worth highlighting: tenant-level private links can access workspaces that allow connections from all networks. If a workspace is configured to deny public access, it requires a corresponding workspace-level private link for access.
So, based on your description, your understanding of the DNS zone configuration is correct.
For more details, please refer to the below Official Microsoft Documentation:
Set up and use a tenant-level private link - Microsoft Fabric | Microsoft Learn
Set up and use workspace-level private links - Microsoft Fabric | Microsoft Learn
Use tenant and workspace private links - Microsoft Fabric | Microsoft LearnI hope this helps. Please feel free to reach out if you have any further questions.
Thank you.Thank you for your responses v-abhinavmu, jubinsoni and AvdBerg - we tried it yesterday after our network analysis came to the same solution and it worked. The last link you provide is now the official confirmation.
So to sum it up for everyone having TENENT Level private links enabled AND block public access enabled and are experiencing one or multiple of the following issues: Manage Connections and Gateways: only show three tabs and now connections or gateways although they do exist and are functioning, lakehouses show red error signs and you are unable to open the file or table explorer although files are there (you get a permission denied error), mirroring can be set up but is not replicating, copy jobs can be started and are working - but the run details and the run itself is not showing or only showing sometimes), nslookup sometimes shows the private IPs and sometimes the public ones - adding fabric.microsoft.com and powerbi.com resolved ALL these issues for us.
