This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hi all! So this one is baffling me!
I have a Windows Server 2019 Azure Virtual Machine deployed into a virtual network with a 0.0.0.0/0 user defined route directing traffic to an Azure Firewall. There are no other user defined routes and the virtual machine is in the same virtual network as the virtual machine.
I have a network security group associated with the subnet that the VM resides in with overriding deny rules. Happy to share these however the important rule is that I'm allowing Internet connections outbound from the virtual network and controlling these connections with the Azure Firewall for more granular control.
While I see no IO errors on the virtual machine (it's not doing much, to be honest though) I'm denying access to several storage accounts I'm unaware of.
Disk export tells me that the FQDN starting md-ssd is the managed disk and I'm assuming the other storage accounts are those abstracted by the managed disk.
Anyway, the questions..
Do I need to allow this traffic through the Azure Firewall? How do I do so without allowing connections to all blob.storage.azure.net / blob.core.windows.net endpoints?
The only documentation I've found so far is that service endpoints aren't going to help: "Disk traffic from an Azure virtual machine: Virtual Machine Disk traffic for managed and unmanaged disks isn't affected by service endpoints routing changes for Azure Storage..." (From - virtual-network-service-endpoints-overview )
Some additional details that may or may not be relevant:
@Matthew Daines
I am investigating this issue and will send an update shortly.
Seeing the exact same, Also wonder why a managed disk is try to access my Firewall, Also the Firewall it self try to access 443 to his own internal IP.
Any update on this @deherman-MSFT ?
Hey! I have a support ticket open and will update this thread once I know more.. Nothing to report yet!
For your Azure Firewall accessing itself I assume you mean IPs within your AzureFirewallSubnet are hitting the Azure Firewall's front end and being processed by the Azure Firewall? If that's the case, it sounds like you have a user defined route on your AzureFirewallSubnet with an address prefix that matches the AzureFirewallSubnet's address range? If you don't want/need to processes this traffic (if that's even supported?) I'd check and remove that user defined route from the subnet that's associated with the AzureFirewallSubnet.
For clarity, in my case with the manged disk, I only have one route table and one user defined route to the Internet.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(134.4, 78%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAB%3C/text%3E%3C/svg%3E)
@Matthew Daines @Robert Smit hey you guys ever hear back about this noise with md- prefix in managed disks ?
Seeing same issue, have a call open with Premier Support but no response after several weeks
thx in advance
Andy
Hey @Andy Ball
Unfortunately, nothing conclusive yet. I've had a ticket open (though, not premier support!) since March and I think the support engineers have given up. I feel like I'm asking the same questions again and again to keep the ticket open but the answers I'm getting are to questions I haven't asked. I promise I will update this post once I have an actual answer but with premier support I'd like to think you'll get there before me!
Just wanted to point out that it's likely you'll also see the virtual machine going to a few storage accounts on <something>.blob.core.windows.net - the regular blob endpoint. md-ssd/md-hdd use blob.storage.azure.net which is probably fine to allow as a wildcard because as far as I know it's not something that other Azure customers can't knowingly use and configure. I just want/need confirmation of that before I do it. The blob endpoints are what trouble me....
I haven't found anything that's broken from blocking this traffic but I do find it strange this traffic is visible on the customer's network in the first place. It's certainly not documented...
Anyway, if you do hear anything, could you update this thread please? Promise I'll do the same!
Hey Matthew,
thanks a lot for replying - comforting to know that someone else is in same boat.
Yep we see the same suffix behaviour, but again wanted to confirm 100% is not available outside of Microsoft - ie andyexilfitrationaccount.blob.storage.azure.net :-)
Same re no ill effects - but we have a VM heavy implementation and this is currently 13% of traffic hitting the firewall / the noise , whilst can be filtered out , is a bit of an Operational pain.
yup will post back here if progress.
cheers,
Andy.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(240, 85%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKZ%3C/text%3E%3C/svg%3E)
It is possible to create your own storage account with blob.storage.azure.net suffix when you use paritioned storage account DNS - https://techcommunity.microsoft.com/t5/azure-storage-blog/public-preview-create-additional-5000-azure-storage-accounts/ba-p/3465466
So no, whitelisting *.blob.storage.azure.net on the FW level is not safe.
Looks like whitelisting md-*.blob.storage.azure.net should be safe as you cannot use hyphens in your storage account names so maybe we can assume it is available only for MS managed storage accounts.
@Matthew Daines @Robert Smit just thought i'd update , there is no update ... still working through it.
Thanks @Andy Ball for the update. So Premier Support does not have a solution for it.
not yet , they are still looking at it
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(64, 84%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWJ%3C/text%3E%3C/svg%3E)
I ran across this today and the solution is to use Service Endpoints to allow the VM to do its admin storage account writes (analytics, etc) without leaving the virtual network, even if the VM and the storage account are on different subnets.
In the subnet that contains the VM that is making the problematic requests, configure the service endpoints thusly:
Then, the entries you're seeing in the log will cease, as shown in this image, taken 20 minutes after I established the service endpoint.
As a colleague in InfoSec wrote to our team after this was found:
Here is a quick explanation.
• The Firewall blocks outbound traffic from our machines to random blob storage accounts, as it should.
• Attempts to send traffic to blob storage accounts we have no visibility into appear suspicious but in this case turn out to be expected behavior
• Microsoft creates storage accounts in our tenant that are not visible to us for things such as this md-* storage and for certain configurations of SQL.
Obviously we can’t allow traffic to any blob storage account on the Internet but Microsoft has a solution called Service Endpoints. Service Endpoints are a special type of routing on a subnet that cause connections from your subnet to specific services that you own to go direct and bypass the firewall. You can enable Service on a per service basis. The solution for this problem is to turn on service endpoint for Storage on the subnets that are running the VMs. Doing this means that the traffic will flow and not hit the FW – a win win.
So, hopefully there you have your answer. Best of luck!
Jeff Woods
Technical Architect
Hey @Woods, Jeffrey ,
first of all thank u (and yer colleague) very much for this , i owe u both a pint or whatever :-). I must admit I hadnt really considered Service Endpoints , off the radar, cos Private Endpoint is V2 of it (sorta).
"our subnet to specific services that you own to go direct and bypass the firewall. "
My concern here , unless i have misunderstood, is that we dont own the md-* storage accounts , Microsoft do and while enabling Service Endpoint on Storage Accounts stops the md- traffic hitting the firewall. it means that ALL traffic Storage Account traffic bypasses the firewall doesnt it ? ie i could send data to a storage account my own tenant.
I guess maybe able do something with Azure Policy in this regard. Still thinking about it , but really must get out in the sun and ride my bike :)
many thanks
Andy.
Obviously we can’t allow traffic to any blob storage account on the Internet but Microsoft has a solution called Service Endpoints.
Service Endpoints are a special type of routing on a subnet that cause connections from your subnet to specific services that you own to go direct and bypass the firewall.
Sorry but these two statements contradict each other.
When you enable Service Endpoints on the subnet you effectively allow traffic to any blob storage account. So how is that you correctly point out from security perspective we can't allow traffic to any storage account and then suggest solution which does that? Makes no sense.
@Kamil Zdanikowski As an FYI you can use service endpoint policies to restrict what services are accessible over a service endpoint.
Service endpoint policies enable you to filter virtual network traffic to specific Azure resources, over service endpoints.However, service endpoint policies aren't helpful when the endpoint is Microsoft managed. Additionally, as in my original post:
Disk traffic from an Azure virtual machine: Virtual Machine Disk traffic for managed and unmanaged disks isn't affected by service endpoints routing changes for Azure Storage. This traffic includes diskIO as well as mount and unmount. You can limit REST access to page blobs to select networks through service endpoints and Azure Storage network rules.
I do agree with Kamil, it's not a win-win in terms of security. Adding the service endpoint without a service endpoint policy onto the subnet is going to inject routes for that service which bypasses a firewall that can apply controls that filter based on FQDN and not just IP or a service tag. (Not sure if I can @ mention "Woods, Jeffrey" as there's a comma?)
Back onto my original question, I've still not gotten to the bottom of this. A Microsoft ticket I raised back in 2022 suggested it might be the Azure VM agent. I might spin up a lab again next week to deep dive.. Importantly, as far as I've been able to tell, nothing appears to be broken from blocking the connection but it would still be nice to know what it is.