While initially deploying StrongDM, administrators of StrongDM may encounter scenarios where they need to troubleshoot one of the following:
Node (Gateway and Relay)
- Connectivity from the Gateway or Relay Node to the Configured StrongDM Resource
- Connectivity from the Relay Node to the Gateway Node
- Connectivity from the Nodes 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 for testing:
When testing from SDM Nodes you may need to install external packages, or use built-in applications.
Linux: Netcat (NC), Netstat, CURL
Connectivity from the Gateway or Relay Node to the Configured StrongDM Resource
In order for the gateway or relay nodes to connect and authenticate to resources (such as databases, SSH servers, and so forth), there must be an IP route to the resource that is not blocked by a firewall, and the credentials to be used must be correct. Many times the resource may be in another VPC or a different subnet, and there is a security group or firewall rule blocking the communication.
Similarly to StrongDM Desktop testing, you can use Netcat (NC) or Powershell from the gateway or relay node, as shown in the above example, but with the FQDN of the server or endpoint IP address and the port of the listening server, such as PostgreSQL TCP port 1486. Since the StrongDM gateways are Linux only, you can use a variety of tools, but NC is the most common.
On Linux you can use the below command:
nc -zv server.domain.com 1486
Once you have established that connectivity succeeds, you might want to test that the credentials you are using are correct. Commonly you might install a DB CLI client like ‘psql’ to make a remote connection to the server.
Example: Using the credentials of the service account you have on the endpoint, test they are successful:
psql -h 192.168.1.1 -p 1486
If the resource is a web app, or is an API listening on a HTTP/HTTPS connection, you can leverage CURL as well. This is common for testing Kubernetes API endpoints.
A simple format is to use http/https://ipAddr/fqdn:port and -I is used to return the header only instead of the full contents of the page.
If you are encountering errors using any of the above methods, please check what might be blocking traffic from the StrongDM node servers. These could be misconfigurations in your cloud security groups, routing and firewall policies, or other security appliances like proxies.
Connectivity from the Relay Node to the Gateway Node
In environments where the relay node has been deployed, it will require egress routes from that server to be successful in connecting to:
- The resource or datasource to be configured in StrongDM, on the correct application ports. This example is shown in the above explanation.
- The relay also needs to communicate out of the network to an available gateway that is listening on its default port; as a reminder, StrongDM’s node listeners are TCP 5000.
- The relay also needs to be able to create an API connection to StrongDM.
You may also test that the route from the relay to the gateway is working correctly, and the port is available by using Netcat (NC) from the CLI.
On Linux you can use the below command:
nc -zv gateway-fqdn/IP-Address 5000
Connectivity from the Nodes to the StrongDM SaaS Platform
Both the gateway and relay nodes need to be able to talk to the platform URLs.
There are three URLs that need to be checked. All URLs are using TCP port 443:
Any attempt to do TLS inspection on the egress traffic will terminate the StrongDM connection. This is important because you may be using a ZTA device or other network inspection, perhaps from a firewall, that will attempt to replace the certificates. StrongDM will detect Manipulator-in-the-Middle (MITM) Attack attempts and exit. Please validate this possibility and correct the network rules to allow traffic unhindered.
On Linux you can use the below commands:
nc -zv app/api/downloads.strongdm.com 443