ANSWERED goldcrest - network lock still active after session terminated

[dhch 0]

Hi,
this is my first time using the AirVPN suite for linux. Everything works fine when connected. I use "goldcrest --air-connect ..." to connect. But when in terminate the sesssion, my entire machines traffic is blocked. There is a seperate user "airvpn" which i switch to in bash in order to control goldcrest.
Is it the network lock that stays active? Or something else i missed?

edit: as suggested in other threads, " systemctl restart systemd-resolved.service" doesnt work. also disabling the firewall with "sudo ufw disable" does not change the behaviour. also, pinging any ip like 1.1.1.1 doesnt work either, so seems not to be a dns issue.
as addition, my os is Linux Mint 21.3 and im using the airvpn suite 1.3

edit2: ok, the dns settings seem to be stuck somehow. when terminating goldcrest the content of /etc/resolv.conf still lists the nameserver set by the vpn client.
am i terminating incorrectly maybe? maybe im still a little bit confused on how to correctly run the client. i start it by chaning the active user in terminal to the user airvpn and use goldcrest with --air-connect to start the vpn. the program stays active in this terminal window and cant be controlled anymore from there. e.g., i can not use "goldcrest --disconnect" to disconnect properly, not even from a different terminal window. instead i use ctrl+c to exit the running program. when i do this is seems to be disconnecting properly, at least it says so in the terminal output.

Edited ... by dhch

[Staff 10334]

@dhch

Hello!
 

1 hour ago, dhch said:

Is it the network lock that stays active?

It may stay active, according to your preferences. Bluetit can operate with a persistent Network Lock if networklockpersist is set to on on your /etc/airvpn/bluetit.rc file, can you please check?

Kind regards
 

[dhch 0]

Hi,

this line seems to be commented out.
"# networklockpersist      <on|nftables|iptables|pf|off>"
i still use the standard-config, right after installation

also see edit2 from original post, maybe this helps to diagnose further

Edited ... by dhch

[Staff 10334]

1 hour ago, dhch said:

the dns settings seem to be stuck somehow. when terminating goldcrest the content of /etc/resolv.conf still lists the nameserver set by the vpn client.

Hello!

AirVPN Suite 2.0.0 has improved Network Lock and DNS managements in general and also when systemd-resolved is in control. It also fixed many bugs. Currently the Suite 2.0.0 is at the beta stage, with public testing. Would you like to test it to check whether the problem gets resolved or not? If so, please see here:
https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/

If you opt testing 2.0.0 beta but the problem persists please send us the complete Bluetit log taken after the problem has occurred. From a terminal:

sudo journalctl | grep bluetit > bluetit.log

then send us the generated bluetit.log file. If you decide not to test the Suite 2.0.0 beta version, please send us anyway Bluetit 1.3.0 log (in the same way, as above).

Kind regards
 

[dhch 0]

i got rid of the problem with consistent dns nameserver overwrite. it seems the program exited once incorrectly. the content of /etc/airvpn/resolv.conf.airvpnbackup showed the nameserver entry. manually removing the line while vpn was disconnected and then connecting again resolved the issue. bit this still doesnt resolve the main issue of network lock staying active

[dhch 0]

2 minutes ago, Staff said:

Would you like to test it to check whether the problem gets resolved or not? If so, please see here:

thank you, will try out

[dhch 0]

so i tried out airvpn suite 2 now. this doesnt work at all. i cant even connect to any airvpn server with it. it is using wireguard by default. i dont have any experience with it. but also when switching to openvpn it can not connect. well, first it says it can connect, then it disconnects after about 20 seconds and tries reconnecting every few seconds.
back to 1.3 and connection is working with vpn tunnel at least. but still not when disconnected

[dhch 0]

here is the logfile while the tunnel is still open: bluetit_running.log
and after terminating: bluetit_disconnected.log

[dhch 0]

during troubleshooting of another problem i just stumbled upon a very very big nogo. when starting airvpn via "goldcrest --air-connect ..." it just disables my entire firewall (ufw). when shutting down the vpn again, it does not enable the firewall again...
i know there is still iptables active in the background. gut disabling any service when starting the bluetit and not enabling it again, when turning off bluetit, shouldnt be correct
im using airvpn suite 1.3 on a linux mint system

[Staff 10334]

Hello!

From the log we see that Suite 1.3.0 can not run properly in your system, we're sorry. Can you also send us the complete Bluetit log of the Suite 2.0.0 beta 4? From our tests, with the exception of the utility airsu , our testing Linux Mint 21.1 machine can run Goldcrest and Bluetit just fine. The problem with airsu is already being investigated (EDIT: found the problem, fix on its way, workaround available), anyway you need it only in part (for traffic splitting, in order to prepare the env to run a GUI based app with traffic outside the VPN tunnel).

EDIT: tech note, the problem with airsu occurs because dash is forced to interpret airsu in spite of the she-bang #!/bin/bash - a more thorough investigation will be performed on this issue. A quick but dirty solution is linking /bin/sh to /usr/bin/bash (after bash package has been installed of course).

Important note: Mint 21.3 comes without bash pre-installed - please install bash package first, then install the Suite. This is necessary because the installer script has been written in bash.

sudo apt install bash

Kind regards
 

[dhch 0]

hi,
thanks for the feedback. but the problem persists, even after uninstalling airvpn suite all together. no connection to internet. so basically the only way to get it working again is to load a backup and not use airvpn suite?
and just to clarify, system is linux mint 21.3, not sure if the mentioned 2.21 is the same, but i guess it is. and as far as i know bash comes preinstalled on linux mit that im using. at least im using it

anyways, here the logs from 2.0:
bluetit_wireguard.log
 

[Staff 10334]

1 hour ago, dhch said:

just to clarify, system is linux mint 21.3, not sure if the mentioned 2.21 is the same

Hello!

Sorry, our testing system is Mint 21.1 Xfce edition and, provided that you install bash, everything runs perfectly, including traffic splitting. We will test on Mint 21.3 and 22.1 in the next days and let you know. The log shows multiple critical problems that are not currently reproducible. We will update this thread in due time.

As far as it pertains to ufw, Bluetit does not disable anything, but Network Lock operates at nftables level in your system through the userspace utility nft, because Bluetit detects that both nftables and nft are working in your system. However, ufw is an iptables frontend, so it can not interact directly with nftables, it must do it through legacy translations. This hybridization is deprecated because it may cause very many problems (Bluetit tries to warn you with "WARNING: ufw is running on this system and may interfere with network filter and lock" as you may have seen).

ufw does not support nftables, which is the new network filtering subsystem of your distribution Linux kernel.

iptables compatibility is maintained through a complex set of translations. If you operate simultaneously with nft and ufw, bad things may (will) happen. When Bluetit restores the previous rules, it does so via nft. If ufw gets disabled at this stage, it's not Bluetit that disables it directly.

The above firewall problems are not user's direct responsibility, instead they look like the outcome of a suffering and maybe not well planned migration from iptables to nftables on Ubuntu and derivatives. Please note that in Mint 21.3, ufw is disabled by default, thus resolving the problem at its root.

Solution: consider to clean up the system to stay entirely on translations or entirely on nftables. If you want to go with nftables, just disable and/or uninstall ufw.

If you prefer to keep ufw then renounce to nft and rely exclusively on translations, and force Bluetit to go back to iptables translation. To do so, just change the networklockpersist setting into iptables (from the default automatic choice).

Kind regards


 

[Staff 10334]

On 2/15/2025 at 4:13 PM, Staff said:

We will test on Mint 21.3 and 22.1 in the next days and let you know.

Hello!

@dhch

The more extended tests on Mint 21.3 allowed to detect the problem. When ufw is running, it sets a series of custom rules. If you then enable network lock with Bluetit in default configuration, Bluetit stores the rules through nft (correctly). However, the system translation from ufw/iptables rules to nft syntax goes horribly wrong. When Bluetit restores the previous firewall status, the restore fails because during the previous translations syntax errors were introduced in the file where the previous rules were saved. This is a well known / notorious issue since years ago, it's the translation problem we wrote about in our previous message.

After that, Bluetit even crashes (core dump you may have seen), so it will also fail to restore DNS system settings if a connection was performed during the session. This crash must be investigated of course: it is triggered by nft critical error (it exits with unknown error 256), so we should be able to avoid the crash, but the syntax errors caused by the system commands during the translations are unavoidable, they are system tools intrinsic. It is not in our scope to fix what's lost in translation; the problem can be avoided in other ways.

By not running ufw when you start Bluetit, you will also be able to avoid another problem we see in your log.

The solution is the one we recommended before: make sure that ufw is disabled when you start Bluetit, or force Bluetit's network lock to fall back to iptables. To disable ufw:

sudo ufw disable

Please let us know whether any problem still persists after you test Bluetit with ufw disabled.

Kind regards
 

[dhch 0]

ok, thanks for the great and thorough answer. this helped a lot to understand the problem. i will clean up my system soon and try to set it up in a correct way to only use nftables