ANSWERED Changed forwarded port for rtorrent, now connection refused (111)

[cccthats3cs 9]

Hello

I had a need to change a forwarded port using rtorrent. After changing the port, restarting rtorrent, and restarting that specific server to avoid any issues and reconnect to AirVPN automatically, I am now getting connection refused (111), as well as the ruTorrent web interface reporting that the port is closed. The previous port worked without issues.

I have changed the port to the new port in the .rtorrent.rc config file, e.g. with a new port 12345, the port range is correctly set in the config file to 12345-12345 to use only that port.

EDIT TO ADD: I forgot to list the pertinent information from client area.
- Port is in pool 1
- Port is enabled
- Port is using TCP+UDP
- Port is using IPv4+IPv6
- Local port is the same as forwarded port
- Device is set correctly.
This setup replicates exactly other rtorrent instances with their own forwarded ports, set to separate devices. Nothing about this particular port/device setup is different from any other working setups, running the same rtorrent and same port config, just adjusted for the specific port in question.

This command output shows rtorrent is listening only on IPv6:
sudo lsof -i -P -n | grep LISTEN | grep rtorrent
rtorrent   935         seedbox   14u  IPv6  31415      0t0  TCP 10.161.167.49:37875 (LISTEN)

I downloaded and compared manually a new config file to my existing one, which has no differences aside from a different entry IP being used.

A user reported this issue on Debian forums here
https://forums.debian.net/viewtopic.php?t=80017
and mentioned that it was an ISP issue.

I previously had to switch ports when moving to AirVPN from another provider which worked without issue after changing the ports in the .rtorrent.rc config.

Any advice is appreciated, I have been through 2 new ports now trying to fix this.

Thanks

[Staff 9921]

@cccthats3cs

Hello!

This account can not connect to VPN servers so we can't verify on our side (you probably have another account). Please open a ticket or a thread to let us know your account name in AirVPN if you want to have us verify that the settings for your account on our side are properly implemented in the VPN servers you connect to.

Kind regards
 

[cccthats3cs 9]

Opened a ticket under my other account. I use this account exclusively for the forum here.

[cccthats3cs 9]

Situation appears to be resolved after opening a support ticket.

[Staff 9921]

@cccthats3cs

Hello!

For the readers too.

The problem was most probably caused by a rare conflict caused by a vicious bug which has been resolved. Haedus runs on a kernel based exclusively on nftables, but with iptables-nft userspace utility still available when the system basic files are uploaded in RAM.

An old script of ours invoked iptables-nft once during the bootstrap and triggered the feared "translations" back an forth between iptables and nftables, which in turn caused rare troubles in adding and removing rules for remote inbound port forwarding. This series of unfortunate events was resolved by fixing the script (no more iptables-nft, of course). Fix deployment has been ongoing on the infrastructure since a week ago but was not yet rolled out on Haedus. The fix is deployed gradually because in general the bug does not cause these issues and also because a complete clients disconnection is required to bring back the system to a "no nft/iptables hybrid" status.

Thank you!

Kind regards
 

[cccthats3cs 9]

Thank you for the information. I greatly appreciate your assistance in promptly resolving this issue as well as the transparency in the above message.