Standard D8ns v6 VMs cannot reach Azure Files Private Endpoint over TCP 445 when NAT Gateway is enabled

Hello mr. Ma,

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

Based on what you have already collected, this looks like a platform level networking behavior tied specifically to the Standard D8ns v6 size rather than a configuration issue in your VNet, NSG, route table or Private Endpoint. You have already ruled out the usual suspects (DNS, NSG, UDR, Private Endpoint health) and isolated the variable to VM size, which is the right approach. Here is how to take this further before and during an Azure Support escalation.

1. Rule out Accelerated Networking as a factor The Dnsv6 family uses a newer NIC and Accelerated Networking implementation compared to older Dv5/Dsv5 series. When Accelerated Networking is enabled, the data path for SR-IOV virtual functions can behave differently when a NAT Gateway is also attached to the same subnet, particularly for flows that should bypass NAT entirely (Private Endpoint traffic). Temporarily disable Accelerated Networking on the affected D8ns v6 VM's NIC and retest TCP 445 to the Private Endpoint.

Stop-AzVM -ResourceGroupName "<rg>" -Name "<vmname>" -Force
Update-AzNetworkInterface -NetworkInterface (Get-AzNetworkInterface -ResourceGroupName "<rg>" -Name "<nicname>") -EnableAcceleratedNetworking $false
Start-AzVM -ResourceGroupName "<rg>" -Name "<vmname>"

If TCP 445 starts working with Accelerated Networking disabled, that confirms the data path implementation on this VM size is the trigger and gives Azure Support a concrete repro to work from.

1. Capture the effective routes from inside the VM, not just Network Watcher Network Watoner showing next hop PrivateEndpoint is correct from a control plane perspective, but it does not always reflect what the host's actual flow table is doing for a specific VM size. Pull the effective routes directly:

Get-AzEffectiveRouteTable -ResourceGroupName "<rg>" -NetworkInterfaceName "<nicname>" | Format-Table

Confirm the Private Endpoint's /32 route still shows next hop type VNetLocal or PrivateEndpoint, and that there is no overlapping NAT Gateway influenced route for that specific /32 prefix.

1. Run a packet capture on the affected VM during a failed connection attempt

netsh trace start capture=yes tracefile=C:\PEtrace.etl
# reproduce the SMB connection attempt to the storage account FQDN
netsh trace stop

Open the trace and check whether the SYN packet is leaving the NIC at all, or whether it is being silently dropped at the host level before it reaches the wire. If the SYN never leaves the VM, this points to a host or NIC driver level issue specific to this VM series rather than anything in the VNet.

1. Check MTU and TCP offload settings Some newer VM series default to different TCP Chimney Offload or RSS settings. From an elevated PowerShell session on the affected VM:

Get-NetAdapterAdvancedProperty -Name "Ethernet*"
netsh interface ipv4 show subinterfaces

Compare the MTU and offload settings against a working D4lds v6 VM in the same subnet. A mismatch here combined with NAT Gateway's flow handling can cause exactly this kind of selective TCP 445 timeout.

1. Escalate to Azure Support with the evidence you already have Since this reproduces consistently across 5 separately created VMs of the same size, and resolves when NAT Gateway is removed, this is very likely a fabric or host networking regression tied to the D8ns v6 SKU rather than something you can resolve from the customer side. Open a support case under Networking > Virtual Network and include:
   • The Network Watcher Connection Troubleshoot results for both the failing and working VM sizes
     • The Resource ID of the affected VM, the NAT Gateway, and the Private Endpoint
       • Results from steps 1 to 4 above
         • The exact timestamps of your test attempts so the networking team can correlate against fabric telemetry

Until this is resolved, removing the affected VM size from the session host pool, or keeping NAT Gateway off this specific subnet and using a UDR to a firewall/NVA for general internet egress instead, is the safest interim workaround so FSLogix profile attach is not impacted.

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

Best Regards,

Jerald Felix.

Hello,

I completed the additional checks you suggested.

1. Accelerated Networking

I tested the affected Standard D8ns v6 VM with Accelerated Networking both disabled and enabled.

Results:

• EnableAcceleratedNetworking = False → TCP 445 to the Azure Files Private Endpoint still fails / times out.
• EnableAcceleratedNetworking = True → TCP 445 to the Azure Files Private Endpoint still fails / times out.

So Accelerated Networking / SR-IOV does not appear to be the cause or workaround in this case.

2. Guest route / adapter comparison

I compared the guest OS route selection and adapter configuration between the affected Standard D8ns v6 VM and a working VM in the same subnet.

The only difference I found is the local Windows InterfaceIndex value. All relevant routing values are otherwise the same:

• Same selected route to the Azure Files Private Endpoint
• Same route logic
• Same route/interface metrics
• No NSG applied
• No UDR / route table applied
• Network Watcher Next Hop still shows PrivateEndpoint / System Route

So this does not appear to be a guest OS route selection issue.

3. Packet capture comparison

I performed packet captures inside both VMs using pktmon and opened the pcapng files in Wireshark.

On the affected Standard D8ns v6 VM, during the TCP 445 test to the Azure Files Private Endpoint, I can see TCP SYN packets being sent to port 445, followed by multiple SYN retransmissions. However, there is no SYN-ACK response from the Azure Files Private Endpoint.

[Insert screenshot 1 here: affected Standard D8ns v6 VM — SYN packets and SYN retransmissions to TCP 445, no SYN-ACK response]

On the working VM size in the same subnet, the same test shows a normal TCP handshake:

• client → 445: SYN
• 445 → client: SYN, ACK
• client → 445: ACK

[Insert screenshot 2 here: working VM size — normal TCP handshake, SYN → SYN-ACK → ACK]

This confirms that the affected Standard D8ns v6 VM is generating and sending the TCP connection attempt, but the TCP handshake does not complete because the SYN-ACK response is not received. The same Azure Files Private Endpoint and TCP 445 flow works from other VM sizes in the same subnet.

Based on these results, the issue still appears to be specific to Standard D8ns v6 / Azure fabric / NIC path behavior rather than DNS, NSG, UDR, guest routing, or Accelerated Networking.

Could you please advise the next diagnostic step?

Given that the suggested checks have been completed and the issue still appears isolated to Standard D8ns v6, could you please escalate this to Azure networking/platform engineering or create a support case on my behalf if further investigation is required? I currently have access through Azure Developer Support / Priority Community Support, so I cannot open a private technical support case directly from the Azure Portal.