Creating tunnels
Get access to any remote TCP port
Last updated
Was this helpful?
Get access to any remote TCP port
Last updated
Was this helpful?
Use tunnels to access remote servers and devices over SSH, remote desktop or any other TCP-based protocol. The tunnels are reverse tunnels initiated by the remote side. That means the IP address of the remote system doesn't matter and the remote side doesn't open any additional ports. The tunnel is created through the HTTP protocol. As long as the remote client is allowed to access the internet via HTTP, you can create tunnels.
Select a client on the left side, and click on it. Select the tunnels tab.
Click the Add Tunnel button.
Select the service you want to access on the remote client.
After the tunnel is created, the remote port – for example the port 3389 of the remote desktop – becomes available on a random port of the rport server. If you would like to use a specific port instead of a random, you can do so.
Usually, only you intend to use the tunnel. Therefore, your current public IP address is prefilled into the access control list (ACL). If you intend to enable public access to a web server inside an intranet, for example, you can switch of the ACL completely.
If you would like to keep tunnels alive, even they are not actively used, unselect the "Close tunnel after inactivity of N minutes" option.
Optionally, you can close (destroy) the tunnel even if it's still in use after a given period.
After the tunnel has been created, you can use it in different ways. The fastest and easiest way is clicking on the "Launch Tunnel" icon.
A tunnel consists of two ends. On the remote side, it ends on TCP port of a rport client. (Read below if the tunnel should not end on the rport client.) The other end of the tunnel ends on the rport server on an arbitrary port, either randomly selected or specified manually. But generally the tunnel does not end on the default ports assigned to the protocol, like 22 for SSH or 3389 for RDP.
On the above example, a tunnel is created to the SSH port of a remote Linux server. The rport server has tied the other end of the tunnel to the port 29304. Let's say your RPort server has the FQDN rport.example.com. To access the remote Linux server via SSH use ssh -p 29304 user@rport.example.com.
If you want to connect the remote desk client to the public end of a tunnel, specify the port after the server name, separated by a colon.
A so-called service forwarding allows you to access resources on a remote network where the rport client is not installed or cannot be installed. A typical use case is getting access to configuration of routers, switches and printers. But a service forwarding is also used to access SSH or RDP on servers, where the rport client cannot run. Any rport client can act as a bridge, creating a service forwarding to external TCP ports.
Look at the example to understand how it works.
The rport client runs on a host called ITXC located in a 192.168.249.0/24 subnet.
The tunnel will create a service forwarding for the RDP port to a neighbor server with the IP address 192.168.249.33.
The service forwarding will be stored in the library. Using this feature, you and your teammates can re-launch the service forwarding with a single click, without entering all the details again.
Starting with RPort 0.5.0 the rport server comes with a built-in HTTP reverse proxy. This reverse proxy can be activated for all tunnels using the http or https scheme.
A typical use case is accessing web-based configurations inside an intranet. You could access any TCP port without a proxy with previous versions, but the new proxy option brings two significant advantages:
All communication from your browser to the end of the tunnel on the rport server is encrypted using HTTPS with valid certificates that doesn't confuse users with warnings.
If the tunnel points to an HTTPS target with invalid certificates, the proxy puts valid certificates on top, avoiding warnings and unsecure communication.
❗The proxy will always listen on a secure HTTPS port on the public side. Using the proxy without encryption is not supported.
On the creation of a tunnel, just activate Enable HTTP Reverse Proxy. 👀Pay attention to the optional host-header. Many web servers use so-called virtual hosts. If the connection does not specify the right host – the name of the site you want to access – the connection might fail, or you land on some default site. Use the domain that you would use to access the site without a tunnel as host-header.
The below example shows how to access the web-based configuration of a router through a tunnel. Because without a tunnel, you would access the router by its internal host name fritz.box this name is used as host-header.
After the tunnel is created, the "exposed port" is where the proxy listens. All requests are forwarded to the end of the tunnel. Clicking the "Launch Tunnel" icon will open a new browser windows or tab on the exposed port.
Depending on the selected protocol (scheme) your browser will launch the application registered as default application (handler) for that scheme. For example, on Linux and Mac desktops, all links with a ssh:// scheme will be opened in a terminal that automatically starts the ssh client. You can achieve this behavior on Windows too. .
Remote desktop connections will not directly open from the browser. Clicking on the "Launch Tunnel" button triggers the download of an RDP configuration file. This file contains all details for the connection. Just double-click on it. On Windows and Mac the Microsoft Remote Desktop opens and connects you. On Linux should open. If not, make Remmina the default application for *.rdp files.
RPort servers >= 0.5.0 installed with the and the have the reverse proxy function enabled by default. If you have upgraded from older versions, the function.
Starting with RPort-Server 0.6.0 the NoVNC proxy and the NoVNC javascript client is included into the server. You directly connect to a remote VNC server from your browser. No VNC viewer is needed.
