Jump to content
Not connected, Your IP: 34.207.247.69
Staff

Linux: AirVPN Suite 1.1.0 beta available

Recommended Posts

Posted ... (edited)

Hello,

is it possible to add an additional DNS nameserver check while connecting with bluetit?

I have experienced issues in case of crashes (e.g. due to powerloss).
The main problem is that the AIR nameserver is being kept in resolv.conf which leads to bluetit not being able to reconnect on restart, because it cannot resolv the AIR entry host.
Thus, resolv.conf has to be edited manually and bluetit.service has to be restarted.

Maybe an additional DNS check while connecting would be appropriate [ e.g. 1) Check resolv.conf for existing private AIR nameserver 2) Replace existing nameserver(s) with public nameserver 9.9.9.9 3) Try to reconnect.. ] ?

PS: The same applies when the link goes down for whatever reason (e.g. restart of the router).

Thanks & Regards.

Edited ... by buy airvpn

Share this post


Link to post
@buy airvpn

Hello!

The issue you report does not depend on DNS. You would have the same outcome even if the machine could resolve names. When Bluetit is in a "dirty" status (*), a manual intervention is required, either by a an airvpn group user with goldcrest --recover-network command, or by root, who can decide for an automatic or a manual clean-up.

Enabling Bluetit to perform automatically a clean up at startup may lead to potentially dangerous situations. It can't know whether the dirty condition has been caused by a power outage (in which case an autonomous clean up would be harmless) or some other cause which requires human analysis before proceeding to restore settings "blindly".

For the reckless system administrators we might consider in the future to enable Bluetit ability to perform autonomously a recover-network (opt-in only) at startup.

Anyway you can achieve the same purpose right now by sending automatically a recover-network command to Bluetit always (even during system bootstrap) at startup (via Goldcrest for example).

If no recover-network is necessary, Bluetit will just not proceed to do it, and if it's necessary Bluetit will do it. After that, you do NOT need to restart Bluetit, you can send an air-connect command: if a connection is already established, the command will be ignored, otherwise the connection will be performed. We do not feel to recommend the above, but at the end of the day it's up to each system administrator.

Kind regards

(*) Bluetit is in a "dirty status" when it finds in /etc/airvpn directory one or more of his system settings backup files which would not have remained there if the previous Bluetit shut down had been successful. If you lose power while Bluetit is connected, clearly all of those files are still there.

Share this post


Link to post
11 minutes ago, Staff said:
@buy airvpn


Anyway you can achieve the same purpose right now by sending automatically a recover-network command to Bluetit always (even during system bootstrap) at startup (via Goldcrest for example).
 

Thank you. I'll go with recover-network.

Share this post


Link to post

Hello!

We're glad to inform you that AirVPN Suite 1.1.0 RC 4 is now available. Download URLs have been updated accordingly in this thread first message. Please check the changelog for a full list of important changes, which in this last time frame between RC3 and RC4 have been particularly numerous.

The latest problems found by our internal and public testers have been reproduced and addressed. Thank you all, you brought to light various, elusive bugs which slipped unnoticed through all the previous testing phases.

AirVPN Suite 1.1.0 RC 4 includes new OpenVPN AirVPN library 3.7 fixing a couple of issues coming from the main branch causing the library to crash under the conditions found by our community testers and reported in this thread: thank you all! Another issue in the library was the confusion between "proto tcp-client" and "proto tcp" in OpeNVPN 3 main branch, which caused a critical problem as reported in this thread by testers.

OpenVPN AirVPN 3.7 is now 103 commits ahead of the main branch, featuring several, new important features and very many bug fixes.
https://github.com/AirVPN/openvpn3-airvpn

Please keep testing RC 4!

Kind regards
AirVPN Staff
 

Share this post


Link to post

Did some testing RC4 candidate. No problems so far. Staff thx a bunch.

kind regards
 

Share this post


Link to post
@Staff

Thank you for taking the time to write such a detailed and informative reply. It is much appreciated.

I'm unfortunately starting to think that Hummingbird just isn't ready to be used as a drop-in replacement for OpenVPN -- at least on my system. Perhaps that was never your intention and I simply misread the situation.

While I am sure it is a perfectly good back-end for Eddie, I am less confident about its capabilities as a standalone VPN client for a number of reasons. First, as you yourself have noted, the profile parser still looks to be "work in progress" that seems not to have been fully tested. Perhaps the OpenVPN 3 developers will get around to fixing the persist-tun problem but the issue as I see it is that you have committed to using OpenVPN 3 code that is arguably not yet ready for production use -- and the OpenVPN devs are probably under little pressure to get things fixed asap. If you are going to have to wait for fixes to arrive from upstream developers, that might not be a comfortable position to be in.

I was also a little disappointed to see that up and down scripts are not supported in Hummingbird (or, it would seem, in OpenVPN 3). This is not noted in the documentation. I was also rather surprised to see that the system log shows further OpenVPN directives that are being "unused", including persist-key and auth-nocache, and this behaviour is, once again, undocumented. If you are going to diverge from OpenVPN 2.5 methods of working, which is what most of us will be familiar with, you really do need to highlight the differences more clearly in the documentation.  

I have reluctantly come to the conclusion that I am not yet ready to use Hummingbird "live". It has some great innovations, such as DNS handling and firewalling, but I believe that a security product needs to be well tested and built on solid foundations. I am not confident that either of these requirements is currently being met.

I wish you every success with the future development of your suite of programs and I will no doubt revisit them at some point in the future.


 

Share this post


Link to post
On 4/21/2021 at 7:53 AM, colorman said:
@Staff
Two error's with start goldcrest?

2021-04-21 07:50:25 ERROR: Cannot allow system DNS to pass through network filter
2021-04-21 07:50:30 Resolved server nl3.vpn.airdns.org into IPv4 213.152.162.156
2021-04-21 07:50:30 Adding IPv4 server 213.152.162.156 to network filter
2021-04-21 07:50:30 ERROR: Cannot activate network filter and lock
2021-04-21 07:50:32 Contacting 213.152.162.156:443 via UDP
2021-04-21 07:50:32 EVENT: WAIT


 


 
@Staff
With RC4 I still see these two errors.
We had a lot of back and forth messages, can you tell me what to look out for?
And should I still start Goldcrest like this?
@localhost: ~> ./goldcrest --network-lock nftables AirVPN_Netherlands_UDP-443-Entry3.ovpn

Eddie with Hummingbird working fine now :)

Share this post


Link to post

I'm using 1.1.0 RC4 and I cannot get the network lock working at all.

A few details about my setup:

  • OS: Arch Linux / Gentoo (occurs on both)
  • Init system: systemd 248.2
  • NetworkManager
From /etc/airvpn/bluetit.rc:
networklockpersist on
networklock on

With bluetit.service active and running, if I reboot my machine manually with the physical reboot button (to simulate a crash), on reboot my network connection is still working and my real IP address / DNS are used. I assume the expected behavior would be no Internet traffic at all until I manually run goldcrest --recover-network and sudo systemctl restart bluetit.service, is that correct?

Output of $ journalctl | rg bluetit at this point:
gentoo systemd[1]: Starting AirVPN Bluetit Daemon...
gentoo bluetit[5184]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
gentoo bluetit[5184]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
gentoo bluetit[5184]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
gentoo systemd[1]: bluetit.service: Can't open PID file /etc/airvpn/bluetit.lock (yet?) after start: Operation not permitted
gentoo bluetit[5186]: Bluetit daemon started with PID 5186
gentoo systemd[1]: Started AirVPN Bluetit Daemon.
gentoo bluetit[5186]: External network is reachable via gateway 192.168.1.254 through interface enp7s0
gentoo bluetit[5186]: Successfully connected to D-Bus
gentoo bluetit[5186]: Reading run control directives from file /etc/airvpn/bluetit.rc
gentoo bluetit[5186]: IPv6 is available in this system
gentoo bluetit[5186]: WARNING: networklockpersist directive found in /etc/airvpn/bluetit.rc. networklock directive is ignored.
gentoo bluetit[5186]: Bluetit successfully initialized and ready
gentoo bluetit[5186]: Bluetit did not exit gracefully on its last run or has been killed.
gentoo bluetit[5186]: Run recover network procedure or restore system settings saved in /etc/airvpn
gentoo bluetit[5186]: ERROR: Cannot enable persistent network filter and lock. It seems Bluetit did not exit gracefully or has been killed.
gentoo bluetit[5186]: ERROR: Connection to AirVPN's ipleak.net cancelled. It seems Bluetit did not exit gracefully or has been killed.
gentoo bluetit[5186]: AirVPN Manifest updater thread started
gentoo bluetit[5186]: ERROR: Cannot start AirVPN boot connection. It seems Bluetit did not exit gracefully or has been killed.

Then, I run:
goldcrest --recover-network
sudo systemctl restart bluetit.service

and everything is back to normal.

I installed AirVPN suite 1.1.0 RC4 with the install script on Gentoo and with airvpn-suite-beta-bin (AUR) on Arch Linux.

Another remark: bluetit.service doesn't automatically restart after resuming from suspend/hibernate. I had to create another systemd unit to restart it:

/etc/systemd/system/bluetit-restart.service:
 
[Unit]
Description=Restart bluetit.service after resuming
After=hibernate.target
After=hybrid-sleep.target
After=sleep.target
After=suspend.target
After=suspend-then-hibernate.target

[Service]
Type=oneshot
ExecStart=/usr/bin/goldcrest --recover-network
ExecStart=/bin/systemctl --no-block restart bluetit.service

[Install]
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target
WantedBy=sleep.target
WantedBy=suspend.target
WantedBy=suspend-then-hibernate.target

@Staff Any idea regarding the network lock part? Thanks in advance.

Share this post


Link to post

Hello!

@colorman

Goldcrest invocation appears correct. The full Bluetit log might be more helpful, can you please publish it? Also, can you tell us your nft version (command "nft --version")?

@183aTr78f9o

The 1st reported behavior is expected. because Bluetit must not proceed when it is in a "dirty condition", but it remains to be seen why Bluetit did not exit cleanly in its last session. Was it intended as a test (i.e. you explicitly wanted a dirty startup to test), or is it unexpected? (OK, you already wrote it was a test :) ).

Once you have issued goldcrest --recover-network you don't need to restart Bluetit, you can directly start a connection. Also, Bluetit will activate network lock immediately after a network recovery, if networklockpersist is set in bluetit.rc - another good reason to avoid a restart.

The 2nd remark describes an unexpected event. What happens after you resume the system? Can you send us the full Bluetit log taken just after the problem has occurred? The expected behavior would be that Bluetit daemon does not exit at all, in the first place, when you order an hibernation. Let's see what kills it, if possible.

@leori

Thank you, we're very glad to know it!

@air2157

We're glad to know that Hummingbird launch by Eddie is fine again.

As explained, up and down scripts with script-security 2 enlarge attack surface and we think that it's very appropriate that a library and a root process (Hummingbird) do not offer them. Even in Eddie, script-security, up and down custom directives have been forbidden a long ago for critical security reasons. Furthermore Eddie does not even allow you to use an arbitrary external ovpn profile, and we're considering to stop supporting it in Goldcrest/Bluetit too.

About the documentation: please note that, just like it happens with any documentation, we document implemented features, not unimplemented ones. Bluetit  developer's documentation is also on its way and we plan to publish it immediately after AirVPN Suite 1.1.0 stable has been released.

As you know we have forked OpenVPN3 so we don't need to wait for bug fixes from the main branch if they are too slow to come or they are urgent. The parts which were not ready for production in our tests have been fixed and/or rewritten already, as these last 3 years of releases and testing in different systems should have shown. In any case, please feel free to point us to those source code parts that you deem as not ready for production at your convenience.

Thank you for your previous tests, they have been much appreciated.

Kind regards
 

Share this post


Link to post
@Staff
localhost:~ # nft --version
nftables v0.8.2 (Joe Btfsplk)

localhost:~ # journalctl | grep bluetit
May 16 14:58:04 localhost bluetit[2147]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
May 16 14:58:04 localhost bluetit[2147]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 16 14:58:04 localhost bluetit[2147]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
May 16 14:58:04 localhost systemd[1]: bluetit.service: PID file /etc/airvpn/bluetit.lock not readable (yet?) after start: No such file or directory
May 16 14:58:04 localhost bluetit[2152]: Bluetit daemon started with PID 2152
May 16 14:58:04 localhost bluetit[2152]: External network is reachable via gateway 192.168.178.1 through interface eth0
May 16 14:58:04 localhost bluetit[2152]: Successfully connected to D-Bus
May 16 14:58:04 localhost bluetit[2152]: Reading run control directives from file /etc/airvpn/bluetit.rc
May 16 14:58:04 localhost bluetit[2152]: IPv6 is available in this system
May 16 14:58:04 localhost bluetit[2152]: Bluetit successfully initialized and ready
May 16 14:58:04 localhost bluetit[2152]: Requesting network IP and country to AirVPN ipleak.net via secure connection
May 16 14:58:04 localhost bluetit[2152]: ERROR: Cannot detect system location: Unknown error: Problem with the SSL CA cert (path? access rights?)
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest updater thread started
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest update interval is 15 minutes
May 16 14:58:04 localhost bluetit[2152]: Updating AirVPN Manifest
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest successfully retrieved from server
localhost:~ # journalctl | grep bluetit
May 16 14:58:04 localhost bluetit[2147]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
May 16 14:58:04 localhost bluetit[2147]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 16 14:58:04 localhost bluetit[2147]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
May 16 14:58:04 localhost systemd[1]: bluetit.service: PID file /etc/airvpn/bluetit.lock not readable (yet?) after start: No such file or directory
May 16 14:58:04 localhost bluetit[2152]: Bluetit daemon started with PID 2152
May 16 14:58:04 localhost bluetit[2152]: External network is reachable via gateway 192.168.178.1 through interface eth0
May 16 14:58:04 localhost bluetit[2152]: Successfully connected to D-Bus
May 16 14:58:04 localhost bluetit[2152]: Reading run control directives from file /etc/airvpn/bluetit.rc
May 16 14:58:04 localhost bluetit[2152]: IPv6 is available in this system
May 16 14:58:04 localhost bluetit[2152]: Bluetit successfully initialized and ready
May 16 14:58:04 localhost bluetit[2152]: Requesting network IP and country to AirVPN ipleak.net via secure connection
May 16 14:58:04 localhost bluetit[2152]: ERROR: Cannot detect system location: Unknown error: Problem with the SSL CA cert (path? access rights?)
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest updater thread started
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest update interval is 15 minutes
May 16 14:58:04 localhost bluetit[2152]: Updating AirVPN Manifest
May 16 14:58:04 localhost bluetit[2152]: AirVPN Manifest successfully retrieved from server
May 16 15:04:58 localhost bluetit[2152]: Requested method "version"
May 16 15:04:58 localhost bluetit[2152]: Requested method "openvpn_info"
May 16 15:04:58 localhost bluetit[2152]: Requested method "bluetit_status -> Bluetit is ready"
May 16 15:04:58 localhost bluetit[2152]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
May 16 15:04:58 localhost bluetit[2152]: Requested method "set_openvpn_profile -> OK"
May 16 15:04:58 localhost bluetit[2152]: Requested method "start_connection"
May 16 15:04:58 localhost bluetit[2152]: OpenVPN3 connection successfully started
May 16 15:04:58 localhost bluetit[2152]: Network filter and lock are using iptables-legacy
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module iptable_filter
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module iptable_nat
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module iptable_mangle
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module iptable_security
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module iptable_raw
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module ip6table_filter
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module ip6table_nat
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module ip6table_mangle
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module ip6table_security
May 16 15:04:58 localhost bluetit[2152]: Successfully loaded kernel module ip6table_raw
May 16 15:04:58 localhost bluetit[2152]: WARNING: firewalld is running on this system and may interfere with network filter and lock
May 16 15:04:58 localhost bluetit[2152]: Network filter successfully initialized
May 16 15:04:58 localhost bluetit[2152]: Starting VPN Connection
May 16 15:04:58 localhost bluetit[2152]: OpenVPN3 client successfully created and initialized.
May 16 15:04:58 localhost bluetit[2152]: TUN persistence is enabled.
May 16 15:04:58 localhost bluetit[2152]: Successfully set OpenVPN3 client configuration
May 16 15:04:58 localhost bluetit[2152]: Starting OpenVPN3 connection thread
May 16 15:04:58 localhost bluetit[2152]: Connection statistics updater thread started
May 16 15:04:58 localhost bluetit[2152]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 16 15:04:58 localhost bluetit[2152]: Frame=512/2048/512 mssfix-ctrl=1250
May 16 15:04:58 localhost bluetit[2152]: UNUSED OPTIONS
May 16 15:04:58 localhost bluetit[2152]: EVENT: RESOLVE
May 16 15:04:58 localhost bluetit[2152]: Local IPv4 address 192.168.178.11
May 16 15:04:58 localhost bluetit[2152]: Local IPv6 address 2001:1c04:509:4000:dd19:6d6d:8993:6ba4
May 16 15:04:58 localhost bluetit[2152]: Local IPv6 address 2001:1c04:509:4000:aaa1:59ff:fe2f:523e
May 16 15:04:58 localhost bluetit[2152]: Local IPv6 address fe80::aaa1:59ff:fe2f:523e
May 16 15:04:58 localhost bluetit[2152]: Local interface eth0
May 16 15:04:58 localhost bluetit[2152]: Setting up network filter and lock
May 16 15:04:58 localhost bluetit[2152]: Allowing system DNS 84.116.46.20 to pass through the network filter
May 16 15:04:58 localhost bluetit[2152]: Allowing system DNS 84.116.46.21 to pass through the network filter
May 16 15:04:58 localhost bluetit[2152]: ERROR: Cannot allow system DNS to pass through network filter
May 16 15:04:58 localhost bluetit[2152]: Resolved server nl3.vpn.airdns.org into IPv4 213.152.161.135
May 16 15:04:58 localhost bluetit[2152]: Adding IPv4 server 213.152.161.135 to network filter
May 16 15:04:58 localhost bluetit[2152]: ERROR: Cannot activate network filter and lock
May 16 15:04:58 localhost bluetit[2152]: Contacting 213.152.161.135:443 via UDP
May 16 15:04:58 localhost bluetit[2152]: EVENT: WAIT
May 16 15:04:58 localhost bluetit[2152]: net_route_best_gw query IPv4: 213.152.161.135/32
May 16 15:04:58 localhost bluetit[2152]: sitnl_route_best_gw result: via 192.168.178.1 dev eth0
May 16 15:04:58 localhost bluetit[2152]: net_route_add: 213.152.161.135/32 via 192.168.178.1 dev eth0 table 0 metric 0
May 16 15:04:58 localhost bluetit[2152]: Connecting to [nl3.vpn.airdns.org]:443 (213.152.161.135) via UDPv4
May 16 15:04:58 localhost bluetit[2152]: EVENT: CONNECTING
May 16 15:04:58 localhost bluetit[2152]: Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysi
ze 256,key-method 2,tls-client
May 16 15:04:58 localhost bluetit[2152]: Peer Info:
May 16 15:04:58 localhost bluetit[2152]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RS
A-SHA1
May 16 15:04:58 localhost bluetit[2152]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Tarazed/emailAddress=info@airvpn.org, signature: RSA-SHA5
12
May 16 15:04:58 localhost bluetit[2152]: SSL Handshake: peer certificate: CN=Tarazed, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any     
Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
May 16 15:04:58 localhost bluetit[2152]: Session is ACTIVE
May 16 15:04:58 localhost bluetit[2152]: EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a stronger algorithm
. Support for SHA1 signatures will be dropped in the future
May 16 15:04:58 localhost bluetit[2152]: EVENT: GET_CONFIG
May 16 15:04:58 localhost bluetit[2152]: Sending PUSH_REQUEST to server...
May 16 15:04:58 localhost bluetit[2152]: OPTIONS:
May 16 15:04:58 localhost bluetit[2152]: PROTOCOL OPTIONS:
May 16 15:04:58 localhost bluetit[2152]: EVENT: ASSIGN_IP
May 16 15:04:58 localhost bluetit[2152]: VPN Server has pushed IPv4 DNS server 10.31.50.1
May 16 15:04:58 localhost bluetit[2152]: Setting pushed IPv4 DNS server 10.31.50.1 in resolv.conf
May 16 15:04:58 localhost bluetit[2152]: VPN Server has pushed IPv6 DNS server fde6:7a:7d20:1b32::1
May 16 15:04:58 localhost bluetit[2152]: Setting pushed IPv6 DNS server fde6:7a:7d20:1b32::1 in resolv.conf
May 16 15:04:58 localhost bluetit[2152]: net_iface_mtu_set: mtu 1500 for tun0
May 16 15:04:58 localhost bluetit[2152]: net_iface_up: set tun0 up
May 16 15:04:58 localhost bluetit[2152]: net_addr_add: 10.31.50.116/24 brd 10.31.50.255 dev tun0
May 16 15:04:58 localhost bluetit[2152]: net_addr_add: fde6:7a:7d20:1b32::1072/64 dev tun0
May 16 15:04:58 localhost bluetit[2152]: net_route_add: 0.0.0.0/1 via 10.31.50.1 dev tun0 table 0 metric 0
May 16 15:04:58 localhost bluetit[2152]: net_route_add: 128.0.0.0/1 via 10.31.50.1 dev tun0 table 0 metric 0
May 16 15:04:58 localhost bluetit[2152]: net_route_add: ::/1 via fde6:7a:7d20:1b32::1 dev tun0 table 0 metric 0
May 16 15:04:58 localhost bluetit[2152]: net_route_add: 8000::/1 via fde6:7a:7d20:1b32::1 dev tun0 table 0 metric 0
May 16 15:04:58 localhost bluetit[2152]: TunPersist: saving tun context:
May 16 15:04:58 localhost bluetit[2152]: Connected via tun
May 16 15:04:58 localhost bluetit[2152]: LZO-ASYM init swap=0 asym=1
May 16 15:04:58 localhost bluetit[2152]: Comp-stub init swap=0
May 16 15:04:58 localhost bluetit[2152]: EVENT: CONNECTED nl3.vpn.airdns.org:443 (213.152.161.135) via /UDPv4 on tun/10.31.50.116/fde6:7a:7d20:1b32::1072 gw
=[10.31.50.1/fde6:7a:7d20:1b32::1]
May 16 15:04:58 localhost bluetit[2152]: Server has pushed its own DNS. Removing system DNS from network filter.
May 16 15:04:58 localhost bluetit[2152]: System DNS 84.116.46.20 is now rejected by the network filter
May 16 15:04:58 localhost bluetit[2152]: System DNS 84.116.46.21 is now rejected by the network filter
localhost:~ #


 

Share this post


Link to post
3 hours ago, Staff said:


@183aTr78f9o
The 1st reported behavior is expected. because Bluetit must not proceed when it is in a "dirty condition", but it remains to be seen why Bluetit did not exit cleanly in its last session. Was it intended as a test (i.e. you explicitly wanted a dirty startup to test), or is it unexpected? (OK, you already wrote it was a test :) ).

Once you have issued goldcrest --recover-network you don't need to restart Bluetit, you can directly start a connection. Also, Bluetit will activate network lock immediately after a network recovery, if networklockpersist is set in bluetit.rc - another good reason to avoid a restart.

The 2nd remark describes an unexpected event. What happens after you resume the system? Can you send us the full Bluetit log taken just after the problem has occurred? The expected behavior would be that Bluetit daemon does not exit at all, in the first place, when you order an hibernation. Let's see what kills it, if possible.
 


I'm not sure I understand. If my machine crashes and reboots, shouldn't the network lock feature keep my Internet from working at all and thus from receiving/sending packets outside of the VPN tunnel?

This is not what happens in my case. If I manually reboot my machine, on reboot my Internet connection is working and I'm not connected to any AirVPN server. And as I said, I do have networklockpersist and networklock values set to on in /etc/airvpn/bluetit.rc

$ systemctl status bluetit.service (right after a savage reboot):

× bluetit.service - AirVPN Bluetit Daemon
     Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sun 2021-05-16 15:16:08 CEST; 28s ago
    Process: 2111 ExecStart=/sbin/bluetit (code=exited, status=1/FAILURE)
        CPU: 7ms

systemd[1]: Starting AirVPN Bluetit Daemon...
bluetit[2111]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
bluetit[2111]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
bluetit[2111]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
bluetit[2111]: Bluetit is already running or did not exit gracefully on its last run or has been killed. Exit>
systemd[1]: bluetit.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: bluetit.service: Failed with result 'exit-code'.
systemd[1]: Failed to start AirVPN Bluetit Daemon.

 


Then, I run $ goldcrest --recover-network:

2021-05-16 15:17:42 Reading run control directives from file /home/user/.config/goldcrest.rc
Goldcrest 1.1.0 RC4 - 14 May 2021

2021-05-16 15:17:42 ERROR: D-Bus service org.airvpn.server is not available


$ systemctl status bluetit.service:

● bluetit.service - AirVPN Bluetit Daemon
     Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-05-16 15:18:38 CEST; 3s ago
    Process: 2828 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS)
   Main PID: 2830 (bluetit)
      Tasks: 2 (limit: 19052)
     Memory: 4.6M
        CPU: 42ms
     CGroup: /system.slice/bluetit.service
             └─2830 /sbin/bluetit

systemd[1]: Started AirVPN Bluetit Daemon.
bluetit[2830]: Bluetit did not exit gracefully on its last run or has been killed.
bluetit[2830]: Run recover network procedure or restore system settings saved in /etc/airvpn
bluetit[2830]: ERROR: Connection to AirVPN's ipleak.net cancelled. It seems Bluetit did not exit gracefully o>
                                         Your system may not be working properly and your network connection may not work
                                         as expected. To recover your network settings, run this program again and use
                                         the "--recover-network" option.
bluetit[2830]: AirVPN Manifest updater thread started
bluetit[2830]: AirVPN Manifest update interval is 15 minutes
bluetit[2830]: ERROR: Cannot start AirVPN boot connection. It seems Bluetit did not exit gracefully or has be>
                                         Your system may not be working properly and your network connection may not work
                                         as expected. To recover your network settings, run this program again and use
                                         the "--recover-network" option.
bluetit[2830]: AirVPN Manifest update suspended: AirVPN boot connection initialization in progress
bluetit[2830]: Updating AirVPN Manifest
bluetit[2830]: AirVPN Manifest successfully retrieved from server


Then, I run $ goldcrest --recover-network again:

2021-05-16 15:20:57 Reading run control directives from file /home/user/.config/goldcrest.rc
Goldcrest 1.1.0 RC4 - 14 May 2021

2021-05-16 15:20:57 Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
2021-05-16 15:20:57 OpenVPN core 3.7 AirVPN linux x86_64 64-bit
2021-05-16 15:20:57 Bluetit does not need a network recovery.
2021-05-16 15:20:57 Bluetit session terminated


$ systemctl status bluetit.service:

● bluetit.service - AirVPN Bluetit Daemon
     Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-05-16 15:18:38 CEST; 1min 21s ago
    Process: 2828 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS)
   Main PID: 2830 (bluetit)
      Tasks: 2 (limit: 19052)
     Memory: 4.8M
        CPU: 104ms
     CGroup: /system.slice/bluetit.service
             └─2830 /sbin/bluetit

bluetit[2830]: AirVPN Manifest update interval is 15 minutes
bluetit[2830]: ERROR: Cannot start AirVPN boot connection. It seems Bluetit did not exit gracefully or has be>
                                         Your system may not be working properly and your network connection may not work
                                         as expected. To recover your network settings, run this program again and use
                                         the "--recover-network" option.
bluetit[2830]: AirVPN Manifest update suspended: AirVPN boot connection initialization in progress
bluetit[2830]: Updating AirVPN Manifest
bluetit[2830]: AirVPN Manifest successfully retrieved from server
bluetit[2830]: Requested method "version"
bluetit[2830]: Requested method "openvpn_info"
bluetit[2830]: Requested method "recover_network -> "
bluetit[2830]: Successfully restored DNS settings
bluetit[2830]: Network filter successfully restored


Still not any connection established to a AirVPN server at this point. I finally have to run $ sudo systemctl restart bluetit.service to connect to an AirVPN server.

Am I doing something wrong?

---

Now regarding bluetit.service no longer working after resuming from suspend/hibernate.

Various outputs taken right after resuming from suspend:

$ systemctl bluetit.service

● bluetit.service - AirVPN Bluetit Daemon
        Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
        Active: active (running) since Sun 2021-05-16 15:22:13 CEST; 2min 20s ago
        Process: 2922 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS)
        Main PID: 2924 (bluetit)
            Tasks: 4 (limit: 19052)
          Memory: 7.1M
                  CPU: 578ms
          CGroup: /system.slice/bluetit.service
                        └─2924 /sbin/bluetit

bluetit[2924]: UDP send exception: send: Network is unreachable
bluetit[2924]: ERROR: NETWORK_SEND_ERROR
bluetit[2924]: ERROR: KEEPALIVE_TIMEOUT
bluetit[2924]: Session invalidated: KEEPALIVE_TIMEOUT
bluetit[2924]: Client terminated, restarting in 2000 ms...
bluetit[2924]: EVENT: RECONNECTING
bluetit[2924]: ERROR: N_RECONNECT
bluetit[2924]: Contacting xxx.xxx.xxx.xxx:443 via UDP
bluetit[2924]: EVENT: WAIT bluetit[2924]: Connecting to [xxx.vpn.airdns.org]:443 (xxx.xxx.xxx.xxx) via UDPv4


It keeps repeating this loop every 10 seconds and never reconnects. At this point, I don't have any working Internet connection at all, even outside of the tunnel.

If I run $ goldcrest --recover-network and $ systemctl status bluetit.service again:

● bluetit.service - AirVPN Bluetit Daemon
     Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-05-16 15:22:13 CEST; 4min 41s ago
    Process: 2922 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS)
   Main PID: 2924 (bluetit)
      Tasks: 4 (limit: 19052)
     Memory: 7.1M
        CPU: 643ms
     CGroup: /system.slice/bluetit.service
             └─2924 /sbin/bluetit

bluetit[2924]: ERROR: N_RECONNECT
bluetit[2924]: Contacting xxx.xxx.xxx.xxx:443 via UDP
bluetit[2924]: EVENT: WAIT
bluetit[2924]: Connecting to [xxx.vpn.airdns.org]:443 (xxx.xxx.xxx.xxx) via UDPv4
bluetit[2924]: Server poll timeout, trying next remote entry...
bluetit[2924]: EVENT: RECONNECTING
bluetit[2924]: ERROR: N_RECONNECT
bluetit[2924]: Contacting xxx.xxx.xxx.xxx:443 via UDP
bluetit[2924]: EVENT: WAIT
bluetit[2924]: Connecting to [xxx.vpn.airdns.org]:443 (xxx.xxx.xxx.xxx) via UDPv4


I have to run $ sudo systemctl restart bluetit.service in order to successfully connect to an AirVPN server.

To sum up: I have to run $ goldcrest --recover-network and $ sudo systemctl restart bluetit.service after resuming from suspend/hibernate so that my machine reconnects to an AirVPN server. Hence my bluetit-restart.service which does all of this automatically.

The second issue isn't a big deal since I can workaround it with another systemd service and because my Internet connection isn't active at all (no leak) after resuming from suspend/hibernate (without my restart unit).

On the other hand, I'm more concerned about the first one. My Linux machine is encrypted so it cannot actually perform the full reboot process until I manually type my LUKS password, but what about another sort of crash that doesn't involve a reboot?

Thanks in advance for your help.

Share this post


Link to post
@183aTr78f9o

Hello!

Behavior 1 is expected: when you enforce a savage reboot by pressing the hardware button, bluetit.lock fie in /etc/airvpn is not deleted (not even by intrusive systemd, as it happens normally), so Bluetit needs to exit at the next run, necessarily: another instance might be running - and anyway the anomalous situation must be investigated by root.

If you want to force Bluetit start in any case without verifications, you just need to
  1. delete /etc/airvpn/bliuetit.lock first if it exists
  2. (re) start Bluetit
  3. finally run goldcrest --recover-network

In this way Bluetit will start in any case. Then, if it finds a dirty situation for the DNS and firewall backup files, it will remain running (it would exit only if the lock files existed): then Goldcrest will ask Bluetit to recover network, Bluetit will comply (if it's in a clean situation it will simply ignore the network recovery order) and immediately after will activate network lock (if newtorklockpersist is specified) and also connect if connectatboot <mode> is specified.

Remember, therefore, not to postpone Bluetit (re)start command with goldcrest --recover-network command, otherwise Golcrest will find no service to contact via D-Bus in your context.

Issue 2 is related to how a system handles suspend/resume: is the network interface powered off? If so, at resume is network re-initialized? If network interface kept working, is network initialized anyway, or do we still have the routing table set by the VPN client according to the server push? What about firewall rules and tun status?

We leave the behavior to each system, ideally Bluetit should not take care of all the possible combinations. Your proposed solution is fine, if we come out with something better we will let you know. A possible weakness of your solution is that the "wake up" unit you defined might start BEFORE Bluetit runs, in some anomalous situation.

Thank you very much for your tests!

Kind regards


 

Share this post


Link to post

@colorman

Hello!

We see that you get some error even when Bluetit enforces network lock through iptables-legacy. However, from the log it's unclear whether those errors are irrelevant or not. While Bluetit is still connected with network lock on (with iptables-legacy, as it is in your last log you sent us) can you send us the output of the command iptables-save ?

About nft 0.8.2, it's an obsolete version. However, Bluetit now handles it correctly (tested in Debian 9 and openSUSE 15.2) - let's see first iptables-legacy anyway.

Kind regards
 

Share this post


Link to post
1 hour ago, Staff said:

@colorman

Hello!

We see that you get some error even when Bluetit enforces network lock through iptables-legacy. However, from the log it's unclear whether those errors are irrelevant or not. While Bluetit is still connected with network lock on (with iptables-legacy, as it is in your last log you sent us) can you send us the output of the command iptables-save ?

About nft 0.8.2, it's an obsolete version. However, Bluetit now handles it correctly (tested in Debian 9 and openSUSE 15.2) - let's see first iptables-legacy anyway.

Kind regards
 

I updated nft to; nftables v0.9.8 (E.D.S.)
On 2 juni leap 15,3 release...... perhaps that solves something?

ocalhost:~ # iptables-save
# Generated by iptables-save v1.8.3 on Mon May 17 12:58:22 2021
*nat
:PREROUTING ACCEPT [54:7047]
:INPUT ACCEPT [23:3002]
:OUTPUT ACCEPT [2362:163825]
:POSTROUTING ACCEPT [2362:163825]
:OUTPUT_direct - [0:0]
:POSTROUTING_ZONES - [0:0]
:POSTROUTING_ZONES_SOURCE - [0:0]
:POSTROUTING_direct - [0:0]
:POST_public - [0:0]
:POST_public_allow - [0:0]
:POST_public_deny - [0:0]
:POST_public_log - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_ZONES_SOURCE - [0:0]
:PREROUTING_direct - [0:0]
:PRE_public - [0:0]
:PRE_public_allow - [0:0]
:PRE_public_deny - [0:0]
:PRE_public_log - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES_SOURCE
-A PREROUTING -j PREROUTING_ZONES
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -j POSTROUTING_direct
-A POSTROUTING -j POSTROUTING_ZONES_SOURCE
-A POSTROUTING -j POSTROUTING_ZONES
-A POSTROUTING_ZONES -g POST_public
-A POST_public -j POST_public_log
-A POST_public -j POST_public_deny
-A POST_public -j POST_public_allow
-A PREROUTING_ZONES -g PRE_public
-A PRE_public -j PRE_public_log
-A PRE_public -j PRE_public_deny
-A PRE_public -j PRE_public_allow
COMMIT
# Completed on Mon May 17 12:58:22 2021
# Generated by iptables-save v1.8.3 on Mon May 17 12:58:22 2021
*mangle
:PREROUTING ACCEPT [85928:94384467]
:INPUT ACCEPT [85928:94384467]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67756:13352826]
:POSTROUTING ACCEPT [67775:13357165]
:FORWARD_direct - [0:0]
:INPUT_direct - [0:0]
:OUTPUT_direct - [0:0]
:POSTROUTING_direct - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_ZONES_SOURCE - [0:0]
:PREROUTING_direct - [0:0]
:PRE_public - [0:0]
:PRE_public_allow - [0:0]
:PRE_public_deny - [0:0]
:PRE_public_log - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES_SOURCE
-A PREROUTING -j PREROUTING_ZONES
-A INPUT -j INPUT_direct
-A FORWARD -j FORWARD_direct
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -j POSTROUTING_direct
-A PREROUTING_ZONES -g PRE_public
-A PRE_public -j PRE_public_log
-A PRE_public -j PRE_public_deny
-A PRE_public -j PRE_public_allow
COMMIT
# Completed on Mon May 17 12:58:22 2021
# Generated by iptables-save v1.8.3 on Mon May 17 12:58:22 2021
*raw
:PREROUTING ACCEPT [85928:94384467]
:OUTPUT ACCEPT [67756:13352826]
:OUTPUT_direct - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_ZONES_SOURCE - [0:0]
:PREROUTING_direct - [0:0]
:PRE_public - [0:0]
:PRE_public_allow - [0:0]
:PRE_public_deny - [0:0]
:PRE_public_log - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES_SOURCE
-A PREROUTING -j PREROUTING_ZONES
-A OUTPUT -j OUTPUT_direct
-A PREROUTING_ZONES -g PRE_public
-A PRE_public -j PRE_public_log
-A PRE_public -j PRE_public_deny
-A PRE_public -j PRE_public_allow
-A PRE_public_allow -p udp -m udp --dport 137 -j CT --helper netbios-ns
COMMIT
# Completed on Mon May 17 12:58:22 2021
# Generated by iptables-save v1.8.3 on Mon May 17 12:58:22 2021
*security
:INPUT ACCEPT [85875:94379443]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67756:13352826]
:FORWARD_direct - [0:0]
:INPUT_direct - [0:0]
:OUTPUT_direct - [0:0]
-A INPUT -j INPUT_direct
-A FORWARD -j FORWARD_direct
-A OUTPUT -j OUTPUT_direct
COMMIT
# Completed on Mon May 17 12:58:22 2021
# Generated by iptables-save v1.8.3 on Mon May 17 12:58:22 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67756:13352826]
:FORWARD_IN_ZONES - [0:0]
:FORWARD_IN_ZONES_SOURCE - [0:0]
:FORWARD_OUT_ZONES - [0:0]
:FORWARD_OUT_ZONES_SOURCE - [0:0]
:FORWARD_direct - [0:0]
:FWDI_public - [0:0]
:FWDI_public_allow - [0:0]
:FWDI_public_deny - [0:0]
:FWDI_public_log - [0:0]
:FWDO_public - [0:0]
:FWDO_public_allow - [0:0]
:FWDO_public_deny - [0:0]
:FWDO_public_log - [0:0]
:INPUT_ZONES - [0:0]
:INPUT_ZONES_SOURCE - [0:0]
:INPUT_direct - [0:0]
:IN_public - [0:0]
:IN_public_allow - [0:0]
:IN_public_deny - [0:0]
:IN_public_log - [0:0]
:OUTPUT_direct - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j ACCEPT
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -g IN_public
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 137 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p udp -m udp --dport 138 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 139 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 445 -m conntrack --ctstate NEW -j ACCEPT
COMMIT
# Completed on Mon May 17 12:58:22 2021

 

Share this post


Link to post
3 hours ago, Staff said:
@183aTr78f9o

Hello!

Behavior 1 is expected: when you enforce a savage reboot by pressing the hardware button, bluetit.lock fie in /etc/airvpn is not deleted (not even by intrusive systemd, as it happens normally), so Bluetit needs to exit at the next run, necessarily: another instance might be running - and anyway the anomalous situation must be investigated by root.

If you want to force Bluetit start in any case without verifications, you just need to
  1. delete /etc/airvpn/bliuetit.lock first if it exists
  2. (re) start Bluetit
  3. finally run goldcrest --recover-network

In this way Bluetit will start in any case. Then, if it finds a dirty situation for the DNS and firewall backup files, it will remain running (it would exit only if the lock files existed): then Goldcrest will ask Bluetit to recover network, Bluetit will comply (if it's in a clean situation it will simply ignore the network recovery order) and immediately after will activate network lock (if newtorklockpersist is specified) and also connect if connectatboot <mode> is specified.

Remember, therefore, not to postpone Bluetit (re)start command with goldcrest --recover-network command, otherwise Golcrest will find no service to contact via D-Bus in your context.

Thanks for the detailed explanation, although I still don't see any valid reason why all my traffic is run outside of the VPN tunnel after an unxepected/forced reboot despite having networklockpersist set to on in /etc/airvpn/bluetit.rc.

From the README.md file:
 
Quote

- networklockpersist: (string) Define the network lock method to be used for the whole bluetit session. When turned on, traffic is allowed to and from the network only in case bluetit is connected to a VPN.


The bold part is quite misleading in my opinion, maybe you should add a section to warn users that this setting won't have any effect in case of an unexpected/forced reboot or power outage for instance.

I'm forced to reboot that way often enough so I don't want to run the risk of forgetting to manually restore the VPN connection. If I forget, all my Internet traffic will run outside of the VPN tunnel and I might never notice it.

My two cents: the network lock should be enforced in such scenarios. Who would want unencrypted traffic after reboot in these situations anyway?

I guess I'll stick with hummingbird + .ovpn files and custom systemd service for the time being. It's been working pretty well for my use case, and even in a case of an unexpected/forced reboot, the VPN connection is still established without any issue after rebooting.
 
4 hours ago, Staff said:
@183aTr78f9o

Issue 2 is related to how a system handles suspend/resume: is the network interface powered off? If so, at resume is network re-initialized? If network interface kept working, is network initialized anyway, or do we still have the routing table set by the VPN client according to the server push? What about firewall rules and tun status?

We leave the behavior to each system, ideally Bluetit should not take care of all the possible combinations. Your proposed solution is fine, if we come out with something better we will let you know. A possible weakness of your solution is that the "wake up" unit you defined might start BEFORE Bluetit runs, in some anomalous situation.

Thank you very much for your tests!

Kind regards

Sorry but I'm just a random end user, I am by no means a netadmin... I'm not sure how I am expected to check all of these. All I know is that bluetit isn't the culprit because I also had to create a restart unit for my custom hummingbird unit. It all started once systemd 247 was released. On previous systemd versions, my service was restarted just fine after resuming from suspend/hibernate. This user was facing the same issue with ProtonVPN.
 

Share this post


Link to post
@183aTr78f9o
Quote


Thanks for the detailed explanation, although I still don't see any valid reason why all my traffic is run outside of the VPN tunnel after an unxepected/forced reboot despite having networklockpersist set to on in /etc/airvpn/bluetit.rc.


Hello!

You can find an explanation and the immediate solution for you needs, which takes just a few seconds, in our previous message.. In this way you can have network lock even when you press a hard reset button or you power cycle the machine while it's working at your own risk..
 
Quote


My two cents: the network lock should be enforced in such scenarios. Who would want unencrypted traffic after reboot in these situations anyway?


The fact is that a daemon must never perform root operations if the lock file exists Ignoring this simple but important rule would be terrible, for quite obvious reasons. Never mind if you can't understand why right now: remove the lock file and you will have the behavior you want.
 
Quote


I'm forced to reboot that way often enough so I don't want to run the risk of forgetting to manually restore the VPN connection. If I forget, all my Internet traffic will run outside of the VPN tunnel and I might never notice it.


If you read the whole documentation there should be no misunderstanding. What it matters is underlining that Bluetit is so flexible that even in this case you can achieve your purpose simply, in the way we described.
 
Quote


I guess I'll stick with hummingbird + .ovpn files and custom systemd service for the time being. It's been working pretty well for my use case, and even in a case of an unexpected/forced reboot, the VPN connection is still established without any issue after rebooting.


Sure, if it suits your needs why not. Just remember that Hummingbird is not a daemon and keep in mind the architectural difference, to understand the risks.
 
Quote

Sorry but I'm just a random end user, I am by no means a netadmin... I'm not sure how I am expected to check all of these.


No reason to be sorry, you were never asked to in the first place. Those questions were rhetorical ones to clarify that in our opinion Bluetit should not take into account all the possible combinations and try to enlarge its scope, because that's strictly a matter of other system components. Given the non-uniformity in behavior of hundreds of Linux distributions, and their ever changing and evolving behavior, we believe it's a wise choice not to interfere in other processes duty.

Therefore, we can close the issue, the behavior is correct and expected, no bugs here.

Kind regards



 

Share this post


Link to post
@colorman

Hello!

We are struggling to reproduce the issue, openSUSE 15.2 is one of our testing systems for AirVPN Suite and we fail to understand why we can't get the same behavior you experience. We have tested both with firewalld enabled and disabled, both with iptables-legacy and nft 0.8.2 (all combinations) and everything went smoothly. In other words, network lock is engaged and disengaged correctly, either with iptables-legacy or nft, tested both with firewalld running and not running.

Can you please try again network lock with:
- firewalld disabled (not running at all)
- by enforcing iptables-legacy (networklock or networklockpersist set to iptables)
- then, by enforcing nftables (networklock or networklockpersist set to nftables)

We are looking forward to hearing from you.

Kind regards
 

Share this post


Link to post

firewalld disabled

localhost:~ # journalctl | grep bluetit
May 18 12:48:32 localhost bluetit[1962]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
May 18 12:48:32 localhost bluetit[1962]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 18 12:48:32 localhost bluetit[1962]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
May 18 12:48:32 localhost bluetit[1973]: Bluetit daemon started with PID 1973
May 18 12:48:32 localhost systemd[1]: bluetit.service: Supervising process 1973 which is not our child. We'll most likely not notice when it exits.
May 18 12:48:32 localhost bluetit[1973]: External network is reachable via gateway 192.168.178.1 through interface eth0
May 18 12:48:32 localhost bluetit[1973]: Successfully connected to D-Bus
May 18 12:48:32 localhost bluetit[1973]: Reading run control directives from file /etc/airvpn/bluetit.rc
May 18 12:48:32 localhost bluetit[1973]: IPv6 is available in this system
May 18 12:48:32 localhost bluetit[1973]: Bluetit successfully initialized and ready
May 18 12:48:32 localhost bluetit[1973]: Requesting network IP and country to AirVPN ipleak.net via secure connection
May 18 12:48:32 localhost bluetit[1973]: ERROR: Cannot detect system location: Unknown error: Problem with the SSL CA cert (path? access rights?)
May 18 12:48:32 localhost bluetit[1973]: AirVPN Manifest updater thread started
May 18 12:48:32 localhost bluetit[1973]: AirVPN Manifest update interval is 15 minutes
May 18 12:48:32 localhost bluetit[1973]: Updating AirVPN Manifest
May 18 12:48:33 localhost bluetit[1973]: AirVPN Manifest successfully retrieved from server
May 18 12:51:35 localhost bluetit[1973]: Requested method "version"
May 18 12:51:35 localhost bluetit[1973]: Requested method "openvpn_info"
May 18 12:51:35 localhost bluetit[1973]: Requested method "bluetit_status -> Bluetit is ready"
May 18 12:51:35 localhost bluetit[1973]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
May 18 12:51:36 localhost bluetit[1973]: Requested method "set_openvpn_profile -> OK"
May 18 12:51:36 localhost bluetit[1973]: Requested method "start_connection"
May 18 12:51:36 localhost bluetit[1973]: OpenVPN3 connection successfully started
May 18 12:51:36 localhost bluetit[1973]: Network filter and lock are using iptables-legacy
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module iptable_filter
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module iptable_nat
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module iptable_mangle
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module iptable_security
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module iptable_raw
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module ip6table_filter
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module ip6table_nat
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module ip6table_mangle
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module ip6table_security
May 18 12:51:36 localhost bluetit[1973]: Successfully loaded kernel module ip6table_raw
May 18 12:51:36 localhost bluetit[1973]: WARNING: firewalld is running on this system and may interfere with network filter and lock
May 18 12:51:36 localhost bluetit[1973]: Network filter successfully initialized
May 18 12:51:36 localhost bluetit[1973]: Starting VPN Connection
May 18 12:51:36 localhost bluetit[1973]: OpenVPN3 client successfully created and initialized.
May 18 12:51:36 localhost bluetit[1973]: TUN persistence is enabled.
May 18 12:51:36 localhost bluetit[1973]: Successfully set OpenVPN3 client configuration
May 18 12:51:36 localhost bluetit[1973]: Starting OpenVPN3 connection thread
May 18 12:51:36 localhost bluetit[1973]: Connection statistics updater thread started
May 18 12:51:36 localhost bluetit[1973]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 18 12:51:36 localhost bluetit[1973]: Frame=512/2048/512 mssfix-ctrl=1250
May 18 12:51:36 localhost bluetit[1973]: UNUSED OPTIONS
May 18 12:51:36 localhost bluetit[1973]: EVENT: RESOLVE
May 18 12:51:36 localhost bluetit[1973]: Local IPv4 address 192.168.178.11
May 18 12:51:36 localhost bluetit[1973]: Local IPv6 address 2001:1c04:509:4000:6400:8709:7d2d:907f
May 18 12:51:36 localhost bluetit[1973]: Local IPv6 address 2001:1c04:509:4000:aaa1:59ff:fe2f:523e
May 18 12:51:36 localhost bluetit[1973]: Local IPv6 address fe80::aaa1:59ff:fe2f:523e
May 18 12:51:36 localhost bluetit[1973]: Local interface eth0
May 18 12:51:36 localhost bluetit[1973]: Setting up network filter and lock
May 18 12:51:36 localhost bluetit[1973]: Allowing system DNS 84.116.46.20 to pass through the network filter
May 18 12:51:36 localhost bluetit[1973]: Allowing system DNS 84.116.46.21 to pass through the network filter
May 18 12:51:36 localhost bluetit[1973]: ERROR: Cannot allow system DNS to pass through network filter
May 18 12:51:36 localhost bluetit[1973]: Resolved server nl3.vpn.airdns.org into IPv4 134.19.179.197
May 18 12:51:36 localhost bluetit[1973]: Adding IPv4 server 134.19.179.197 to network filter
May 18 12:51:36 localhost bluetit[1973]: ERROR: Cannot activate network filter and lock
May 18 12:51:36 localhost bluetit[1973]: Contacting 134.19.179.197:443 via UDP
May 18 12:51:36 localhost bluetit[1973]: EVENT: WAIT
May 18 12:51:36 localhost bluetit[1973]: net_route_best_gw query IPv4: 134.19.179.197/32
May 18 12:51:36 localhost bluetit[1973]: sitnl_route_best_gw result: via 192.168.178.1 dev eth0
May 18 12:51:36 localhost bluetit[1973]: net_route_add: 134.19.179.197/32 via 192.168.178.1 dev eth0 table 0 metric 0
May 18 12:51:36 localhost bluetit[1973]: Connecting to [nl3.vpn.airdns.org]:443 (134.19.179.197) via UDPv4
May 18 12:51:36 localhost bluetit[1973]: EVENT: CONNECTING
May 18 12:51:36 localhost bluetit[1973]: Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysi
ze 256,key-method 2,tls-client
May 18 12:51:36 localhost bluetit[1973]: Peer Info:
May 18 12:51:36 localhost bluetit[1973]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RS
A-SHA1
May 18 12:51:36 localhost bluetit[1973]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Aspidiske/emailAddress=info@airvpn.org, signature: RSA-SH
A512
May 18 12:51:36 localhost bluetit[1973]: SSL Handshake: peer certificate: CN=Aspidiske, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any   
  Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
May 18 12:51:36 localhost bluetit[1973]: Session is ACTIVE
May 18 12:51:36 localhost bluetit[1973]: EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a stronger algorithm
. Support for SHA1 signatures will be dropped in the future
May 18 12:51:36 localhost bluetit[1973]: EVENT: GET_CONFIG
May 18 12:51:36 localhost bluetit[1973]: Sending PUSH_REQUEST to server...
May 18 12:51:36 localhost bluetit[1973]: OPTIONS:
May 18 12:51:36 localhost bluetit[1973]: PROTOCOL OPTIONS:
May 18 12:51:36 localhost bluetit[1973]: EVENT: ASSIGN_IP
May 18 12:51:36 localhost bluetit[1973]: VPN Server has pushed IPv4 DNS server 10.33.146.1
May 18 12:51:36 localhost bluetit[1973]: Setting pushed IPv4 DNS server 10.33.146.1 in resolv.conf
May 18 12:51:36 localhost bluetit[1973]: VPN Server has pushed IPv6 DNS server fde6:7a:7d20:1d92::1
May 18 12:51:36 localhost bluetit[1973]: Setting pushed IPv6 DNS server fde6:7a:7d20:1d92::1 in resolv.conf
May 18 12:51:36 localhost bluetit[1973]: net_iface_mtu_set: mtu 1500 for tun0
May 18 12:51:36 localhost bluetit[1973]: net_iface_up: set tun0 up
May 18 12:51:36 localhost bluetit[1973]: net_addr_add: 10.33.146.128/24 brd 10.33.146.255 dev tun0
May 18 12:51:36 localhost bluetit[1973]: net_addr_add: fde6:7a:7d20:1d92::107e/64 dev tun0
May 18 12:51:36 localhost bluetit[1973]: net_route_add: 0.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:51:36 localhost bluetit[1973]: net_route_add: 128.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:51:36 localhost bluetit[1973]: net_route_add: ::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:51:36 localhost bluetit[1973]: net_route_add: 8000::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:51:36 localhost bluetit[1973]: TunPersist: saving tun context:
May 18 12:51:36 localhost bluetit[1973]: Connected via tun
May 18 12:51:36 localhost bluetit[1973]: LZO-ASYM init swap=0 asym=1
May 18 12:51:36 localhost bluetit[1973]: Comp-stub init swap=0
May 18 12:51:36 localhost bluetit[1973]: EVENT: CONNECTED nl3.vpn.airdns.org:443 (134.19.179.197) via /UDPv4 on tun/10.33.146.128/fde6:7a:7d20:1d92::107e gw
=[10.33.146.1/fde6:7a:7d20:1d92::1]
May 18 12:51:36 localhost bluetit[1973]: Server has pushed its own DNS. Removing system DNS from network filter.
May 18 12:51:36 localhost bluetit[1973]: System DNS 84.116.46.20 is now rejected by the network filter
May 18 12:51:36 localhost bluetit[1973]: System DNS 84.116.46.21 is now rejected by the network filter
May 18 12:53:22 localhost bluetit[1973]: Requested method "bluetit_status -> Bluetit is connected to VPN"
May 18 12:53:22 localhost bluetit[1973]: Requested method "stop_connection"
May 18 12:53:22 localhost bluetit[1973]: Stopping OpenVPN3 connection thread
May 18 12:53:22 localhost bluetit[1973]: Connection statistics updater thread finished
May 18 12:53:22 localhost bluetit[1973]: net_route_del: 8000::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:53:22 localhost bluetit[1973]: net_route_del: ::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:53:22 localhost bluetit[1973]: net_route_del: 128.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:53:22 localhost bluetit[1973]: net_route_del: 0.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:53:22 localhost bluetit[1973]: net_addr_del: fde6:7a:7d20:1d92::107e/64 dev tun0
May 18 12:53:22 localhost bluetit[1973]: net_addr_del: 10.33.146.128/24 dev tun0
May 18 12:53:22 localhost bluetit[1973]: net_iface_mtu_set: mtu 1500 for tun0
May 18 12:53:22 localhost bluetit[1973]: net_iface_up: set tun0 down
May 18 12:53:22 localhost bluetit[1973]: net_route_del: 134.19.179.197/32 via 192.168.178.1 dev eth0 table 0 metric 0
May 18 12:53:22 localhost bluetit[1973]: EVENT: DISCONNECTED
May 18 12:53:22 localhost bluetit[1973]: Successfully restored DNS settings
May 18 12:53:22 localhost bluetit[1973]: Network filter successfully restored
May 18 12:53:22 localhost bluetit[1973]: OpenVPN3 connection thread finished
May 18 12:53:22 localhost bluetit[1973]: OpenVPN3 connection thread successfully terminated
May 18 12:53:22 localhost dbus-daemon[1162]: [system] Rejected send message, 3 matched rules; type="error", sender=":1.80" (uid=1000 pid=4353 comm="./goldcr
est AirVPN_Netherlands_UDP-443-Entry3.ovpn") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply="0"
destination=":1.18" (uid=0 pid=1973 comm="/sbin/bluetit ")
May 18 12:53:26 localhost bluetit[1973]: Requested method "version"
May 18 12:53:26 localhost bluetit[1973]: Requested method "openvpn_info"
May 18 12:53:26 localhost bluetit[1973]: Requested method "bluetit_status -> Bluetit is ready"
May 18 12:53:26 localhost bluetit[1973]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
May 18 12:53:26 localhost bluetit[1973]: Requested method "set_openvpn_profile -> OK"
May 18 12:53:26 localhost bluetit[1973]: Requested method "start_connection"
May 18 12:53:26 localhost bluetit[1973]: OpenVPN3 connection successfully started
May 18 12:53:26 localhost bluetit[1973]: Network filter and lock are using iptables-legacy
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module iptable_filter
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module iptable_nat
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module iptable_mangle
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module iptable_security
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module iptable_raw
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module ip6table_filter
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module ip6table_nat
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module ip6table_mangle
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module ip6table_security
May 18 12:53:26 localhost bluetit[1973]: Successfully loaded kernel module ip6table_raw
May 18 12:53:26 localhost bluetit[1973]: WARNING: firewalld is running on this system and may interfere with network filter and lock
May 18 12:53:26 localhost bluetit[1973]: Network filter successfully initialized
May 18 12:53:26 localhost bluetit[1973]: Starting VPN Connection
May 18 12:53:26 localhost bluetit[1973]: OpenVPN3 client successfully created and initialized.
May 18 12:53:26 localhost bluetit[1973]: TUN persistence is enabled.
May 18 12:53:26 localhost bluetit[1973]: Successfully set OpenVPN3 client configuration
May 18 12:53:26 localhost bluetit[1973]: Starting OpenVPN3 connection thread
May 18 12:53:26 localhost bluetit[1973]: Connection statistics updater thread started
May 18 12:53:26 localhost bluetit[1973]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
May 18 12:53:26 localhost bluetit[1973]: Frame=512/2048/512 mssfix-ctrl=1250
May 18 12:53:26 localhost bluetit[1973]: UNUSED OPTIONS
May 18 12:53:26 localhost bluetit[1973]: EVENT: RESOLVE
May 18 12:53:26 localhost bluetit[1973]: Local IPv4 address 192.168.178.11
May 18 12:53:26 localhost bluetit[1973]: Local IPv6 address 2001:1c04:509:4000:6400:8709:7d2d:907f
May 18 12:53:26 localhost bluetit[1973]: Local IPv6 address 2001:1c04:509:4000:aaa1:59ff:fe2f:523e
May 18 12:53:26 localhost bluetit[1973]: Local IPv6 address fe80::aaa1:59ff:fe2f:523e
May 18 12:53:26 localhost bluetit[1973]: Local interface eth0
May 18 12:53:26 localhost bluetit[1973]: Setting up network filter and lock
May 18 12:53:26 localhost bluetit[1973]: Allowing system DNS 84.116.46.20 to pass through the network filter
May 18 12:53:26 localhost bluetit[1973]: Allowing system DNS 84.116.46.21 to pass through the network filter
May 18 12:53:26 localhost bluetit[1973]: ERROR: Cannot allow system DNS to pass through network filter
May 18 12:53:28 localhost bluetit[1973]: Resolved server nl3.vpn.airdns.org into IPv4 134.19.179.197
May 18 12:53:28 localhost bluetit[1973]: Adding IPv4 server 134.19.179.197 to network filter
May 18 12:53:28 localhost bluetit[1973]: ERROR: Cannot activate network filter and lock
May 18 12:53:28 localhost bluetit[1973]: Contacting 134.19.179.197:443 via UDP
May 18 12:53:28 localhost bluetit[1973]: EVENT: WAIT
May 18 12:53:28 localhost bluetit[1973]: net_route_best_gw query IPv4: 134.19.179.197/32
May 18 12:53:28 localhost bluetit[1973]: sitnl_route_best_gw result: via 192.168.178.1 dev eth0
May 18 12:53:28 localhost bluetit[1973]: net_route_add: 134.19.179.197/32 via 192.168.178.1 dev eth0 table 0 metric 0
May 18 12:53:28 localhost bluetit[1973]: Connecting to [nl3.vpn.airdns.org]:443 (134.19.179.197) via UDPv4
May 18 12:53:28 localhost bluetit[1973]: EVENT: CONNECTING
May 18 12:53:28 localhost bluetit[1973]: Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysi
ze 256,key-method 2,tls-client
May 18 12:53:28 localhost bluetit[1973]: Peer Info:
May 18 12:53:28 localhost bluetit[1973]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RS
A-SHA1
May 18 12:53:28 localhost bluetit[1973]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Aspidiske/emailAddress=info@airvpn.org, signature: RSA-SH
A512
May 18 12:53:28 localhost bluetit[1973]: SSL Handshake: peer certificate: CN=Aspidiske, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any   
  Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
May 18 12:53:28 localhost bluetit[1973]: Session is ACTIVE
May 18 12:53:28 localhost bluetit[1973]: EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a stronger algorithm
. Support for SHA1 signatures will be dropped in the future
May 18 12:53:28 localhost bluetit[1973]: EVENT: GET_CONFIG
May 18 12:53:28 localhost bluetit[1973]: Sending PUSH_REQUEST to server...
May 18 12:53:28 localhost bluetit[1973]: OPTIONS:
May 18 12:53:28 localhost bluetit[1973]: PROTOCOL OPTIONS:
May 18 12:53:28 localhost bluetit[1973]: EVENT: ASSIGN_IP
May 18 12:53:28 localhost bluetit[1973]: VPN Server has pushed IPv4 DNS server 10.33.146.1
May 18 12:53:28 localhost bluetit[1973]: Setting pushed IPv4 DNS server 10.33.146.1 in resolv.conf
May 18 12:53:28 localhost bluetit[1973]: VPN Server has pushed IPv6 DNS server fde6:7a:7d20:1d92::1
May 18 12:53:28 localhost bluetit[1973]: Setting pushed IPv6 DNS server fde6:7a:7d20:1d92::1 in resolv.conf
May 18 12:53:28 localhost bluetit[1973]: net_iface_mtu_set: mtu 1500 for tun0
May 18 12:53:28 localhost bluetit[1973]: net_iface_up: set tun0 up
May 18 12:53:28 localhost bluetit[1973]: net_addr_add: 10.33.146.128/24 brd 10.33.146.255 dev tun0
May 18 12:53:28 localhost bluetit[1973]: net_addr_add: fde6:7a:7d20:1d92::107e/64 dev tun0
May 18 12:53:28 localhost bluetit[1973]: net_route_add: 0.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:53:28 localhost bluetit[1973]: net_route_add: 128.0.0.0/1 via 10.33.146.1 dev tun0 table 0 metric 0
May 18 12:53:28 localhost bluetit[1973]: net_route_add: ::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:53:28 localhost bluetit[1973]: net_route_add: 8000::/1 via fde6:7a:7d20:1d92::1 dev tun0 table 0 metric 0
May 18 12:53:28 localhost bluetit[1973]: TunPersist: saving tun context:
May 18 12:53:28 localhost bluetit[1973]: Connected via tun
May 18 12:53:28 localhost bluetit[1973]: LZO-ASYM init swap=0 asym=1
May 18 12:53:28 localhost bluetit[1973]: Comp-stub init swap=0
May 18 12:53:28 localhost bluetit[1973]: EVENT: CONNECTED nl3.vpn.airdns.org:443 (134.19.179.197) via /UDPv4 on tun/10.33.146.128/fde6:7a:7d20:1d92::107e gw
=[10.33.146.1/fde6:7a:7d20:1d92::1]
May 18 12:53:28 localhost bluetit[1973]: Server has pushed its own DNS. Removing system DNS from network filter.
May 18 12:53:28 localhost bluetit[1973]: System DNS 84.116.46.20 is now rejected by the network filter
May 18 12:53:28 localhost bluetit[1973]: System DNS 84.116.46.21 is now rejected by the network filter
localhost:~ #

 

Share this post


Link to post

@Staff
Need help with this?
do you mean this?
- by enforcing iptables-legacy (networklock or networklockpersist set to iptables)
./goldcrest --network-lock iptables AirVPN_Netherlands_UDP-443-Entry3.ovpn
- then, by enforcing nftables (networklock or networklockpersist set to nftables)
./goldcrest --network-lock nftables AirVPN_Netherlands_UDP-443-Entry3.ovpn


When leap 15.3 comes out, I will reinstall everything.
Hopefully that will provide clarity.

Edit: In virtualbox I have leap 15.3 as a test and have tested airvpn / bluetit / goldcrest.
See Appendix......

log.txt

Share this post


Link to post
@colorman

Hello!

We finally managed to understand how to reproduce the issue. We are working on it. In the meantime you should be able to circumvent the problem in any of the following ways. Please check if you have time.
  1. specify your network lock favorite method via networklock or networklockpersist directive in file /etc/airvpn/bluetit.rc - then you don't need to specify it on goldcrest command line. You can edit, with root privileges, /etc/airvpn/bluetit.rc with any text editor (example sudo nano /etc/airvpn/bluetit.rc). Enter anywhere the line networklock on, or even networklockpersist on then save the file
  2. alternatively, connect without a profile, for example goldcrest --network-lock on --air-connect -air country <your favorite country> (you may enter your AirVPN credentials on the terminal when Goldcrest asks for them, or set them in Goldcrest configuration file)

Kind regards
 

Share this post


Link to post

It would be useful if we could list all available countries and servers with goldcrest. Unless I missed it in $ goldcrest --help, I don't think such feature is available.

Maybe something like

$ goldcrest --air-list --air-country --all
$ goldcrest --air-list --air-server --all


Again, unless I'm mistaken, for now we still have to give an argument to either --air-country or --air-server:
 
Quote
### List AirVPN servers                                                     
                                                                              
 List all AirVPN servers which name, country or location contain the pattern  
 "co"                                                                         
                                                                            
 │  $ goldcrest --air-list --air-server co                                     
                                                                            
 List all AirVPN servers located in Germany                                   
                                                                            
 │  $ goldcrest --air-list --air-server germany                                
                                                                            
 or                                                                           
                                                                            
 │  $ goldcrest --air-list --air-server de                                     
                                                                              
 #### List AirVPN countries                                                   
                                                                              
 List all AirVPN countries which name or ISO code contain the pattern "se"    
                                                                            
 │  $ goldcrest --air-list --air-country SE    
 

which isn't very convenient.

Share this post


Link to post
@183aTr78f9o
 
Quote

It would be useful if we could list all available countries and servers with goldcrest. Unless I missed it in $ goldcrest --help, I don't think such feature is available.


Hello!

Quite right. The feature will be available in the 1.1.0 stable release.

Kind regards
 

Share this post


Link to post
On 5/18/2021 at 6:47 PM, Staff said:
@colorman

Hello!

We finally managed to understand how to reproduce the issue. We are working on it. In the meantime you should be able to circumvent the problem in any of the following ways. Please check if you have time.
  1. specify your network lock favorite method via networklock or networklockpersist directive in file /etc/airvpn/bluetit.rc - then you don't need to specify it on goldcrest command line. You can edit, with root privileges, /etc/airvpn/bluetit.rc with any text editor (example sudo nano /etc/airvpn/bluetit.rc). Enter anywhere the line networklock on, or even networklockpersist on then save the file
  2. alternatively, connect without a profile, for example goldcrest --network-lock on --air-connect -air country <your favorite country> (you may enter your AirVPN credentials on the terminal when Goldcrest asks for them, or set them in Goldcrest configuration file)

Kind regards
 
@Staff
I'm having trouble using networklockpersist , after reboot I can't use Bluetit/Goldcrest.
How to recover Bluetit?
Sometimes after reboot again, it works?

@localhost:/usr/local/bin> ./goldcrest --recover-network                      
2021-05-29 16:37:33 Reading run control directives from file /home/gerrit/.config/goldcrest.rc
Goldcrest 1.1.0 RC4 - 14 May 2021

2021-05-29 16:37:33 Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC4 - 14 May 2021
2021-05-29 16:37:33 OpenVPN core 3.7 AirVPN linux x86_64 64-bit
2021-05-29 16:37:33 Failed to restore DNS and network filter settings. Please see syslog for details.
2021-05-29 16:37:34 ERROR: Backup copy of resolv.conf not found.
2021-05-29 16:37:34 Network filter successfully restored
2021-05-29 16:37:34 ERROR: Network filter and lock are already enabled
2021-05-29 16:37:34 Bluetit session terminated


 

Share this post


Link to post
@colorman

Hello!

We have discovered some other bugs (while we fixed the ones you reported) which caused network recovery failure. A new version is coming, probably on Monday.

Kind regards


 

Share this post


Link to post

Hello!

We're very glad to inform you that 1.1.0 has just been released! We are locking this thread, please continue if necessary here:
 
Kind regards
 

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...