Install a Linux Gateway | RS
Linux Gateways can be used for the following session types:
- RDP
- SSH/Telnet
- VNC
Setup of a Gateway on a remote network is a multi-step process that includes ensuring dependencies are met, configuring from the /login administrative interface, downloading the installer, and running the installation wizard.
Install dependencies
Several Linux libraries must be installed on the Gateway host. Exact requirements depend on the distribution of Linux, however the following libraries are recommended.
- libopengl0
- libglx0
- libxkbcommon-dev
- libfontconfig
- libx11 (for X server). X server does not need to be running.
- libnetfilter-queue1 or libnetfilter_queue as it applies to your distribution.
If the Gateway installation fails due to missing libraries, the error message includes information on what is missing.
To use Website, install X server and an X dummy driver. For example:
Ubuntu:
apt install xserver-xorg-video-dummy
CentOS:
yum install xorg-x11-drv-dummy
Configure /etc/X11/Xwrapper.config. Create file if it is missing.
allowed_users=anybody
needs_root_rights=no
For more information about X servers, see What is X11? or other online resources.
Configure
- From the administrative interface, go to Asset Management > Gateway.
- Click Add.
- Create a unique name to help identify this Gateway. This name should help users locate this Gateway when they need to start a session with a computer on its same network.
- Set a code name for integration purposes. If you do not set a code name, one is created automatically.
- If you have a Password Safe integration, and the Gateway for External Asset Sessions selection is set to Automatically Selected by External Asset Network ID, on the /login Security page, enter the External Asset Network ID. This value is equivalent to the Workgroup attribute for managed systems in Password Safe. It is matched against the Network ID property of external Assets returned by the Endpoint Credential Manager to determine which Gateway handles the session.
- Add comments to help identify this Gateway.
- Select Linux for the Gateway Platform. Once the Gateway has been created, this option cannot be changed.
- Leave the Disabled box unchecked.
- Check the Clustered box, if appropriate. Once the Gateway has been created, this option cannot be changed.
- A clustered Gateway allows you to install up to ten redundant nodes of the same Gateway on different host systems on the same local network. If this option is selected, the Gateway will be available as long as at least one of the installed nodes is online. This provides redundancy, preventing the failure of all Assets associated with the failure of a single, stand-alone Gateway, and improves load balancing across the system. All configuration of clustered Gateways is done in /login, with no local configuration available during the install. Once created, a clustered Gateway cannot be converted to stand-alone, nor a stand-alone Gateway converted to clustered.
- Linux Gateways can only be used for RDP, SSH/Telnet, and VNC sessions, allowing for credential injection from user or Vault, as well as RemoteApp functionality and Jump filtering. Clustered Gateways can only add new nodes of the same OS. You cannot mix Windows and Linux nodes.
Important informationGateway cluster nodes must be installed on hosts residing in the same local area network.
-
If you want users to be able to connect to SSH-enabled and Telnet-enabled network devices through this Gateway, check Enable SSH Method.
-
From the Gateway edit page, you can authorize users to start sessions through this Gateway. After the Gateway has been created, you can also grant access to groups of users from Users & Security > Group Policies.
-
If you check Enable Proxy Proxy, you can set up this Gateway to function as a proxy server, allowing it to proxy connections for Assets on the network that do not have a native internet connection, such as POS systems. Using a Gateway as a proxy routes traffic only to the B Series Appliance.
You can enable Proxy Proxy on either a standalone Gateway or a Gateway cluster. If you set up a Gateway cluster as a Proxy Proxy, then if an endpoint is connected to one Proxy Proxy and that system goes down, the endpoint can connect to another Proxy Proxy in the cluster. Proxy Proxies are not supported for Atlas deployments.
-
Optionally, under Proxy Host, you can enter the hostname of the machine on which this Gateway will be installed. Do not start the hostname with http://or https://. IP addresses are not recommended as they might change. The Gateway will automatically detect the hostname if one is not provided. If this is a clustered Gateway, this field does not appear, and the Gateway will automatically detect the hostname on install. If the hostname changes, you may have to redeploy any Assets that use this Gateway as a proxy.
The proxy host and port should be set carefully since any Asset deployed using this Gateway as a proxy server uses the settings available to it at the time of deployment and are not updated should the host or port change. If the host or port is changed, the Asset must be redeployed.
In order for a Gateway to function as a Proxy Proxy, its host system cannot reside behind a proxy. The Gateway must be able to access the internet without having to supply proxy information for its own connection.
-
Under Proxy Port, enter the port through which Assets will connect to this Gateway. If the port changes, you may have to redeploy any Assets that use this Gateway as a proxy.
-
Check Allow HTTP GET to enable HTTP connections to proxy to the B Series Appliance. This is needed only if you want to use a browser to access /login or /console from behind the proxy.
-
Under Restriction Type, select No access restrictions to allow Asset connections from any IP address. You can limit allowed connections by selecting Deny access only for the following IP addresses or Allow access only from the following IP addresses, then entering network address prefixes, one per line. Netmasks are optional, and they can be given in either dotted-decimal or integer bitmask format. Entries that omit a netmask are assumed to be single IP addresses.
-
-
Under Allowed Users, you may authorize users to start sessions through this Gateway. After you have created the Gateway, you can also grant access to groups of users from Users & Security > Group Policies.
-
Save the configuration. Your new Gateway now appears in the list of configured Gateways.
Once you have installed the Gateway and started it at least once, Remote Support populates the table with the hostname of the system it is installed on, as well as with that system's public and private IP addresses. This information can help you locate the Gateway's host system in case you need to change the Gateway's configuration.
Download
Now that the Gateway is configured, you must install the Gateway on a single system in the remote network you wish to access. This system serves as the gateway for Sessions with other computers on the remote network. You can either install the Gateway directly to the host or email the installer to a user at the remote system. If this is to be a clustered Gateway, you add nodes after the Gateway is installed.
- From the table, find the appropriate Gateway and click the link to download the installer file.
- If you are logged into the system you want to use as the Gateway host, you can run the installation file immediately.
- Otherwise, save the file and then transfer it to and deploy it onto the system that will serve as the Gateway host.
- If you need to change the Gateway's host system, click Redeploy. This uninstalls the Gateway from its current location and makes the download links available. You can then install the Gateway on a new host. The new Gateway replaces the old one for any existing Assets that are associated with it.
- The Gateway installer expires 7 days after the time of download.
Install
-
Once the installer file is on the remote system, use a command interface to install the file and specify any desired parameters. The Gateway must be installed within 7 days of downloading it. The exact install process depends on the Linux distribution and version, but general steps are provided below.
-
Install the Gateway using --install-dir . You must have permission to write to this location, and the path must not already exist.
sh ./sra-jpt-{uid}.bin --install-dir /home/username/Gateway -
If you wish to install under a specific user context, you can pass the --user argument. The user must exist and have rights to the directory where the Jump Client is being installed. If you do not pass this argument, the Gateway installs under the user context that is currently running.
sh ./sra-jpt-{uid}.bin --install-dir /home/username/Gateway --user jsmith
-
Important informationIt is not recommended to install the Gateway under the root context. If you attempt to install when the current user is root, you receive a warning message and are required to pass --user to explicitly specify the user that the process.
-
After installing the Gateway, you must start its process.
/home/username/Gateway/init-script startThis init script also accepts the stop, restart, and status arguments. You can use ./init-script status to make sure the Gateway is running.
-
You must also arrange for init-script start to run at boot in order for the Gateway to remain available whenever the system restarts. An example system.d service displays once the Gateway is installed. Copy this information and create the new service for the Gateway, filename.service (where filename is any name you choose), following these steps:
- cd /etc/systemd/system
- vi filename.service
- Paste copied information.
- Run chmod 777 filename.service
- Reload the systemctl daemon.
- Enable and start the service file:
- Run sudo systemctl start filename.service to start the service file.
- Run sudo su - to get to root.
- Run systemctl enable filename.service to enable the service file, so the Gateway service will automatically start after every reboot.
- Reboot the Gateway machine.
-
To remove the files, use the uninstall.sh script included in the installation.
If the Gateway installation fails due to missing libraries, the error message includes information on what is missing.
Clustered Gateway setup: adding nodes
The steps for creating a clustered Gateway in /login are the same as for a standalone, with one difference: once you have created the clustered Gateway, you add nodes to it. At least one node needs to be installed for the Gateway to be online.
- From the administrative interface, go to Asset Management > Gateway.
- From the table of existing Gateways, find the appropriate Gateway and click the Add Node link to download the installer file (sra-jpt-{uid}.bin).
- If you are logged into the system you want to use as the Gateway host, you can run the installation file immediately.
- Otherwise, save the file and then transfer it to and deploy it onto the system that will serve as the Gateway host.
- Install the node following the same steps for Install, as above.
- In the Gateway table, the clustered Gateway now shows information about each installed node, including public and private IP addresses and online or offline status.
Nodes can be deleted but cannot be individually edited. In the representative console, none of the nodes are visible; only the clustered Gateway under which they are installed is visible. Nodes function as redundant connection points. When a user needs to use the Gateway, one of the nodes is selected randomly. At least one node must be online for the Gateway to work.
Set up a Proxy Proxy in public clouds
Cloud environments may not broadcast mDNS by default, which is required for the auto-detection of a Proxy Proxy. Below are two workaround methods.
AWS Transit Gateway
Set up an AWS Transit Gateway to provide multicast to the Virtual Private Cloud.
For more information, see Multicast in Amazon VPC Transit Gateways.
Manually edit a Gateway proxy connection
Manually edit the settings.ini file of the Gateway or the settings.ini file of the Jump Client to point to the proxy or proxies.
If you see this line, delete it:
Proxy=DIRECT
If connecting to a standalone Proxy Proxy, add these lines:
[Proxy\<your_site>:443\Detected\1]
Proxy="<ip_of_jump_zone_proxy_node>:<port_configured_in_login>"
If connecting to a clustered Proxy Proxy, each node of the cluster must be defined separately. In case of node failure, fallback will occur in this order. Add these lines:
[Proxy\<your_site>:443\Detected\1]
Proxy="<ip_of_jump_zone_proxy_node>:<port_configured_in_login>"
[Proxy\<your_site>:443\Detected\2]
Proxy="<ip_of_jump_zone_proxy_node>:<port_configured_in_login>"
Deploy a clustered Linux Gateway as a Docker image
You can run a clustered Linux Gateway in a Docker container. To do so, you need the Gateway's deploy key. You can get the deploy key in one of three ways:
- Click the Copy Docker deploy key button from the main Gateway table.
- Edit the Gateway and copy the value from the Docker DEPLOY_KEY field.
- Use GET /Gateway/{id} in the configuration API.
Pass the deploy key to the Gateway image in the Docker environment as DEPLOY_KEY.
The Docker image uses a bound volume to persist the Gateway install between image restarts and upgrades. To enable this, bind a volume to /jpt in the image. The Gateway install data is located under /jpt/home/install. The image requires the ipc_lock capability to do keyring operations.
The deploy key is saved under /jpt/. Deleting this file will force a re-install the next time the container runs.
Example Docker run command:
docker run -e DEPLOY_KEY=<key> -v <data_dir>:/jpt --name <name> --cap-add ipc_lock --cap-add NET_ADMIN --cap-add NET_RAW beyondtrust/sra-Gateway:latest
| <key> | The key that ties this Docker image to the specific Gateway or cluster in your Remote Support site. |
| <data_dir> | The local path where the container is mounted to preserve settings and configuration across restarts. |
| <name> | Any name to identify this container in Docker. |
Gateway through a Gateway deployed as a proxy server
You can configure a Gateway to go through another Gateway deployed as a proxy server. This allows secure access to isolated, non-routable, OT networks without being constrained to only Jump Clients. Follow these steps:
- On System 1, install a Gateway configured as a Proxy Proxy server.
- On System 2, which can be non-routable and on a network isolated from the internet, install a Gateway.
- On System 2, configure the Gateway's basic proxy configuration to point to the Proxy Proxy on System 1.
- You can now create new Assets using the Gateway on System 2, for endpoints in the same isolated network as System 2, and start sessions with them through the Proxy Proxy on System 1.
- The Proxy Proxy, whether standalone or clustered, must be deployed to the target network before installing the Jump Client or Gateway used to create Assets. This enables automated discovery of the broadcasting proxy.
- Automated discovery works only if the installing Gateway or Jump Client is on the same subnet as the Proxy Proxy or if you have configured mDNS broadcasts to route across networks.
Updated 7 days ago