0

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

Daniel
  • 73
  • 2
  • 7
  • You should try to understand why you have SNAT port exhaustion first. Which language / technology are you using ? C# dotnet offer `HttpClientFactory` that should be use to create HttpClient. It manages the connections for you and most of time will prevent SNAT port exhaustion. – Thomas May 27 '22 at 02:05
  • Hi, it's .net core 2 c#. The http requests are primarily made from a nuget package not code we've written. Our custom code uses addHttpClient. We've decompiled the nuget package that makes the requests and it appears to be using DI to get a HttpClient... Are SNAT port exhaustions impossible if using HttpClientFactory? If so maybe we should examine the decompiled code... – Daniel May 27 '22 at 02:14
  • using httpclientfactory, it will reuse existing connection so in most case it should be fine. – Thomas May 27 '22 at 02:22
  • I think you read that already: https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-intermittent-outbound-connection-errors. There is a section related to connection pooling. that would be my first try before changing the infrastructure – Thomas May 27 '22 at 02:30
  • Yea I read that page a few times. It's where I saw "service endpoint" and "regional vnet integration". I'll try reading more about connection pooling but as this is a third party package and decompiling seems to suggest it's using HttpClientFactory I'm not very hopeful it will help. – Daniel May 27 '22 at 02:44
  • Because you want your app services to remain public, you cannot use private endpoints or service endpoints. You should use vnet integration if connection pooling doesn't solve your problem. I would suggest you read this post about the differences in networking options for app services: https://stackoverflow.com/questions/68200096/connecting-two-app-services-within-the-same-vnet/73759580#73759580 – Cloudkollektiv Sep 18 '22 at 14:36

2 Answers2

0

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?

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:

enter image description here

For more information please refer the below links:-

AjayKumarGhose
  • 4,257
  • 2
  • 4
  • 15
0

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:

  1. Connection pools: By pooling your connections, you avoid opening new network connections for calls to the same address and port.

  2. Service endpoints: You don't have a SNAT port restriction to the services secured with service endpoints.

  3. Private endpoints: You don't have a SNAT port restriction to services secured with private endpoints.

  4. 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):

  1. 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.

  2. In your situation you want the app service to remain public, so using service endpoints is not an option.

  3. In your situation you want the app service to remain public, so using private endpoints is also not an option.

  4. 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:

    • Create a vnet with some subnets.
    • The subnet used for the vnet integration should be dedicated.
    • The subnet used for the azure firewall should also be dedicated.
    • Create an azure firewall.
    • Create route tables and an NSG if applicable.
    • Enable vnet integration with the vnet "route all" option.
Cloudkollektiv
  • 11,852
  • 3
  • 44
  • 71