I have two completely separate tenants/subscriptions. Tenant A has a Web App, within a VNET in 10.0.50.0/24 and renders details about table storage. Tenant B has an Azure Storage resource /w Table storage. I want to connect the Web App to the table storage. Easy enough to grab the connection string. However I want to lock down the storage resource so that only a specific IP can access it. I do the following: Tenant A I add a NAT Gateway, and standard Public IP as its sole outgoing IP, and associate it to my 10.0.50.0/24 subnet. I configure the web app gateway integration to 'route all' I validate NAT Gateway is using the new PIP via console and ipify (all checks out!) Tenant B I swap storage from 'All Networks' to 'Selected Networks' I whitelist the PIP used in tenant A. When complete, Tenant A cannot access the table storage anymore. I added diagnostic logs, and the Tenant B storage doesn't see the public IP, but rather the Tenant A subnet IP (i.e. 10.0.50.253) as the callerIpAddress. Why is this? Private IP's cannot be whitelisted. Why am I not seeing the public IP? I've looked into internet routing vs Microsoft routing but from what I read this is unrelated to the issue. Public IPs with internet routing cannot be associated to NAT anyway and table storage doesnt allow for a route specific endpoint anyway. Thanks!

@Mike M Greetings. This should be an expected behavior, see : Grant access from a virtual network . However, this shouldn't be an issue as long as you can request TenantB Storage Account to add the VNET/Subnet from TenantA. This is doable via CLI or Powershell but not from Portal as of now. See : Managing virtual network rules . In step 4, This in fact provides an increased security as Traffic always stays in the MS backbone, even the ones between TenantA and TenantB. Hope this helps. Cheers, Kapil

Azure Storage showing incoming IP as subnet IP instead of NAT Public IP

Mike M 20

I have two completely separate tenants/subscriptions.

Tenant A has a Web App, within a VNET in 10.0.50.0/24 and renders details about table storage.
Tenant B has an Azure Storage resource /w Table storage.

I want to connect the Web App to the table storage. Easy enough to grab the connection string. However I want to lock down the storage resource so that only a specific IP can access it. I do the following:

Tenant A
1. I add a NAT Gateway, and standard Public IP as its sole outgoing IP, and associate it to my 10.0.50.0/24 subnet.
  1. I configure the web app gateway integration to 'route all'
    1. I validate NAT Gateway is using the new PIP via console and ipify (all checks out!)
Tenant B
1. I swap storage from 'All Networks' to 'Selected Networks'
  1. I whitelist the PIP used in tenant A.

When complete, Tenant A cannot access the table storage anymore. I added diagnostic logs, and the Tenant B storage doesn't see the public IP, but rather the Tenant A subnet IP (i.e. 10.0.50.253) as the callerIpAddress.

Why is this? Private IP's cannot be whitelisted. Why am I not seeing the public IP?

I've looked into internet routing vs Microsoft routing but from what I read this is unrelated to the issue. Public IPs with internet routing cannot be associated to NAT anyway and table storage doesnt allow for a route specific endpoint anyway.

Thanks!

Adam Zachary 2,911 Reputation points

2023-11-22T22:48:06.7233333+00:00

Hi Mike,

Your issue with Azure Storage showing the subnet IP instead of the NAT public IP when trying to connect from Tenant A (with a web app in a VNET) to Tenant B's Azure Storage resource seems to be related to how Azure handles NAT gateways and IP network rules.

NAT Gateway Behavior: The NAT gateway in Azure is designed for outbound connectivity from a virtual network. It does not facilitate inbound traffic directly from the internet through the NAT gateway. This is important because it suggests that the NAT gateway's public IP is used for outbound connections, but it does not influence the inbound traffic's identification, which could be why the Azure Storage is recognizing the subnet IP.

Public IP of NAT Gateway and Private IP Communication: Azure's NAT gateway cannot connect directly to a private IP over the internet. This could be relevant if your setup is attempting to use the public IP of the NAT gateway to communicate directly with a private IP, which is not supported.

Azure Storage Network Rules: Azure Storage network rules apply only to public internet IP addresses, and IP address ranges reserved for private networks are not allowed in IP rules. This could be one reason why the Azure Storage resource is recognizing the subnet IP address, as it may be treating it as a private network address.

Restrictions on Same-region Requests: IP network rules in Azure Storage have no effect on requests originating from the same Azure region as the storage account. If your Tenant A and Tenant B are in the same Azure region, this could be why the IP network rules are not functioning as expected.

Given these points, the issue might be stemming from how Azure NAT gateway and Azure Storage network rules are designed to work. They do not support the direct connection from a public IP of a NAT gateway to a private IP, and IP network rules do not apply to private network addresses or to requests coming from the same Azure region.

To resolve this, you may need to adjust your network setup. For instance, ensuring that Tenant A's web app and Tenant B's Azure Storage are not in the same Azure region could help, as this would allow IP network rules to take effect. Additionally, you may need to review the configuration of your NAT gateway and subnet route table to ensure that outbound connections from Tenant A correctly utilize the NAT gateway's public IP.

Please review Microsoft documentation for Configuring Azure Storage FW and Virtual Networks

Kindly if you find the provided information helpful and it resolves your query, please consider accepting the answer. Your feedback is valuable and helps ensure the quality and relevance of the responses.
KapilAnanth-MSFT 47,046 Reputation points Microsoft Employee

2023-11-24T11:03:09.7366667+00:00
@Mike M

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

I understand that you are seeing the private IP of the VNET integrated WebApps in the logs of the Storage Account.

In the subnet of the VNET integrated WebApps,

Can you check if Microsoft.Storage Service EndPoint was enabled?

If so, can you please deselect it and give it a try?

See : How to check if Service EndPoint is enabled in a subnet?

Cheers,

Kapil
KapilAnanth-MSFT 47,046 Reputation points Microsoft Employee

2023-11-27T11:14:09.4566667+00:00

@Mike M

May I know if you got a chance to review my previous comment?

Please let me know if you are facing any challenges or if there are any follow-up questions, I shall be glad to address them.

Thanks,

Kapil
Mike M 20 Reputation points

2023-11-27T14:28:06.71+00:00

@Anonymous I reviewed much of the link provided however I can't find much that directly targets this issue. Having different regions may work however it would not fit into our goals. Regardless, I have attempted this and the same issue resides.

@KapilAnanth-MSFT I do have Microsoft.Storage Service EndPoint enabled on Tenant A as the web app communicates with its own storage account to function. Let me review this and I will get back to you. I'm not sure if removing this would be something we'd want to do, as we want communication to stay on the backbone for our (Tenant A) services.
TP 98,176 Reputation points

2023-11-27T15:17:35.38+00:00

Hi Mike. One option to consider is to set up a private endpoint to the table storage in tenant B along with DNS entry pointing to it so that tenant A would reach it that way instead. If you need more details let me know.
Mike M 20 Reputation points

2023-11-27T15:43:24.75+00:00

@KapilAnanth-MSFT Just confirming, it is the service endpoint translating the IP to be private (NAT outbound PIP used once off). Not sure if keeping this disabled is ideal however, I will keep looking into solutions while keeping Tenant A internal routing for storage.

TP I will give this an attempt!
Mike M 20 Reputation points

2023-11-27T21:22:53.8333333+00:00

As well, thanks TP I looked into private endpoint/private link but this process would be too cumbersome to fit into how we are building things out

Accepted answer

KapilAnanth-MSFT 47,046 Reputation points Microsoft Employee

2023-11-27T15:51:57.1866667+00:00
@Mike M

Greetings.

This should be an expected behavior, see : Grant access from a virtual network.

However, this shouldn't be an issue as long as you can request TenantB Storage Account to add the VNET/Subnet from TenantA.

This is doable via CLI or Powershell but not from Portal as of now.

See : Managing virtual network rules.

In step 4,

This in fact provides an increased security as Traffic always stays in the MS backbone, even the ones between TenantA and TenantB.

Hope this helps.

Cheers,

Kapil
Please sign in to rate this answer.

1 person found this answer helpful.
Mike M 20 Reputation points

2023-11-27T15:56:59.9+00:00

@KapilAnanth-MSFT this might be exactly what I'm looking for. I will review and get back to you!

Mike M 20 Reputation points

2023-11-27T20:10:55.4133333+00:00

Thanks @KapilAnanth-MSFT !! This is a solution to the issue, despite the original problem being with incoming IP the broader issue was ensuring security lockdown and this achieves the goal.

Are you able to convert your response to an answer so I can close this out?

Also -- This is beyond the scope of the original question, but can you confirm this approach would not work with Cosmos/SQL? I was hoping the solution could expand to cover those services, however it seems like Azure only supports remote VNET with Azure Storage, whereas Cosmos/SQL remote vnet fails with 'not authorized' and would require roles added to Tenant A from Tenant B. I may leave it at this for now and come back to this later on.

KapilAnanth-MSFT 47,046 Reputation points Microsoft Employee

2023-11-28T06:37:13.83+00:00

@Mike M

I am glad the issue has been resolved now.

Yes, as of now, Cosmos and Azure SQL do not support cross tenant service endPoints (they should support same tenant VNETs as long as you have the required roles in those VNET or VNET's subscription)

See: Use virtual network service endpoints Azure SQL Database

In some cases, the database in SQL Database and the virtual network subnet are in different subscriptions. In these cases, you must ensure the following configurations:

Both subscriptions must be in the same Microsoft Entra tenant.

The user has the required permissions to initiate operations, such as enabling service endpoints and adding a virtual network subnet to the given server.

Both subscriptions must have the Microsoft.Sql provider registered.

P.S : Microsoft.DocumentDB resource provider for Cosmos.

In cases with Cross-Tenant like yours, I would suggest you use Private EndPoints to secure the traffic.

Cheers,

Kapil.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure Storage showing incoming IP as subnet IP instead of NAT Public IP

0 additional answers

Your answer