Share via

Azure P2S VPN and Azure File Share

rr-4098 2,291 Reputation points
2026-05-28T16:06:37.89+00:00

Here is our setup which is setup this way to keep cost down. We have a S2S VPN tunnel setup to onprem and in Azure have a Azure File Share with a private endpoint. We are not using Azure DNS on any VM's in Azure for DNS but have our test user update their local host file to point the azure file share to the correct private IP.

Our test user needs to access the Azure File share over a Azure P2S VPN which has the onprem DNS server listed and dns suffix. When I run Get-DnsClientNrptPolicy all of the settings in the XML are listed perfectly. The problem is when a user enters in their domain creds to a Azure FIle share they get access denied. Please note, they are in the correct roles in Azure. Also users cannot ping the the onprem AD server which tells me clients do not have a line of sight to the DC. Is the only way to resolve this issue is to have a DC in Azure? Further if I connect to the onprem VPN while on the Azure P2V I can authenticate to the Azure share.

Azure VPN Gateway
Azure VPN Gateway

An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.

0 comments

Answer accepted by question author

AI answer

2026-05-28T16:06:59.7666667+00:00

The issue is caused by lack of line-of-sight from the P2S VPN client to the on-premises domain controller and DNS, which prevents Kerberos/NTLM authentication to Azure Files over SMB. A DC in Azure is not strictly required, but the client must be able to reach a DC and resolve the necessary DNS records over the active VPN path.

Key points from the described setup:

  • Azure Files is exposed via a private endpoint and is being accessed over VPN only.
  • Authentication is via on-premises AD DS.
  • P2S VPN clients use the on-premises DNS server and suffix, but cannot ping or otherwise reach the on-prem DC while connected only to the Azure P2S VPN.
  • When the user also connects to the on-prem VPN, authentication succeeds, confirming that AD line-of-sight is the missing piece.

To make this work without adding a DC in Azure, the following must be true:

  1. The P2S VPN client must have IP connectivity to the on-premises DCs (and any required AD ports) over the Azure P2S connection. That typically means:
    • The P2S address pool and routes on the Azure VPN Gateway must include routes to the on-premises network where the DCs reside.
    • The S2S VPN between Azure and on-prem must allow transit traffic from the P2S address pool to on-prem (no asymmetric routing or blocked subnets).
    • On-prem firewalls must allow traffic from the P2S address pool to the DCs.
  2. DNS resolution for the storage account and AD must be correct from the P2S client:
    • The storage account FQDN (e.g., storageaccount.file.core.windows.net) must resolve to the private endpoint IP, not the public IP. This is normally done via DNS forwarding to Azure DNS/private DNS zones rather than host file entries.
    • The client must also be able to resolve on-prem AD/DNS names via the on-prem DNS server reachable over VPN.

The Microsoft guidance for hybrid Azure Files with AD DS assumes:

  • A private endpoint for Azure Files.
  • A DNS forwarder or Azure DNS Private Resolver in the Azure virtual network.
  • On-prem DNS configured with conditional forwarders for file.core.windows.net (and afs.azure.net if using Azure File Sync) to the DNS infrastructure in Azure.
  • A site-to-site VPN or ExpressRoute that extends the on-prem network to Azure so that SMB and AD traffic traverse private connections.

In this model, P2S clients can also work, but only if they can reach both:

  • The Azure virtual network (for the private endpoint and DNS forwarder/Azure DNS), and
  • The on-prem DCs (for AD authentication), via the configured VPN routes.

So, a DC in Azure is one valid solution (it gives local line-of-sight in Azure), but not the only one. The alternative is to:

  • Ensure transitive routing between P2S clients, Azure VNet, and on-prem network over the existing P2S + S2S setup.
  • Implement proper DNS forwarding for Azure Files instead of relying on local hosts file entries.

If transitive routing cannot be achieved or is too complex, deploying a DC (or read-only DC) in Azure in the same VNet as the private endpoint is the practical way to provide line-of-sight for P2S clients accessing Azure Files.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vallepu Venkateswarlu 9,830 Reputation points Microsoft External Staff Moderator
    2026-05-28T20:00:12.56+00:00

    Hi rr-4098,

    Welcome to Microsoft Q&A Platform.

    It looks like your P2S clients aren’t actually reaching your on-prem DC over the VPN, so Azure Files can’t do its Kerberos/NTLM handshake and you get “Access Denied.” You can fix this without standing up a new DC in Azure by doing two things:

    1. Push on-prem routes down your P2S tunnel

    • Make sure your VPN gateway is route-based (only route-based supports both S2S and P2S together).
    • In the Azure portal, go to your VPN gateway’s Point-to-site configuration and add your on-prem AD subnet(s) as Custom routes.
    • Regenerate and re-install the VPN client so it learns those on-prem prefixes.
    • Verify from your laptop (while connected P2S) that you can ping or Test-Connection to your DC’s IP and that nslookup against your on-prem DNS server resolves your domain controllers.

    2. Use proper DNS instead of hosts files

    • For Azure Files private endpoints, spin up a Private DNS zone (privatelink.file.core.windows.net), link it to your VNet, and let Azure auto-create the A-record for your storage account.
    • On-prem DNS should forward that private zone to the Azure DNS resolver or to an Azure DNS Private Resolver inbound endpoint.
    • Push your on-prem DNS server IP (and suffix) in the P2S config so clients use your own DNS and can both resolve the file-share FQDN and find your DC.

    Once your P2S VPN client can both resolve your AD-DS names and actually reach the DC over the tunnel, you’ll get line-of-sight for Kerberos/NTLM and users will be able to mount the file share with their domain credentials.

    If you’d rather not extend your on-prem AD over VPN, another common pattern is to deploy an AD-DS domain controller (or use Azure AD Domain Services) in the same VNet as your file share. That way authentication stays entirely in Azure but it isn’t the only way.

    References:
    https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-howto-point-to-site-route
    https://learn.microsoft.com/azure/storage/files/storage-files-identity-ad-ds-enable?tabs=azure-portal
    https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-troubleshoot-vpn-point-to-site-connection-problems

    https://learn.microsoft.com/azure/storage/files/storage-files-networking-dns?tabs=azure-portal

    Please210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, **this can be beneficial to other community members.

    Was this answer helpful?

    0 comments
  2. Jerald Felix 13,255 Reputation points Volunteer Moderator
    2026-05-28T17:30:17.1233333+00:00

    Hello rr-4098,

    Greetings! Thanks for raising this question in Q&A forum.

    This is a very common and well-known scenario! The root cause here is that your P2S VPN clients cannot reach the on-premises Domain Controller (DC) to perform Kerberos/NTLM authentication. Azure Files with AD DS authentication requires the client to have direct line-of-sight to a DC and since your P2S clients can't ping the on-prem DC, authentication fails with "Access Denied" even though your Azure RBAC roles are correctly set.

    The fact that it works when you also connect to the on-prem VPN confirms this is purely a DC reachability problem, not a permissions issue.

    To fix this without necessarily adding a DC in Azure, here is what you need to check and configure step by step:

    Step 1 — Ensure transitive routing is in place

    Your P2S VPN clients need to be able to reach the on-prem DC subnet through the existing S2S tunnel. To allow this:

    • Make sure the P2S address pool is included in the routes advertised over the S2S tunnel to on-prem.
    • Verify the Azure VPN Gateway is configured to allow transit traffic from P2S clients to the on-prem network.
    • Check that there is no asymmetric routing or route filtering dropping P2S traffic on either side.

    Step 2 — Open the right firewall ports on-premises

    Your on-prem firewall needs to allow traffic from the P2S address pool to reach the DC. At minimum, these ports must be open:

    • TCP/UDP 88 (Kerberos)
    • TCP/UDP 389 (LDAP)
    • TCP 445 (SMB)
    • TCP/UDP 53 (DNS)
    • TCP 135 + dynamic RPC ports (Netlogon)

    Step 3 — Fix DNS properly (move away from hosts file)

    Using a local hosts file is a workaround that can break in subtle ways. The right approach is:

    • Deploy an Azure DNS Private Resolver or a small DNS forwarder VM in your Azure VNet.
    • Configure your on-prem DNS server with a conditional forwarder for file.core.windows.net pointing to that Azure DNS forwarder.
    • This ensures the storage account FQDN resolves to the private endpoint IP for all clients, including P2S users no hosts file edits needed.

    Step 4 — Test DC reachability from the P2S client

    Once routing and firewall changes are in place, from a P2S connected machine run:

    # Test DC reachability
Test-NetConnection -ComputerName <onprem-DC-IP> -Port 88

# Test DNS resolution of the file share
Resolve-DnsName <yourstorageaccount>.file.core.windows.net

    The private endpoint IP should come back — not the public IP.

    Step 5 — If transitive routing is too complex, deploy a DC in Azure

    If getting P2S → Azure → on-prem routing working cleanly is not feasible in your environment, then deploying a Read-Only Domain Controller (RODC) in your Azure VNet is the most practical solution. It gives P2S clients local line-of-sight to a DC within Azure, keeps your cost low (a small VM), and avoids the complex routing requirements entirely.

    To summarise a DC in Azure is not strictly required, but your P2S clients must be able to reach a DC one way or another. Right now they can't, and that is the sole reason for the "Access Denied" error. Fixing the transitive routing through the S2S tunnel is the cleanest no-new-VM solution, but an RODC in Azure is the simplest and most reliable path forward if that proves difficult.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,

    Jerald Felix.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.