How do I test my VPN or TLS connection to the Vista Database? Is there a firewall blocking me?
Author: Eric Vasbinder
Contents
Overview
Once a TLS Database endpoint or an IPSEC VPN has been set up between your on-premise environment and your new Vista cloud environment, you should test that connection. In effect, you are testing to see if your local, on-premise systems such as Insight (Global) Spreadsheet Server, SSRS, and others can communicate to the Vista database in our cloud. To ensure this, you need to understand a little about how your Vista database communicates to other tools. Here are some key points:
Your Vista database runs on Microsoft SQL Server
Microsoft SQL server uses specific Internet communication channels (a.k.a ports) to communicate to other tools
The specific ports that SQL server uses are 1433 and 1434
If something is blocking port 1433 and 1434, you will be unable to communicate with Vista. Well, what can block those? A key item that many people forget about is that not only do you have to ensure that your TLS endpoint is set up on our end or that your VPN exists and is connected from on-premise to the cloud, you also have to ensure that no firewall rules are blocking your communications to Vista. In many cases, a firewall rule has to be opened to allow your tools on premise to communicate to Vista on the channels (ports) that the Vista database uses: port 1433 and port 1434.
Please note that if you are using the TLS Database Endpoint (TLS VPN), you WILL also need to open communications on the custom port used by the TLS Database Endpoint (TLS VPN).
See this page for a little more specific detail: Which firewall ports do I need to open on my end to allow us to "see" the Vista database hosted in your cloud?
Once the firewall ports are opened, what's next? ...Testing!
How Do I Test Connectivity to Vista Over Port 1433 and 1434?
Once you believe that you have opened the firewall to Vista on port 1433 and 1434, you need to test. The easiest way to test this connectivity from a Windows workstation is to use the PowerShell "Test-NetConnection" command. Another option is to try the "telnet" command to telnet to port 1433 and port 1434: this option works all modern workstation Operating Systems, including Windows, macOS, and Linux.
Using PowerShell to Test IPSEC VPNs
NOTE: This method is only applicable if you are running on a Windows 10+ workstation with PowerShell installed.
Open your PowerShell application by typing in "Powershell" in the taskbar's search box.
Type the following command (replace the z's with the IP address of your Vista server in the cloud if you are using the IPSEC VPN to connect, or the DNS name of your TLS Database Endpoint if you are using that method to connect): Test-NetConnection -ComputerName xxx.xxx.xxx.xxx -Port 1433
3. If the test is successful, you will see at the bottom of the results list, "TcpTestSucceeded : True". If the test fails, you will see "TcpTestSucceeded : False"
Using Telnet to Test IPSEC VPNs
From a Windows Workstation
Most of you are using Windows workstations to test and perform your operations - these are some good steps to test connectivity to Vista.
Open your Windows command prompt.
Click on the Search box in the lower-left hand part of the taskbar.
Type "CMD" into the search box.
When the Command Prompt appears, click on it to open your command prompt.
Use Telnet to Test
Once opened, type in the following command to test connectivity to Vista: TELNET <IPADDRESS> 1433
"<IPADDRESS>" should be replaced with the actual IP address of the Vista database, given to you by your transformation project manager.
NOTE: If you are running on a later version of Windows, the "TELNET" command may not be installed. In this situation, Windows will give an error about Telnet not being a recognized command.
If Telnet is NOT installed, please use the steps on this page to install Telnet on your Windows computer: https://www.sysprobs.com/install-and-enable-telnet-in-windows-8-use-as-telnet-client
OR (if you are not allowed to install Telnet on your local workstation)
You may download and use PUTTY without installing it (use the "standalone" .EXE file), a great third party Telnet application, for this test: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
Results of Testing via Telnet
If the connection is reachable via Telnet, you will see a blank screen.
If the connection is not reachable via Telnet, you will see an error similar to the below screenshot ("Could not open connection to the host"):
From a macOS System
On a Mac, you can install Telnet via Homebrew and test that way: https://osxdaily.com/2018/07/18/get-telnet-macos/
OR, you may use NetCat, which should already be installed on your Mac: https://www.igorkromin.net/index.php/2018/07/12/macos-has-a-much-better-tool-than-telnet-for-testing-remote-server-connectivity/
From a Linux System
Please ensure that you install netcat or the telnet client using your package manager, such as "yum" or "apt". Then use the command syntax listed in the links for macOS above to test connectivity to Vista's database.
Testing a TLS Database Endpoint (TLS VPN)
Testing of this connection should take place from the network behind the whitelisted IP, using a TCP connection to your custom cloud port. NOTE: This port is now always a random four digit port number, and is almost always NOT the standard port 1433.
Please replace the letters PPPP with the exact port number given to you when your TLS Database Endpoint (TLS VPN) was set up.
Options for testing include:
Powershell command (PREFERRED FOR WINDOWS CLIENTS): Test-NetConnection COMPANYCODE-sql.viewpointdata.cloud -port PPPP
Telnet to Your Custom TCP port (PREFERRED FOR macOS and LINUX CLIENTS): telnet COMPANYCODE-sql.viewpointdata.cloud PPPP
The following two methods merely confirm if the port is open, not if the server is actively pending connections on that port, thus these two methods are not quite as useful as either “tnc” on Powershell or Telnet on macOS / Linux:
TCPPING to Custom TCP Port: tcpping -c -x 5 COMPANYCODE-sql.viewpointdata.cloud PPPP
PSPING to Custom TCP Port: psping -t -4 COMPANYCODE-sql.viewpointdata.cloud:PPPP
Changelog
Monday, 05 February 2024 at 06:17PM:
Updated to show that the port number will almost always now NOT be 1433 for the ODBC port on TLS Database Endpoint (TLS VPN) connections.
Friday, 13 May 2022 at 10:18PM
Changed -VRL references to -SQL
Added note that port 1433 may not be the correct port to use, depending on what has been assigned.
Thursday, 10 March 2022 at 01:26PM
Updated to include TLS Database Endpoint (TLS VPN) testing instructions and Table of Contents.
Monday, 29 November 2021 at 10:44AM
Updated to include PowerShell instructions for testing the VPN connection.