Let’s say subnet A has microsoft.storage service endpoint and a VM1 is connected to subnet A has public IP 13.68.158.24 and a subnet B does not have microsoft.storage service endpoint and a VM2 is connected to subnet B has public IP 13.68.158.50. TestStorage has firewall configured to allow access from 13.68.158.0/24 IP address range. Which virtual machine can access TestStorage ?
Let’s say subnet A has microsoft.storage service endpoint and a VM1 is connected to subnet A has public IP 13.68.158.24 and a subnet B does not have microsoft.storage service endpoint and a VM2 is connected to subnet B has public IP 13.68.158.50. TestStorage has firewall configured to allow access from 13.68.158.0/24 IP address range only. Which virtual machine can access TestStorage ?
Interesting scenario. I like how it highlights the subtle difference between service endpoints and plain firewall filtering.
If the storage firewall is only checking the public IP range 13.68.158.0/24, then both VM1 and VM2 technically match that rule. So from a pure IP-allowlist perspective, either VM should be able to reach TestStorage.
Where the twist comes in is the service endpoint. VM1’s subnet has it enabled. That means its traffic to Storage will be forced over the Microsoft backbone, giving an additional security guarantee that the source is trusted. VM2 doesn’t have that. So even though its IP falls into the approved CIDR, the traffic would probably be blocked because it’s not coming through the trusted path.
In short. VM1 can access the storage account. VM2 looks like it should be allowed at first glance, but the missing service endpoint breaks the trust requirement.
It’s a good reminder that network rules aren’t just about IP ranges. The path you take matters too.