Azure NetApp Files Standard AcrossT2 mount target does not respond on TCP 2049 from same-VNet AKS nodes

We have an Azure NetApp Files Flexible volume using NFSv4.1 with Standard network features. The ANF delegated subnet and AKS node subnet are in the same VNet. There is no VNet peering, user-defined route, NVA, or NAT gateway in the data path.

Resource names, identifiers, and IP addresses in this public post have been anonymized. Complete command output is available through a private support channel.

ANF reports:

• Requested network features: Standard
• Effective network features: Standard
• Storage-to-network proximity: AcrossT2
• Volume provisioning state: Succeeded
• Network sibling-set state: Succeeded
• Protocol: NFSv4.1
• Security: Unix sec=sys
• Kerberos: disabled
• LDAP: disabled
• Export policy permits the complete AKS node subnet with NFSv4.1 read/write and root access

Direct tests from both underlying AKS VMSS hosts fail before NFS negotiation:

Node A:

ANF target via VNet gateway on eth0 using the node's private source IP

TCP 2049: timed out

Native NFSv4.1 mount: Connection timed out

Node B:

ANF target via VNet gateway on eth0 using the node's private source IP

TCP 2049: timed out

Native NFSv4.1 mount: Connection timed out

acket captures on both nodes show repeated outbound TCP SYN packets to the ANF mount target on port 2049. There is no SYN-ACK or RST response, and the packet captures report zero dropped packets.

We independently verified that general AKS networking is healthy in both directions:

• Direct cross-node pod-to-pod HTTP succeeds
• ClusterIP service routing succeeds
• NodePort ingress succeeds on both nodes
• CoreDNS resolution succeeds
• Kubernetes API connectivity succeeds
• Public HTTPS egress succeeds from both nodes
• Azure CNI, CNS, kube-proxy, CoreDNS, and konnectivity components are healthy

We also checked customer-controlled filtering:

• Neither subnet has a route table
• Neither subnet has a NAT gateway
• The VMSS has no NIC-level NSG
• Same-VNet traffic is allowed by both subnet NSGs
• The higher-priority port-2049 deny rule applies only to source Internet
• A temporary explicit TCP 2049 allow rule did not change the result and was removed
• Temporarily detaching the ANF-subnet NSG did not change the result; the NSG was immediately reattached
• Node host firewall services are inactive, with forwarding and output policies set to allow
• The subscription's Azure Firewall is in an unrelated region and VNet
• No Network Manager security-admin policy, Virtual WAN, NVA, or route-table next hop places a customer firewall on this flow

The ANF-created network interface exists in the delegated subnet, owns the mount-target IP, reports Succeeded, and references the current volume. The volume and its effective Standard network configuration also report Succeeded.

The earlier working ANF deployment used Basic network features. After it was deleted, new volume requests were provisioned with Standard network features, consistent with the July 2026 retirement of Basic for new or modified volumes. Microsoft documentation states that same-VNet connectivity is supported with Standard network features and that no Private Endpoint is required.

This appears specific to the Azure-managed Standard AcrossT2 attachment or return path between the ANF storage infrastructure and its delegated-subnet network interface.

Could the Azure NetApp Files networking team please help validate:

1. Whether this behavior indicates a Standard AcrossT2 data-plane or return-routing problem.
2. Whether storageToNetworkProximity=AcrossT2 with t2Network=null is expected.
3. Whether a network sibling set can report Succeeded while its mount target remains unreachable.
4. Whether stale ANF sibling-set or bare-metal associations from deleted volumes can affect a newly created Standard attachment.
5. What additional diagnostics can be collected before escalation to the ANF service team.

We have a timestamped evidence bundle containing raw Azure CLI output, direct VMSS mount tests, packet captures from both nodes, NSG and firewall analysis, and successful AKS connectivity control tests. Please provide a private mechanism for sharing the unredacted resource identifiers and logsacket captures on both nodes show repeated outbound TCP SYN packets to the ANF mount target on port 2049. There is no SYN-ACK or RST response, and the packet captures report zero dropped packets.

We independently verified that general AKS networking is healthy in both directions:

• Direct cross-node pod-to-pod HTTP succeeds
• ClusterIP service routing succeeds
• NodePort ingress succeeds on both nodes
• CoreDNS resolution succeeds
• Kubernetes API connectivity succeeds
• Public HTTPS egress succeeds from both nodes
• Azure CNI, CNS, kube-proxy, CoreDNS, and konnectivity components are healthy

We also checked customer-controlled filtering:

• Neither subnet has a route table
• Neither subnet has a NAT gateway
• The VMSS has no NIC-level NSG
• Same-VNet traffic is allowed by both subnet NSGs
• The higher-priority port-2049 deny rule applies only to source Internet
• A temporary explicit TCP 2049 allow rule did not change the result and was removed
• Temporarily detaching the ANF-subnet NSG did not change the result; the NSG was immediately reattached
• Node host firewall services are inactive, with forwarding and output policies set to allow
• The subscription's Azure Firewall is in an unrelated region and VNet
• No Network Manager security-admin policy, Virtual WAN, NVA, or route-table next hop places a customer firewall on this flow

The ANF-created network interface exists in the delegated subnet, owns the mount-target IP, reports Succeeded, and references the current volume. The volume and its effective Standard network configuration also report Succeeded.

The earlier working ANF deployment used Basic network features. After it was deleted, new volume requests were provisioned with Standard network features, consistent with the July 2026 retirement of Basic for new or modified volumes. Microsoft documentation states that same-VNet connectivity is supported with Standard network features and that no Private Endpoint is required.

This appears specific to the Azure-managed Standard AcrossT2 attachment or return path between the ANF storage infrastructure and its delegated-subnet network interface.

Could the Azure NetApp Files networking team please help validate:

1. Whether this behavior indicates a Standard AcrossT2 data-plane or return-routing problem.
2. Whether storageToNetworkProximity=AcrossT2 with t2Network=null is expected.
3. Whether a network sibling set can report Succeeded while its mount target remains unreachable.
4. Whether stale ANF sibling-set or bare-metal associations from deleted volumes can affect a newly created Standard attachment.
5. What additional diagnostics can be collected before escalation to the ANF service team.

We have a timestamped evidence bundle containing raw Azure CLI output, direct VMSS mount tests, packet captures from both nodes, NSG and firewall analysis, and successful AKS connectivity control tests. Please provide a private mechanism for sharing the unredacted resource identifiers and logs