Use cases

This page describes typical usage scenarios for the application.

General notes

We're assuming in the following examples, that an end user called Alice wants to make her screen available to a support staff called Bob. Alice only requires an installation of Customer Support Tool. Bob on the other side requires an installation of Staff Support Tool in order to make remote administration possible.

Direct support connection

In this scenario Alice sends her desktop through a direct connection to Bob.

Tasks for Bob

• In case that Bob sits behind a router / NAT, he has to open the configured port (5900 by default) in his router / NAT and has to forward incoming traffic from this port to his local machine, where the VNC client is listening.
• Bob has to launch the Staff Support Tool and press the "Start" button.
• Bob has to tell Alice his public IP address and the port number to access his machine.

Tasks for Alice

• Alice enters Bob's IP address and port number into her Customer Support Tool and clicks "Connect".

Advantages

• This solution provides best possible performance.
• Bob may enable SSL encryption before starting the support session. In this case he has to tell Alice to also enable the SSL option in her Customer Support Tool.

Disadvantages

• Bob has to open a port in the firewall of his router / NAT, what can be a security risk.
• Bob has to obtain his current IP address and needs to tell it to Alice, what makes the initiation of the support connection a bit trickier.

Gateway support connection

In this scenario Alice sends her screen through a SSH server to Bob, that acts as a gateway (SSH reverse tunnel).

Preparing the SSH server once

In order to use remote port forwarding through a SSH server, the option GatewayPorts yes needs to be set in sshd_config. Also make sure, that AllowTcpForwarding yes is set (generally it is enabled by default). Without these settings any incoming traffic of Alice is not properly redirected to Bob's machine.

The correct setup of remote port forwarding might be tested with the command

ssh -R 12345:localhost:5900 $GATEWAY_USER@$GATEWAY_ADDRESS

which opens port 12345 on the gateway server and forwards incoming traffic to Bob's local SSH daemon on port 5900. While the SSH connection is open, you can do a local port scan on the server with

netstat -npl

which should show a line like this:

tcp        0      0 0.0.0.0:12345           0.0.0.0:*               LISTEN      -

In this case remote port forwarding is properly configured. If it shows instead

tcp        0      0 127.0.0.1:12345         0.0.0.0:*               LISTEN      -

remote port forwarding is not properly configured.

Tasks for Bob

• Bob has to launch the Staff Support Tool, enable the "SSH tunneling" option, enter the required SSH settings and press the "Start" button.
• Bob has to tell Alice the IP address / hostname of the SSH server and the remote port number.

Tasks for Alice

• Alice enters the hostname / IP address of the SSH server and remote port number into her Customer Support Tool and clicks "Connect".

Advantages

• No port forwarding in a router / NAT is required - neither for Alice nor for Bob.
• Bob does not have to provide his IP address to Alice.

Disadvantages

• An additional SSH server is required, that is available over the internet.
• Remote port forwarding has to be explicitly enabled in the configuration of the SSH server (GatewayPorts yes in sshd_config).
• Performance is slightly worse, due to the separate gateway and a possible overhead of partial double encryption.