ArchLinuxArm (aarch64) on RPi3 leaking DNS requests

[Pi77Bull 0]

I have a RaspberryPi 3B+ running ArchLinuxArm (aarch64), Hummingbird 1.1.0 (manually installed, not via AUR) as a systemd service and qbittorrent-nox as a systemd service.
In qBittorrent I've set the port that I forwarded on AirVPN and I've set the network interface in the advanced settings to tun0.

Everything works well, except that qBittorrent is leaking DNS requests according to https://www.doileak.com
There it says:

Torrent DNS: Your torrent client did send DNS requests via the following IPs:
176.95.16.4  	Vodafone DSL (3209), Germany (EU) (Leak?)
192.30.89.51  	Tech Futures (394256), Canada (NA) (Leak?)
176.95.16.6  	Vodafone DSL (3209), Germany (EU) (Leak?)
We received DNS requests from your torrent client via a DNS server from another AS (routable network) than your HTTP request. This could mean that your DNS requests are leaking.
 
If a magnet link or a torrent file contains a tracker which is addressed with a domain name, your torrent client has to resolve the domain name to an IP address. This tests helps you to detect the DNS server your torrent client is using.

Vodafone is my ISP and that's the IP addresses that show on ipleak.net when I'm not connected to any VPN.

Any help is appreciated!

[OpenSourcerer 1441]

10 minutes ago, Pi77Bull said:

In qBittorrent I've set the port that I forwarded on AirVPN and I've set the network interface in the advanced settings to tun0.

First, an off-topic question: How do you do this? I experimented with qb-nox in the past but never found a setting to bind to something, be it an interface or IP.

Then: If qb-nox queries DNS outside the tunnel, it's possible your whole system is querying DNS outside the tunnel, which is not a leak but a misconfiguration. There is no setting to set DNS servers in qB because it uses the ones from the system. You should check Hummingbird logs whether DNS is pulled and applied and whether it detects other players like systemd-resolved, NetworkManager and others running.

[Pi77Bull 0]

46 minutes ago, giganerd said:

First, an off-topic question: How do you do this? I experimented with qb-nox in the past but never found a setting to bind to something, be it an interface or IP.

In the web interface, go to Tools > Options... > Advanced and the first settings will be "Network Interface (requires restart):" and "Optional IP Address to bind to (requires restart):". https://i.imgur.com/zkLRS7y.png

 

46 minutes ago, giganerd said:

You should check Hummingbird logs whether DNS is pulled and applied and whether it detects other players like systemd-resolved, NetworkManager and others running.

Where does Hummingbird store the logs?
Also, while Hummingbird is running, /etc/resolv.conf contains "Created by AirVPN. Do not edit." etc. with a nameserver at the bottom that is not my ISP's. Edited ... by Pi77Bull
embedded image was messed up

[Pi77Bull 0]

Ok, you're probably right that it's a misconfiguration. I've used this script to check my DNS servers: https://github.com/macvk/dnsleaktest
The results are the same as with the torrent detection website - VPN IP address (Canada) and my ISP's DNS server (Germany).

I'm going to play around wit the configuration a bit. Tips are still welcome

[OpenSourcerer 1441]

2 hours ago, Pi77Bull said:

In the web interface, go to Tools > Options... > Advanced and the first settings will be "Network Interface (requires restart):" and "Optional IP Address to bind to (requires restart):". https://i.imgur.com/zkLRS7y.png

Huh. That must be new, because these two were not there around the qB 4.0.0 release. Good to know, thank you!
 

2 hours ago, Pi77Bull said:

Where does Hummingbird store the logs?

Just like Eddie, nowhere. Output is written to STDOUT, so the only way to see the logs of a systemd unit is privileged via journalctl:

# journalctl -efu name-of-your-hummingbird-unit-file.service

.

[Flx 76]

1 hour ago, Pi77Bull said:

I've used this script to check my DNS servers:

I hope you did not just run the script without checking the contents first. No matter of where it comes from GitHub or some other reliable source.

[Pi77Bull 0]

35 minutes ago, giganerd said:

Just like Eddie, nowhere. Output is written to STDOUT, so the only way to see the logs of a systemd unit is privileged via journalctl:

# journalctl -efu name-of-your-hummingbird-unit-file.service

Thanks! Here is the output, starting from the last reboot: https://bin.privacytools.io/?961682727a7894a8#lrlB74md9dNzINnntBkb66Bvq1Dm2Z7PYT8zBdRYCZI=
It does say:

WARNING: systemd-resolved is running on this system and may interfere with DNS management and cause DNS leaks

however, all seems to be fine at the end:

System DNS 192.168.2.1 is now rejected by the network filter

I'm also wondering why Hummingbird is using iptables-legacy and if the missing kernel modules might be causing problems.

@Flx No, of course not.

[OpenSourcerer 1441]

3 hours ago, Pi77Bull said:

I'm also wondering why Hummingbird is using iptables-legacy and if the missing kernel modules might be causing problems.

Hummigbird takes advantage of the nft utility if you tell it to use nf_tables. This one is not installed on Debian and descending distros by default, and it seems like it's the same on Arch and descendants. It should really fall back to iptables-nft instead, but that's another discussion. You go ahead and install nftables, then try using nf_tables, see if it helps.

$ pacman -S nftables

.

[Pi77Bull 0]

On 10/18/2020 at 11:56 PM, giganerd said:

Hummigbird takes advantage of the nft utility if you tell it to use nf_tables. This one is not installed on Debian and descending distros by default, and it seems like it's the same on Arch and descendants. It should really fall back to iptables-nft instead, but that's another discussion. You go ahead and install nftables, then try using nf_tables, see if it helps.

$ pacman -S nftables

That's not what I meant. I was confused why it used iptables-legacy instead of iptables (not legacy). There doesn't seem to be any difference though (?). Thanks for mentioning nftables though. I'll look into it.

I also managed to fix the DNS issue I was having. Turns out I'm not the only one with this issue: https://github.com/systemd/systemd/issues/6076
The problem is that systemd-resolved always queries at least one nameserver of each network interface (or something like that).
There is a solution mentioned in that issue thread and I'm thinking if Hummingbird/Eddie/OpenVPN3 shouldn't be doing that already? https://github.com/systemd/systemd/issues/6076#issuecomment-451007387

I just configured my network interface to not use the DNS advertised by my router by setting "UseDNS=false" in /etc/systemd/network/eth.network  . Besides that I also set a static IP and disabled IPv6.

Thanks  @giganerd

[OpenSourcerer 1441]

15 minutes ago, Pi77Bull said:

I was confused why it used iptables-legacy instead of iptables (not legacy). There doesn't seem to be any difference though (?)

The difference is that iptables could call iptables-nft, which is the syntax of iptables with the nf_tables kernel module. I think the dev wanted to meet people's expectations about that option actually using iptables kernel modules and not nf_tables, so iptables-legacy is used directly. On some distributions like Debian 10 /usr/sbin/iptables calls iptables-nft and such cases were apparently undesired by the dev.
 

44 minutes ago, Pi77Bull said:

There is a solution mentioned in that issue thread and I'm thinking if Hummingbird/Eddie/OpenVPN3 shouldn't be doing that already? https://github.com/systemd/systemd/issues/6076#issuecomment-451007387

I fully agree with this quote here:

Quote

That the tool someone uses to make VPN connection does not know how to configure systemd-resolved is the fault of this tool and not systemd-resolved so please direct your laments to the maintainer of the tool you are using not here.

I don't think it's handled. Current Hummingbird v1.0.3 simply warns the user that systemd-resolved is running. You wouldn't simply issue a warning if your program knew what to do with the fact it was detected.