Virtual Network: Deterministic TCP SYN Black-Holing to Azure Resource Manager — Issue with Outbound HTTPS Connections in East US

Question

Virtual Network: Deterministic TCP SYN Black-Holing to Azure Resource Manager — Issue with Outbound HTTPS Connections in East US

ChrisRyan-1170 0

Problem description

I am experiencing deterministic, source-port-dependent failures when making outbound HTTPS (TCP 443) connections from an Azure VM in East US to Azure Resource Manager. TCP SYN packets are being black-holed, preventing the connection from completing. The issue started around 2026-09-17, with approximately 10% of new TCP connection attempts failing. When the same source port is reused, the SYNs receive no response, while retries with different source ports succeed within milliseconds.

Environment

Azure Virtual Machine in East US with a public IP, outbound TCP 443 connections to Azure Resource Manager, using Standard static IP with Accelerated Networking enabled.

What I've already tried

I have not documented any troubleshooting steps beyond initial issue reporting. The supporting materials include Network Watcher Connection Troubleshoot to validate TCP connectivity and checks on NSG and UDR configurations. Packet captures indicate that SYN packets leave the VM NIC intact, with no SYN-ACK or RST responses received on failing attempts, suggesting the fault lies in the Azure platform path below the guest OS.

Current status

The last documented state is the initial report, with no confirmed resolution. I am seeking investigation into possible stale flow or connection state issues on Azure's SDN, host, or ARM front end, and guidance on how to resolve the deterministic source port collision problem affecting outbound HTTPS connections.

0 comments

1 answer

Your answer

Answer 1

Hi @ChrisRyan-1170

The deterministic source-port behavior is useful evidence, but I don't think the available information is sufficient to attribute this specifically to a stale Azure SDN/host/ARM frontend flow.

Because the VM has an instance-level public IP, the outbound traffic uses that public IP, and this configuration is implemented as stateless 1:1 NAT. The VM therefore isn't subject to the Azure Load Balancer SNAT-port allocation behavior that normally causes SNAT exhaustion.

Run Network Watcher Connection Troubleshoot against the affected ARM destination on TCP/443, specifying both:

a source port that consistently fails
a source port that consistently succeeds

Microsoft's Connection Troubleshoot supports specifying a source port and can identify conditions including NSG/route problems and SourcePortInUse.

Since you've already captured SYNs leaving the VM, preserve simultaneous packet captures for a known-good and known-bad source port, along with:

source private/public IP
resolved ARM destination IP
source and destination ports
UTC timestamps
Connection Troubleshoot results
effective NSG and route information

If the same destination consistently succeeds or fails solely according to the source port, while Network Watcher shows no customer-controlled NSG/route issue, that is strong evidence for escalation.

At that point, open an Azure support case and provide the successful and failed flow tuples plus their UTC timestamps so Microsoft can correlate the traffic with platform-side telemetry.

References:

Connection Troubleshoot overview

Troubleshoot outbound connections with Connection Troubleshoot

SNAT for outbound connections

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.