Libtorrent 1.2.3+ announces own IP with certain openvpn clients on windows.

[mhertz]

(Edited title of ticket after getting a better understanding of things, from replies further down - originally assumed it was all openvpn clients on windows 10 using libtorrent 1.2.7 that was affected - seemingly not actually an issue in libtorrent either, but unfortunate it doesn't work out of the box in some combos, which wasen't the original assumption)

I noticed that with ipmagnet testing website, then on windows, libtorrent 1.2.7 using either deluge or qbittorrent, lists announces from both VPN IP and own IP. If i'm not mistaken, that would mean your true IP would be announced to trackers and swarm, on windows, using libtorrent 1.2.7 with a VPN. Didn't test RC_1_2 yet. On linux, I tested deluge with libtorrent 1.2.7 and it didn't occure there i.e. only VPN IP listed on ipmagnet website. Guessing it's related to that multi-homed thing you implemented after 1.2.3.

Thanks in advance.

[FranciscoPombal]

In qBittorrent, do you still experience this even after restricting the values of the advanced settings "optional IP address to bind to" and "network interface" to the corresponding values of the VPN interface?

[arvidn]

@FranciscoPombal what do those options do?
It's still disconcerting that it wouldn't work out-of-the-box, which it's supposed to.
@mhertz which version of windows are you using?
what kind of VPN do you use?
Does it add a virtual network adapter?
What does qbt say in its log, regarding which interfaces it's listening on?

[mhertz]

Firstly, I much apologize, as somehow got in my head that the latest qbittorrent installer for windows was using libtorrent 1.2.7, but remembered wrong, and was 1.2.6. I'm sorry for wrong report.

However, still applies for issue.

FranciscoPombal,

I don't experience this during a binding to network interface of TAP device in qbt.

arvidn,

They limits/binds connectivity to specific interface's name/IP. As you state, would be nice working out-of-the-box. Btw, I hope i'm not misunderstanding something fundamentally here, in which case, I apologize in advance.

I tested this in a windows 10 VM(deluge-lt1.2.7/qbt-lt1.2.6), and stationary win10 machine(deluge-lt1.2.7), and linux stationary machine(deluge-lt1.2.7 - arch linux - not affected here).

Windscribe, through openvpn.net's community client, with windscribe's ovpn configs added.

Yes, TAP adapter installed through openvpn.net's community client installer.

It lists that it detects external IP of VPN and next line same with my real IP.

Then as per your question, it states succesfully listening on:

::1
Two different ipv6 addresses.
127.0.0.1.
local IP of VPN.
Local IP of my real public IP.

Sorry for lacking original report.

[ghost]

Can you reproduce it by settings bind to all IPv4 address?

[mhertz]

Yes.

I just checked this time in my win10 VM on linux(virtualbox with bridged networking), and not the other win10 physical machine of family memember, but always where the same before, and/so shouldn't make a difference.

Btw, I check on the ipmagnet website directly, as when just checking the tracker status in qbittorrent for the ipmagnet torrent, then it states 'IP: VPN-IP', but it presumably only lists last announce gotten(as shows latest status report from tracker there), as on website then lists two entries as seperate lines on each new announce, one with own public IPv4 address and one with VPN public IPv4 address.

This is the ipmagnet relevant code: https://github.com/cbdevnet/ipmagnet/blob/master/index.php

If getting an announce with additional &IP, &IPv4 or &IPv6 field, then I believe it lists only one line for each announce, with the extra included IP listed after the main one(SRC address of announce packet), so on same line, and when seperate lines, then it's seperate announces, unless i'm wrong. Same port for both IPs. I checked another site ipleak, which listed the communication transcript, or some of it, and there lists both announces and stopped even etc, and afterwards same with started event etc.

[ghost]

By default qbt would pass 0.0.0.0:port,[::]:port
But since libtorrent expands 0.0.0.0 to include other local IPs that might be causing the leak. Maybe your VPN isn’t forcing all traffic to go through it either.

[mhertz]

Just before coming back to this ticket and reading your post, then I also just finished testing another VPN I have from older times, tigervpn, where I got both as life-time accounts previously, and same happens there(qbittorrent on win10 VM, so libtorrent 1.2.6).

Yeah, i did knew qbt and deluge passes 0.0.0.0:port and probably the IPv6 too ::1, and with the added multi-homed support on-top then sounds like the issue, though arvid stated it supposedly should work however(like other bittorrent implementations using VPNs overtaking default route). As said, nonproducible though on linux(removed my kill-switch first of-course), so openvpn configs seemingly fine.

It should be standard openvpn configs without anything special, and does overtake the primary route like usual. I prefered using the open-source light-weight openvpn community client and just define my own kill-switch, instead of the more bloated official clients, and just downloaded the providers zip of standard openvpn configs for intended usage on nonsupported platforms.

Personally I use linux solely, with namespace tun0 lockdown(using deluge-console), so not affected, but just wanted to report of-course regardless.

[arvidn]

I'm getting the impression that there are VPN clients that rely entirely on the metric or weight of network interfaces, and add a new tun0 interface with the highest priority, assuming that no traffic will go to the lower-priority en0 interface. But without introducing any measures to prevent traffic from going over the real network interface (e.g. en0).

With such set-up, and a client listening to 0.0.0.0, what would prevent a peer to connect directly to that client? i.e. circumventing the VPN. If it is in fact possible to accept an incoming connection via the real IP (not via the VPN), then it's not obvious to me that it's wrong to announce it to trackers and employ UPnP/NAT-PMP/PCP to that network.

I'm not super familiar with what normal VPN software does, but the ones I've tried (on linux, PIA and NordVPN) work as I would expect, where you can't reach the internet from the real interface.

@mhertz would it be possible for you to test whether the real IP is open to the outside with your VPN client?

[mhertz]

Thanks for reply Arvid.

I remember reading a post, on qbittorrent issues section I believe, or elsewhere(possibly deluge forum), and was reported the same, and reporter checked torrent on other machine/connection and saw both IPs listed under peers, where VPN IP was showing traffic, but true IP was stalled at 0.

Also found likewise issue here: qbittorrent/qBittorrent#12961 (airvpn with official client on win10, which is a very reputable VPN)

So seemingly its not accepting connections, but if you want me to still test, then if you kindly could suggest a test-scenario, e.g ssh, port test or something, sorry not that in to networking honestly myself other than the basics.

My issue with this, well in theory as unaffected as stated, is that I read along time ago an older paper about testing torrenting and getting dmca letters, where e.g wifi printers etc was getting letters, as &IP fields sent with embedded IPs of such upon regular torrents, or like-minded techniques, for testing to see if only getting dmca letters if actually trying to download from you with infringed content, or if solely being registered in swarm was enough, so could just harvest IPs from tracker and sort for countries and ISP etc and make copyright claims, which unfortunetly was the case, atleast in said paper.

I understand of-course if there's nothing you can do about it, or if you deem it as correct behavior as stated.

Edit: Sorry, misread and misunderstood at first, so if not getting incoming connections, then indeed an issue, gotcha.

As said, not happening on linux with tun0 and only on windows with TAP-9.

[arvidn]

in order to support multi-homed machines (e.g. machines with both IPv4 and IPv6 connectivity), libtorrent starts a listen socket on each IP on each network interface. It then tries to connect to the tracker from each of them, to announce that IP.

So, the only way an IP is announced to a tracker is by the IP being the source IP of the TCP connection or UDP packet (for UDP trackers). So, if the tracker can see the IP, it seems like a pretty strong indication of the network interface/IP actually being connected to the internet.

There are some heuristics to figure out whether an IP is part of or connected to the network where the tracker is. e.g. 127.0.0.1, does not have a gateway and a netmask that restricts it to IPs the tracker IP most likely is not part of.

The one exception to this are private trackers, where an IP different from the source IP can be reported in the &ipv4= and &ipv6= query parameters. Are you seeing this with a private tracker? if so, do you see either of those parameters in the tracker request?

[mhertz]

I see what you mean. Strange indeed, and that it differentiates with exact same ovpn config upon linux vs windows.

I don't use private trackers, and only stumbled on this during the ipmagnet testing website which I at times runs a quick test at, as usually setup manual routing for torrenting only through VPN, but disabled that here of-course.

Sorry not good with wireshark/tcpdump etc, and so just checked ipleak.net magnet test, which features additional option for showing the request dump, and there no embedded ip fields added/listed.

Are there really not any win10 openvpn users experiencing this through e.g. ipmagnet website or wireshark etc, besides me? Makes me kinda nervous that i'm missing something somehow, but cannot see it as of yet though.

[arvidn]

I will test this on PIA on windows in the next few days (I'm not at my computer at the moment, so I can't reboot it into windows).

@ssiloti do you have any ideas?

The scenario is that on windows10 with VPN, both the VPN IP address as well as the actual IP address are announced to public trackers. As if the main network adapter is still usable after enabling the VPN.

[ssiloti]

I'm not particularly familiar with how VPN software works. If the software isn't somehow masking the underlying interface such that it does not appear as an active interface to applications then it will be required to explicitly configure libtorrent to only use the VPN interface. It's possible there's some flag somewhere which libtorrent could use to detect when the underlying interface should not be used, but I don't see anything obvious in MS's documentation.

[mhertz]

As ssiloti stated, then I guess the openvpn client needs to specifically block/mask true IP interface, which the open-source openvpn windows client seemingly doesn't. It is a pretty popular client however, in which I learned about some years ago when people recommended it over PIA at the time, for less buggy and more lightweight + open-source etc, and I sticked to it after that as liked it.

I believe that client just does the standard openvpn things of changing routing table with added 128.0.0.0 entry to overidde your true IP when an app binds to 0.0.0.0. To specifically block other interfaces I guess the client needs to be more advanced and bring extra meassures as ssiloti stated. Strange the basic open-source openvpn linux client doesn't have this issue though.

Anyway, I tested latest version of official windscribe client, and changed away from default ikev2 and into openvpn and disabled there kill-switch which they call firewall. This then have same issue as the open-source openvpn client. When enabling kill-switch/firewall, then it doesn't. Reading up on it, then windscribe states they include actual firewall into client(possibly they mean interface/wrapper to windows firewall, but regardless), so this obviously would solve the issue that way.

Generally, when choosing the open-source openvpn client, then it's up to you to provide kill-swicth and such if wanted, and solely is basic openvpn period, I believe, but I just didn't think it would be able to announce from true IP when VPN was still up, but seemingly does.

So anyway, this issue seems to be strictly about only specific openvpn clients, on windows, not adding extra steps on-top of the openvpn implementation, just as ssiloti previously stated.

So quite possibly PIA isn't affected through official default windows client, though as per the qbittorrent link I previously in thread posted, then was an issue atleast previously with airvpn too, and libtorrent 1.2.5.

Sorry for titling ticket wrong originally, due to misunderstanding and assuming it was an all-inclusive windows VPN problem, and not client based, on windows.

Edit: Sorry, and as Arvid was saying all along too - just reread all posts, sorry :)

[arvidn]

@mhertz this is super useful information, thanks!

[FranciscoPombal]

@arvidn

@FranciscoPombal what do those options do?

I believe this is the behavior:

• Listen interface -> All IPs corresponding to the selected interface (qBittorrent can only select one value, including Any interface) are passed to settings_pack::listen_interfaces.
• Optional IP address to bind to -> settings_pack::outgoing_interfaces Selected value is passed to this setting. Can only select one value, including All addresses, All IPv4 addresses and All IPv6 addresses. When using one of the latter 3, the libtorrent setting is left blank

[ghbplayer]

It's normal and common for VPNs not to block your direct internet connection. That's the original purpose of VPN, to be connected to some private network virtually. Many people use such connections for work, and don't want all their internet traffic to route through work for performance and privacy reasons.

The sort of VPN providers the torrent community is used to really aren't VPNs at all. They're a hack to hide your IP address and have different settings.

If I'm VPN'd into work and torrent an ISO, I certainly don't want that traffic routed through my work.

The point is, it's not the torrent program's job to decide which IP to use. I can tell LT which interface to use, or I can force an interface with VPN configuration. If I do either or neither, I expect LT to behave like other software. Don't add some hidden heuristic complexity.

[arvidn]

I think the crux is that "all other software" generally makes the assumption "one computer == one IP". With such assumption, all traffic would be routed through the highest priority interface (if, say, the remote network you're connected to advertise a route to the internet, and its interface is configured with higher priority than your local).

libtorrent used to do that until somewhat recently (before 1.2). So, I think all you say makes sense, but users may not have that same mental model.

Perhaps users could be given such mental model by the qBT UI asking explicitly "which interface do you want to use?", and it always picks one (and only one).

If you, on the off-chance, have multiple interfaces, there could be some other check-box to say "I want to use multiple network interfaces".

[FranciscoPombal]

Perhaps users could be given such mental model by the qBT UI asking explicitly "which interface do you want to use?", and it always picks one (and only one).

This is what I always recommend in these kinds of issues: to select a single interface in the "Network Interfaces" drop-down - and it will work (#4803 (comment)):

I don't experience this during a binding to network interface of TAP device in qbt.

The thing is qBittorrent provides an "Any interface" option as the default in said drop-down. I don't think this should stop being the default though. But perhaps a one-time warning at first start-up, or some kind of more sophisticated "on-boarding" experience would be a good thing for VPN users... Or maybe just warn of this situation in the FAQ, download page, etc?

Anyway, in my view, this is not an issue on qBittorrent and libtorrent's side - I think the onus here is on the VPN software (and/or the user configuring the network) to properly prevent programs from using other interfaces - not just to "suggest" via route metrics. It is indeed a shame that this cannot be achieved in a simple way OOTB when using the standard OpenVPN client.

[arvidn]

This is what I always recommend in these kinds of issues: to select a single interface in the "Network Interfaces" drop-down - and it will work (#4803 (comment)):

Would it hurt anyone if this was the default in qbt?

I guess if the first time you start, the direct interface is picked, the next time you start there's a VPN and you're still using the setting from the first run. That might be even more confusing.

[FranciscoPombal]

Would it hurt anyone if this was the default in qbt?

I guess if the first time you start, the direct interface is picked, the next time you start there's a VPN and you're still using the setting from the first run. That might be even more confusing.

Yeah, I agree it would be more confusing that way, that's why I believe the current default is still the better solution.

[ghost]

How about a toggle that will turn off multi homed support and choose the highest priority interface by default? This will eliminate the confusion part to some extent.

[ssiloti]

I would think VPN users want to specify the VPN interface explicitly in their client. Otherwise if the VPN is off for whatever reason (software crashes, user forgets to start it) libtorrent is going to leak torrent traffic over the direct interface.

[ghost]

I would think VPN users want to specify the VPN interface explicitly in their client. Otherwise if the VPN is off for whatever reason (software crashes, user forgets to start it) libtorrent is going to leak torrent traffic over the direct interface.

But we're talking about out of the box experience here?

Currently it's leaking IP out of the box for some VPN users that do not use a firewall. Doesn't have to be a client crash or "forgot to start VPN".
If their software crashes or they forget to start VPN, that would be a different case, If they want to avoid it they simply have to change the interface settings.

[ssiloti]

But we're talking about out of the box experience here?

We are? I don't think the toggle you suggested should be in single home mode by default, so VPN users would need to change a setting either way.

Either way, I contend it is better to leak traffic right away when the user is most likely to notice than to leak it at some unpredictable point in the future when they are unlikely to notice.

[ghbplayer]

I don't use qBT, but my suggestion is to default leaky and have a highly visible warning icon when in leaky mode. Leaky mode is any configuration that doesn't have a single tunnel interface selected. Click the warning icon to select a tunnel interface or disable the warning permanently.

This is usable out of the box, doesn't surprise users, and isn't confusing. Just don't automatically change the selected interface.

One other thing: OVPN is a POS and nobody should rely on that to keep them safe. Even when it's configured perfectly the connections are known to drop at any time.

[mhertz]

In deluge, people generally doesn't use the binding options very much, I believe, and I've seen several requests of how it works there, on the forum, and if interfaces is allowed there, instead of just IPs, you have to type them yourself etc. or change new IP every VPN restart etc.

There's a plugin for it, but only works on linux hosts the project page states, and this wasent an issue on Linux in my tests, and only on windows.

[FranciscoPombal]

I don't use qBT, but my suggestion is to default leaky and have a highly visible warning icon when in leaky mode. Leaky mode is any configuration that doesn't have a single tunnel interface selected. Click the warning icon to select a tunnel interface or disable the warning permanently.

This is usable out of the box, doesn't surprise users, and isn't confusing. Just don't automatically change the selected interface.

There is no "leaky mode" as far as torrent client configurations go. If anything, VPN clients that don't default to forcing all connections through the tunnel interface by stronger means other than routing metrics, are the pieces of software that are defaulting to a "leaky mode", and this is the thing that needs to change.

Either way, I contend it is better to leak traffic right away when the user is most likely to notice than to leak it at some unpredictable point in the future when they are unlikely to notice.

👍, the checkbox is a good idea, but the default should be multihome (i.e. checkbox not toggled by default). IMO, the only purpose of such a checkbox should be to cover the case of "I'm using a setup that relies 100% on routing metrics and want the convenience of using the highest priority interface by default".

[mhertz]

It's "leaky" mode, imho, because many(all?) other torrent implementations/clients doesn't behave like this, if I'm not mistaken. If I am, then I apologize in advance. I tested it didn't happen using libtorrent 1.2.3, which is just before multi-homed support added, I believe.

Also, in the couple other reports I've seen of this, then they never transfer, so Arvids comment about it being OK if accepting incoming connections over own IP, seems like not the case, but don't understand why they dont, or the full picture of this all, honestly.

People know to bind there client to VPN, either in client or through firewall, namespace etc for avoiding leaks when VPN is down, but few would know that you specifically need it to not leak your IP when VPN is fully up and working, as in this case.

I would never use such without some form of protection, or setup such without, for a family member, but just still think it's a special kinda way this is occuring here regardless, for noobs etc.

Strange that openvpn.net's open-source client/libtorrent doesn't do this on Linux, when it's same CLI client and just smacks on a lightweight openvpn-gui in the windows installer.

[mhertz]

Sorry, just wanted to state that I checked that a port I opened with netcat, and forwarded in router, was showing as open on true IP from outside, while VPN on(windows only, doesn't happen on Linux I tested). Also, I tested binding qbittorrent to true interface, and traffic moved fine. Lastly I also tested same without the openvpn-gui and just openvpn.exe, like it's linux-counterpart from same codebase, to be sure it wasen't the gui interferring/adding something strange(as openvpn binary/CLI doesn't do this on linux, with exact same profile).

I think that was the question Arvid asked me in beginning of thread, and later stated that it wouldn't be wrong in his mind to announce that to trackers if it accepted incoming connections. I don't know why the two other reporters stated there real IP in swarm always was stalled, and i'm not really able to test if im in same situation.

As this seemingly is correct behaviour, then I apologize for the noise and please close ticket now or when see fit Arvid, thanks.

It certanly however, needs to be mentioned to people, so they know about this behaviour in certain VPN clients(like the official client, on windows) and newer libtorrent combos(1.2.3+), but that's besides the point, and of-course I fully understand that you should regardless "protect yourself" anyways(firewall/bindings/namespaces), and not have total faith in only the VPN by itself, but as said, this was just really unexpected behaviour here. Likewise, I of-course see the usefullness of multi-homed support, and that this seemingly is bound to happen on that regard, when certain clients(on windows) behave in this way.

Sorry about misconceptions on my side y'all.

[mhertz]

Sorry @arvidn , I hope you will see through/allow a couple off-topic questions here, as I want to iterate on the deluge forum that what I before described as a bug, actually wasent, atleast not in libtorrent, and to specify how to fix it(from the means of libtorrent), and also to know how to answer subsequent requests of help about this, thanks.

1. Am I correct in saying that listen/outgoing_interfaces libtorrent options can both be interface names and/or IPs on both windows and Linux, and that listen_interfaces just needs a port specified additionally, and lastly that for both options only guid uppercased/curly-braced names are only supported type of interface names supported for windows, when using such? (the reference docs e.g state only guids for windows interface names, when used, but only list that for one of the options and not the other)

2. Is the example of windows guid interface name and port a typo or correct, when using double colons when specifying port: {GUID}::7777?

3. Last, but certainly not least, what specifically is reffered to when under outgoing_interfaces it states: "Binding an outgoing connection to a local IP does not necessarily make the connection via the associated NIC/Adapter". So is it needed to specifically use interface name and not local IP of VPN for avoiding issue of this ticket then?

3b. Does same issue/answer of question 3, apply to listen_interfaces too, I.e using local IP of VPN isn't "good enough" and device name is preferred instead to avoid leaks fully?

Again, apologize for off-topicness. Thanks alot in advance.

Edit: Crap, the above was related to deluge usage, but now trying test this in my win10 VM with deluge2, see both fields only support 15 chars each, so no interface name even can be defined on windows, as GUIDs longer than that, and neither room for port on incoming field, but I see deluge appends port internally anyhow. Now hoping answer to question 3/3b is me misunderstanding the docs, as else a big problem in deluge then, regarding this. Quick testing with ipmagnet and local IP of VPN in both deluge fields, shows problem not occuring, but still am uneasy about that comment in reference libtorrent docs though. If instead using deluged's command-line options '-i' and '-o'(-o only in deluge2), for in/out binds of interface/IP, then if GUID used, then is added stripped to 15 chars(-o) or just not added(-i), but can be used to define local IP(again without port on '-i' as added by deluge internally), just like in the GTK UI interface. Just added for interessted deluge users possibly seeing this. I'm gonna make a ticket on deluge bugtracker about this soon.

[arvidn]

Am I correct in saying that listen/outgoing_interfaces libtorrent options can both be interface names and/or IPs on both windows and Linux, and that listen_interfaces just needs a port specified additionally

correct.

, and lastly that for both options only guid uppercased/curly-braced names are only supported type of interface names supported for windows, when using such? (the reference docs e.g state only guids for windows interface names, when used, but only list that for one of the options and not the other)

Right, interface names on windows are the long GUIDs in curly braces. I haven't kept up with windows lately, are there human readable names for network interfaces on windows now?

Is the example of windows guid interface name and port a typo or correct, when using double colons when specifying port: {GUID}::7777?

There should only be a single colon. fixed #4835

Last, but certainly not least, what specifically is reffered to when under outgoing_interfaces it states: "Binding an outgoing connection to a local IP does not necessarily make the connection via the associated NIC/Adapter". So is it needed to specifically use interface name and not local IP of VPN for avoiding issue of this ticket then?

No, that just means that your operating system is still in control over routing, and there is no (portable) way to force packets to be routed in a certain way. There's SO_BINDTODEVICE on linux, and other counterparts on BSD and OSX, but for some of them you need to be root.

Additionally, you may need to configure your routing table to make routing happen the way you like it. On linux for instance, you may have to set source hints to your routes in the routing table.

3b. Does same issue/answer of question 3, apply to incoming_interfaces too, I.e using local IP of VPN isn't "good enough" and device name is preferred instead to avoid leaks fully?

Whether you specify an IP or a device name does not make that big of a difference. The device name is "resolved" to IP addresses to call bind() (which only takes IPs), but with a device name SO_BINDTODEVICE is called in addition. However, that requires root, so it's likely not making any difference.

[arvidn]

I've learned about a routing table trick that it seems OpenVPN uses to create a more specific route to the tunnel than the default route. It sets up two routes 0.0.0.0/1 and 128.0.0.0/1 both pointing to the tunnel. This will make all traffic routed there since those routes are more specific than the default route (of 0.0.0.0). In libtorrent's heuristic to determine which interfaces it should listen on by default, it fails to recognize the tunnel as one such interface, because it doesn't have a default route.

This could be fixed by manually configuring the tunnel as the listen interface, but I'm also attempting to fix it here: #4881 (it's only the last commit that's relevant to this comment).

I think there's sufficient overlap with this ticket and in #4850, I'd like to move all discussions aimed at improving routing and the default listen behavior there.