Rtorrent: Leaking IPv6 local public addresses to tracker although IPv6 is behind VPN and DNAT+SNAT'd to other public address.

[Nodens-]

The setup:
Local server with VPN tunnel to a remote server. All traffic is tunneled.
Both local ipv4 and ipv6 are being masqueraded to their own unique public IPs on the remote server via DNAT & SNAT rules.
visual scheme example:
private local ipv4->vpn tunnel->unique public remote ipv4
public local ipv6->vpn tunnel->unique public remote ipv6

For all intends and purposes the local server is seen and contacted via its assigned addresses on the remote server.

The problem is that rtorrent is announcing the public local ipv6 address which can easily be tested with the magnet test on ipleak.net.

What has been tested:
network.local_address.set = vpn interface ipv4 address
result: rtorrent announces vpn interface ipv4 address and public local ipv6

network.local_address.set = unique public remote ipv6
result: rtorrent announces only public local ipv6

network.local_address.set = dns.name.com (which has A and AAAA records pointing to the unique public remote addresses
result: rtorrent announces public remote ipv4 and public local ipv6

Is there any way to mitigate this security issue?
Disabling IPv6 is not an option for many reasons but primarily because this server is serving multiple services to the internet including a mail server that needs to listen to both IPv6 and IPv4 stacks.
If it is not currently possible to rectify the announce behavior, is there any way to stop rtorrent specifically from using IPv6 as a temporary workaround?

[chros73]

Which version of rtorrent/libtorrent?
If 0.9.7/0.13.7 then you can try to build from one feature-bind branch and test it.

[Nodens-]

Yes it's 0.9.7/0.13.7. I will build and test feature-bind. Is there any documentation for it? Or a commit I could examine?

EDIT: For clarification, documentation of feature-bind not on building :)

[chros73]

There's none, you can go through the commits if you want.

[Nodens-]

After testing, this is apparently fixed on feature-bind branch without any binding to ips or anything of the sort. I am closing this.

Is there a relative timeframe for merging with master? Trying to figure out if I should script building xmlrpc-c+libtorrent+rtorrent for deployment on other Fedora systems or just wait for it to land on the repos. Thanks.

[chros73]

Is there a relative timeframe for merging with master?

Only @rakshasa can answer this, but I don't think it will happen in the near future (not to mention creating new release).

... if I should script building ...

You can try to use the build script of rtorrent-ps-ch to build vanilla rtorrent from feature-bind branch:

• modify the git_lt / git_rt variables to: feature-bind
• delete the vanilla_lt_all_00-openssl_11_fix.patch from patches dir
• run: time nice -n 19 ./build.sh vanilla git

[Nodens-]

Excellent! Thank you very much!