While initially deploying StrongDM, administrators of StrongDM may encounter scenarios where they need to troubleshoot one of the following:
Client-side (Desktop)
- Connectivity from the StrongDM Client to the Customer-installed Gateway
- Connectivity from the StrongDM Client to the StrongDM SaaS Platform
This guide will walk through some common steps that can be taken to determine if issues in the network may be blocking traffic. This diagram below describes a simple connection flow.
Requirements:
When testing from different operating systems you may need to install external packages, or use built-in applications.
Linux: Netstat or Netcat (NC) may or may not be installed depending on your distribution.
Windows: Depending on the OS version, Netcat may be installed as a Linux tool, or Powershell may be utilized instead. You can also use a tool from Sysinternals called TCPView (https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview)
MacOS: Use Netcat, or lsof.
Connectivity from the StrongDM Client to the Customer-Installed Gateway
The end-user on the desktop may have installed the StrongDM client, which includes the StrongDM Desktop application and/or CLI. After authentication, the list of resources appears in the client. The connection may appear healthy (green) in a connected state. When attempting to use a database tool like DBeaver or when connecting via SSH, the connection fails.
Order of diagnosis:
- Verify local ports
- Verify StrongDM Desktop Connects to Remote Gateway Ports
1. Verify Local Ports
Commonly, applications may have already reserved a port on the operating system that the StrongDM client is trying to bind to. Check first to make sure that the port is not owned by another process. These examples show StrongDM owning port 18444.
Windows: Using Powershell you can determine which process might be owning the port.
At the prompt use:
Get-Process -Id (Get-NetTCPConnection -LocalPort $PORT).OwningProcess
For example:
Get-Process -Id (Get-NetTCPConnection -LocalPort 18444).OwningProcess
>>
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
347 30 39716 61372 268.91 12564 1 sdm32
macOS: You can use ‘lsof’ on macOS to find the owning process:
sudo lsof -nP -i4TCP:$PORT | grep LISTEN
For example:
~ sudo lsof -nP -i4TCP:18444 | grep LISTEN
sdm.darwi 60383 john.doe 42u IPv4 0x6777debfe09428a3 0t0 TCP 127.0.0.1:18444 (LISTEN)
Linux:
There are many methods on Linux, but a common one is to use Netstat:
netstat -pntl | grep $PORT
For example:
john@ubuntu-arm:~$ sudo netstat -pntl | grep 18444
tcp 0 0 127.0.0.1:18444 0.0.0.0:* LISTEN 1311/sdm
2. Verify StrongDM Desktop Connects to Remote Gateway Ports
StrongDM’s built-in diagnosis tool, called ‘sdm doctor’, can be accessed from the desktop app or from the CLI.
In the desktop app, select the Diagnostics option. This will output tests that check for ports being open from the client to the gateway, in addition to many other helpful clues.
The output from the CLI is similar to Diagnosis, but you enter the command ‘sdm doctor -v’, and it will output the same info into the terminal.
It will test access to the registered gateway nodes on the listen port, which is typically the default TCP 5000.
You may also test that the route from the desktop app to the gateway is working correctly, and the port is available by using Netcat (NC) from the CLI.
On macOS or Linux you can use the below command:
nc -zv gateway-fqdn/IP-Address 5000
For example:
On Windows, you can use NC, or commonly a Powershell command:
Test-NetConnection -ComputerName “gateway.company.com” -Port 5000
You will get a similar output as NC that will tell you if the port was open and the test succeeded. If you are encountering errors using any of the above methods, please check what might be blocking traffic from the StrongDM client to the Node servers. These could be misconfigurations in your cloud security groups, routing and firewall policies, or other security appliances like proxies or VPNs.
Connectivity from the StrongDM client to the StrongDM platform
The end-user on the desktop may have installed the StrongDM desktop client or CLI. The client fails to log you in when you enter your email. This is usually because the outbound traffic to the Saas application is being blocked. Users must authenticate to StrongDM, or be redirected to their SSO.
An easy way to check is to open a browser to https://app.strongdm.com and validate you can reach it. There are two other URLs that need to be checked as well. They are https://api.strongdm.com , and https://downloads.strongdm.com. All URLs are using tcp port 443.
These can be validated from using the ‘sdm doctor -v’ command, which will tell you if there is an attempt to do TLS inspection on the egress traffic, which will shutdown the connection. You can see this output in the RootCAs display in the above screenshot. This mention is important as many customers may be using a ZTA device, or other network inspection, perhaps from a firewall, that will attempt to replace the certificates. StrongDM will detect MiTM attempts and shutdown the traffic.
Other ways to test from the Desktop are using NC or Powershell as shown in the above example but using the URL and port 443. This will test that the route from the desktop to the platform is working correctly, and the port is available.
On macOS or Linux you can use the below command:
nc -zv app.strongdm.com 443
On Windows, you can use NC, or commonly a Powershell command:
Test-NetConnection -ComputerName “app.strongdm.com” -Port 443
You may encounter errors that seem mismatched, such as the netcat connection succeeding, but you are still not able to login. The ‘doctor’ output may show you a different CA Root listed, so the issue may lie with TLS inspection.
There are other tools you can use to determine from the CLI, such as openssl s_client: ‘openssl s_client -connect app.strongdm.com:443 -showcerts’