Linux: AirVPN Suite 1.1.0 released

[OpenSourcerer 1442]

11 hours ago, eburom said:

ERROR: Error while loading kernel module iptable_filter (-1)
 ERROR: Error while loading kernel module iptable_nat (-1)
 ERROR: Error while loading kernel module iptable_mangle (-1)
 ERROR: Error while loading kernel module iptable_security (-1)
 ERROR: Error while loading kernel module iptable_raw (-1)
 ERROR: Error while loading kernel module ip6table_filter (-1)
 ERROR: Error while loading kernel module ip6table_nat (-1)
 ERROR: Error while loading kernel module ip6table_mangle (-1)
 ERROR: Error while loading kernel module ip6table_security (-1)
 ERROR: Error while loading kernel module ip6table_raw (-1)

Can reproduce on 5.15.5-zen. For me, NetLock with explicit -N iptables is not engaged, but the connection is established.

[eburom 16]

Thanks for pointing that out @magnavoid

@OpenSourcerer
Yes, this is something I've already discussed with the staff team. Even if you tell the tool enable network lock you have to check by yourself if it did since the connection can get established but without the lock being on. I would have preferred the tool to fail, as it could not run as instructed, so I had to explicitly set it without network lock and be more aware of what was happening instead of having to pay attention to the logs or check if it worked every time I connect. But they didn't seem to agree on that.

Should I then open a ticket about iptables not working on my setup?

 

[OpenSourcerer 1442]

People posted comments on the AUR package of eddie-ui that it couldn't interface with iptables as well. I believe this issue is bigger than anticipated.

Can everyone running a rolling release except Arch Linux come forward and test if Eddie, Hummingbird and/or Bluetit/Goldcrest still work for you? State your distribution with version (e.g. lsb_release -a) and the output of uname -a if you do so.
Issue confirmed.

Edited ... by OpenSourcerer
Issue confirmed, don't post that.

[cheapsheep 6]

Bluetit still working for me. However - and in order to be able to use it with docker - i have to explicity specify the nftables directive in the .rc file.

networklockpersist                      nftables

1)
Operating System: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-9-amd64
Architecture: x86-64
Linux deb 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
iptables v1.8.7 (nf_tables)

2)
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 5.10.63-v8+
Architecture: arm6
Linux umbrel 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
iptables v1.8.2 (nf_tables)
 

[Staff 10018]

@cheapsheep @eburom @magnavoid @OpenSourcerer

Thank you very much for the bug report, the issue will be investigated very soon. In the meantime please force nftables (if available, and remember that userspace utility nft is currently required) as @cheapsheep suggested to circumvent the problem.

EDIT: Eddie, Hummingbird and Bluetit assume that iptable_* modules exist if iptables exists. This is no more true in some distributions, where iptables userland utility exists but iptable modules don't (and it would be false even in customized kernels compiled with embedded iptable). We will be working on a more robust implementation.

@eburom

Both implementations are logical and probably the "Right and Just" one does not exist. If Bluetit renounced to the connection when Network Lock fails it would leave the machine completely exposed (remember that Bluetit is a daemon) because it has no way to block the traffic when the firewall fails (*). If Bluetit goes on at least it tries to connect the machine and establish a "tunnel". In early Bluetit implementations Bluetit aborted the connection if Network Lock failed, now the other solution has been preferred even after consultation with users.

(*) It might sabotage the routing table or the gateway or it might turn off the network interfaces to isolate the machine completely, but this solution is considered too invasive and it is unacceptable for various system administrators, especially those who run remote servers.

Kind regards
 

[sableslayer 1]

I have a work around for Arch for the time being, just downgrade to the LTS kernel. Network lock works with kernel 5.10.82-1-lts.

[Staff 10018]

20 hours ago, sableslayer said:

I have a work around for Arch for the time being, just downgrade to the LTS kernel. Network lock works with kernel 5.10.82-1-lts.

Hello!

Good solution for Eddie because Eddie doesn't let you pick the firewall framework. With AirVPN Suite, if you prefer the newer kernel, you don' need to downgrade, you can just tell the software to use nftables for Network Lock. And you can do the same with Eddie too. Just install nft and Eddie will prefer nftables, no need to downgrade kernel, and the Network Lock will be fine.

Kind regards
 

[eburom 16]

Thank you for the explanation @Staff everything sounds pretty reasonable.

Just want to point out that when I suggested it I was talking about hummingbird.
AirVPN Suite being a server makes it a whole different story indeed.

 

[Staff 10018]

Hello!

@OpenSourcerer and any other Arch user.

Slightly Off Topic: if Eddie fails with Arch with kernel 5.15.x and nft  (the userspace utility) is installed, please contact us. Eddie gives priority to nftables if it finds nft, so if Network Lock does not work even when nft is available something else might be going on. Please check if you can and if you find any malfunciton even with nft installed send us (in a ticket if possible) Eddie system report showing the failure. Also specify the nft version.

Kind regards
 

[OpenSourcerer 1442]

36 minutes ago, Staff said:

Slightly Off Topic: if Eddie fails with Arch with kernel 5.15.x and nft  (the userspace utility) is installed, please contact us. Eddie gives priority to nftables if it finds nft, so if Network Lock does not work even when nft is available something else might be going on. Please check if you can and if you find any malfunciton even with nft installed send us (in a ticket if possible) Eddie system report showing the failure. Also specify the nft version.

Cannot reproduce. If nft is installed, Linux nftables is always used and NetLock is engaged successfully. If Linux iptables is explicitly selected:

! 2021.11.30 10:58:01 - Activation of Network Lock - Linux nftables
! 2021.11.30 10:58:03 - Deactivation of Network Lock
! 2021.11.30 10:59:04 - Activation of Network Lock - Linux iptables
F 2021.11.30 10:59:04 - Exception: iptables don't reply, probabily kernel modules issue

10:58 is with NetLock mode Automatic.

[sableslayer 1]

NFT as iptables-nft or nftables or is there another package im not aware of?

[OpenSourcerer 1442]

19 minutes ago, sableslayer said:

NFT as iptables-nft or nftables or is there another package im not aware of?

iptables-nft should depend on nftables in all distributions because the latter provides nft while the former provides a tool called ip[6]tables-translate. You input an iptables rule, it outputs an equivalent rule in nft syntax. Calling iptables-nft translates the given iptables syntax rule to nft syntax and feeds its output to nft. At least, that's how I read the section using the nf_tables compat backend on the nftables wiki.

[Pwbkkee 0]

I finally discovered why my system kept leaking name resolution requests to my router at unexpected moments, and what appears to be the correct way to prevent such leaks.

When Bluetit and Goldcrest are configured to accept the VPN server's pushed DNS settings, and the system is using systemd-resolved, Bluetit does two things. Firstly, it writes the VPN server's pushed DNS settings to /etc/resolv.conf. Secondly, it tells systemd-resolved to configure the main network interface to use the list of DNS servers that the VPN server pushed to Bluetit.

Unfortunately, on my system at least, systemd-resolved doesn't clear the main network interface's previous list of DNS servers before adding the VPN server's list of DNS servers. This means that every time Bluetit tells systemd-resolved to use the list of DNS servers that it received from the VPN server, my router's IPv4 and IPv6 addresses would remain in systemd-resolved's list. And when my router is faster at answering name resolution requests, systemd-resolved would prefer my router.

This goes unnoticed for a while because /etc/resolv.conf at this point still contains only the list of DNS servers that Bluetit wrote. And since Firefox doesn't yet query systemd-resolved directly, but rather relies on /etc/resolv.conf, tests at https://ipleak.net wouldn't yet reveal the leaks. It is only when /etc/resolv.conf later gets overwritten by systemd-resolved—presumably when the system's DHCP lease is renewed—that the leaks are revealed. At this point, if /etc/resolv.conf was a symlink to /run/systemd/resolve/stub-resolv.conf, it would then revert to pointing to systemd-resolved's stub resolver—and since systemd-resolved itself at this point prefers the router, all name resolution requests would be sent to the router. If /etc/resolv.conf was a symlink to /run/systemd/resolve/resolv.conf, it would then revert to the DHCP-specified list of DNS servers, causing all name resolution requests to be sent to those DNS servers.

The correct solution to prevent such leaks is apparently threefold. Firstly, /etc/resolv.conf ought to be a symlink to /run/systemd/resolve/stub-resolv.conf—Bluetit should not overwrite it. But if /etc/resolv.conf was not a symlink to /run/systemd/resolve/stub-resolv.conf, then Bluetit should make it one. This forces all name resolution requests to be sent to systemd-resolved by default, which is what we want. Secondly, the pushed DNS settings from the VPN server should not be applied to the main network interface—eno0 on my system—but rather to the tunnel interface. And thirdly, systemd-resolved should be instructed to set the tunnel interface as the default route for name resolution requests and to unset the main network interface as the default route for name resolution requests. This threefold solution results in systemd-resolved sending all name resolution requests to the tunnel interface's list of DNS servers only. And since /etc/resolv.conf would now point to systemd-resolved's stub resolver only, the entire system ends up sending all name resolution requests to the VPN server only. The resolvectl commands to achieve this would look something like this, where eno0 is the name of the system's main network interface and tun0 is the name of the tunnel interface:
 

# resolvectl dns tun0 [VPN server gateway's IPv6 address] [VPN server gateway's IPv4 address] ; resolvectl default-route eno0 false ; resolvectl default-route tun0 true

I do this manually on my system now—Goldcrest is configured to ignore the VPN server's pushed DNS settings—and it works. My system no longer leaks name resolution requests to my router, even after a DHCP lease renewal. I therefore ask @Staff to consider updating AirVPN Suite to implement this approach. There would be no need to block port 53 at the firewall level.

Credit goes to https://github.com/jonathanio/update-systemd-resolved#dns-leakage and https://blogs.gnome.org/mcatanzaro/2020/12/17/understanding-systemd-resolved-split-dns-and-vpn-configuration/ for pointing me in the right direction.

[sableslayer 1]

Thanks OpenSourcer. Works with iptables-nft on 5.15.6-arch2-1. =)

[eburom 16]

On 11/29/2021 at 9:53 AM, Staff said:

EDIT: Eddie, Hummingbird and Bluetit assume that iptable_* modules exist if iptables exists. This is no more true in some distributions, where iptables userland utility exists but iptable modules don't (and it would be false even in customized kernels compiled with embedded iptable). We will be working on a more robust implementation.

Hi, I have done some research on this and found that, at least in my case, the modules do exist but Arch linux now has this files compressed using zstandard instead of xz.
https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/

Airvpn suite uses some code that expects it to be uncompressed or compressed in xz. From the code, when a filename dos not end with xz it is treated as an uncompressed file. This finally fails when trying to init the module with an errno code of

ENOEXEC
              Exec format error

as the binary information is not correct.

I have added a piece of code that treats the binary data in a different way in case the filename ending is zst.
It only works if the compressed file has information about the uncompressed size of the item (which happens to be so in this case but is not mandatory for the zstandard). In case it weren't so it keeps failing as usual.

I have compiled and run last version of hummingbird in the Airvpn-Suite repository and now works with iptables.

I'm sharing the patch to be applied over version 28a9669 of the repository in case it helps anyone wanting to use iptables.

core/zstd needs to be installed on the machine (it will probably be).

As a last note: AirVPN-Suite does not compile with the last commint on openvpn3-airvpn repo due to some changes on ClientAPI::Config. I had do got back to commit 8f568324 to make it work.

 

fixLoadingZSTDCompressedModules.path

[Staff 10018]

@eburom

Thank you very much!

The problem you found and kindly reported has been fixed and you'll see the fix in the next, imminent version.

From the developer: you can't build the Suite now because OpenVPN3 has recently changed ClientAPI::Config definition. They replaced member ipv6 with allowUnusedAddrFamilies which is basically used for the very same purpose. The change has been already imported into OpenVPN3-AirVPN 3.7.1 fork and Bluetit/Hummingbird code has been updated accordingly in the development branch which is to be released very soon, along with some other minor fixes and changes [including the aforementioned one}.

Kind regards
 

[Staff 10018]

@Pwbkkee

Hello!

Thanks for the detailed report and the suggested solution. Unfortunately we could not reproduce the issue. Can you please tell us your exact distribution name, version and (if any) customization, to let us start from a common testing ground?

Kind regards