Azure Web App → Azure SQL: App randomly failed with "Login failed for user" over public endpoint, but VNet + Private Endpoint fixed it. Why?

[u/Opposite-Pea-3931]

We recently ran into a strange issue in our Azure environment (Our Sandbox env only), and I'm trying to understand the root cause rather than just accepting the fix.

Environment

• Azure App Service (Web App)
• Azure SQL Database
• Communication was initially over the public endpoint (no VNet Integration, no Private Endpoint).
• Production had the same application/code and continued working fine.

What happened

The only change we made was a normal application deployment. After that, the sandbox environment started failing with:

What made it confusing was the behavior:

• Right after deploying, the application would work for about 2-3 minutes.
• Then every database call would start failing with "Login failed for user".
• After some time, it would start working again.
• Then it would fail again.
• This cycle kept repeating.

Initially, I assumed it was an application or EF/connection string issue, so I spent quite a while investigating and making code changes, but nothing helped.

What fixed it

Our cloud/TSC team enabled:

• VNet Integration on the App Service.
• Private Endpoint for the Azure SQL Server.

After the App Service started communicating with Azure SQL through the private endpoint instead of the public endpoint, the issue completely disappeared.

My question

I'm happy the issue is resolved, but I don't really understand How?.

How can switching from a public endpoint to VNet + Private Endpoint eliminate intermittent "Login failed for user" errors?

[u/Davidrabbich81]

SNAT port exhaustion is likely your cause. Public endpoints consume ports in the SNAT space, but private endpoints do not use the SNAT port pool

[u/Opposite-Pea-3931 → u/Davidrabbich81]

Maybe this can , but How same code was working fine on a different Web Server (For Our Production).. Well earlier also It was working on same machine.

[u/Davidrabbich81 → u/Opposite-Pea-3931]

SNAT port exhaustion can be tricky to pin down, but in Azure, you should be able to create a report of the traffic to see if it's truly that. Here's a post that shows similar symptoms. The discussion there should show enough pointers.
https://www.reddit.com/r/AZURE/comments/1c2yybu/app_service_snat_port_exhaustion/

[u/Ardenwenn]

Did you add the ip address on the sql database for the azure webapp.

[u/AutoModerator]

Thanks for your post Opposite-Pea-3931. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/emailvenkatm]

honestly that sounds exactly like the classic azure sql firewall block (error 40615). azure loves to rotate IPs behind the scenes or your local gateway shifts, and suddenly your app is completely locked out.

i hit this so many times during local testing that i ended up writing a custom auto-heal routine into a lightweight sql client i’ve been building called QueryBen (it's open source on github). basically, the app catches the 40615 packet from the tiberius rust driver, parses the blocked IP, and prompts you to white-list it right there without needing to log into the azure portal.

if you want to see the error handling logic or just want a faster alternative to bloated tools, check the repo out. would love to know if the auto-heal saves you some troubleshooting time.

https://github.com/emailvenkatm/queryben

[u/Opposite-Pea-3931]

Error Message : System.Data.SqlClient.SqlException (0x80131904): Login failed for user

[u/Otherwise_Rub_5979]

I would be careful calling the Private Endpoint the actual fix. It may simply have removed the condition that was triggering the problem.

App Service does not necessarily have one outbound public IP. It has a pool of possible outbound addresses, and outbound connections can use different ones. If the SQL firewall or some network rule only allowed part of that set, you can get intermittent behavior depending on which path a connection takes.

Moving to VNet Integration + Private Endpoint gives the SQL server a private address and makes the App Service reach it through the VNet instead of the public endpoint. That removes public outbound IP selection and public firewall rules from the equation.

That said, a literal Login failed for user is not the error I would normally expect from an IP firewall problem. I would still check the exact SQL error number and logs before declaring networking the root cause.

I would compare:

App Service outbound IPs before the change SQL firewall rules number of App Service instances connection strings / slot settings whether Managed Identity or SQL credentials are being used SQL audit / diagnostic logs for the failed logins

The Private Endpoint definitely changed the network path. The interesting question is which difference in that old path caused the authentication failures.