Deluge Forum

Posted: **Sat Jun 05, 2021 2:58 pm**

Hello all

I don't know if this is deluge or the tracker - the torrent leak tests show
that deluge sends them the public IP address.

Also deluge-gtk on the status line is showing me the correct public IP on the status bar

BUT ... BUT the deluged log file is saying that some trackers are getting the
VPN service's internal IP address (below I show what whois says about it)
- I replaced the IP address with the whois response

Code: Select all

[SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED:port]

from the deluged log file:

Code: Select all

09:24:23 [DEBUG   ][deluge.core.alertmanager      :130 ] tracker_error_alert: torrent name XXXX  
(http://XXXXX.xxx.org/xxxxx/announce)
[SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED:port] 
tracker sent a failure message "non routable IP found" (1)

When I put the public IP address in the deluge config option "Outgoing Interface"
it doesn't make a difference

Posted: **Sat Jun 05, 2021 4:03 pm**

It's not deluge, but libtorrent and the openvpn client not restricting the routes allowed through. I've seen this issue before on a win10 VM running the open-source openvpn.net client there, though strangely not when using same client on linux(running bare for testing, and not using extra protection measures). I actually posted bug-ticket about it on libtorrent github issues section, but in end it was intended behaviour concensus was, because of the added multi-homing support of libtorrent 1.2.(3 or 4)+. I just tested now on linux and libtorrent 1.2.11 and didn't see it as usual, but didn't test on my win10 VM sorry.

With newer libtorrents, it's up to us now, to restrict further the communication - well of course have always been like that i.e. regarding kill-switches, but I mean the added issue of also leaking when VPN is fully up and running without interuption, because of said multi-homing support added.

So, either use vpn-client with killswicth behaviour, and/or bind to VPN in torrent-client and/or use firewall rules to restrict access, and/or other meassures like namespaces etc.

If using deluge's interface binding to restrict this, then set both in and out, and it's actually the 'in' which controls which ip is announced to trackers and not 'out', counter-intuitively - more info on this in libtorrent api docs(settings_pack - listen_interfaces / outgoing_interfaces).

Edit: Stopped being so damn lazy and fired up my win10 VM to test there also

Leaked own/real IP as usual, and announced both VPN IP and own IP in two seperate announces sent - tested both libtorrent 1.2.13 and 1.2.10, as had them laying around there already from older times, again openvpn.net community(open-source) client, deluge-dev and no interface bindings defined - when actually binding 'in' and 'out', then no leaks and only VPN IP announced - I had an unmerged PR by strangelovian applied, so I could use interface name(GUID on windows) in both 'in' and 'out', instead of checking VPN local IP after every VPN startup and add to 'in' and 'out', but doesn't change the inner working otherwise, so irrelevant and just referrenced for full-disclosure or how it's put.

Deluge Forum

deluge sends interface IP, not public IP

deluge sends interface IP, not public IP

Re: deluge sends interface IP, not public IP