Deluge
Hi,
I have been using deluge on my Synology ds920+ NAS.
I installed the docker container with the vpn provider adapter bound in deluge for 'outgoing interface' and the ip address of the vpn adapter defined for 'incoming address' yet the external ip address shown in the web ui is my isp ip address.
I've checked in different ways and confirmed that traffic is going through the vpn.
ran this "curl http://ifconfig.co" inside the docker container and shows the vpn ip
also checked the ip of torrents and every time it showed the vpn ip and also checked https://iknowwhatyoudownload.com, it shows stuff I downloaded with the vpn ip and with my isp ip doesn't show anything.
I looks like a bug on the listed public ip in the web ui.
web UI showing my ip, not vpn ip
Re: web UI showing my ip, not vpn ip
I cannot say why happens, sorry, but here's an older thread where I explained in detail how that IP is gotten(from libtorrent docs), and same api function used for retrieving it from a libtorrent alert, in webui/gtkui/console-UI.
viewtopic.php?t=56243
As said there, it's a guess of several sources, but sounds like possibly a leak. I would change to interface name also in incoming, as supported also(and 'incoming' control announcing out in libtorrent, counter-intuitively). I'm thinking if you entered the vpn routable ip by mistake there, and not local adapter one - cannot remember what happens if trying bind to wrong address I.e if it just falls back to default or what.
In a later post in that linked thread, I stated with binding to vpn it lists here the vpn ip or n/a, and when not binding, then in 10 tries lists between vpn ip, own ip and n/a.
Anyway, hope helps with binding to interface name instead.
viewtopic.php?t=56243
As said there, it's a guess of several sources, but sounds like possibly a leak. I would change to interface name also in incoming, as supported also(and 'incoming' control announcing out in libtorrent, counter-intuitively). I'm thinking if you entered the vpn routable ip by mistake there, and not local adapter one - cannot remember what happens if trying bind to wrong address I.e if it just falls back to default or what.
In a later post in that linked thread, I stated with binding to vpn it lists here the vpn ip or n/a, and when not binding, then in 10 tries lists between vpn ip, own ip and n/a.
Anyway, hope helps with binding to interface name instead.
Re: web UI showing my ip, not vpn ip
Already done, it is bound to the vpn interface, and we also specify the vpn adapters ip for incoming, so yeah not much else i can do here unless im missing a setting in the ui.Anyway, hope helps with binding to interface name instead.
but there is no way to do that, you can only set the incoming address, and if you try and force this by editing the core.conf it simply errors, so i dont know how to achieve thisI would change to interface name also in incoming
Re: web UI showing my ip, not vpn ip
If using local vpn IP for incoming, then yeah shouldn't make a diff, but might as well use interface if could, but apparently not, sorry. Not at my computer now, but just began to remember there I believe once raised issue with checking if e.g interface exist, in thinclient, as checked on client-side, not server, but I thought was fixed, but apparently not, sorry, or else I'm confusing things up.
Anyway, if sure that bound in/out correctly, ip or interface names not important in that case, then probably nothing to worry about, but I would to make sure, check e.g a torrent ip checker like ipmagnet sadly down now, but many alternatives available, though liked that because thoroughly also checked any possible ipv4/ipv6/ip fields included with announce(in addition to regular practise of registering src address of announce packet), and/or didn't stop after first announce arrived, and some of the other ones I believe don't, but another which I'm guessing include that too(guessing because source not available, in contrary to ipmagnet), atleast detected my own ip + vpn in test where not binding, and another test site didn't(only showed vpn), was ipleak.net's test, so would recommend try that magnet test, in addition to rest tests you already outlined doing.
Anyway, if sure that bound in/out correctly, ip or interface names not important in that case, then probably nothing to worry about, but I would to make sure, check e.g a torrent ip checker like ipmagnet sadly down now, but many alternatives available, though liked that because thoroughly also checked any possible ipv4/ipv6/ip fields included with announce(in addition to regular practise of registering src address of announce packet), and/or didn't stop after first announce arrived, and some of the other ones I believe don't, but another which I'm guessing include that too(guessing because source not available, in contrary to ipmagnet), atleast detected my own ip + vpn in test where not binding, and another test site didn't(only showed vpn), was ipleak.net's test, so would recommend try that magnet test, in addition to rest tests you already outlined doing.