Can anyone advise me on how to configure two app services on a vnet (or otherwise) so that app service ‘A’ can offer up a restful API and service ‘B’ call the API on A repeatedly without experiencing SNAT port exhaustion?
Our current set up is just 2 app services (one calling the other) without a vnet. Both are accessible publicly and I’d like to keep it this way 1) for debugging, and 2) as other servers may be connecting to server ‘A’. The problem is we’re seeing port exhaustion…
"Private endpoint" on server A and vnet integration on B seems easy enough to configure but this causes A to become unavailable over the internet.
I’ve tried fiddling with the subnets and service end points options in the virtual network to no avail. I’ve also tried the "endpoint service policy" feature but that only seems to let me select Microsoft Storage resources…
Any tips or advice would be gratefully appreciated.
Thank you
2
Answers
One of the workaround , you can follow
Please check if findings are correct:-
Two app services are communicated with via v-net integration and a private link. If you’re only going to use the v-net integration and not the private link. Then outbound requests are possible, but inbound requests are not. This is why apps are unable to communicate with one another.
Private Endpoint with VNet Integration:- Private Endpoint assigns a unique IP address to your app for inbound traffic exclusively. It prevents your app from making outgoing calls within your network. You must utilize both Private Endpoint and Regional VNet Integration on two separate subnets if you want to have all inbound and outbound traffic in your VNet. You can secure inbound traffic with Private Endpoint, and outbound traffic with VNet Integration.
Here is the workflow that how v-net integration working with app services:
For more information please refer the below links:-
SO THREAD|Azure App Service to App Service communication via Private Link & Connecting two App Services within the same VNet
MICROSOFT DOCUMENTATION|Using Private Endpoints for Azure Web App & Use IHttpClientFactory to implement resilient HTTP requests.
You are hitting a limitation of Azure app Services here. A public app service (with vnet integration) is only pre-allocated 128 SNAT ports. This may not be enough in certain scenarios. As described in detail here, this can be resolved by using:
Connection pools: By pooling your connections, you avoid opening new network connections for calls to the same address and port.
Service endpoints: You don’t have a SNAT port restriction to the services secured with service endpoints.
Private endpoints: You don’t have a SNAT port restriction to services secured with private endpoints.
NAT gateway: With a NAT gateway, you have 64k outbound SNAT ports that are usable by the resources sending traffic through it.
If I would apply those recommended solutions to your specific scenario, I think the only options are solution 1 (connection pooling) and 4 (azure firewall):
I would certainly recommend connection pooling. This is a minor change in the code running within your app service. If you are a senior programmer you might have already implemented this correctly.
In your situation you want the app service to remain public, so using service endpoints is not an option.
In your situation you want the app service to remain public, so using private endpoints is also not an option.
If connection pooling alone is not enough, then your only option is to implement a NAT gateway or Azure firewall. Azure firewall itself provides 2,496 SNAT ports (source) per public IP address configured. Azure firewall is pretty expensive, so keep that in mind. In short, you’ll have to do the following: