Azure App Service suddenly uses a new IP for the database connection that does not appear in the list of IPs

Question

We use an Azure App Service that connects to a PostgreSQL database on Azure. For this we have entered the IP of the app service in the firewall rules of the DB server. This has always worked so far. But since today we get the following error message:

28000: no pg_hba.conf entry for host "xx.xx.xx.xx", user "xx", database "xx", SSL on

The app has not been running since then. The IP mentioned in the error message is NOT listed in the App Service IP list. But if I enter the IP in the firewall rules of the DB server, I can start the app again without errors.

Why has the IP changed and why can't I find it among the App Server IPs? This worries me, I am afraid that it could be a hacking attack and the requests are now routed through a proxy or something.

Answer 1

@Wolfgang Roese We understand that you have started to encounter errors regarding your App Service and PostgreSQL DB.

You mention that you added an IP address to your DB firewall but in reality, you need to add many IP addresses to your outbound firewall. I am left to assume that the IP address that you added is what's called as the virtual IP address (inbound IP address). What you need to add though is the list of outbound IP addresses. All of the listed IPs need to be added as traffic can come from any of them. To find these please:

1. Go to your web app in the Azure portal.
2. Select settings> and then select the configuration blade.
3. Here you will see a list of IP addresses called outbound IP addresses. You will need to add all of these IP addresses to your DB firewall.
4. You may also want to add the list of "additional outbound IP addresses" to your DB firewall listed if you feel you meet any of these scenarios talked about here.

For future reference the virtual IP address is also known as the inbound IP address. This is what you would use for an A record for your DNS or if your app's code requires you to hard code an IP address (not a best practice but sometimes required for legacy apps).