Problem
Presentation
Recently, I tried out some networking shenanigans. I was attempting to isolate the route across a commercial VPN with a SOCKS5 server. Programs elsewhere on the LAN would be configured to pass through that proxy when I desired to move traffic out the VPN. qBittorrent (5.1.2) was one such program, marked to proxy announces and peer connections. Unfortunately, this use of a SOCKS5 proxy in qB presented an issue with announces to a certain tracker. Announces were rejected, and I received a message reported back of ‘port 1 is blacklisted.’
Explanation
The problem boils down to the listening port being unset when a proxy is configured and ‘use proxy for peer connections’ is enabled. This effectively disables inbound peer connections, and makes that fact known to trackers through your announces.
Tracker operators can choose to blacklist clients which say they listen on certain ports. For at least one piece of tracker software, this is interpreted as port 1. Presumably the tracker in question for me blacklists the entire privileged port range.
This behavior was implemented in qB with the understanding that one cannot accept unsolicited incoming connections through a SOCKS proxy by design. To be connectable when making use of the proxy feature for peer connections, one would have to consider additional networking intervention such as a reverse TCP proxy to route inbound traffic from the proxy server back to the client machine.
This is obviously out of the scope of the BitTorrent client, and it was presumed that broadcasting that the client is unconnectable to trackers would be better for swarm health considering the very reasonable assumption that the majority of proxy users wouldn’t go to the lengths required to be otherwise.
That said, this frankly opinionated behavior isn’t uniformly applied in qB; when the client knows your unconnectable from other means, it doesn’t unset the listening port. I’d call this an inconsistent and unintuitive implementation detail.
Solution
... continue reading