Unable to connect to private endpoint for file service

Hi ,

Thanks for reaching out to Microsoft Q&A.

Here is the simpler explanation of what is happening.

• Your Private Endpoint subnet has Private endpoint network policy set to Enabled.

When this is enabled, the NSG rules on that subnet apply to the Private Endpoint.

• By default, cross VNet traffic to the Private Endpoint will not be allowed unless you explicitly add a rule for it.

That is why the VM in the same subnet works (local traffic is fine) but the VM in another VNet cannot connect.

2 easy ways you can try to fix it:

1. Simplest option > Go to the subnet where the Private Endpoint is placed and set Private endpoint network policy to Disabled. This makes the Private Endpoint work without needing special NSG rules.
2. If you want to keep it Enabled > In the NSG for the PE subnet, add an inbound rule that allows traffic from the other VNet’s IP range to the PE’s private IP on port 445 (azure Files).

The easiest and most common approach is to disable the network policy for that subnet.

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.

Hello @Apurva Pathak,

Hope you're doing well! Thanks for the update.

I tested this in my lab by creating the storage account and private endpoint in East US and running the test from West US 2, and it worked fine. I’ve attached a screenshot with my results. Please check if both your working and failing VMs return the same output.

Please follow the steps below for the Client VM. 

1.Please verify the DNS resolution, it should resolve to the Private Endpoint’s private IP of your resource.

nslookup storage account .file.core.windows.net  

2. If the DNS resolves correctly but TCPTestSucceeded fails, then the issue is likely related to routing or peering.

Test-NetConnection storage account.file.core.windows.net -Port 445

3.Please check the effective routes on the NIC and confirm that a route to 10.x.x.0 (PE private IP) exists via VirtualNetwork.  In my screenshot, it shows as an interface endpoint because I didn’t create the VM in the same region as the Private Endpoint. Since you have VMs on both sides, the route should appear via VirtualNetwork in your case.

az network nic show-effective-route-table \   --name <CLIENT_VM_NIC_NAME> \   --resource-group <CLIENT_RG> \   -o table

Run the following command on both VMs (Client VNet and PE VNet):

az network vnet peering list --resource-group <RG_NAME> --vnet-name <VNET_NAME> -o table

Make sure the settings are as follows:

• "allowVirtualNetworkAccess": true
• "allowForwardedTraffic": true (required if there’s a UDR or firewall in the path)

Traffic must be enabled in both directions. Please refer to the screenshot below for guidance

5. Please verify the DNS zone links.

az network private-dns zone list -o table

Locate your privatelink.file.core.windows.net zone, then run:

az network private-dns link vnet list   --resource-group <RG_NAME>  --zone-name privatelink.file.core.windows.net   -o table

Ensure that the failing VM’s VNet is properly linked to the Private DNS zone. Refer to the screenshot below for reference.

6)Please review the storage account firewall rules.

az storage account network-rule list  --account-name <STORAGE_ACCOUNT_NAME>   --resource-group <RG_NAME>  -o table 

az storage account show \ --name mystoragesep1908 \ --resource-group RGAUG19 \ --query "networkRuleSet" \ -o json  

Check for:

• "defaultAction": "Allow" → Storage is accessible from all networks.
• "defaultAction": "Deny" → Only the VNets/Private Endpoints listed are allowed.

Important: For a Private Endpoint (PE) scenario, the expected configuration is:

• defaultAction = Deny
• Network rules must include your Private Endpoint.
• Ensure the VNet/subnet with your Private Endpoint is listed.

In my setup, I allowed all networks, so I see an empty list ([]).

Please follow the steps below for the target VM (PE’s Subnet/VNet).

Since I haven’t created a route table, I’m only providing the command:

1.Check PE Subnet Network Policy

• You already confirmed that Private endpoint network policy = Disabled.
• No further changes are required here. 

2. Verify the subnet’s route table using:

az network route-table show    --name <ROUTE_TABLE_NAME>   --resource-group <RG_NAME>   -o table

Ensure that no UDR is redirecting 0.0.0.0/0 or 10.0.0.0/8 to a firewall or NVA.

3.Please check the VNet peering from PE VNet to Client VNet:

az network vnet peering list \   --resource-group <PE_RG> \   --vnet-name <PE_VNET_NAME> \   -o table

It must show "allowVirtualNetworkAccess": true (as noted in Step 4).

If you run all the above commands for both the working VM and the failing VM. Compare the results side by side.

If you find differences in the Effective Routes or DNS zone links, that is causing the issue

If the Client VM resolves to the PE private IP but port 445 fails: DNS is working correctly and the issue lies with Routing, NSG, or Peering

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

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

I was able to dig down the root cause. Below are the details:

The destination Hub Vnet had a UDR applied at its GatewaySubnet for the traffic destined to the address space of my source VM. But there was no UDR applied at the Subnet of my Source VM which was causing the asymmetric routing.

I removed the UDR from the GW Subnet and the issue was fixed.

Thanks a lot everyone who gave their precious time and efforts to this.