Client is not connecting

If a client does not connect, likely a firewall causes the problem. Let's check this quickly from the command line.

Check the connection

Grab the address and port of your RPort sever.

Open the configuration file /etc/rport/rport.conf or C:\Program Files\rport\rport.conf with a text editor and look for the line that contains your RPort sever address. Or grab it directly from the console using grep "server =" /etc/rport/rport.conf on Linux or find "server =" "C:\Program Files\rport\rport.conf" on Windows.

The server settings consist of the FQDN or IP Address and the port, divided by colon. Optionally there is a protocol prefix http://.

Example: server = "v0e0vj4l5j1m.users.rport.io:80" The server address is v0e0vj4l5j1m.users.rport.io and the port is 80.

On Linux, execute echo > /dev/tcp/<SERVER>/<PPORT> && echo "All good"||echo "Server not reachable".

echo > /dev/tcp/v0e0vj4l5j1m.users.rport.io/80 && echo "All good"||echo "Server not reachable"
-bash: connect: No route to host
-bash: /dev/tcp/v0e0vj4l5j1m.users.rport.io/80: No route to host
Server not reachable

On Windows, use the PowerShell and execute Test-NetConnection -ComputerName <SERVER> -Port <PORT>.

If the above check fails, a firewall is blocking the outgoing connections.

Observe the logs

If the client is not connecting, you should look at the logs.

From a Windows PowerShell execute Get-Content "C:\Program Files\rport\rport.log"| Select-Object -Last 100.

From a Linux console execute tail -n 100 /var/log/rport/rport.log.

You might get a hint why the client is not connecting.

Check for transparent proxies

Some networks have implemented a so-called transparent proxy. All outgoing connection targeting a remote port 80 are intercepted and redirected through an HTTP proxy. Usually, this is done for automatic virus scanning or blockage of malicious websites. Because RPort uses encryption on application layer, a proxy cannot scan the packets send by the rport client. Most proxies deny the connection if they can't consider them as harmless.

How to solve such issues?

Create an exemption rule in the scanning engine of the proxy and exclude your rport server address from all scanning.

Use multiple ports for client connections

If the above is not possible, try using a different port than 80. If only a few clients are affected, do not change the client connections port of your RPort server. Just bring a second port that can be used as an alternative to the main port. The fastest way for doing this, is using rinetd. Install it by executing apt-get install rinetd, and create a config in /etc/rinetd.conf like the example below.

/etc/rinetd.conf

# Open port 8345 and forward to 80. 
# bindadress    bindport  connectaddress  connectport
0.0.0.0         8345      127.0.0.1       80 

Restart with service rinetd restart.

If you have numerous clients connecting through rinetd, you might get an error like socket(): Too many open files. On most distributions, the old system-v-inet is used to manage rinetd. Check systemctl status rinetd . If you get Loaded: loaded (/etc/init.d/rinetd; generated)the modern and de-facto standard, Systemd is not used.

Create a file /etc/systemd/system/rinetd.service with the following content:

/etc/systemd/system/rinetd.service

[Unit]
Description=internet redirection server
After=network.target network-online.target
Requires=network-online.target

[Service]
User=root
Group=root
ExecStart=/usr/sbin/rinetd -f -c /etc/rinetd.conf
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Pay attention to line 11 and 12. Now you have increased the limits to its maximum. To activate the new systemd service file, execute

systemctl daemon-reload
systemctl stop rinetd
systemctl start rinetd
systemctl status rinetd # should print "loaded /etc/systemd/system/rinetd.service"
systemctl enable rinetd