Azure Storage Account access logs CallerIpAddress is showing Private IP Address

Question

Azure Storage Account access logs CallerIpAddress is showing Private IP Address

Apurva Pathak 845

Hello folks,
I have an Azure Storage account that I’m trying to access from an Azure Win19 VM. The storage account is configured to allow public access only from specific public IP addresses.

When I attempt to access the storage blob from the VM, I receive a 403 (Network blockage) error, even though I’ve allowed the public IP assigned by Microsoft under default outbound access, when I check the StorageBlobLogs, the source IP logged (CallerIpAddress) is the private IP of the VM—not the public IP given by MS under default outbound access.

To troubleshoot, I routed the traffic from the VM through our firewall, which has a dedicated public IP assigned via a Public Load Balancer. We can see the traffic hitting the firewall and being allowed. However, when I checked the StorageBlobLogs again, the source IP logged (CallerIpAddress) is the private IP of the firewall instance—not the public IP (again).

Initially, I assumed this was just a logging issue, but the access still fails even though the dedicated public IP is whitelisted.

Could someone please help me understand below:

Why does Azure log the private IP (VM’s private IP in default outbound scenario, and firewall’s private IP when forced routing) instead of the public IP?
Is there any way to ensure Azure recognizes the public IP for access control?
If it's Azure logging issue, can we avoid it?

PFB snippet of the IP entry which we see.

{B5F7E519-3272-47A5-995B-A1C1805E371D} Any guidance would be greatly appreciated.

Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator

2025-11-24T19:09:27.47+00:00
Hello @Apurva Pathak,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

Thank you for your detailed description of the scenario and sharing the log snippets. Here’s some clarity on what’s happening:

When you access Azure Storage from within Azure using private connectivity options such as Service Endpoints or Private Endpoints, the traffic remains inside Azure’s internal network. In this case, Azure Storage logs the source IP as the private IP address of your VM or firewall, not the public IP. This is expected behavior because the connection never goes out over the public internet.

As a result, if you have configured your Storage account to allow access only from specific public IP addresses, it won't align with which IP is actually logged or used for access control when private connectivity is involved.

If you want Azure Storage to recognize and log your public IP for access control, you need to:

Avoid using private connectivity options like Service Endpoints or Private Endpoints.

Ensure your VM or firewall egresses traffic directly to the internet using its dedicated public IP.

Whitelist this public IP in the Storage account’s firewall and virtual network settings.

Once set up this way, Azure Storage will log the public IP and enforce access based on IP allow-listing correctly.

Alternatively, if you want to keep using private connectivity for better security, here’s what to know:

Access control happens using virtual network and subnet rules instead of public IP allow-listing.

Azure Storage will always log the internal private IP of your VM or firewall.

You must configure the Storage account firewall to allow the virtual network or subnet that your VM/firewall belongs to.

To verify whether you are hitting a private endpoint, you can run the command:

nslookup <yourstorageaccount>.blob.core.windows.net

If it resolves to a domain like privatelink.blob.core.windows.net, then you are using a private endpoint and the private IP logging is normal.

This behavior is by design and not a bug, as it improves security by isolating traffic inside Azure’s network when private connectivity is enabled.

Azure Storage Private Endpoints https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints

Troubleshoot Azure Private Endpoint DNS issues https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns

Configure network rules for Azure Storage https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-guide

Kindly let us know if the above helps or you need further assistance on this issue.
Adam Zachary 2,025 Reputation points

2025-11-24T21:02:48.1833333+00:00

I’ve seen this before, and nothing is wrong with your logs. Azure shows the private IP because your VM is not actually reaching the storage account through the public internet. It is staying on the Azure backbone, so the storage account only sees the private source IP and blocks it.

To fix it, the traffic must really go out through a device that performs public SNAT. In other words, force the VM’s traffic through a firewall or NAT gateway that uses a true public IP, and make sure that device is actually translating the source address.

Once the traffic leaves the VNet with the real public IP, the storage account will see it correctly and your allow list will work.
Apurva Pathak 845 Reputation points

2025-11-25T06:51:26.5733333+00:00

Hi @Adam Zachary ,

The traffic is flowing through a Standard Public LB via Outbound rule, and this is one of the recommended ways of MS to achieve outbound connectivity. Also, the destination is in different Azure tenant, and it resolves with a Public IP.

Pre server of the same environments works perfectly fine, issue is only with the Prod box.

Any further suggestions on this would be very helpful.
Apurva Pathak 845 Reputation points

2025-11-25T06:51:34.8133333+00:00

The traffic is flowing through a Standard Public LB via Outbound rule, and this is one of the recommended ways of MS to achieve outbound connectivity. Also, the destination is in different Azure tenant, and it resolves with a Public IP.

Pre server of the same environments works perfectly fine, issue is only with the Prod box.

Any further suggestions on this would be very helpful.
Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator

2025-11-25T20:11:00.82+00:00
Hello @Apurva Pathak,

Thanks for sharing the detailed steps. The issue you’re seeing happens because when Azure Storage traffic goes over Azure’s private backbone (using Service or Private Endpoints, or when outbound SNAT to a public IP doesn’t occur), Storage logs the VM’s or firewall’s private IP. This causes public IP allow-listing to fail, resulting in the 403 error.

To fix this and have Azure Storage recognize your public IP for allow-listing, please:

Ensure outbound traffic from your VM/firewall is NATed to your dedicated public IP. Using an Azure NAT Gateway is recommended for consistent egress IPs over Standard Load Balancer rules.

Remove any Service Endpoint or Private Endpoint on your subnet directing storage traffic privately so it goes through the public internet.

Confirm DNS for your storage endpoint resolves to the public Azure blob service by running:

nslookup <yourstorageaccount>.blob.core.windows.net

Verify your VM’s effective public IP matches the IP allow-listed on your Storage firewall by running:

curl https://api.ipify.org

If you prefer private connectivity with Private Endpoints, then use VNet and subnet rules for allow-listing instead of public IPs. In that case, Azure Storage will always log the private IP.

I’m happy to help compare your PROD and PRE environment setups such as NAT Gateway vs Standard Load Balancer, DNS, and routing to find why PROD behaves differently.

Helpful references:

Private DNS and Private Endpoint setup: Azure Private Endpoint private DNS zone values | Microsoft Learn

Using Private Endpoints with Storage: Use private endpoints - Azure Storage | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.
Apurva Pathak 845 Reputation points

2025-11-26T07:43:42.1133333+00:00
I’ve got the root cause of it, we are hitting an Azure limitation, below are detailed analysis and possible ways to fix it.

Infrastructure overview (for non-working VMs):

Default Outbound connection (No Firewall involved):

VM Region: UK West

Connection forced via Firewall (routed through Azure Public LB)

VM Region: UK West

Firewall Region: UK West

Root cause: When the source Azure resource (Load Balancers, VMs) is deployed in the same region as destination Azure Storage account, the connection from source to the storage account doesn’t go via public internet even if we have dedicated Public IPs assigned to Load Balancers. It travels on MS backbone and that’s why Azure only gets the private IP of the resources.

MS Doc: Frequently asked questions - Azure Load Balancer | Microsoft Learn

Possible solutions: Since, we cannot whitelist the Private IPs over storage account network settings due to limitations with IP rules (refer here), we will either have to

Deploy a Private Endpoint connection to this storage account.

Create a Vnet rule to whitelist the traffic from the subnet of our source machines on the storage account firewall settings.

Thanks all for your attention to this.
Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator

2025-11-26T18:50:32.6166667+00:00
Hello @Apurva Pathak,

Thanks for your patience. The 403 error happens because both your VM/Load Balancer and Storage account are in the same Azure region (UK West). Traffic between them stays on Microsoft’s internal network instead of going out to the public internet. Azure Storage then sees only the private IP of your VM or firewall, so the public IP allow-list doesn’t work and access is blocked.

Two ways to fix this:

Option 1 – Private connectivity (recommended for security)

Create a Private Endpoint to the Storage account, or

Add a Virtual Network rule on the Storage firewall to allow the subnet that hosts your VM/firewall. Result: Storage will continue to log private IPs, and access will be controlled by VNet/subnet rules instead of public IP allow‑lists.

Azure Storage Account access logs CallerIpAddress is showing Private IP Address - Microsoft Q&A

Option 2 – Public egress with IP allow‑listing

Ensure there are no Service/Private Endpoints or routes forcing Storage traffic over private paths for this scenario.learn.microsoft

Attach an Azure NAT Gateway to the VM subnet (recommended over relying solely on Standard Load Balancer outbound) so traffic is SNATed to a dedicated, consistent public IP.

Your PRE environment likely uses NAT Gateway or no private route, which is why it works. For PROD, compare endpoint types, DNS, routing, and outbound IP setups.

References to help:

Azure Storage firewall rules | Microsoft Learn

Use private endpoints - Azure Storage | Microsoft Learn

Frequently asked questions - Azure Load Balancer | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

1 answer

Your answer

Adam Zachary 2,025 Reputation points

2025-11-24T21:02:48.1833333+00:00

I’ve seen this before, and nothing is wrong with your logs. Azure shows the private IP because your VM is not actually reaching the storage account through the public internet. It is staying on the Azure backbone, so the storage account only sees the private source IP and blocks it.

To fix it, the traffic must really go out through a device that performs public SNAT. In other words, force the VM’s traffic through a firewall or NAT gateway that uses a true public IP, and make sure that device is actually translating the source address.

Once the traffic leaves the VNet with the real public IP, the storage account will see it correctly and your allow list will work.
Apurva Pathak 845 Reputation points

2025-11-25T06:51:26.5733333+00:00

Hi @Adam Zachary ,

The traffic is flowing through a Standard Public LB via Outbound rule, and this is one of the recommended ways of MS to achieve outbound connectivity. Also, the destination is in different Azure tenant, and it resolves with a Public IP.

Pre server of the same environments works perfectly fine, issue is only with the Prod box.

Any further suggestions on this would be very helpful.
Apurva Pathak 845 Reputation points

2025-11-25T06:51:34.8133333+00:00

The traffic is flowing through a Standard Public LB via Outbound rule, and this is one of the recommended ways of MS to achieve outbound connectivity. Also, the destination is in different Azure tenant, and it resolves with a Public IP.

Pre server of the same environments works perfectly fine, issue is only with the Prod box.

Any further suggestions on this would be very helpful.
Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator

2025-11-25T20:11:00.82+00:00

Hello @Apurva Pathak,

Thanks for sharing the detailed steps. The issue you’re seeing happens because when Azure Storage traffic goes over Azure’s private backbone (using Service or Private Endpoints, or when outbound SNAT to a public IP doesn’t occur), Storage logs the VM’s or firewall’s private IP. This causes public IP allow-listing to fail, resulting in the 403 error.

To fix this and have Azure Storage recognize your public IP for allow-listing, please:

Ensure outbound traffic from your VM/firewall is NATed to your dedicated public IP. Using an Azure NAT Gateway is recommended for consistent egress IPs over Standard Load Balancer rules.

Remove any Service Endpoint or Private Endpoint on your subnet directing storage traffic privately so it goes through the public internet.

Confirm DNS for your storage endpoint resolves to the public Azure blob service by running:

nslookup <yourstorageaccount>.blob.core.windows.net

Verify your VM’s effective public IP matches the IP allow-listed on your Storage firewall by running:

curl https://api.ipify.org

If you prefer private connectivity with Private Endpoints, then use VNet and subnet rules for allow-listing instead of public IPs. In that case, Azure Storage will always log the private IP.

I’m happy to help compare your PROD and PRE environment setups such as NAT Gateway vs Standard Load Balancer, DNS, and routing to find why PROD behaves differently.

Helpful references:

Private DNS and Private Endpoint setup: Azure Private Endpoint private DNS zone values | Microsoft Learn

Using Private Endpoints with Storage: Use private endpoints - Azure Storage | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.
Apurva Pathak 845 Reputation points

2025-11-26T07:43:42.1133333+00:00

I’ve got the root cause of it, we are hitting an Azure limitation, below are detailed analysis and possible ways to fix it.

Infrastructure overview (for non-working VMs):

Default Outbound connection (No Firewall involved):

VM Region: UK West

Connection forced via Firewall (routed through Azure Public LB)

VM Region: UK West

Firewall Region: UK West

Root cause: When the source Azure resource (Load Balancers, VMs) is deployed in the same region as destination Azure Storage account, the connection from source to the storage account doesn’t go via public internet even if we have dedicated Public IPs assigned to Load Balancers. It travels on MS backbone and that’s why Azure only gets the private IP of the resources.

MS Doc: Frequently asked questions - Azure Load Balancer | Microsoft Learn

Possible solutions: Since, we cannot whitelist the Private IPs over storage account network settings due to limitations with IP rules (refer here), we will either have to

Deploy a Private Endpoint connection to this storage account.

Create a Vnet rule to whitelist the traffic from the subnet of our source machines on the storage account firewall settings.

Thanks all for your attention to this.
Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator

2025-11-26T18:50:32.6166667+00:00

Hello @Apurva Pathak,

Thanks for your patience. The 403 error happens because both your VM/Load Balancer and Storage account are in the same Azure region (UK West). Traffic between them stays on Microsoft’s internal network instead of going out to the public internet. Azure Storage then sees only the private IP of your VM or firewall, so the public IP allow-list doesn’t work and access is blocked.

Two ways to fix this:

Option 1 – Private connectivity (recommended for security)

Create a Private Endpoint to the Storage account, or

Add a Virtual Network rule on the Storage firewall to allow the subnet that hosts your VM/firewall. Result: Storage will continue to log private IPs, and access will be controlled by VNet/subnet rules instead of public IP allow‑lists.

Azure Storage Account access logs CallerIpAddress is showing Private IP Address - Microsoft Q&A

Option 2 – Public egress with IP allow‑listing

Ensure there are no Service/Private Endpoints or routes forcing Storage traffic over private paths for this scenario.learn.microsoft

Attach an Azure NAT Gateway to the VM subnet (recommended over relying solely on Standard Load Balancer outbound) so traffic is SNATed to a dedicated, consistent public IP.

Your PRE environment likely uses NAT Gateway or no private route, which is why it works. For PROD, compare endpoint types, DNS, routing, and outbound IP setups.

References to help:

Azure Storage firewall rules | Microsoft Learn

Use private endpoints - Azure Storage | Microsoft Learn

Frequently asked questions - Azure Load Balancer | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Answer 1

Hello Apurva Pathak,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure Storage Account access logs CallerIpAddress is showing Private IP Address.

This happens because when you use Service Endpoints or Private Endpoints, traffic flows through Azure’s internal backbone network, and the storage service logs the VM’s private IP by design. Therefore, even if you whitelist the public IP, the request will still be blocked since the logged source remains private.

To resolve this and ensure the storage account recognizes the public IP, the most reliable approach is to route traffic through a NAT Gateway or Azure Firewall with SNAT enabled. This forces outbound traffic to use a designated public IP, which will appear in the logs and align with firewall rules. If you prefer to maintain private connectivity for security reasons, you should avoid relying on public IP-based firewall rules and instead configure Virtual Network rules or Private Endpoints with Private DNS zones. These methods are documented here: Azure NAT Gateway, Private Endpoint and DNS, and Storage Firewall and VNet rules.

Finally, if your compliance or monitoring requirements demand public IP logging, you must disable Service Endpoints and Private Endpoints and allow public network access through a controlled NAT Gateway. Alternatively, for hybrid setups, use Azure Firewall or Application Gateway to manage SNAT and enforce outbound traffic policies. This ensures accurate CallerIpAddress logging while maintaining security. For implementation, see these docs on Configure NAT Gateway for subnets and Azure Firewall SNAT.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Share via

Azure Storage Account access logs CallerIpAddress is showing Private IP Address

1 answer

Your answer