Networking Considerations for Azure Files

Here’s a concise summary of the article “Azure Files networking considerations.”

Overview

Azure file shares can be accessed via:
- Public endpoint (internet-exposed)
- Private endpoints (private IPs in one or more VNets)
- Cached on-premises via Azure File Sync (SMB only) — see Introduction to Azure File Sync
Configure access at the storage account level (the top-level management object for Azure Files).

Applies to

Key networking considerations

SMB uses TCP port 445; many organizations/ISPs block outbound 445. SMB 3.x is encrypted and internet-safe, but legacy blocking policies may prevent mounts without additional networking work.
NFS relies on network-level authentication and is only accessible from restricted networks (requires networking configuration).

Secure transfer

By default, storage accounts require secure transfer. For Azure Files, this affects SMB, NFS, and FileREST:
- With Secure transfer required enabled:
  - SMB shares require SMB 3.x with AES-128-CCM/GCM or AES-256-GCM encryption. You can configure allowed SMB encryption algorithms via SMB security settings.
  - FileREST only accepts HTTPS.
- Disabling Secure transfer allows unencrypted SMB (including SMB 2.1) and HTTP for FileREST.
Azure Files uses TLS for client-storage communication.

Public endpoint

Default endpoint; can be disabled.
SMB: accessible from anywhere using SMB 3.x with encryption. For SMB 2.1 or SMB 3.x without encryption, two conditions must be met: Secure transfer disabled, and the request must originate from inside the Azure region.
NFS: public endpoint access only when the storage account’s public endpoint is restricted to specific VNets via service endpoints.
FileREST: accessible via public endpoint; HTTPS required if secure transfer is enabled.

Public endpoint firewall settings

Storage account firewall can restrict the public endpoint by IP ranges, virtual networks, or disable it entirely.
Service endpoints let you restrict access to specific VNets while still using the storage account’s public IP (the networking layer validates the VNet origin).
NFS via public endpoint requires service endpoints.

Private endpoints

Provide a private IP for a storage account in a VNet subnet. A storage account can have private endpoints in multiple VNets.
Benefits:
- Secure access from on-premises via VPN or ExpressRoute (private-peering).
- Ability to block public endpoint connections (note: creating a private endpoint doesn’t automatically block the public endpoint).
- Reduce risk of data exfiltration by restricting where storage can be reached.
See Configuring private endpoints for Azure Files to create private endpoints.

Tunneling traffic (VPN / ExpressRoute)

To access SMB/NFS from on-premises using private endpoints, you must tunnel traffic via:
- Azure VPN Gateway:
  - Point-to-Site (P2S) — per-client VPN useful for telecommuters. See P2S guides for Windows and Linux.
  - Site-to-Site (S2S) — single site-level configuration for an organization’s network.
- ExpressRoute — private, dedicated connectivity (non-internet) useful for performance or compliance needs.
Note: You can technically route to the public endpoint over VPN, but this requires hard-coding storage cluster IPs (brittle, not recommended).

DNS configuration

Creating a private endpoint normally creates/updates a private DNS zone for the privatelink subdomain and adds A/CNAME records so the storage account name resolves to the private IP within the linked VNet.
From on-premises, the storage account name normally resolves to the public IP. To make it resolve to a private endpoint from on-premises, options include:
- Editing hosts files (not recommended for production).
- Creating A records in on-prem DNS (works but brittle).
- Forwarding the core.chinacloudapi.cn zone from on-prem DNS to the Azure private DNS zone (recommended approach). Azure provides scripts to deploy DNS forwarders in VNet to simplify this.
Use Resolve-DnsName / nslookup to verify resolution. See Configuring DNS with Azure Files for details.

SMB over QUIC

QUIC-based SMB (uses UDP/port 443 instead of TCP/445) is supported in Windows Server 2022 Azure Edition (server) and Windows 11 clients, offering a more internet-friendly transport.
Azure Files does not currently support SMB over QUIC directly. A viable option is to use Azure File Sync on Windows Server 2022 Azure Edition to provide SMB-over-QUIC access to cached shares (on-prem or in other datacenters).
See Deploy Azure File Sync and SMB over QUIC for more details.

References

Last updated: 07/08/2025

If you’d like, I can:

Produce a compact checklist for setting up secure SMB access from on-premises.
Create a step-by-step summary for configuring private endpoints and DNS forwarding.
Extract all links referenced in the article into a single list.

Was this helpful?