Firewall blocking port 9000 traffic to 10.255.0.x across multiple tenants

Question

Firewall blocking port 9000 traffic to 10.255.0.x across multiple tenants

mani 45

I am seeing ongoing firewall blocks on port 9000 across two different managed tenants and wanted to check if this pattern is expected platform behavior or if anyone has insights into it.

Here are the details from our firewall logs stretching back over the last month:

Tenant A: Traffic is originating from an Azure SQL Managed Instance subnet and attempting to route toward 10.255.0.x on port 9000, which is being actively blocked by the firewall.

Tenant B: We are observing continuous traffic coming from everywhere (external/random sources) attempting to send to that exact same IP address (10.255.0.x) and port (9000), which is also being blocked by the firewall.

Are these port 9000 patterns recognised internal platform probes, telemetry, or typical background scanning noise? Any guidance from the community or MVPs would be greatly appreciated.

@GitaraniSharma-MSFT

0 comments

1 answer

Your answer

Answer 1

Hi mani,

The Tenant A traffic is consistent with Azure SQL Managed Instance's automatic internal connectivity tests, which have been running on all SQL Managed Instances since May 2026. These tests originate from reserved private IPs in the MI subnet and run every 10 seconds.

However, Microsoft does not document port 9000 or 10.255.0.x as a specific SQL MI probe endpoint, so I would not treat every connection to that address/port as confirmed Microsoft telemetry based on the logs alone.

For Tenant B, traffic described as coming from external/random sources is a different pattern. 10.255.0.0/8 is private address space, so those sources are likely being represented after NAT, proxying, or internal platform routing rather than being Internet clients directly reaching a 10.255.0.x address.

I would therefore not create a firewall allow rule for 10.255.0.x:9000 solely based on these logs. First identify the actual source interface/IP, next hop, and route in the Azure Firewall logs and Network Watcher before allowing the traffic.