I am working on an Azure App Service API using ASP.NET Core 3.1 and Entity Framework Core 3.1
I currently have a database connection to an Azure SQL server instance working just fine. Now I need to add an additional database connection to a local on-prem SQL Server, so I have set up an Azure Hybrid Connection in my portal and I have installed the Hybrid Connection Manager on my local on-prem Windows Server 2019 with SQL Server 2017. The Hybrid Connection Manager on the on-prem server and the Azure Hybrid Connections screen both show "Connected". However, I get the following error when debugging my app service:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - No such host is known.)
I have read through many posts on this subject where people seem to be having a similar issue and they talk about using an FQDN for the host name, which I assume they are referring to the "Endpoint Host" property of the Hybrid Connection in Azure.
I am a little confused about the FQDN as they seem to imply in the posts I have read that the FQDN needs to be resolvable on the Internet DNS and that is why I am getting the "No such host is known" error.
However, I thought the point of the Hybrid Connection in Azure was to allow access to an on-prem (as in not publicly accessible) database. I do not have a host name registered in my ISP's DNS for my on-prem SQL Server. Do I actually need to do that?
For example, if my public domain name is "mycompany-online.com" but my internal domain name of my Windows domain is mycompany.local, and the Windows Server 2019 host name on my local network is called "DEV-SQLSVR-1", should my "Endpoint Host" name be "DEV-SQLSVR-1.mycompany.local", "DEV-SQLSVR-1.mycompany-online.com" (assuming I somehow register DEV-SQLSVR-1 as a host name or CNAME in my public DNS. See Note 1), or just "DEV-SQLSVR-1"?
Note 1: Do I actually need to register the host name "DEV-SQLSVR-1" with my ISP DNS pointing to... what exactly, since I do not really want my on-prem SQL server to be public facing?
Also, what should the connection string look like in ASP.NET Core 3.1? Currently, I have the following in my appsettings.json;
"ConnectionStrings": {
"HcConnectionString": "Server=dev-sqlsvr-1,1433;Initial Catalog=MyDb;Persist Security Info=False;User ID=XXXX;Password=XXXX;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=True;Connection Timeout=30;"
}
And for the record, I disconnected the Hybrid Connection to the DEV-SQLSVR-1 Endpoint Host and deleted it from the configuration file on the server hosting the Hybrid Connection Manager. Then I set up a new Hybrid Connection using the DEV-SQLSVR-1.mycompany.local instead of DEV-SQLSVR-1, thinking that is what was needed for the FQDN. I then edited my connection string to use "dev-sqlsvr-1.mycompany.local" rather than just "dev-sqlsvr-1". Even though it also shows the new Hybrid Connection as "connected" on both the Hybrid Connection Manager on the local server and in the Hybrid Connections in Azure, I still get the same error when trying to debug the API in Visual Studio 2019.
Some additional detail;
#1: In my App Service API --> Startup.cs --> ConfigureServices method, I am using the following to set up the EF Core DbContext for the SQL Server Connection that uses the Hybrid Connection:
services.AddDbContext<HcContext>(options =>
{
options.UseSqlServer(
Configuration.GetConnectionString("HcConnectionString"));
});
#2: My local SQL instance is called "SQL Server (MSSQLSERVER), if that actually matters.
#3: I can access the SQL Server using Sql Server Management Studio from my DEV workstation while connected to the local network and while connected remotely using a VPN so I know at least the firewall properties on the local SQL Server are working.
[UPDATE 1] Just an FYI: If I connect my DEV workstation over a VPN to the network with the SQL Server and run the API locally in Visual Studio, using the exact same connection string, it works fine. So I know the issue is not with the SQL Server / API code.
What am I missing here?