Connectivity Troubleshooting for Agent , Elasticsearch and the MC

General Connectivity troubleshooting

Network troubleshooting between the Waratek Secure agent and the management console, as well as elasticsearch can be a complex task, as there are many factors that can impact the connection. To troubleshoot this issue, you should first check the network settings on the Waratek Secure agent and the management console server, as well as elasticsearch to ensure that they are correct. This includes verifying that the IP address, FQDN's , and your port ranges are all correct. If you are unsure about any of these settings, you may need to consult your network administrator for assistance.

Firewall settings can often block incoming connections, so you will need to ensure that the appropriate ports are open on both devices. You may also need to configure your firewall to allow traffic through specific ports or protocols.

Below we will discuss the additional debug flags you could put in your file on the agent side to get additional logging.

You can safely enable the following parameter all the time as that will print out the start parameters for every application start.


It is useful for seeing all the configuration parameters for an application in the application logfile


For connectivity troubleshooting between Waratek Secure agent and MC , and elasticsearch the following can be enabled for troubleshooting purposes. You should disable these config parameters once connectivity is established.

com.waratek.debug.transport.file=<new log file>

These will print out debug messages into specified logfiles, the rules.log, and the mc.log.


Also setting the following


will enable additional more verbose during the showstart of the application in the application logs.


Connectivity troubleshooting to our SAAS Portal

Setting the debug flags above on the agent , and reviewing the resulting logs does not always clearly reveal the issue. 

First step should be to check connectivity from agent to SAAS portal is ok

you can run the following command:

curl -v '' --data '{"runtimeLanguage": "JAVA"}'

to see the following expected output

* Trying
* Connected to ( port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*
*  start date: Jan 23 00:00:00 2024 GMT
*  expire date: Feb 20 23:59:59 2025 GMT
*  subjectAltName: host "" matched cert's "*"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority:]
* [HTTP/2] [1] [:path: /api/2/agents]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [content-length: 27]
* [HTTP/2] [1] [content-type: application/x-www-form-urlencoded]
> POST /api/2/agents HTTP/2
> Host:
> User-Agent: curl/8.4.0
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
< HTTP/2 403
< content-length: 0
< date: Tue, 20 Feb 2024 16:00:41 GMT
< x-content-type-options: nosniff
< x-xss-protection: 0
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-frame-options: DENY
< x-cache: Error from cloudfront
< via: 1.1 (CloudFront)
< x-amz-cf-pop: DUB56-P1
< x-amz-cf-id: 19JemrOAzs9Sa9Kc_QDvKgG_k9IIpUkUOZz28AG6yO98_IMMSaau6g==
* Connection #0 to host left intact


If the Curl connection works but the Agent doesn’t, it’s possible that the issue is with the version of Java.
Attached is a simple Java class that establishes a connection to the Portal, very similar to what Curl does, and very similar to what the Java Agent does internally. Except it doesn’t swallow any exceptions so can be more useful when debugging.


To compile with the version of Java the agent is using:

and then to run it:
/path/to/java/bin/java PortalRestClient
And expected output should include a 403 response:
start doConnection
Forcing TLSv1.2 was successful
response: 403
end doConnection