I’m not an expert on SQL Server and currently working on a specific setup but encountering issues while trying to connect to a SQL Server running on an EC2 instance (in a private subnet) from Windows Subsystem for Linux (WSL) using Boundary. My setup includes Boundary deployed on AWS EKS with both a controller and a worker. The goal is to establish a connection to a SQL Server instance.
Here’s what I’ve confirmed so far:
The security groups are configured to allow inbound access on port 1433.
SQL server ports are open on 1433.
I am able to RDP into the same instance using a different Boundary target setup with port 3389 with no issues.
However, when trying to connect to the SQL Server using boundary connect from WSL, I receive the following errors:
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: Error code 0x2749.
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to {hostname}. Server is not found or not accessible.
To connect to the database, I used the following command:
I’m looking for guidance or suggestions on what might be causing these errors and how to resolve them. Any advice on additional configurations or troubleshooting steps would be greatly appreciated.
What server address is sqlcmd trying to connect to? Are you passing it the port number being set up by the Boundary proxy or is it trying to connect to the default port of 1433?
Hi there,
Have you perhaps tried connecting directly from the Windows OS to see if that can successfully connect. For example, the Boundary desktop client? In case this is successful then WSL is a potential issue that could be looked at next.
One question, the working target test using RDP, was that done from the WSL Linux instance as well?
Keep in mind, WSL is just a lightweight virtual machine running on your Windows host. To connect to WSL remotely you can either use the Windows host as a jump box, and run either some CLI or SQL Management Studio on the Windows host, or you will need to set up some additional port forwarding to get to the WSL VM.
As @omkensey pointed out, you’re not telling sqlcmd where to connect, and if you haven’t also set a default client port on the target, even if sqlcmd tries connecting to localhost when not given an address, sqlcmd will be trying to connect to 1443 but you won’t be listening on that port.
You could use -listen-port=1443 in the boundary connect call, also assuming sqlcmd does default to connecting to localhost. You may also want to try not using -exec to start out with, and manually connecting sqlcmd to the output address from boundary connect to ensure that works; once it does, you can use -exec with the templating options to give sqlcmd a valid address to connect to.