Microsoft Connected Cache for ISP serves clients outside configured Manual Routing CIDRs

Question

Microsoft Connected Cache for ISP serves clients outside configured Manual Routing CIDRs

Vadim kirichenko 0

We are an ISP operating Microsoft Connected Cache for ISP using Manual Routing.

We provide and fund the MCC infrastructure ourselves, including server hardware, SSD storage, power, network capacity and Internet connectivity.

According to the Microsoft Connected Cache documentation, Manual Routing CIDRs define the client IP address ranges that should be routed to our Connected Cache node. At the same time, the MCC node is required to use a publicly accessible IPv4 address.

We configured only our own customer networks and specifically selected downstream networks in Manual Routing.

However, we are observing valid Microsoft Delivery Optimization requests from public source IP addresses that are not included in any of our configured Manual Routing CIDRs.

We verified this using packet capture. For example, one client outside all configured CIDRs made the following request to our MCC:

Source IP: 34.79.154.21 Destination: <our MCC public IPv4>:80 GET /filestreamingservice/files/.../pieceshash?cacheHostOrigin=dl.delivery.mp.microsoft.com HTTP/1.1 User-Agent: Microsoft-Delivery-Optimization/10.1 Host: <our MCC public IPv4>

The MCC responded:

HTTP/1.1 200 OK

We have observed similar traffic from multiple IP networks outside our configured Manual Routing ranges, including cloud providers, VPN/proxy networks, mobile operators and unrelated ISPs.

This creates an apparent inconsistency that we would like Microsoft to clarify.

Is an MCC for ISP operator expected to serve Microsoft content to source IP addresses that are outside all Manual Routing CIDRs configured for that cache node?
What exactly does “publicly accessible IPv4 address” mean in this context? Does it only mean that the cache node must have a globally routable/reachable IPv4 address, or must TCP/80 be open to the entire public Internet?
Is it supported to configure an inbound firewall ACL that permits MCC content traffic only from the customer/downstream CIDRs configured in Manual Routing?
Would such source-IP filtering interfere with MCC health checks, management/control traffic, or violate Microsoft Connected Cache requirements?
If a legitimate client is assigned our MCC while using one of our configured CIDRs and then changes its public source IP because of a VPN, proxy, mobile network, roaming, etc., is that client still expected to use our cache? If yes, for how long does the MCC assignment remain valid?

Our concern is not about the cache having a public IPv4 address. Our concern is whether an ISP participating in Microsoft Connected Cache is expected to provide its privately funded cache infrastructure and network capacity to arbitrary Internet source networks that were never included in its Manual Routing configuration.

We would appreciate an authoritative clarification of the intended behavior and the supported firewall policy for Microsoft Connected Cache for ISP.

Vadim kirichenko 0 Reputation points

2026-08-27T18:52:17.6666667+00:00

Additional packet capture confirms that this is not limited to metadata requests. The same source IP outside all configured Manual Routing CIDRs successfully requested Microsoft content from our MCC and received:

HTTP/1.1 200 OK Content-Length: 96669542

This represents an approximately 96.7 MB content response from our ISP-operated cache to a source address outside the configured Manual Routing ranges.

Other successful responses in the same short capture included 13.6 MB and 2.8 MB objects.

1 answer

Your answer

Vadim kirichenko 0 Reputation points

2026-08-27T18:52:17.6666667+00:00

Additional packet capture confirms that this is not limited to metadata requests. The same source IP outside all configured Manual Routing CIDRs successfully requested Microsoft content from our MCC and received:

HTTP/1.1 200 OK Content-Length: 96669542

This represents an approximately 96.7 MB content response from our ISP-operated cache to a source address outside the configured Manual Routing ranges.

Other successful responses in the same short capture included 13.6 MB and 2.8 MB objects.

Answer 1

Hello @Vadim kirichenko

Your packet capture is useful evidence, and I think the distinction here is between client assignment/routing and network access control.

Microsoft documents Manual Routing as providing the CIDR blocks representing the client IP address space that should be routed to the Connected Cache node. Delivery Optimization then matches a client's IP address with the corresponding MCC node.

However, I cannot find Microsoft documentation stating that the MCC server also enforces those Manual Routing CIDRs as an inbound source-IP allowlist.

So, to answer your questions directly:

1. Should clients outside the configured CIDRs be assigned to this MCC?

Based on the documented Manual Routing behavior, the configured CIDRs should determine which client address space is associated with the cache. Your evidence that unrelated source networks successfully retrieved large objects deserves investigation.

2. What does publicly accessible IPv4 mean?

Microsoft requires the cache server to have a publicly accessible IPv4 address. The documentation I can find does not explicitly say that this means TCP/80 must accept connections from every IPv4 address on the Internet.

3. Can you restrict TCP/80 to only the Manual Routing CIDRs?

I would not implement that as a production change yet. Microsoft doesn't document the Manual Routing list as a supported firewall allowlist, so we can't safely assume the configured CIDRs represent every source that MCC infrastructure may legitimately need to accept.

4. Could filtering interfere with health/control traffic?

Potentially, which is why Microsoft should confirm the required inbound sources before deploying such filtering. The public documentation doesn't provide enough information to state that restricting TCP/80 exclusively to Manual Routing CIDRs is supported.

5. What happens when a client changes IP after assignment?

Microsoft documents that clients periodically contact the Delivery Optimization service and are matched to an MCC based on their IP address, but I cannot find a documented assignment lifetime or behavior covering a client switching its public IP through VPN, proxy, roaming, etc.

One related documented behavior is worth noting: Microsoft states that for network service providers with downstream transit customers, the cache controller prefers the downstream ASN when handling that ASN's traffic. This reinforces that MCC selection involves Microsoft's cache-controller logic and isn't simply an ACL applied to the cache server.

Since you've captured an outside source IP successfully receiving about 96.7 MB of actual content, rather than merely probing the endpoint, I think you've provided enough evidence to warrant escalation.

You may ask the Microsoft Connected Cache product team to confirm two things specifically:

Are Manual Routing CIDRs intended only for Delivery Optimization cache assignment, or are they also intended to define the source networks an MCC operator is expected to serve?
And what inbound firewall policy is officially supported for TCP/80 on an ISP-operated MCC node?

Until Microsoft answers those questions, I would avoid assuming the observed traffic is expected behavior or blocking all non-configured sources, because neither conclusion is clearly supported by the current documentation.

Microsoft references:

Microsoft Connected Cache for ISPs overview

Microsoft Connected Cache for ISPs FAQ

Please "Accept the Answer" if this information helped you. This will help us and others in the community.

Vadim kirichenko 0 Reputation points

2026-08-27T21:13:32.66+00:00

Thank you. This confirms the distinction we were concerned about.

We agree that the key unresolved point is not whether Manual Routing is technically implemented as an ACL, but whether an ISP operator is expected to provide cache service to source networks outside the configured Manual Routing CIDRs.

In our case this is not theoretical. We have now captured repeated successful Microsoft Delivery Optimization downloads from an unrelated public source IP outside all configured CIDRs, including:

HTTP/1.1 200 OK Content-Length: 96669542

as well as additional successful responses of approximately 13.6 MB and 2.8 MB during the same short capture.

Could you please escalate this to the Microsoft Connected Cache product team, or advise the correct channel for obtaining an authoritative product-team answer?

Specifically, we need an official answer to these two questions:

Are Manual Routing CIDRs only used for cache assignment, while an ISP-operated MCC node is nevertheless expected to serve valid DO requests from arbitrary Internet source networks?

What inbound TCP/80 firewall policy is officially supported for MCC for ISP, including any Microsoft health/control source ranges that must remain reachable?

We would prefer not to deploy an unsupported firewall policy, but equally we cannot assume that privately funded ISP cache infrastructure and network capacity are intended to serve arbitrary external networks without an explicit Microsoft requirement.
Vadim kirichenko 0 Reputation points

2026-08-28T00:02:28.17+00:00

Thank you. We followed your recommendation and attempted to open a technical support case under Microsoft Connected Cache for ISPs in the Azure portal.

However, our Azure subscription currently has the Basic support plan, and the portal does not allow us to submit a technical support request without purchasing a paid Azure support plan.

Since Microsoft Connected Cache for ISP itself is a Microsoft-operated ISP caching program, could you please advise whether there is a dedicated MCC ISP support/escalation channel for this product, or whether you can escalate this question internally to the MCC engineering/product team?

We can provide the MCC resource/node ID, configured Manual Routing CIDRs, timestamps, source/destination IP addresses and packet captures.