Skip to content

What is Gateway and What is It Used for?

Gateway is a small console application that provides other devices in the same network with access to the Getscreen.me server.

It is useful when a direct connection to the server is not available due to network restrictions, or when the server needs access to resources inside the customer’s local network that are not exposed to external networks.

The application is available for the Windows and Linux operating systems.

Download Gateway


Features

Using Gateway does not add any new features, but it significantly improves how the system can be used by creating better conditions for those features to work. Here is what you can get when using gateways:

  • Custom data proxying for connections between a remote device and a technician’s device
  • Importing technician accounts from the corporate Active Directory
  • Proxying the Magic Packet signal for Wake-on-LAN inside your local network
  • Server access for the Agent application from restricted networks

Proxying connections to devices

Gateway can be used as a proxy server to transfer data between a remote device and a technician’s device during a connection session. This allows you to:

  • Improve the network conditions between the remote device and the technician’s device, which can improve image quality and data transfer speed.
  • Restrict physical access to traffic for security reasons.

Gateway supports both data transmission channels: WebRTC and WebSocket. They can be used separately or at the same time.

Data Transmission Channel

Learn more about data transmission channels in the Screen Image Quality guide.

WebRTC

Although WebRTC is a protocol for establishing P2P connections, it still requires access to service STUN servers to detect the participants’ IP addresses and TURN servers to proxy data when P2P connections are not possible due to network conditions. Gateway runs these servers to keep the channel operational.

Network requirements

For Gateway to work as a proxy for the WebRTC channel, it must be available by its IP address to all other participants in the connection process: the server, the Agent application, and the technician’s browser. The required ports for incoming TCP and UDP connections must also be open. See the Configuration section for details.

⚠ The proxy server for the connection session is selected by the Agent application on the remote device. Restart the Agent application to make your Gateway available for selection as a proxy.

WebSocket

To support the alternative channel, Gateway runs as a public web server and proxies HTTP connections over the WebSocket protocol.

Network requirements

To keep Gateway operational, it must be accessible by domain name to all other participants in the connection process: the server, the Agent application, and the technician’s device.

After creating an A record that points the domain name to the Gateway IP address, specify the hostname in config.json in the proxy.websocket.host field. See the Configuration section for details.

You also need an SSL certificate for your domain name so that the browser can establish a secure connection. Place the certificate file and the private key file in the cert folder next to the executable file, using the following names: server.crt and server.key.

By default, Gateway listens for incoming connections on port 443 on all available IP addresses. To change these settings, specify different values in config.json in the proxy.websocket.listen_ip and proxy.websocket.port fields. See the Configuration section for details.

⚠ The proxy server for the connection session is selected by the Agent application on the remote device. Restart the Agent application to make your Gateway available for selection as a proxy.

System requirements

To use Gateway as a custom proxy, the recommended minimum system requirements for the device running it are:

  • RAM: 2 GB
  • CPU: 2 cores
  • Drive: 16 GB
  • Bandwidth: up to 100 Mbps

Importing technician accounts from Active Directory

Active Directory domain controllers usually do not have open Internet access for security reasons. Because of this, the Getscreen.me server cannot directly send requests to import accounts from Active Directory. To give the server access to Active Directory, run the Gateway application inside the same local network as an intermediary. The running Gateway can synchronize accounts by performing the following operations as instructed by the server:

  1. Receive credentials from the server for connecting to Active Directory
  2. Connect to Active Directory over LDAP and retrieve user account data
  3. Send the retrieved data to the server

Network requirements

To use Gateway as an Active Directory data importer and send data to the Getscreen.me server, the device running Gateway must have open access to the server by domain name on port 443, and open access to the Windows directory service over LDAP. A public IP address is not required.

Integration with Active Directory

See the detailed instructions for importing technician accounts from Active Directory in the separate guide.

Technicians and Access Rights System

Learn more about the access rights system and technician accounts in the separate guide.

Proxying the Magic Packet signal for Wake-on-LAN

When a device is woken up using Wake-on-LAN, the server sends a Magic Packet signal to all known IP addresses of the target device. However, the target device often does not have a public IP address, so the packet may not reach it. At the same time, the device may be connected to other devices in the local network and can receive the wake-up signal from them.

This means you can turn one of the devices in your local network into a “watcher” by installing the Gateway application on it. At the server’s request, Gateway sends the Magic Packet signal over the local network, ensuring that the target device is woken up reliably.

Network requirements

To use Gateway as a Magic Packet forwarder, the device running Gateway must have open access to the server by domain name on port 443. A public IP address is not required.

Wake-on-LAN

Learn more about the device wake-up feature in the separate guide.

Server access for the Agent application from restricted networks

When the Agent application on a remote device has no direct access to the server, it can connect to the server through a Gateway that does have server access. This may be required when setting up remote access to devices without Internet access, for example in restricted corporate networks.

Network requirements

For Gateway to work, the device running Gateway must have open access to the server by domain name on port 443. A public IP address is not required.

Gateway configuration

To change the port used by Agent applications to connect to Gateway, update the proxy.websocket.port setting in config.json. See the Configuration section for details.

Starting the Agent application

To use Gateway, start the Agent with the Gateway address and port specified as a custom connection server in the -config parameter, as shown in the example below:

getscreen.exe -config "server='192.168.1.1:443'"

About the Agent application

Learn more about the Agent application in the separate guides:

Managing Gateways

A running Gateway application is identified on the server by a token that Gateway sends to the server when connecting. The server uses this token to identify the Gateway owner account and the roles available for it.

Tokens and roles can be managed in the personal account on the Gateways page in the Settings section.

On the Installation and Launch tab in the token card, you can find brief Gateway installation instructions and download a preconfigured config.json file for configuring the running instance. This file contains the server address and token.

On the Running Applications tab, you can see the list of running instances using this token.

On the other tabs, you can enable or disable the required Gateway roles:

Installing and starting the service

The Gateway application is managed using console commands.

To install the Gateway application as a service, use the -install command:

./gateway -install

To start the service, use the -start command:

./gateway -start

List of all available commands:

Command Description
-install Install service
-uninstall Uninstall service
-start Start service
-stop Stop service

Configuration

A running Gateway instance is configured using the config.json file, which must be located next to the executable file. Restart the application to apply any changes.

Connecting to the server

Connection settings for the Getscreen.me server:

Parameter Type Description
server.host string Server address. Default: getscreen.me
server.token string Authorization token. See the Management section
server.secure boolean Connect only to servers with a valid SSL certificate. Default: true.
Example
{
  "server": {
    "host": "getscreen.me",
    "token": "3wHcXGzc4KVMCJgxjX7sw5j6UO...",
    "secure": true
  }
}

Proxying connections

Settings required to run Gateway as a data proxy when connecting to remote devices:

Parameter Type Description
WebRTC Channel
proxy.webrtc.public_ip string Public IP address
proxy.webrtc.listen_ip string Internal IP address for listening for incoming connections
proxy.webrtc.port number Port for listening for incoming TCP connections. Default: 3478.
proxy.webrtc.udp_ports_max number Maximum port in the range for listening for incoming UDP connections. Default: 60000
proxy.webrtc.udp_ports_min number Minimum port in the range for listening for incoming UDP connections. Default: 40000
WebSocket Channel
proxy.websocket.host string Domain name where Gateway will be available and for which the SSL certificate is issued
proxy.websocket.listen_ip string IP address for listening for incoming connections. Default: 0.0.0.0
proxy.websocket.port number Port for listening for incoming connections. Default: 443
Example
{
  "proxy": {
    "webrtc": {
      "public_ip": "62.110.17.123",
      "listen_ip": "0.0.0.0",
      "port": "3478",
      "udp_ports_max": "60000",
      "udp_ports_min": "40000"
    },
    "websocket": {
      "host": "proxy.example.com",
      "listen_ip": "0.0.0.0",
      "port": "443"
    }
  }
}