Slow Torrent speed and weird connection drops

[zeedatrup 0]

On 1/11/2020 at 5:47 AM, giganerd said:

There is one thing you absolutely need to do: Bind qBittorrent to your TAP adapter! In Advanced section, look for a "Bind to interface" setting and select the TAP adapter from the drop-down menu when you're connected.
This causes qBittorrent to only use the TAP adapter when talking to the outside world, and if that adapter is not in a connected state it won't be able to talk. Easy. It's like a kill switch: If the connection dies, all connections of qB die. If you reconnect, qB will reconnect to peers.
 
In Speed section, set your max upload to whatever your uplink is you're subscribed to, -10%. The "problem" you might be facing is that a connection between computers is a two-way street. When you're downloading packets, you're also sending packets back which ACKnowledge that you received the package. As your download throughput increases, so does the amount of ACKs sent back. Plus, if other clients download from you, the bottleneck is perfected.
If you carelessly ignore the max upload setting, you allow the torrent client to fill your uplink with packets.

Hi, hope you don't mind me tagging you - you seem very knowledgeable and generous in responding.

I have read quite a few of the threads on torrenting, however some appear quite old and am not sure of their relevance today.

New to vpn and torrenting. Not very computer literate.

Using w10 and qbittorent and eddie client.

 

Regarding the one thing you absolutely need to do - binding the network interface.

At ipleak.net, the only ip and dns address shown are the airvpn server address (exit address?), webrtc shows no leak (disabled in browser), layeripv6 blocked in eddie 'networking menu', network lock set to automatic and padlock in locked position on eddie ui (although allow lan/private, ping - default setting?) and in qbittorrent tools>options>advanced, network interface 'bind' set to what appears to be the network that is the tap network, as opposed to the physical network card that came with the comp.

For a day or so the qbittorrent network interface 'bind' was only set to 'any interface'.

Then and now the torrent detection test at ipleak.net only showed the respective airvpn server address and the port forwarded through airvpn. During the day or so there did not appear to be vpn disconnections. Does this mean that for the day or so it was set to 'any interface', it would likely only be showing the airvpn server and forwarded port as appeared during the ipleak.net test (done when set to both the any interface option and the tap network option)?

Further, is the above sufficient, broadly speaking, to restrict real ip address appearing during torrenting.

I hope the above is set out in a clearly understandable way and would appreciate your response.

thankx.

Edited ... by zeedatrup
added text

[OpenSourcerer 1441]

7 hours ago, zeedatrup said:

Does this mean that for the day or so it was set to 'any interface', it would likely only be showing the airvpn server and forwarded port as appeared during the ipleak.net test (done when set to both the any interface option and the tap network option)?

If you were connected the whole time, yes. All traffic is routed through the AirVPN server regardless according to the kernel routing table (in a command prompt or PowerShell, enter route print to see what I mean).
 

7 hours ago, zeedatrup said:

Further, is the above sufficient, broadly speaking, to restrict real ip address appearing during torrenting.

For torrenting it's even sufficient to connect to AirVPN and bind to the VPN interface in the torrent client. NetLock is for those who don't want any app to access the internet outside the tunnel.

By the way, they're not the same features: One tells the client which interface is to be used explicitly (so it's only for the torrent client), the other adds firewall rules to actively block outgoing connections to the world if not going through the tunnel (so it's for all apps on the PC, including the torrent client). I think they're not standing in each other's way if you want to use both, it's more like a redundancy.

[zeedatrup 0]

Thankx very much for the easy to understand explanation and for the quick response as well.

[wintermute1912 6]

Don't use Deluge. For whatever reason which I have not had time to properly investigate it gives you away and you get replay attacks.
The following torrent clients run fine for me:

• qbittorrent (latest version installed via PPA: https://www.qbittorrent.org/download.php
• Transmission (native install on Ubuntu 16.04.5)
• rtorrent (probably the safest but text based interface only)

Also change the TCP port you have mapped quite frequently.

And check you're not getting DNS leaks:

sudo tcpdump -i tun0 -n "port 53"

 

If you see any other IP address than the AirVPN DNS server you have leaks

[Staff 10014]

@wintermute1912

If traffic passes through the tun interface it's in the tunnel, so even if you want to reach 3rd parties DNS servers, the queries and their replies are tunneled, it's not a DNS leak. Even worse: in this way you will never find DNS leaks, even if they are really occurring.

To verify effectively you need to check traffic from the physical network interface. Unencrypted DNS queries from the physical network interface, if not blocked by the firewall, hint to DNS leaks for real.

Kind regards
 

[wintermute1912 6]

On 3/5/2020 at 1:11 AM, Staff said:

@wintermute1912

If traffic passes through the tun interface it's in the tunnel, so even if you want to reach 3rd parties DNS servers, the queries and their replies are tunneled, it's not a DNS leak. Even worse: in this way you will never find DNS leaks, even if they are really occurring.

To verify effectively you need to check traffic from the physical network interface. Unencrypted DNS queries from the physical network interface, if not blocked by the firewall, hint to DNS leaks for real.

Kind regards
 

Perhaps not but if you have connected to a VPN server using its hostname you've told your ISP which VPN provider you use and it's not entirely inconceiveable traffic pattern analysis could correlate DNS queries originating from known VPN public IP addresses to your account.

Not sure about the second part. update-resolv-config ensures DNS resolution through the VPN's DNS server only on tun0 interface. The only traffic originating from my physical adapter is directly to the OpenVPN server and back again. There's nothing else.

[wintermute1912 6]

If you're using Windows 10 run netstat the next time Eddie is connected and you'll see an established connection between the internal LAN IP address of your PC and the Microsoft telemetry server. #yikes

Haven't tried on macOS but doubtless it does the same.

I really don't believe it's possible to be 100% certain all your traffic is being routed through the VPN on Windows or macOS. They're just too sneaky.

[Staff 10014]

1 hour ago, wintermute1912 said:

If you're using Windows 10 run netstat the next time Eddie is connected and you'll see an established connection between the internal LAN IP address of your PC and the Microsoft telemetry server. #yikes

Hello!

Yes, already checked in another thread months ago, no traffic leaks. Remember that Windows does not reset sockets when routing table and default gateway change but Network Lock prevents leaks. Specifically tested for telemetry service.
 

1 hour ago, wintermute1912 said:

I really don't believe it's possible to be 100% certain all your traffic is being routed through the VPN on Windows or macOS. They're just too sneaky.

Firewall rules ensure no traffic leaks but then again you might have processes from the manufacturer that secretly modify the system packet filtering table and then restore them without leaving traces. It's not rational running a closed source Operating System nowadays but that's what most people prefer (at least in the Desktop market), so we provide solutions to minimize risks.

Kind regards