Leostream Gateway Troubleshooting Guide

The Leostream Gateway offers remote access to your end users without the need of a legacy VPN. There are two main functionalities of the Leostream Gateway. The first functionality is forwarding web traffic to your Connection Broker so users can authenticate and select the desktop they want to connect to. The second functionality is orchestrated by the Connection Broker, which instructs the Leostream Gateway to proxy display protocol traffic from end user's clients to their desired desktop programmatically and securely. 

This is a living document, and will be updated as a FAQ sheet for Gateway issues.

TABLE OF CONTENTS

• Users are unable to access their desktop when the protocol traffic is directed at the Gateway
• Gateway appears offline in the Connection Broker, but I can access it's CLI
• Unable to connect to this desktop. A desktop connection already exists from your device
• Error during SSL Handshake with remote server
• Random Disconnects

Users are unable to access their desktop when the protocol traffic is directed at the Gateway

• Verify that the connection file really is directing traffic to the Leostream Gateway's public FQDN or IP address with the correct port by editing the file. If this step is wrong, please make sure the user is being assigned the correct policy + protocol plan w/ Gateway attached (Troubleshooting Assignment Issues: Test Login)
  
  
• Confirm connectivity from Client --> Gateway by running a telnet or ncat port check based on the connection file's target hostname/IP + port found in step I.
  
  
• If the step above did not succeed, verify the rich rules created on the Leostream Gateway. These rules can be found by using the Gateway's CLI and running firewall-cmd --list-all. Find the IP address of the desired desktop in the "destination" section of the rule. Can you find a matching rule for your client? If you can't find a matching rule, and step II confirmed the client cannot access the port found in the Connection file, use your Connection Broker's System > Log to find the below error:
  
  
  "show details" will provide a more in-depth description of the error. Please submit a support ticket if you have questions about the error provided.
  
  
• If Step II succeeded, we can determine that the client has full connectivity to the Leostream Gateway and the rich rule was created successfully. The last piece of the puzzle would be the connection between the Gateway and the desired desktop. Please make sure that the Leostream Gateway can reach the desired desktop on the protocol port using ncat or telnet from the Leostream Gateway CLI. This should be based on the destination IP and port found in the rich rule.
  
  
• If both Client --> Gateway and Gateway --> Client seem to work, but the connection is still not establishing, verify that masquerading is enabled and a "public (active)" zone exists on your Gateway:
  
  
• In rarer cases, security applications can interfere with the sudoers permissions on the appliance that runs the Leostream Gateway application. Please verify that the /etc/sudoers.d/leo file exists and looks like below:
  
  RHEL/Rocky/Alma 8:
  
  
  
  RHEL/CentOS/ 7:
  

Gateway appears offline in the Connection Broker, but I can access it's CLI

• First, verify that the Connection Broker can reach the Leostream Gateway on port 443 using a tool like ncat or telnet against the defined Private IP in the Gateway record.
  
  
• If the above succeeds, make sure the Leostream Gateway can reach the Connection Broker on port 443.
  
  
• If both the above steps succeed, there is a rare chance that the encryption key used for SSL communication no longer works. Try editing the Gateway under Setup > Gateways and pressing "Save" to reset this.
• If that doesn't work, take inventory of any protocol plan that leverages this Gateway and schedule a maintenance window to delete and add the Leostream Gateway back
  1. First, remove the Gateway's reference in any of the protocol plans you've inventoried
  2. Second, note down the Gateway's configuration (Public FQDN, Private IP, Method for Routing)
  3. Once that is complete, editing the Gateway record should give an option to delete it. Try deleting it.
  4. If you can successfully delete it, then you can try to add it back using the "Add Gateway" option
  5. If there are issues deleting it or adding it back, and it's impacting a production environment, please open an urgent ticket
     
     

Unable to connect to this desktop. A desktop connection already exists from your device

• First, find the correlated Connection Broker log by navigating to System > Log in the Connection Broker
  
  
• Determine whether the REMOTE_ADDR is unique to the end-user, or if there are multiple users behind the same Public IP.
  • If there are multiple users connecting from the same Public IP, you will need to change the "Method for routing" setting to "From random gateway port" without client source IP address filtering. Please be mindful to adjust firewall rules to allow connections to the Gateway on the default random port range (20001-23000)
  • If it's a unique public IP to a single user, verify that the user is not assigned to any existing desktop. If the Leostream Agent sends a logout or disconnect notification to the Connection Broker, the Gateway forwarding rule is removed. If releasing the desktop removes the Gateway rule, double check that Agent --> Broker communication is healthy. If you are unsure, please submit a support ticket.
    
    
  • If it's a unique public IP to a single user, and the user is not assigned to another desktop, please submit log packages from both the Gateway and Connection Broker

Error during SSL Handshake with remote server

This issue can occur when web traffic is being proxied to the Connection Broker via HTTPS and a cert error is encountered.

1. Verify that the SSL certificate on the Connection Broker is valid. 

2. Compare the FQDN used in leostream-gateway --broker matches the Common Name of the Connection Broker SSL certificate.

3. Verify that the Connection Broker certificate isn't expired

4. Try installing a self-signed certificate by navigating to System > Maintenance in the Connection Broker

5. Verify that the Gateway can reach the IP/FQDN defined in leostream-gateway --broker on port 443

6. If the issue persists, please submit a support ticket.

Random Disconnects

Users experiencing random disconnects makes it frustrating for IT administrators to track down the root cause. In general, the only Leostream component that is in the data path of the protocol connection would be the Leostream Gateway. The Leostream Gateway opens and closes forwarding ports based on instructions from the Connection Broker. The Connection Broker will send these instructions based on the notifications sent by the Leostream Agent. Here are some useful tips to help troubleshoot these issues:

• Verify that the disconnect issue isn't happening with direct connections, internally
• Certain protocols might experience a lapse in connection and try to reconnect - this can cause the Leostream Agent to send a disconnect notification to the Connection Broker, therefore closing the Gateway forwarding rule. To give the connection a chance to re-establish, navigate to System > Settings in your Connection Broker and adjust the below setting:
  
• Verify that the disconnect issue isn't happening with direct connections, externally. This means opening a port in your firewall that would forward traffic to a particular desktop.
• If the issue persists, please submit a support ticket.

© Copyright 2023 Leostream Corporation