none
VNet Integration (preview) and Service Endpoints not working RRS feed

  • Question

  • Hi,

    We're looking at the VNet Integration for Windows Web Apps which is currently in preview which I believe is supposed to add support for Service Endpoints.  We have been trying this out with a Windows App Service and a SQL Azure database, but are unable to get this to work.

    Our setup has been performed as follows:

    1. Created a VNet and subnet within this.
    2. Enabled the Microsoft.SQL service endpoint for this subnet.
    3. Added the virtual network using the subnet defined previously to the firewall configuration for the SQL Azure server.
    4. Added the VNet Integration to the web app using the subnet defined previously.

    Our expectation is that this would allow connectivity from the app service to the database via a private IP address defined within the subnet.

    Unfortunately this does not appear to be the case, and we are receiving the following error:

    com.microsoft.sqlserver.jdbc.SQLServerException: Cannot open server 'dude-vnet-uks-poc' requested by the login. Client with IP address '51.140.159.132' is not allowed to access the server.  To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range.  It may take up to five minutes for this change to take effect.

    This still appears to be using the outgoing public IP address for the app service, shouldn't this be using the private IP address from the subnet?

    I cannot create the connection to the database unless I either explicitly add the public IP address to the SQL Server firewall, or enable the "Allows access to Azure services" option, which defeats the point.

    I did note the following from the documentation:

    "A Web App can be mapped to a private IP in a VNet/subnet. Even if service endpoints are turned ON from the given VNet/subnet, connections from the Web App to the server will have an Azure public IP source, not a VNet/subnet source. To enable connectivity from a Web App to a server that has VNet firewall rules, you must Allow Azure services to access server on the server."

    https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview#limitations

    However, I was assuming this was for the old gateway VNet integration, rather than the new regional VNet integration.  If this is true, it makes the service endpoints redundant.

    Is there anything additional that I need to do to get this to work?

    Cheers,

    Mark

    Thursday, August 15, 2019 3:38 PM

Answers

  • Got to the bottom of this.

    My original test was just a simple Java command line tool running from Kudu to test the database connectivity.  When this was run, it was still using the app service public outbound IP address and therefore the connection was refused.

    Turns out that the database connection has to be made from a web app.  When I created a simple test web app and deployed this with Tomcat, everything worked correctly and the database connection was originating from a private IP address within the subnet.

    Seems a bit odd, but I guess this is just how it works.

    Cheers,

    Mark

    • Marked as answer by MarkBowler Wednesday, August 28, 2019 10:01 AM
    Wednesday, August 28, 2019 10:01 AM

All replies

  • Microsoft support have confirmed that the "Allow access to Azure services" option in the SQL Azure firewall isn't required when using the regional VNet integration.

    We've also confirmed that the VNet integration does appear to be working, as I can ping a VM provisioned within the same VNet.  The issue appears to be that the service endpoint isn't work.

    Friday, August 16, 2019 1:40 PM
  • Are you able to ping dude-vnet-uks-poc database from the kudu console of your app service? See https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#troubleshooting.

    Thanks in advance, Ryan

    Friday, August 16, 2019 9:17 PM
    Moderator
  • Yes, but you can do that regardless of whether the SQL firewall is configured to allow access or block access.  I believe that running a tcpping against the database server on port 1433 is just testing the connection to the Azure SQL gateway, rather than against the server itself, and therefore always succeeds.

    Cheers,

    Mark

    Friday, August 16, 2019 9:23 PM
  • Got to the bottom of this.

    My original test was just a simple Java command line tool running from Kudu to test the database connectivity.  When this was run, it was still using the app service public outbound IP address and therefore the connection was refused.

    Turns out that the database connection has to be made from a web app.  When I created a simple test web app and deployed this with Tomcat, everything worked correctly and the database connection was originating from a private IP address within the subnet.

    Seems a bit odd, but I guess this is just how it works.

    Cheers,

    Mark

    • Marked as answer by MarkBowler Wednesday, August 28, 2019 10:01 AM
    Wednesday, August 28, 2019 10:01 AM