Rtorrent: "Safety" of the '-b' bind option for VPN usage.

[mhertz]

Sorry, hope it's okay for me to ask a question here :)

I have setup split-tunneling with my VPN and just use the rtorrent '-b' option to bind to local IP of VPN and relies on that for "kill-switch behaviour" and use regular non-VPN connection for everything else. If this(-b switch of rtorrent) works consistently, then it's a full-proof method for avoiding IP leaks and don't need any iptables roules or anything else like that, and is what I use now, but I was worried how much I should rely on this? I know it's not the same, but I used to use rasterbar's libtorrent through deluge-console and there I had setup a socks5 proxy and enabled an option for always forcing traffic through the proxy(force_proxy), no matter if it wen't down or error'ed out and I asked the lead-dev how safe this was, and he said he had added internal tests for it to check that it applied, but of course there where the risk of bugs where it would no longer apply in some specific circumstance.

Thanks alot for any advice in advance.

-Martin.

[chros73]

I've just created a VPN with Traffic Splitting WIKI page, still fresh and warm :)
Enjoy!

[mhertz]

Thanks chros73, much appreciate your reply, and efforts, in ps-ch fork and general help around :) Yeah, I remember seeing you post a pull request on the namespaced-openvpn project I saw a little time ago when researching best solution for this, if I needed to change my already setup split-tunnel.

I'm considering going that route also, but just thought that since I already have a nice setup working nicely, then I only wanted to change if the -b switch of rtorrent wasen't meant to be completely relied upon always. I've made a rtorrent-vpn script which starts the VPN and setups PIA port-forwarding and starts rtorrent with forwarded VPN-port and bound to the tun0 interface :) I actually made this "issue" question-post here to get to know if I needed to change to namespaced-openvpn or if the rtorrent binding option where "safe" enough. I'm just talking IP leaks here, nothing else, btw.

Thanks again, i'm thinking about it for sure, but still would much appreciate if anyone had any opinions upon how much reliance in general we assume to rely on the bind rtorrent option being "fool-proof or not" :)

Oh, sorry, about the wiki article, then will the port not work anymore hence your recommendation for a socket, or is it a security meassure in general(the port works fine for me currently with my setup bound to tun0). Also, why the need for updating the IP field? Since only LO and tun0 are available in run namespace, then doesn't rtorrent pick the IP up by itself from tun0(or whatever named) ? Lastly, I only get one port-forward from my VPN-provider, so do you know if I can use that as both the regular TCP port and DHT UDP port? Thanks again!

Edit: Sorry, some of my questions, I could just test for myself of course. The scgi port doesn't work as you state and hence needs a socket. However, I still don't understand the IP needing to be defined, as I checked with the ipmagnet site that the correct VPN IP was used to pass to tracker. Ohh, maybe it's related to the DNS-thing you implement, which I skipped, as no use for personally. Lastly, why do you specifically add the writepid option to namespaced-openvpn command? I don't use that, and wondered if I was missing something.

I'm pretty sure i'll change over to this technique as i'm sure the answer to my question originally, will be that it should work, but of course cannot be guarantied because of unknown bugs now or later.

I just tested this and it's pretty cool, i'l adapt my script now! :) Thanks again in advance!

[chros73]

Hey! :)

I already have a nice setup working nicely ... if the rtorrent binding option where "safe" enough.

There was a similar question lately and I asked the same thing: "How exactly?" :) Because there's loads of ways to achieve this. :)
You can test it easily by terminating the tunnel and see what rtorrent does.
Of course, we don't even mentioned the rest of the security concerns.

And you also answered your own question :) :

it should work, but of course cannot be guarantied because of unknown bugs now or later

Although I have to tell you that using only certain private trackers doesn't even require a VPN connection, for now at least. :)

will the port not work anymore hence your recommendation for a socket, or is it a security measure in general ... The scgi port doesn't work as you state and hence needs a socket

It works but not locally if you use namespaces: it can be reached via the tunnel.
But for both security and separation of concerns it's best to use a socket.

why the need for updating the IP field? ... I still don't understand the IP needing to be defined

Good question, honestly I don't really know either whether it's still necessary or just certain trackers need it. network.local_address is a special way that rtorrent uses to report the local IP to trackers: if it's set then rtorrent uses it, otherwise it doesn't. But it can't hurt to set it. :)

Since only LO and tun0 are available in run namespace, then doesn't rtorrent pick the IP up by itself from tun0 ... maybe it's related to the DNS-thing you implement ...

It's nothing to do with any of them, see above.

I only get one port-forward from my VPN-provider, so do you know if I can use that as both the regular TCP port and DHT UDP port?

I don't know really. I just tried out setting the same ports and it seems to work. One thing is for sure that rtorrent uses a different port for this by default. Try it out, leave it for couple of days and see if any misbehaviour is happening.

why do you specifically add the writepid option to namespaced-openvpn command?

No reason, by tradition. :)

I just tested this and it's pretty cool, i'l adapt my script now! :)

Congrats! :) It's easy and foolproof :)

[mhertz]

Thanks alot again chros :) I much appreciate you took the time to go through all my questions, thank you!

I used before this method here, though changed little to match my system and add port-forwarding and setup tunnel automatically and close it when rtorrent quits etc: https://gist.github.com/awidegreen/825794317f98a941107f

I did test it many times, and it did stop whenever the VPN was closed, but i'm just a little paranoid and still wondered in general, though agreed my question was self-explanatory as you stated :)

I omit the IP defining personally, as it's used when needing to separate out the source-ip of the tracker announce from the correct IP that should be used e.g. when running own tracker, but I tested that the source-address correctly comes from the VPN-IP, so don't need to. Sorry I know you know this too, and as you say, it doesn't hurt either :)

Thanks again mate, much appreciated again! :)

CU around,

Martin.

[chros73]

Awesome!
Just one more thing: it doesn't hurt either to utilize @sallyswiss's IPv4 filter enhancement :)

Take care!

[mhertz]

Cool, I much appreciate your advice, and just closed to not "pollute" the open issues-section :) I'll look into that too, thanks mate :)