Unable to reach Internal Application via Connector from the Endpoint

Problem

Managed endpoints are unable to establish a connection with the internal application via the Connector, resulting in a reachability failure.

Cause

The reachability failure occurs due to a break in the secure communication chain at one of two specific network legs:

• Connectivity issue between the Managed Endpoint and the Connector
• Connectivity issue between the Connector and the Internal Application.

Resolution

Check Endpoint to Connector Reachability

Run the following commands on your managed endpoint to verify connectivity to the Connector:

curl -v -k -I --connect-timeout 10 https://domain_name:8443

• If the output indicates an established connection or a connection aborted message, the connectivity between the Endpoint and Connector is confirmed. Continue with Check Connector to Internal Application Reachability.
• If the output shows a connection timed out error, there is a connectivity issue. There are two possible causes:

  1. Firewall blocking traffic

     The firewall may be blocking outbound traffic on port 8443.

     Resolution: Allowlist port 8443 in the firewall for traffic between the managed endpoint and the Connector.

  2. WAF inspecting the traffic

     A Web Application Firewall (WAF) may be inspecting the traffic between the endpoint and the connector, breaking the connection.

     Resolution: Provide direct access between the managed endpoint and the Connector, bypassing the WAF for this traffic path.

Check Connector to Internal Application Reachability

Run the following checks on the Application Connector machine against the internal application.

Replace <domain> with the application's hostname or IP address and <port> with its listening port. For example, use app.internal.local and 8443.

Step 1: Check the application port

Test whether the Connector can establish a TCP connection to the application port:

nc -zv <domain> <port>

• succeeded or open: The port is reachable. Continue to Step 2.
• timed out: The connection did not complete. Check for firewall or routing issues using Causes of a timeout.
• refused: The connection was rejected. Check that the application is listening on the specified port.
• could not resolve: Check DNS resolution on the Connector.

Step 2: Check the application response

Test the connection to the application's HTTPS endpoint:

curl -v -k -I --connect-timeout 10 https://<domain>:<port>

• If the output indicates an established connection or a connection aborted message, the connectivity between the Connector and the Internal Application is confirmed. If users still cannot access the application, continue with Step 3 and Step 4 before contacting support.
• Connection timed out: Investigate the connection between the Connector and the application using Causes of a timeout.
• For applications that use HTTP, replace https:// with http://.

Causes of a timeout

Check the following causes in order:

1. DNS resolution: Run nslookup <domain> on the Connector. If the hostname does not resolve or returns an incorrect IP address, correct the Connector's DNS configuration.
2. Application server firewall: Check whether the host firewall blocks inbound connections. Allow traffic from the Connector's IP address to the application port.
3. Network firewall: Check the firewall rules between the Connector and the application. Allow traffic from the Connector to the application on the required port.
4. Server or service unavailable: Confirm that the application server is running and the application service is listening on the expected port. Check the Connector service separately with sudo systemctl status sse-gateway.

Step 3: Test for packet loss between the Application Connector and the application

To test for packet loss in the network path between the Application Connector and the application, run a TCP MTR test for 50 cycles against the application host and port:

sudo mtr -rzwc 50 -T -P <port> <domain>

Start by checking Loss% for the destination, shown as the last hop:

• No destination loss: A last-hop value of 0% means no packet loss was observed at the destination during this test. Loss shown only at intermediate hops can result from routers rate-limiting their replies.
• Loss continuing to the destination: If loss begins at a hop and continues through subsequent hops, ask the network team to investigate that part of the path. The result is a diagnostic clue, not proof of the exact failing hop. Use the AS column to help identify the network owner.
• Increased latency or variation: A rise in Avg or StDev can indicate congestion or variable latency. Compare subsequent hops before identifying a location to investigate.

Share reports showing packet loss with your network or system administration team for investigation.

Step 4: Monitor connectivity during the failure

Start an interactive TCP MTR session against the application host and port:

sudo mtr --tcp --port <port> <domain>

Keep the session running while the user reproduces the access failure.

Capture a screenshot before pressing q to exit, so the live results are retained for investigation.

Contact support

If the issue persists after these checks, send the following information to the support team:

• Connector name.
• Application hostname or IP address and port tested (<domain>:<port>).
• Complete text output from Steps 1, 2, and 3. Do not summarize the output.
• Screenshot from Step 4, if captured.
• Connector logs.
• Test time and time zone.