binhex / arch-qbittorrentvpn

Docker build script for Arch Linux base with qBittorrent, Privoxy and OpenVPN
GNU General Public License v3.0
397 stars 46 forks source link

IP Leakage when Container is starting (PIA + Wireguard) #102

Closed keturo closed 2 years ago

keturo commented 2 years ago

Hey @binhex ,

thanks for your work and docker containers. In my testing of the binhex qbittorrentvpn with PIA and Wireguard, i noticed something. I use a tightend Firewall for the VPN Clients and wanna find all ports that are needed to make a connection by the client.

As i found out the ports udp/53 (DNS resolution), tcp/443 (configuration download), tcp/1337 (wireguard connection); udp/1337 (wireguard connection) are necessary.

With this setup the connection starts correctly BUT while the docker is starting up and trying to connect to the VPN, the qbittorrent client already begins to download and is leaking your real IP address, as i see on my firewall. After some seconds the VPN connection is started no more leakage happens. If i only allow the above mentioned ports everything works and is blocking the leakage works but i think this should be analysed!

keturo commented 2 years ago

Setting the network interface in qbittorrent prevents the leakage while starting the container, but still this should be avoided with the iptables.

Maybe relatet with this about iptables? https://github.com/binhex/arch-qbittorrentvpn/issues/100

binhex commented 2 years ago

I suspect the issue you are seeing is this one has posted here on the forum:-https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=961874

read the subsequent replies from me, in short I think you are seeing dht due to qbittorent communicating on all interfaces, I can only assume that the automation I put in place to bind to the tunnel adaptor is no longer working with the latest version of qbittorent, so i will need to re work this for the current version.

binhex commented 2 years ago

Fyi just checked and for me network adaptor binding is working for me on latest image and I can change between wireguard and OpenVPN and the adaptor binding changes correctly, are you running latest image?

keturo commented 2 years ago

I can reproduce it every time Using "binhex/arch-qbittorrentvpn"

Did you set an Interface in the qbittorrent settings or did you set it to any? When i choose wg0 no leakage happens with Any the leak happens on a restart.

The port used in the leakage is the qbittorrent port.

Edit: Interesting, after installing the container new with new config files, qbittorrent has set Any as Interface After i choose wg0 one time, after every reboot it will reset to wg0

binhex commented 2 years ago

What exactly is the leak? Is it to a specific IP, i.e. your VPN providers endpoint? I'm assuming it will be as the iptables are very restrictive and will not permit traffic outbound to LAN, the only exception is traffic to the VPN b endpoint which of course ju6st be permitted.

keturo commented 2 years ago

The port is the listening port which is set in qbittorrent before the new port from the vpn connection get configured.

binhex commented 2 years ago

I don't understand how that is possible, there are checks in place to ensure all iptables block BEFORE qbittorrent process can start, can you do this:- I need a full log to diagnose the issue further, please do the following:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md

keturo commented 2 years ago

I am really confused now. I cant reproduce the problem now, tried it 2 times with new container and config files. No leakage. Yesterday i had it nearly every time.

Maybe i did a missconfiguration with the allowed networks or something else and fixed it while debugging. Sorry for wasting your time, will test this a little more if i find something i will inform you.

Thanks for your work

binhex commented 2 years ago

Ok thanks for letting me know, I am very confident it does not leak if configured correctly, if you misconfigure then yes you could get into trouble, an example of this would be setting your LAN_NETWORK to be a non private range, or settng VPN_INPUT_PORTS (or output) to qbittorrent incoming port (not what it's for), there could be other cases too but they are the ones that spring to mind.

binhex commented 2 years ago

i havent heard any more for a week, so im assuming all is fine, if this is not the case then please re-open and include logs as linked above.