Cannot connect to Console address
Depending on your setup, you might need to configure a DNS entry for use in a multi-cloud configuration, or choose an IP address from the drop-down list. Note that if you select an IP address, and Console’s IP address changes, communication between Defender and Console will be interrupted. Therefore, we recommended that you use DNS names instead.
Choose the name that Defenders use to access Console.
When installing Defender using the curl command generated by Console, be sure it contains a hostname (or IP address) that your host can resolve.
Go to the Manage > Defenders > Deploy page in Console.
The drop down list at the top (a. Choose the name that clients and Defenders use to access this Console) selects the hostname that gets used in the auto-generated curl command.
Try pinging Console’s hostname from the host where you want to install Defender. If you get an error, you need to fix Console’s hostname.
$ ping cto-dev-console.c.cto-sandbox-internal ping: unknown host cto-dev-console.c.cto-sandbox-internal
Under Manage > Defender > Names, you can optionally add a Subject Alternative Name that the Defenders can use to connect to the Console. This name is also applied to Deploy Daemonset Tab and needs to be added if the Daemonset uses a different name / IP to connect. Failure to do so may result in certificate error.
If Defender installs without any issues, but Console does not list it in Manage > Defenders > Manage, then Defender cannot connect to Console. By default, Defender is configured to communicate with Console on port 8084. If port 8084 is closed, then Defender cannot communicate with Console.
Verify that port 8084 on Console’s host machine is open. On Defender’s host machine, run the following command to verify that a connection can be established:
$ sudo lsof -i defender 2196 root 15u IPv4 31535 0t0 TCP cto-dev-coreos.internal:37562->cto-dev-console.internal:8084 (ESTABLISHED)
If port 8084 is open, and Defender still can’t connect to Console, the problem could be that your load balancer is configured for SSL termination. You can verify this by connecting to the node that runs Defender, then checking /var/lib/twistlock/logs/defender.log for a message such as:
http: TLS handshake error from 10.10.1.1:8084: remote error: tls: bad certificate
Resolve the issue by setting the load balancer to pass-through, or by ensuring that the certificate is on all three stages of the load balanced connection (Console > Load Balancer > Defender).