I’m having a very specific issue with Azure and I couldn’t find any solution on the web.
So, we are little by little migrating our client’s infrastructure to Azure and we are starting with our Workers (webjobs).
These webjobs need to consume data present on a AWS SQL Server instance.
We already have checked that the App Service Plan’s Outbound IPs are whitelisted and that the SQL server is listening on TCP port 1433.
An evidence of that is the fact that we are able to communicate with the SQL Server instance through the Azure Debug Console:
But when we run the WebApp, the worker cannot find and connect to the same DB:
Does anyone have a clue of how I can solve this issue? It would be very appreciated!
Well, as you demonstrated by the first image, the SQL Server instance is configured correctly.
The worker Outbound IP address is definetely the same as the App Service Plan's machine.
Based on that, can you then please check if the Connection string you are setting have 'tcp:' before the IP Address?
Sometimes you need to force it, otherwise IIS can choose other ways to connect to your SQL server (like UDP for instance).
Related
I am on VPN and trying to connect Azure SQL server from SQL Management Studio
I get this popup, but IP on it keep changes.
Because of this, I see a lot of IP's getting added in Firewall settings of SQL Server in Azure portal
What is the solution here?
Is it expected behaviour?
I have the same environment that connect to the Azure SQL database via VPN connection. The client IP may changes every some days, I need to manually add the new IP to the firewall again manually. Just for now. I think that's caused by the VPN servers.Some suggestions are that keep your VPN address fixed. There isn't a good solution for now.
HTH.
Our infrastructure team has worked to configure a site-to-site Azure VPN connection between our Azure subscription and our on-prem firewall, essentially following these steps. To test this, we've created a simple Azure web app that makes a query against a SQL Server that is located on-prem behind the firewall.
This web app works locally with no issues. Furthermore, the same code and connection string, when compiled as a console application and run on an Azure virtual machine, works correctly as well. But when deployed to the web app in Azure, the connection to the SQL Server fails:
[Win32Exception (0x80004005): The wait operation timed out]
[SqlException (0x80131904): 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 - The wait operation
timed out.)]
Both the Azure VM and web app are configured to point to the Azure VNet. It seems like something is preventing the web app from communicating with the SQL Server on its default port (1433). If I open up the web app's debug console and do a tcpping at the SQL Server with the default port (80), it returns successfully. But a tcpping to port 1433 times out.
It doesn't appear that the Azure Network Security Group is blocking that port:
The only solutions I've found that are relevant to our specific setup basically boil down to "use Azure Hybrid Connections instead", which would not be our first choice.
After working with Microsoft's support, the following changes were made and the VNet integration is working now. I apologize for the lack of detail on some of these, but our infrastructure team did most of the troubleshooting. Hopefully, some of these items will help point someone else the direction of a solution for their setup:
Initially, the connection was being made through public internet and not the VNET Integration and VPN. We identified that the VNET integration was failing due to the tunnel type being used. Azure App Service has a requirement that the tunnel type is SSTP. Once we changed it and synced the network, we were able to tcpping the SQL Server through its private IP.
We noticed it had to allow on the on-premises Network the point-to-site address pool. As a workaround, we decided to use the New VNET Integration (Preview). We created an empty subnet and were able to use this new feature.
We noticed then the App Service was not using the custom DNS. To resolve this, we added the DNS on the Virtual Network and also in the App Settings ("WEBSITE_DNS_SERVER") for the web app.
I am working with azure based application. In which, I need to get connected with azure sql server. I had already configured firewall setting on azure portal for my IP address. But still even when I tried to get connected to azure sql server, it never gets connect at the very first time. When I try to connect it more than two times then it gets connected.
This problem is also with application level connectivity, when i try to run the application on visual studio same happens.
I had researched a lot regarding this specific problem but didn't get any solution yet. I always get network related error Error Code : 53.
Any help will be appreciated.
This looks a lot like a local network issue.
When your application is deployed onto an Azure resource (App service, VM, etc.) does it get a similar connection error?
Every Azure SQL Server has a firewall, you need to create a client IP rule but also to allow access to the Azure service.
I am new to workflow stake and don't have good knowledge in networking.
Can someone please tell me if I have an application server in DMZ which connects to SQL server instance which is not in DMZ, Is there any difference if i connect to SQL server or SQL Server instance. I am able to make connection to the SQL Server but once i try to try the instance it won't find the instance.
I.e. Can connect to sqlservername but not to sqlservername\instanename the error i am getting is the SQL Server instance can't be found. the instance is setup to allow remote connection. Hope my question make sense.
Regards
You can't connect to named instance? - as minimum you need to enable remote connections to this server from SSMS->Server->Properties->Connections or you can read, for example, this article for more information how to do that. And... be sure that Sql Server Browser service is started and feels good, because it's responsible for managing connections to named instances.
The main issue with DMZ in my experience is dealing with authentication. Domain users usually can't access DMZ so, services such as Analysis Services (known as Cubes) for example, which allow only windows authentication, will be not accessible from the application server without extra efforts, establishing for example, kerberos auth.
One of our partners recently reported that our software could not contact a remote instance of SQL Express until they started the RPC Locator and SQL Server Browser services. Where would I find a list of services that must be running, on both server and client, to enable remote access to SQL Express and/or SQL Server?
Sadly, the SQL Express documentation does not appear to include this detail.
SQL Express always installs as a named instance (servername\sqlexpress) and hence has a dynamic port assigned to it. The SQL Browser service is required for clients to locate the instance. Without the SQL browser, a client won't know what port the service is listening on.
Looking at my current installation of SQL Server, I have remote connections enabled and working and both RPC Locator and SQL Server Browser services are disabled on the machine.
The key is that you have to enable remote connections properly in the Surface Area Configuration Wizard.
I've experienced problems in the past running linked server queries if the MS DTC (Distributed Transaction Co-ordinator) service was not running
I don't know of any services that need to running on the client (unless they're application dependencies), but for the server, this KB article explains how to enable remote connections to SQL Server: http://support.microsoft.com/kb/914277.
By default, SQL Express is configured to only allow local connections. The gist of the article is: use the Surface Area Configuration tool to tell the SQL service to listen on tcp/ip and/or named pipes; then enable the SQL Browser service (or don't, and use a specific port in your client connection); and finally, poke a hole in your firewall. Anecdotally, I think most people have the most trouble with the firewall exceptions.
I think the RPC Locator service is more of a general windows service for handling COM calls, so I'm not sure it's fair to characterize it as a SQL-specific requirement; your app may require it to connect, but I don't know that every app would (e.g. Mitchel says that his installation works fine w/out it).