How to send HTTP request from one App Service to another using its VNet internal address?

Question

Dear Community!

How to send HTTP request from one App Service to another using its VNet internal address?
I would like to get help in the following scenario.

I have two App Services:

• srvc1
• srvc2

srvc1 must be publicly accessible on the internet

I configured VNet integration for both services to the same VNet/subnbet:

• mySubnet

srvc1 sends HTTP requests to srvc2 with its 'azurewebsites.net' address.

Assumption:

My assumption was, that if I configure Access Restriction for srvc2 and allow only mySubnet IP range, the case will be solved because the routing will resolve srvc2 VNet address thus the services will communicate on the VNet.

However I got error: HTTP 403 forbidden when sending HTTP request.

What else did I try?

Outbound addresses:

I added an allow rule for srvc1 Outbound Addresses to Access Restriction. The HTTP 403 error persists.

I found the outbound addresses on the Portal > Networking (preview) tab.

Private IP:

I checked the WEBSITE_PRIVATE_IP of srvc2, and try to access it from srvc1 with its WEBSITE_PRIVATE_IP to send HTTP request, I got error: connection refused (ECONNREFUSED)

I know this address would change, just wanted to try if it works.

Thanks for your help in advance,

(this is my very first question so feel free to request any further info)

Kind regards,

Peter

Answer 1

@Péter Cataño I was able to setup a test scenario where my srvc1 was open to the internet and my srvc2 was blocked from the internet without blocking communication between srvc 1 and srvc 2.

To do so, I set two access restrictions on srvc 2 via the networking blade.

1. I did a IPv4 block on the CIDR range 0.0.0.0/32, which blocks access to the internet
2. I did an allow of the virtual network/subnet of the subnet that srvc1 is connected to.

Can you please try this configuration and let us know the outcome?

Please note that sometimes it can take a few minutes for the access restrictions to take effect. While not necessary, I personally find restarting the web app to help speed up the sync, which can be a small time saver during testing.