Is it possible to seed with Deluge in internal network?

[FishBoneEK]

Hello!

My computer is in an internal network (using NAT, that is), thus I find some trouble seeding.
I also have a VPS which I have root access on. I use it as my proxy server.

For now I can download at high speed, but I can't seed.

If I let deluged not use my proxy server, I imagine no one can connect to me because of NAT.

If I let deluged use my proxy server, taking SOCKS5 as example, the only way other peers can connect to me is via the BINDing in SOCKS5 protocol, however according to SOCKS5 protocol the client cannot specify which port the SOCKS5 server should listen on for remote peers. Although the SOCKS5 server responds with the listening address, but it's random and so each time the client posts a BIND request, the client has to announce its listening address to trackers and DHT nodes, thus is not quite feasible. Plus...I tried to monitor the port status on my VPS, and I observed no BIND requests nor UDP ASSOCIATE requests.
And about other proxy protocols...frankly I'm not familiar with them.

If I penetrate my internal network (via https://github.com/ehang-io/nps), other peers are able to connect to me via connecting to my VPS, but I cannot find any setting to let deluged announce a user specified listening address. And...I found that BT clients check if the address of connecting peer is correct by comparing to the peer list obtained from trackers and DHT nodes, so if I use penetration, from deluged's view, all connecting peers are on localhost, I don't know how deluged will react to this?

Thanks!

[FishBoneEK]

I tried to use transparent proxying and policy routing on my computer (done by another application, so deluged is configured to not use proxy, traffic is stilled proxied ofc) plus internal network penetration, now I see some peers connecting via my proxy server.

Still not seeding though, but it's probably because there's too few peers trying to download the resource I'm downloading. Will keep testing.

[ambipro]

Unless you have something like wireguard setup with port forwarding enabled, you're proxy server will not be able to seed at all effectively. Only possible when you connect to peers and they then request pieces from you.

If you are using socks5, port forwarding like this is not possible.

IIRC Deluge get's its announce IP from a check it does, not from you.

[FishBoneEK]

Unless you have something like wireguard setup with port forwarding enabled, you're proxy server will not be able to seed at all effectively. Only possible when you connect to peers and they then request pieces from you.

If you are using socks5, port forwarding like this is not possible.

IIRC Deluge get's its announce IP from a check it does, not from you.

Is it really not possible?
What about this: the BT client in a internal network uses the proxy for all outgoing traffic, and announce its IP with a user specified IP (e.g. the IP of the proxy server), also internal net penetration is applied on the client and the proxy server: all incoming connection to the proxy is forwarded to the client, and the client doesn't check the address of incoming connections. So that the client acts as if it's running on the proxy server.

If Deluge doesn't support the scenario above, do you know if there's any other BT client that is capable of it?

By the way, I understand that WireGuard helps with this, but WireGuard's traffic is easy to detect, so if I use WireGuard there's high chance that my proxy will get banned. In addition, I use a custom solution to connect to my proxy via TCP, so I don't need to worry about TCP; however my solution doesn't work on UDP (at least it needs an amount of work to make it work on UDP), so WireGuard...is just not suitable for me.

[ambipro]

You're making this way harder than it needs to be. You also haven't given any description of what you are actually trying to use, just an example of SOCKS5. SOCKS5 is incredibly insecure and easy to detect, it's general practice to avoid it for torrenting as it is incompatible with seeding and potentially leaks your IP.

Wireguard is the "latest and greatest". There is no reason to tie yourself to inferior and pretty generally unworkable solutions.

I'm not saying you HAVE to use Wireguard, but for torrenting it is considered the cream of the crop in VPN/Proxy protocols. There are plenty of alternatives besides it, OpenVPN is one. Paying for something like Torguard and having it done by professionals who design their system for this use-case is another.

All that said, I'm not going to be able to help you with setting up something on an incredibly vague description of theories and no information on the choice of the proxy/protocol, daemon/server, or OS/Environment.

[FishBoneEK]

Sorry if my description is not helpful, will try to give more detailed info here.

Censorship in my nation sniffs traffic, and if it determines that your traffic is VPN/proxy related, your proxy server will get banned by dropping packets. Though my nation won't accuse me for using torrent.
Thus I wrote a program that encrypts TCP traffic. It's explicitly designed to make all traffics to look like random bytes, including the handshake part. And I establish proxy connections (VLESS, SOCKS5 e.t.c.) under this "tunnel". However it takes an amount of work to make it work on UDP.
For alternatives beside WireGuard, OpenVPN is pay-to-use and I wish to find an open source solution. If there's a VPN that runs on TCP only, I can try to make in run under my "tunnel", and in this case I think it would be nice.
So in summary, I have a VPS, a program that encrypts TCP, I'm able to set up proxy and internal net penetration. My nation sniffs traffic. And I want to find a solution to seed in internal network, based on these conditions.

Also, my VPS is hosted by Bandwagon, located in USA, running Ubuntu, and my conneciton to it is around 10MB/s. My OS is Arch Linux, running Linux 6.5.7. I use v2ray and x-ray for doing policy routing e.t.c., and they support HTTP, SOCKS5, VMESS, VLESS, TROJAN e.t.c..

[ambipro]

This sounds like an incredibly over-engineered solution to a relatively simple problem.

That being said, OpenVPN is open source, and while VPN provider may charge you, you can easily use it for free. Source code available https://openvpn.net/source-code/ on their website.

Wireguard and OpenVPN are two of the more popular proxy/VPN protocols. There is nothing about them that inherently charges you anything to use it, except the provider.

By the sound of it, though, Deluge is not going to be the reason this doesn't work specifically, but your ability to receive incoming traffic properly. Much like I've been mentioning.

There's not much help I can give you, as I've never written a program like that, or seen yours.

Sorry.

[FishBoneEK]

Thanks for your reply!

I saw that big "Pricing" button on their home page and thought OpenVPN is pay-to-use. Looks like OpenVPN can operate on TCP only, I will try it out.

About my program, sorry I can't provide much more info, because it's functional only when it's not popular, thus I didn't open source it but kept it in my private repo.
And it's not over-engineered...or perhaps it is...but I enjoyed coding my program, and found it really useful for me so far.

Anyways, will go try OpenVPN (over my "tunnel", hehe). Thanks for your patience!

[FishBoneEK]

I set up the OpenVPN today, it seems to be working:
I can seed now, though speed is kind of slow, doesn't matter though.
No more "Port Issue" warning at the down right corner of deluge-gtk.
tcpdump shows incoming connections.

Although for now I need to edit my routing table manually, will see if I can fix it via NetworkManager.

Thanks!

[FishBoneEK]

After days of trying, here comes my solution v2.0 (UDP doesn't seem to work though, but download/upload speed is fast enough)

OpenVPN is too slow (download max 3MB/s), thus I did some work on my "tunnel" to make it support UDP, and then tried WireGuard. According to the web, WireGuard should be fast, but because of the QoS limitation of my nation, UDP traffic is...slower than it should be. Latency is OK, but when it comes to speedy transmission, it just gets slowed down. So in my case, WireGuard...is even slower than OpenVPN.

I recalled that Deluge doesn't seem to listen TCP on localhost if proxy is used, some digging shows that it's libtorrent's problem. libtorrent seems to not listen TCP in fear of leaking traffic. However, there's a patch enabling listening: https://xcel.me/qbittorrent-listening-o ... ing-proxy/
I applied this patch and built the libtorrent runtime library, started up my "tunnel", proxy and internal network penetration on my VPS, this time it works: outgoing traffic goes through my tunnel and my proxy, incoming traffic goes through the penetration, arriving to the forced-to-listen Deluge client. Speed looks fine, I'm content with the result.

The plugin ltconfig (recommended by @ambipro) is also used. I use it to enable 2 libtorrent options:
1) allow_multiple_connections_per_ip: because penetration is applied, all incoming peers will show up as 127.0.0.1 to Deluge. This option must be enabled, otherwise only 1 incoming connection will be allowed.
2) announce_to_all_trackers: This is disabled by default (see posts above), enabling makes Deluge to connect to A LOT more peers (from ~10 originally, to ~20 currently)
Also thanks to @ambipro who provided advice on working around a bug in ltconfig. If you are unable to toggle options in ltconfig, see posts above.

However, when proxy is enabled, libtorrent doesn't seem to send DHT messages. Well, I'm satisfied anyways, if I wanna fix it I will see if there's any option I can enable, or search on the web, or dig into the code to make a patch e.t.c..

Hehe, feeling good to see that I can download and upload BT at a relatively high speed, while sitting back in NAT and firewalls.