Jump to content
Not connected, Your IP: 34.227.191.136
Staff

Linux: AirVPN Suite 1.1.0 released

Recommended Posts

Hello!


We're very glad to inform you that AirVPN Suite version 1.1.0 for Linux has been released. Check supported systems below

The suite includes:

  • Bluetit: lightweight, ultra-fast D-Bus controlled system daemon providing full connectivity and integration to AirVPN servers, or generic OpenVPN servers. Bluetit can also enforce Network Lock and/or connect the system to AirVPN during the bootstrap
  • Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN servers
  • Hummingbird: lightweight and standalone binary for generic OpenVPN server connections

All the software is free and open source, licensed under GPLv3.

 

What's new in 1.1.0 version

 

  • full compatibility with OSMC, Open Source Media Center
  • enhanced compatibility with Raspbian
  • persistent Network Lock implementation, useful for example to enforce prompt Network Lock during system bootstrap and prevent traffic leaks caused by processes at bootstrap (**). Use directive networklockpersist in bluetit.rc to enable Network Lock as soon as Bluetit starts, regardless of network status and connection attempts
  • revisited Network Lock logic for additional safety (****)
  • new directives for bluetit.rc: networklockpersist, connectretrymax and aircipher
  • enhanced DNS handling for peculiar systemd-resolved operational modes
  • more rigorous handling of events through semaphore implementation
  • new D-Bus methods for Network Lock aimed at easier control by clients. Developer's documentation will be published soon
  • crash caused by systemd signal flooding has been resolved
  • libcurl crash in OSMC and other systems has been fixed
  • crash in some 32 bit systems has been fixed
  • logical flaw causing Network Lock missed activation in case of account login failure has been fixed
  • various bug fixes
  • see the changelog below for more information and details
 

Important notes

(**) Ponder the option carefully if your machine needs network sync via NTP or other network services outside the VPN during the bootstrap phase
(***) Fedora 33 and openSUSE 15.2 users beware: we have noticed that in freshly installed Fedora 33 libcurl cannot find CA LetsEncrypt certificates and this will prevent Bluetit from detecting the country from ipleak.net. In this case, you can overcome this bug by using the country directive in bluetit.rc file, therefore avoiding the need to contact ipleak.net web site.
(****) Please note that Network Lock is enforced only on devices where the AirVPN Suite runs. Network Lock and DNS settings  can not be enforced by AirVPN Suite in devices where the Suite does not run on. Furthermore, any root process or daemon can modify firewall rules and DNS settings and it's exclusive task of the system administrator preventing situations caused by root processes and daemons which can not be handled in any way by the Suite.
 

AirVPN Suite changelog


 

Version 1.1.0 - 4 June 2021

  • [ProMIND] vpnclient.hpp: restoreNetworkSettings() now returns a warning in case backup files are not found
  • [ProMIND] vpnclient.hpp: restoreNetworkSettings() improved restoring management with more cases/scenarios
  • [ProMIND] updated all dependencies and libraries


Version 1.1.0 RC 4 - 14 May 2021

  • [ProMIND] optionparser.cpp: added proper message errors in case of invalid argument and allocation memory error
  • [ProMIND] netfilter.cpp: systemBackupExists() now evaluate every firewall mode backup file name
  • [ProMIND] netfilter.cpp: restore() now check for every firewall mode backup and restore it accordingly
  • [ProMIND] netfilter.cpp: IPv6 rules are now allowed or added only in case IPv6 is available in the system


Version 1.1.0 RC 3 - 16 April 2021

  • [ProMIND] Updated to OpenVPN 3.7 AirVPN
  • [ProMIND] vpnclient.hpp: avoid netFilter setup in case NetFilter object is not private
  • [ProMIND] dbusconnector.cpp: fine tuned D-Bus wait cycle in R/W dispatch. Implemented a thread safe wait in order to avoid D-Bus timeout policy


Version 1.1.0 RC 1 - 7 April 2021

  • Release Candidate, no change from Beta 2


Version 1.1.0 Beta 2 - 2 April 2021

  • [ProMIND] localnetwork.cpp: added getDefaultGatewayInterface() method

Version 1.1.0 Beta 1 - 11 March 2021
 
  • [ProMIND] rcparser.cpp: removed formal list control for STRING type
  • [ProMIND] netfilter.hpp, netfilter.cpp: added functions to set the availability of specific iptables tables in order to properly use available tables only
  • [ProMIND] vpnclient.hpp: onResolveEvent() sets iptables tables according to the loaded modules
  • [ProMIND] vpnclient.hpp: Changed constructor in order to use both private and external NetFilter object
  • [ProMIND] localnetwork.cpp: added getLoopbackInterface(), getLocalIPaddresses() and getLocalInterfaces() methods
  • [ProMIND] airvpntools.cpp: added detectLocation() method to retrieve location data from ipleak.net
  • [ProMIND] airvpnuser.cpp: detectUserLocation() now uses AirVPNTools::detectLocation()
  • [ProMIND] airvpnuser.cpp: loadUserProfile() now correctly sets userProfileErrorDescription in case of network failure
  • [ProMIND] airvpnserverprovider.cpp: added "DEFAULT" rule to getUserConnectionPriority() in case user's country or continent is undefined
  • [ProMIND] airvpnmanifest.cpp: loadManifest() now correctly sets the status STORED in case of network failure
  • [ProMIND] Added Semaphore class
  • [ProMIND] dnsmanager.hpp: method revertAllResolved() renamed to restoreResolved(). Besides reverting all interfaces it now restarts systemd-resolved service as well.
  • [ProMIND] install.sh: improved update/upgrade process
 

Bluetit changelog
 

Version 1.1.0 - 4 June 2021
  • [ProMIND] Client option "network-lock" is now forbidden in case persistent network lock is enabled
  • [ProMIND] Avoid network lock initialization in case persistent network lock is enabled and client is requiring an OpenVPN connection from profile
  • [ProMIND] --air-list option now accepts "all" for sub options --air-server and --air-country
  • [ProMIND] AirVPN Manifest update suspended in case Bluetit is in a dirty status
  • [ProMIND] Changed systemd unit in order to prevent the obnoxious SIGKILL signal inappropriately sent before stop timeout completion and for no logical or practical reason when Bluetit is properly and neatly terminating in response to a legal and expected SIGTERM
 
Version 1.1.0 RC 4 - 14 May 2021
  • [ProMIND] Added directives airipv6 and air6to4 in bluetit.rc
  • [ProMIND] In case it is requested a network recovery, VpnClient object is now initialized with NetFilter::Mode::OFF
  • [ProMIND] In case the requested network lock method is not available, connection is not started
  • [ProMIND] In case system location cannot be determined through ipleak.net, country is now properly set to empty, latitude and longitude to 0.
  • [ProMIND] Persistent network lock is enabled only in case Bluetit status is clean
  • [ProMIND] AirVPN boot connection is started only in case Bluetit status is clean
  • [ProMIND] DNS backup files are now properly evaluated when determining dirty status
  • [ProMIND] Added D-Bus commands "reconnect_connection" and "session_reconnect"

Version 1.1.0 Beta 2 - 2 April 2021
  • [ProMIND] Gateway and gateway interface check at startup. Bluetit won't proceed until both gateway and gateway interface are properly set up by the system
  • [ProMIND] Increased volume and rate data sizes for 32 bit architectures
  • [ProMIND] Added aircipher directive to bluetit.rc
  • [ProMIND] Added maxconnretries directive to bluetit.rc

Version 1.1.0 Beta 1 - 11 March 2021
  • [ProMIND] connection_stats_updater(): now uses server.getEffectiveBandWidth() for AIRVPN_SERVER_BANDWIDTH
  • [ProMIND] added bool shutdownInProgress to control bluetit exit procedure and avoid signal flooding
  • [ProMIND] system location is detected at boot time and eventually propagated to all AirVPN users
  • [ProMIND] Network lock and filter is now enabled and activated before AirVPN login procedure
  • [ProMIND] Added dbus methods "enable_network_lock", "disable_network_lock" and "network_lock_status"
  • [ProMIND] Renamed bluetit.rc directive "airconnectonboot" to "airconnectatboot"
  • [ProMIND] Added bluetit.rc directive "networklockpersist"
 

Goldcrest changelog


Version 1.1.0 - 4 June 2021

  •  [ProMIND] Production release


Version 1.1.2 RC 4 - 14 May 2021

  • [ProMIND] DNS backup files are now properly evaluated when determining dirty status
  • [ProMIND] ProfileMerge is now constructed by allowing any file extension
  • [ProMIND] Reconnection (SIGUSR2) is now allowed only in case tun persistence is enabled



Version 1.1.2 - 2 April 2021

  • [ProMIND] Updated base classes

Hummingbird changelog


Version 1.1.2 - 4 June 2021

  • [ProMIND] updated all dependencies and libraries


Version 1.1.2 RC 4 - 14 May 2021

  • [ProMIND] DNS backup files are now properly evaluated when determining dirty status
  • [ProMIND] ProfileMerge is now constructed by allowing any file extension
  • [ProMIND] Reconnection (SIGUSR2) is now allowed only in case tun persistence is enabled

 


Architecture


The client-daemon architecture offered by Goldcrest and Bluetit combination offers a robust security model and provides system administrators with a fine-grained, very flexible access control.

Bluetit is fully integrated with AirVPN. The daemon is accessed through a D-Bus interface by providing specific methods and interface in order to give full support to OpenVPN connection and AirVPN functionality, including - but not limited to - quick automatic connection to the best AirVPN server for any specific location as well as any AirVPN server or country. Connection during system bootstrap is fully supported as well.

 

New OpenVPN 3 library features


Hummingbird and Bluetit are linked against a new version of our OpenVPN 3 library which supports directive data-ciphers: it can be used consistently with OpenVPN 2.5 syntax in OpenVPN profiles.

The directive allows OpenVPN 3 based software to negotiate a common Data Channel cipher with the OpenVPN server,, updating therefore our library to ncp-like negotiation with OpenVPN 2 branch. Hummingbird and Bluetit are already linked against the new library version, while Eddie Android edition will be updated in the near future.

The new library also includes a different handling of IV_CIPHERS variable, fixing OpenVPN main branch issues which caused a plethora of problems with OpenVPN 2.5. The implementation, at the same time, takes care of full backward compatibility with OpenVPN versions older than 2.5.

ncp-disable directive, which to date has never been implemented in the main  branch, is still supported, in order to further enhance backward compatibility with both OpenVPN profiles and servers, as well as connection flexibility with servers running older than 2.5 OpenVPN versions.

Please note that if you enforce a specific Data Channel cipher by means of Bluetit configuration file, Hummingbird line option, or Goldcrest configuration file and/or line option, the enforced Data Channel cipher will override data-ciphers profile directive.
 

Notes on systemd


Users running Linux distributions which are not based on systemd can safely ignore this section.
 

1


Superusers of linux-systemd systems must be aware that systemd unit configuration file has been changed in order to circumvent a systemd critical bug which causes two obnoxious SIGKILL signals inappropriately sent before stop timeout completion and for no logical or practical reason when Bluetit is properly and neatly terminating in response to a legal and expected SIGTERM. The only known workaround so far to compensate the bug is forbidding systemd to send SIGKILL to Bluetit. The bug affects at least systemd versions 205, 214, 234, 246, but it might affect other versions too.
 

2


In Fedora 33 systemd-resolved comes pre-configured to work in "on-link" mode and network-manager works together with it.

This very peculiar, Windows-like setup kills Linux global DNS handling, causing those DNS leaks which previously occurred only on Windows. Hummingbird and Bluetit take care of preventing the brand new DNS leaks caused by such a setup.

Also note that systemd-resolved comes pre-configured with fallback DNS (Google DNS is a systemd-resolved default fallback DNS, smart choices pile up!) which will be queried if each interface DNS server fails some resolution. In such a case, if and only if you have Network Lock enabled will DNS leaks be prevented.
 

Supported systems


The suite is currently available for Linux x86-64, i686 (32 bit distributions), arm7l (for example Raspbian, OSMC and other ARM 32 bit based systems) and aarch64 (ARM 64 bit). Both systemd and SysV-style init based systems are supported.

AirVPN Suite is free and open source software licensed under GPLv3.
 

Overview and main features

 
AirVPN’s free and open source OpenVPN 3 suite based on AirVPN’s OpenVPN 3 library fork
 
  • Bluetit: lightweight D-Bus controlled system daemon providing full connectivity to AirVPN servers and generic OpenVPN servers. Ability to connect the system to AirVPN during the bootstrap.
  • Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN servers
  • Hummingbird: lightweight and standalone client for generic OpenVPN server connection
  • Linux i686, x86-64, arm7l and arm64 (Raspberry) support
  • Full integration with systemd, SysV Style-init and chkconfig
  • No heavy framework required, no GUI
  • Tiny RAM footprint
  • Lightning fast
  • Based on OpenVPN 3 library fork by AirVPN version 3.6.6 with tons of critical bug fixes from the main branch, new cipher support and never seen before features
  • ChaCha20-Poly1305 cipher support on both Control and Data Channel providing great performance boost on ARM, Raspberry PI and any Linux based platform not supporting AES-NI. Note: ChaCha20 support for Android had been already implemented in our free and open source Eddie Android edition
  • Robust leaks prevention through Network Lock based either on iptables, nftables or pf through automatic detection
  • Proper handling of DNS push by VPN servers, working with resolv.conf as well as any operational mode of systemd-resolved additional features
 

User documentation (*) and source code:


https://gitlab.com/AirVPN/AirVPN-Suite

User documentation is also included in an md file in each package.

(*) Developer documentation to create custom software clients for Bluetit will be published in the very near future.
 

Download page:

https://airvpn.org/linux/suite/

Share this post


Link to post

Hello,

First of all, thank you for this release and all the effort you put into it!

I am currently using bluetit and try to blacklist two AirVPN servers: Server1 and Server2 (using official names of course). As the readme suggests, the directive should be put as a list.
However, bluetit seems to ignore this option since i cannot see anything related to the directive in my logs. Further, i am getting connected to the "blacklisted" server.
 

airblackserverlist              Server1,Server2
 
I have also tried "Server1,Server2" and 'Server1,Server2'.
Blacklisting just one server doesn't work either.

What is exactly meant by list? Do i have to create a seperate list (.csv, .xml, .lst, .txt) and refer to it in the .rc file? What am i missing?

Operating System: Ubuntu 21.04
Kernel: Linux 5.11.0-19-generic
Architecture: x86-64


Thanks & Regards

Share this post


Link to post
@cheapsheep

Hello!

Thank you for your feedback. Bug reproduced and confirmed, it will be investigated to have a fix in the next release. Your syntax is correct and in your case a list is simply a series of names separated by commas. The list works effectively, but only for "quick" connection mode. In "country" connection mode Bluetit ignores it. You can, in the meantime, have some sort of good workaround by setting boot connection mode to quick and compiling white and black list according to your needs.

Kind regards
 

Share this post


Link to post

Hello,

The suite has been working quite well for me and I'm grateful for your efforts!

I have successfully installed the software on a raspberry pi. I'm using bluetit and the "'connectatboot" feature to connect. Using bluetit, when I set the cipher to "CHACHA20-POLY1305" and initialise bluetit, I get the following error: 

ERROR: cipher algorithm 'AES-256-GCM' is not allowed by Bluetit policy.

Here is a copy of my bluetit config:

If you need any more information, let me know. Thanks for your help!

#

# bluetit runcontrol file

#

 

# AirVPN bootstrap servers

 

bootserver                  http://63.33.78.166

bootserver                  http://52.48.66.85

bootserver                  http://54.93.175.114

bootserver                  http://63.33.116.50

 

# RSA Parameters

 

rsaexponent                 AQAB

rsamodulus                  wuQXz7eZeEBwaaRsVK8iEHpueXoKyQzW8sr8qMUkZIcKtKv5iseXMrTbcGYGpRXdiqXp7FqrSjPSMDuRGaHfjWgjbnW4PwecmgJSfhkWt4xY8OnIwKkuI2Eo0MA$

 

airconnectatboot                country

airusername                     <my-username>

airpassword                     <my-strong-password>

airkey                          <My-key>

# airserver                                     <airvpn_server_name>

aircountry                      Japan

airproto                        udp

airport                         443

# manifestupdateinterval        <minutes>

# airwhiteserverlist            <server list>

# airblackserverlist            <server list>

# airwhitecountrylist           <server list>

# airblackcountrylist           <server list>

country                         CN

# remote                                        <ip|url list>

# proto                                         <udp|tcp>

# port                                          <port>

tunpersist                      yes

cipher                          CHACHA20-POLY1305

# tcpqueuelimit                         <value>

ncpdisable                      no

networklock                     off

# ignorednspush                         <yes|no>

# timeout                                       <seconds>

compress                        no

tlsversionmin                   tls_1_2

# proxyhost                                     <ip|url>

Share this post


Link to post
1 hour ago, sooprtruffaut said:
 

cipher                          CHACHA20-POLY1305


Please use aircipher. The same goes for country which should be aircountry now.

Btw: Did you do a fresh install or just update from an older version? In case you updated, i think your "old" bluetit.rc was kept - which now has old directives that do not work anymore. I have experienced the same difficulties.

@Staff If directives are changed in newer suite versions (like connectatboot vs connectonboot), will an existing bluetit.rc be updated accordingly?

Regards.

Share this post


Link to post
@cheapsheep
@sooprtruffaut

Hello!

We aim at maintaining backward compatibility, but what you mention is a different case,. "Old" directives work as usual and have not been changed. New directives, which in previous versions were not available, have been added.

Please note that country and aircountry are totally different directives, check the documentation:

country: (string) ISO code of the country where your computer is located in. [...]

aircountry: (string) Name of AirVPN country to be used for boot connection by means of airconnectatboot directive. In this specific case, airconnectatboot must be assigned to "country" option. When this mode is enabled, AirVPN connection will be established with the best performing server of the specified country. Default: empty.

Moreover, please note that cipher and aircipher are also quite different directives with different purposes. Check the documentation again.
https://airvpn.org/suite/readme/

As @cheapsheep noticed, in order to specify the data channel cipher for connectatboot mode, you need aircipher. This should resolve the error you experience. That said, this error will be investigated, because it might hide some bug according to your report.

Kind regards
 

Share this post


Link to post
@cheapsheep
@Staff

Hello, thank you both for your help. Using "aircipher" has worked and the problem is solved.

To give you more details, I was using the config from the beta versions of AirVPN Suite, which is why the older settings were used. I'll pay close attention to the new directives  in case I need to modify things in the future.

Thanks again for your help both of you!

Share this post


Link to post
Posted ... (edited)

Hello, AirVPN! Thank you for your hard work and for creating such wonderful way to use VPN on Linux systems 😃

I have a little problem with systemctl Bluetit service: it works great all the time, but it does not start automatically at system startup.

My configuration: ArchLinux x64 - fully up-to-date; systemd system; AirVPN Suite 1.1.0 - 4 June 2021 - installed according to the documentation with all required dependencies and dynamic libraries; configured "bluetit.rc" control file; both "root" and "user" are in "airvpn" group.

Every time I turn on my computer I execute the following command:

$ systemctl status bluetit.service
And it returns the following result:
bluetit.service - AirVPN Bluetit Daemon
   Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
When I start the service manually, it works perfectly fine:
# systemctl start bluetit.service
Active: active (running)
And, of course, I already enabled Bluetit service with the following command:
# systemctl enable bluetit.service
But after every reboot I'm getting the same problem: Bluetit service is "inactive (dead)". At the same time my another systemctl service, for example, Tor, seems to start automatically at system startup without any problems.

Thank you very much in advance for any help! Edited ... by 9zkHR9tCN7bo
Personal info removal.

Share this post


Link to post
@Hotty Capy

Hello and thank you very much for your great feedback!

Let's try and understand what happens with Bluetit during the system bootstrap. Please send us Bluetit log (cut out sensitive info if necessary) after the system has completed its startup sequence. From a terminal [emulator}:
sudo journalctl | grep bluetit

Kind regards
 

Share this post


Link to post
Posted ... (edited)
@Staff

Thank you very much for your answer!

I think I hurried a little and Bluetit service actually starts automatically, but not immediately at system startup. It takes about 2 minutes from session's start (user logs in, desktop appears) before the real IP address changes to AirVPN server exit IP. However, it looks like the service itself starts not immediately.

Here is my Bluetit log:

10:02:12 host bluetit[4119]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 - 4 June 2021
10:02:18 host kernel: audit: type=1130 audit(1625670132.368:88): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
10:02:12 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
10:02:12 host systemd[1]: bluetit.service: Failed to parse PID from file /etc/airvpn/bluetit.lock: Invalid argument
10:02:12 host bluetit[4119]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
10:02:12 host bluetit[4119]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
10:02:12 host bluetit[4145]: Bluetit daemon started with PID 4145
10:02:12 host bluetit[4145]: External network is reachable via gateway * through interface *
10:02:12 host bluetit[4145]: Successfully connected to D-Bus
10:02:12 host bluetit[4145]: Reading run control directives from file /etc/airvpn/bluetit.rc
10:02:12 host bluetit[4145]: IPv6 is available in this system
10:02:12 host bluetit[4145]: System country set to * by Bluetit policy.
10:02:12 host bluetit[4145]: WARNING: networklockpersist directive found in /etc/airvpn/bluetit.rc. networklock directive is ignored.
10:02:12 host bluetit[4145]: Bluetit successfully initialized and ready
10:02:12 host bluetit[4145]: Enabling persistent network filter and lock
10:02:18 host bluetit[4145]: Network filter and lock are using nftables
10:02:18 host bluetit[4145]: Successfully loaded kernel module nf_tables
10:02:18 host bluetit[4145]: Network filter successfully initialized
10:02:18 host bluetit[4145]: Persistent network filter and lock successfully enabled
10:02:18 host bluetit[4145]: AirVPN Manifest updater thread started
10:02:18 host bluetit[4145]: Starting AirVPN boot connection
10:02:18 host bluetit[4145]: AirVPN Manifest update interval is 15 minutes
10:02:18 host bluetit[4145]: AirVPN Manifest update suspended: AirVPN boot connection initialization in progress
10:02:18 host bluetit[4145]: Persistent Network Lock and Filter is enabled
10:02:18 host bluetit[4145]: Updating AirVPN Manifest
10:02:18 host bluetit[4145]: AirVPN bootstrap servers are now allowed to pass through the network filter
10:02:18 host bluetit[4145]: Waiting for a valid AirVPN Manifest to be available
10:02:19 host bluetit[4145]: Logging in AirVPN user *
10:02:19 host bluetit[4145]: AirVPN Manifest successfully retrieved from server
10:02:19 host bluetit[4145]: AirVPN user * successfully logged in
10:02:19 host bluetit[4145]: Selected user key: *
10:02:19 host bluetit[4145]: Starting connection to AirVPN server *
10:02:19 host bluetit[4145]: Starting VPN Connection
10:02:19 host bluetit[4145]: OpenVPN3 client successfully created and initialized.
10:02:19 host bluetit[4145]: TUN persistence is enabled by Bluetit policy
10:02:19 host bluetit[4145]: TUN persistence is enabled.
10:02:19 host bluetit[4145]: TCP queue limit set to 8192 by Bluetit policy
10:02:19 host bluetit[4145]: Negotiable Crypto Parameters (NCP) is enabled by Bluetit policy
10:02:19 host bluetit[4145]: Connection timeout set to 0 by Bluetit policy
10:02:19 host bluetit[4145]: Compression mode set to 'no' by Bluetit policy
10:02:19 host bluetit[4145]: TLS minumum version set to 'tls_1_2' by Bluetit policy
10:02:19 host bluetit[4145]: Proxy HTTP basic auth isdisabled by Bluetit policy
10:02:19 host bluetit[4145]: CIPHER OVERRIDE: *
10:02:19 host bluetit[4145]: Successfully set OpenVPN3 client configuration
10:02:19 host bluetit[4145]: Network lock set to 'nftables' by Bluetit policy
10:02:19 host bluetit[4145]: Ignore DNS push is disabled by Bluetit policy
10:02:19 host bluetit[4145]: Starting OpenVPN3 connection thread
10:02:19 host bluetit[4145]: Connection statistics updater thread started
10:02:19 host bluetit[4145]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
10:02:19 host bluetit[4145]: Frame=512/2048/512 mssfix-ctrl=1250
10:02:19 host bluetit[4145]: UNUSED OPTIONS
10:02:19 host bluetit[4145]: EVENT: RESOLVE
10:02:19 host bluetit[4145]: WARNING: NetworkManager is running on this system and may interfere with DNS management and cause DNS leaks
10:02:19 host bluetit[4145]: WARNING: systemd-resolved is running on this system and may interfere with DNS management and cause DNS leaks
10:02:19 host bluetit[4145]: Local IPv4 address *
10:02:19 host bluetit[4145]: Local IPv6 address *
10:02:19 host bluetit[4145]: Local interface *
10:02:19 host bluetit[4145]: Setting up network filter and lock
10:02:19 host bluetit[4145]: Allowing system DNS * to pass through the network filter
10:02:19 host bluetit[4145]: Allowing system DNS * to pass through the network filter
10:02:20 host bluetit[4145]: Adding IPv4 server * to network filter
10:02:20 host bluetit[4145]: Network filter and lock successfully activated
10:02:20 host bluetit[4145]: Contacting * via *
10:02:20 host bluetit[4145]: EVENT: WAIT
10:02:20 host bluetit[4145]: net_route_best_gw query IPv4: *
10:02:20 host bluetit[4145]: sitnl_route_best_gw result: via * dev *
10:02:20 host bluetit[4145]: net_route_add: * via * dev * table 0 metric 0
10:02:20 host bluetit[4145]: Connecting to * via *
10:02:20 host bluetit[4145]: EVENT: CONNECTING
10:02:20 host bluetit[4145]: Tunnel Options:V4,dev-type tun,link-mtu 1510,tun-mtu 1500,proto *,comp-lzo,cipher *,auth [null-digest],keysize 256,key-method 2,tls-client
10:02:20 host bluetit[4145]: Peer Info:
10:02:20 host bluetit[4145]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1
10:02:20 host bluetit[4145]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=*/emailAddress=info@airvpn.org, signature: RSA-SHA512
10:02:20 host bluetit[4145]: SSL Handshake: peer certificate: CN=*, 4096 bit RSA, cipher: * TLSv1.3 Kx=any Au=any Enc=* Mac=AEAD
10:02:20 host bluetit[4145]: Session is ACTIVE
10:02:20 host bluetit[4145]: 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
10:02:20 host bluetit[4145]: EVENT: GET_CONFIG
10:02:20 host bluetit[4145]: Sending PUSH_REQUEST to server...
10:02:20 host bluetit[4145]: OPTIONS:
10:02:20 host bluetit[4145]: PROTOCOL OPTIONS:
10:02:20 host bluetit[4145]: EVENT: ASSIGN_IP
10:02:20 host bluetit[4145]: VPN Server has pushed IPv4 DNS server *
10:02:20 host bluetit[4145]: Setting pushed IPv4 DNS server * in resolv.conf
10:02:20 host bluetit[4145]: Setting pushed IPv4 DNS server * for interface * via systemd-resolved
10:02:21 host bluetit[4145]: net_iface_mtu_set: mtu 1500 for tun0
10:02:21 host bluetit[4145]: net_iface_up: set tun0 up
10:02:21 host bluetit[4145]: net_addr_add: * brd * dev tun0
10:02:21 host bluetit[4145]: net_route_add: * via * dev tun0 table 0 metric 0
10:02:21 host bluetit[4145]: net_route_add: * via * dev tun0 table 0 metric 0
10:02:21 host bluetit[4145]: TunPersist: saving tun context:
10:02:21 host bluetit[4145]: Connected via tun
10:02:21 host bluetit[4145]: LZO-ASYM init swap=0 asym=1
10:02:21 host bluetit[4145]: Comp-stub init swap=0
10:02:21 host bluetit[4145]: EVENT: CONNECTED * via /* on tun/*/ gw=[*/]
10:02:21 host bluetit[4145]: Connected to AirVPN server *
10:02:21 host bluetit[4145]: Server has pushed its own DNS. Removing system DNS from network filter.
10:02:21 host bluetit[4145]: System DNS * is now rejected by the network filter
10:02:21 host bluetit[4145]: System DNS * is now rejected by the network filter


I`m sorry for my mistake in the first post. As you can see, my problem is not critical, but if it can be fixed somehow, it would be great, because when Bluetit service is not active yet network lock function is not active too and websites can see my real IP adress if I visit them during these first ~2 minutes 🙂 Edited ... by 9zkHR9tCN7bo
Personal info removal.

Share this post


Link to post
@Hotty Capy

Hello!

Thank you for the information you published.

When Bluetit is started by systemd it activates Network Lock and connects to a server in just a few seconds. The decision to start Bluetit is up to systemd according to the target rules specified in the unit file. Contrarily to what you can do with any serious init system, determining the exact moment when a daemon or a process is started by systemd is not possible: this is one of the notorious, countless systemd flaws. The default unit file tells systemd to start Bluetit when network-online has started. Once network-online has started, systemd will start Bluetit according to its own internal priorities.

Can we see how network-online is configured in your system?
sudo systemctl status network-online.target
sudo journalctl | grep bluetit
In this way we can see the exact timing of both. Enter those commands after Bluetit has started.

Kind regards



 

Share this post


Link to post
Posted ... (edited)
@Staff

Hi! Thanks for the detailed explanation!

It looks like timing is perfect: Bluetit service starts at the same second as Network-Online becomes active and connecting to AirVPN server takes only 2 seconds.

This time I had my real IP address along with the ability to visit absolutely any website through the browser within a minute and a half from the moment I entered the user's password and the desktop appeared (yes, I counted it using a stopwatch 😀).

I can access the Internet directly through the provider (without VPN connection yet) immediately at the moment the desktop appears (at the same moment any website is successfully loaded in my browser). It looks like network-online.target is a little late on average from a minute to two: while the real Internet access is already available, the service is still inactive for a short period of time.

Here are the results of the commands:

[hotcapy@hotcapy-desktop ~]$ sudo systemctl status network-online.target
[sudo] password for hotcapy:
● network-online.target - Network is Online
Loaded: loaded (/usr/lib/systemd/system/network-online.target; static)
Active: active since Thu 2021-07-08 16:44:58 +07; 29s ago
Docs: man:systemd.special(7)
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

июл 08 16:44:58 hotcapy-desktop systemd[1]: Reached target Network is Online.

[hotcapy@hotcapy-desktop ~]$ sudo journalctl | grep bluetit
июл 08 16:44:58 hotcapy-desktop bluetit[4049]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 - 4 June 2021
июл 08 16:44:58 hotcapy-desktop bluetit[4049]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
июл 08 16:44:58 hotcapy-desktop bluetit[4049]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Bluetit daemon started with PID 4051
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: External network is reachable via gateway 10.21.10.88 through interface enp37s0
июл 08 16:44:58 hotcapy-desktop systemd[1]: bluetit.service: Supervising process 4051 which is not our child. We'll most likely not notice when it exits.
июл 08 16:44:58 hotcapy-desktop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Successfully connected to D-Bus
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Reading run control directives from file /etc/airvpn/bluetit.rc
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: IPv6 is available in this system
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: System country set to R2 by Bluetit policy.
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: WARNING: networklockpersist directive found in /etc/airvpn/bluetit.rc. networklock directive is ignored.
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Bluetit successfully initialized and ready
июл 08 16:44:58 hotcapy-desktop kernel: audit: type=1130 audit(1625737498.647:91): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Enabling persistent network filter and lock
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Network filter and lock are using nftables
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Successfully loaded kernel module nf_tables
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Network filter successfully initialized
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Persistent network filter and lock successfully enabled
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Starting AirVPN boot connection
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: AirVPN Manifest updater thread started
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: AirVPN Manifest update interval is 15 minutes
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: AirVPN Manifest update suspended: AirVPN boot connection initialization in progress
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Persistent Network Lock and Filter is enabled
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Updating AirVPN Manifest
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: AirVPN bootstrap servers are now allowed to pass through the network filter
июл 08 16:44:58 hotcapy-desktop bluetit[4051]: Waiting for a valid AirVPN Manifest to be available
июл 08 16:44:59 hotcapy-desktop bluetit[4051]: AirVPN Manifest successfully retrieved from server
июл 08 16:44:59 hotcapy-desktop bluetit[4051]: Logging in AirVPN user Hotty Capy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: AirVPN user Hotty Capy successfully logged in
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Selected user key: Desktop
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Starting connection to AirVPN server Xuange, Zurich (Switzerland)
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Starting VPN Connection
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: OpenVPN3 client successfully created and initialized.
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: TUN persistence is enabled by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: TUN persistence is enabled.
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: TCP queue limit set to 8192 by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Negotiable Crypto Parameters (NCP) is enabled by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Connection timeout set to 0 by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Compression mode set to 'no' by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: TLS minumum version set to 'tls_1_2' by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Proxy HTTP basic auth isdisabled by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: CIPHER OVERRIDE: AES-256-GCM
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Successfully set OpenVPN3 client configuration
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Network lock set to 'nftables' by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Ignore DNS push is disabled by Bluetit policy
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Starting OpenVPN3 connection thread
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Connection statistics updater thread started
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Frame=512/2048/512 mssfix-ctrl=1250
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: UNUSED OPTIONS
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: RESOLVE
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: WARNING: NetworkManager is running on this system and may interfere with DNS management and cause DNS leaks
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: WARNING: systemd-resolved is running on this system and may interfere with DNS management and cause DNS leaks
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Local IPv4 address 10.21.10.1
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Local IPv6 address fe80::2d8:61ff:fe19:ea0a
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Local interface enp37s0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Setting up network filter and lock
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Allowing system DNS 1.1.1.1 to pass through the network filter
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Allowing system DNS 1.0.0.1 to pass through the network filter
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Adding IPv4 server 79.142.69.162 to network filter
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Network filter and lock successfully activated
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Contacting 79.142.69.162:443 via UDP
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: WAIT
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_route_best_gw query IPv4: 79.142.69.162/32
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: sitnl_route_best_gw result: via 10.21.10.88 dev enp37s0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_route_add: 79.142.69.162/32 via 10.21.10.88 dev enp37s0 table 0 metric 0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Connecting to [79.142.69.162]:443 (79.142.69.162) via UDPv4
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: CONNECTING
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Tunnel Options:V4,dev-type tun,link-mtu 1522,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Peer Info:
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Xuange/emailAddress=info@airvpn.org, signature: RSA-SHA512
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: SSL Handshake: peer certificate: CN=Xuange, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Session is ACTIVE
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: 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
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: GET_CONFIG
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Sending PUSH_REQUEST to server...
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: OPTIONS:
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: PROTOCOL OPTIONS:
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: ASSIGN_IP
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: VPN Server has pushed IPv4 DNS server 10.10.6.1
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Setting pushed IPv4 DNS server 10.10.6.1 in resolv.conf
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Setting pushed IPv4 DNS server 10.10.6.1 for interface enp37s0 via systemd-resolved
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_iface_mtu_set: mtu 1500 for tun0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_iface_up: set tun0 up
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_addr_add: 10.10.6.199/24 brd 10.10.6.255 dev tun0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_route_add: 0.0.0.0/1 via 10.10.6.1 dev tun0 table 0 metric 0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: net_route_add: 128.0.0.0/1 via 10.10.6.1 dev tun0 table 0 metric 0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: TunPersist: saving tun context:
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Connected via tun
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: LZO-ASYM init swap=0 asym=1
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Comp-stub init swap=0
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: EVENT: CONNECTED 79.142.69.162:443 (79.142.69.162) via /UDPv4 on tun/10.10.6.199/ gw=[10.10.6.1/]
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Connected to AirVPN server Xuange, Zurich (Switzerland)
июл 08 16:45:00 hotcapy-desktop bluetit[4051]: Server has pushed its own DNS. Removing system DNS from network filter.
июл 08 16:45:01 hotcapy-desktop bluetit[4051]: System DNS 1.1.1.1 is now rejected by the network filter
июл 08 16:45:01 hotcapy-desktop bluetit[4051]: System DNS 1.0.0.1 is now rejected by the network filter


So the problem is definitely in my system, not in Bluetit service.

Edit: yes, here is the command output obtained right after turning on the computer and successfully accessing the AirVPN website (before Bluetit service started):

[hotcapy@hotcapy-desktop ~]$ sudo systemctl status network-online.target
[sudo] password for hotcapy:
○ network-online.target - Network is Online
Loaded: loaded (/usr/lib/systemd/system/network-online.target; static)
Active: inactive (dead)
Docs: man:systemd.special(7)
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

Edited ... by Hotty Capy
Add additional info.

Share this post


Link to post
@Hotty Capy

Hello!

Thank you! We will investigate, because when the network is online, network online target should have been reached: that's exactly network-online.target purpose! But we have learned that we can't trust many Linux infecting wrecks, so this might be one of those cases.

In the meantime, a quick workaround to harden your setup is enforcing permanent firewall rules blocking any communications except communications to/from 255.255.255.255 (to allow DHCP) and to/from the local network and localhost. In this way your machine can't reach the Internet until Bluetit starts (in such a setup, Network Lock becomes strictly necessary, to lift the total block).

Another workaround might be editing the unit file, telling that Bluetit must be started regardless of network status, because Blueitt has its own internal verification to avoid critical errors when network interfaces are not configured and/or default gateway is not available etc. We will think about it and we will let you know.

Kind regards
 

Share this post


Link to post

Hi,
Thank for this release.
I'm testing this for the first time and I've encounter unreliable connection using goldcrest on Linux: most of the time it connects for a few minutes, than I've this error message.

ERROR: KEEPALIVE_TIMEOUT
Session invalidated: KEEPALIVE_TIMEOUT
Client terminated, restarting in 2000 ms...
../..
EVENT: RECONNECTING
ERROR: N_RECONNECT
Contacting [someIPv6addr]:443 via UDP
EVENT: WAIT
net_route_del: someIPv6addr/128 via anotherIPv6addr dev eno1 table 0 metric 0
net_route_best_gw query IPv6: someIPv6addr/128
sitnl_route_best_gw result: via UNSPEC dev 
Connecting to [someIPv6addr]:443 (someIPv6addr) via UDPv6
Server poll timeout, trying next remote entry...
EVENT: RECONNECTING
ERROR: N_RECONNECT
Contacting [someIPv6addr]:443 via UDP
EVENT: WAIT

and it keeps repeating...
How can I have reliable connections?
Best regards.

Share this post


Link to post
@WYjNh056OGEG2tgNvV4iHzoNNU

Hello!

Please compare stability with OpenVPN 2 and report everything in a ticket. Please include complete Bluetit log and your Linux distribution name and version. You can print Bluetit log with command
sudo journalctl | grep bluetit
Kind regards
 

Share this post


Link to post

Hi! I have encountered a small "bug" in the Bluetit service that hindered it from connecting to AirVPN servers on startup (systemd). When the password given to the airpassword option in the bluetit.rc control file includes a comma character ( , ) it is interpreted as a list and not as a single string, prompting the error: 
 

ERROR: invalid RC directive 'airpassword' - List is not allowed for this directive

A workaround was to change my password to one without commas. Probably also applies to commas in airusername, I have not tried that out though.

Thank you!

Share this post


Link to post

Network Lock apparently does not prevent my Debian 11.1 system from querying my router's DNS resolver and receiving valid responses from it. After establishing a VPN connection with Goldcrest, and after Goldcrest has reported the removal of my router's IP address (192.168.1.1) from the network filter, sending a query to my router's DNS resolver returns a valid response—e.g., dig @192.168.1.1 -q airvpn.org -t A +dnssec +multiline +tcp returns a complete and valid response. This becomes especially problematic when my system's DHCP lease gets renewed during an active VPN session; my router's IP address would be added to my system's list of available resolvers and it would then leak name resolution requests to the router.

Here is the content of my system's /etc/airvpn/bluetit.rc file:
 

bootserver http://63.33.78.166
bootserver http://52.48.66.85
bootserver http://54.93.175.114
bootserver http://63.33.116.50
rsaexponent AQAB
rsamodulus wuQXz7eZeEBwaaRsVK8iEHpueXoKyQzW8sr8qMUkZIcKtKv5iseXMrTbcGYGpRXdiqXp7FqrSjPSMDuRGaHfjWgjbnW4PwecmgJSfhkWt4xY8OnIwKkuI2Eo0MAa9lduPOQRKSfa9I1PBogIyEUrf7kSjcoJQgeY66D429m1BDWY3f65c+8HrCQ8qPg1GY+pSxuwp6+2dV7fd1tiKLQEoJg9NeWGW0he/DDkNSe4c8gFfHj3ANYwDhTQijb+VaVZqPmxVJIzLoE1JOom0/P8fKsvpx3cFOtDS4apiI+N7MyVAMcx5Jjk2AQ/tyDiybwwZ32fOqYJVGxs13guOlgI6h77QxqNIq2bGEjzSRZ4tem1uN7F8AoVKPls6yAUQK1cWM5AVu4apoNIFG+svS/2kmn0Nx8DRVDvKD+nOByXgqg01Y6r0Se8Tz9EEBTiEopdlKjmO1wlrmW3iWKeFIwZnHt2PMceJMqziV8rRGh9gUMLLJC9qdXCAS4vf5VVnZ+Pq3SK9pP87hOislIu4/Kcn06cotQChpVnALA83hFW5LXJvc85iloWJkuLGAV3CcAwoSA5CG1Uo2S76MM+GLLkVIqUk1PiJMTTlSw1SlMEflU4bZiZP8di5e2OJI6vOHjdM2oonpPi/Ul5KKmfp+jci+kGMs9+zOyjKFLVIKDE+Vc=
airipv6 on
air6to4 on
country [Redacted]
networklock nftables

Here is the content of my system's ~/.config/goldcrest.rc file:
 
air-tls-mode crypt
air-ipv6 on
air-6to4 on
air-user [Redacted]
air-password "[Redacted]"
air-key [Redacted]
network-lock nftables
ipv6 yes
conn-stat-interval 0

My system's nftables version is 0.9.8-3.1. Network and name resolution are managed by systemd-networkd and systemd-resolved, with /etc/resolv.conf being a symlink to /run/systemd/resolve/resolv.conf.

Share this post


Link to post
4 hours ago, Pwbkkee said:

Network Lock apparently does not prevent my Debian 11.1 system from querying my router's DNS resolver and receiving valid responses from it. After establishing a VPN connection with Goldcrest, and after Goldcrest has reported the removal of my router's IP address (192.168.1.1) from the network filter,
...
dig @192.168.1.1 -q airvpn.org -t A +dnssec +multiline +tcp returns a complete and valid response.


Hello!

That's correct and expected because Network Lock does not and must not block communications with your router, otherwise your system would be completely isolated from the network. Please note that while a connection is active, your system can't query the router DNS server, because Bluetit sets VPN DNS (provided that you do not disable this feature) - and actually you need to specify in dig a specific address.

It's up to you to prevent such situation when the VPN connection is not active. The "problem" is that your system gateway address is also your system DNS server address. Act accordingly by configuring properly DNS settings of either your system, your router or both.

Network Lock might make an effort to prevent some communications with your router by blocking destination port 53 to your router. That's however a questionable solution and currently it's not adopted, maybe we could implement it as an option in the future. Anyway it would not work in Hummingbird but only in Bluetit, given the different network lock and persistent network lock: logic when Hummingbird drops the connection, it cancels Network Lock, while Bluetit does not, when persistent Network Lock is enabled (consider to enable it anyway).

Kind regards
 

Share this post


Link to post

My system can and does query the router's resolver during an active VPN session—it does so after its DHCP lease is renewed during the active VPN session.

The main problem is that the router's IP address gets added to the system's list of available resolvers when its DHCP lease is renewed during an active VPN session. The system then leaks requests to the router. Network Lock as advertised is supposed to prevent such leaks, but it doesn't. And these leaks might have been happening from the very beginning, and I was completely unaware of it, because I would have tested for leaks only shortly after establishing a new VPN session.

A switch that makes Network Lock block all communications from the system to the router over the detected DNS port would therefore be of great help in such situations. It would also restore Network Lock to its advertised behavior. And doesn't Eddie's Network Lock have a switch that blocks LAN communications? And the point here is not about preventing such leaks when the VPN session is dropped or terminated; it's about preventing such leaks when the VPN session is still active.

Share this post


Link to post
@Pwbkkee
 
Quote

My system can and does query the router's resolver during an active VPN session—it does so after its DHCP lease is renewed during the active VPN session.


Hello!

You have various options to resolve this problem. You can have e a longer DHCP lease time (1 year is not atypical), you can disable DHCP for sensitive machines, or you may set in one second the proper firewall rule to block traffic to port 53 of your router IP address (after Network Lock has been enabled). Another solution is setting on the router, as primary DNS server, 10.4.0.1 address (VPN DNS address).
 
Quote

The system then leaks requests to the router. Network Lock as advertised is supposed to prevent such leaks


Sorry that's false. Network Lock is advertised to prevent any traffic leak outside the tunnel to the Internet IPv6/IPv4 addresses, it is not advertised to lock your computer out from your router (i.e. prevent traffic to your local router) . Moreover you are clearly warned that running systemd-resolved and/or Network Manager is dangerous and may cause DNS leaks.
 
Quote

A switch that makes Network Lock block all communications from the system to the router over the detected DNS port would therefore be of great help


We will think about it for port 53 for sure. It's not a big deal by the way: just see above the proposed solutions, in the meantime.
 
Quote

And doesn't Eddie's Network Lock have a switch that blocks LAN communications?


Yes, with the obvious exception to your local upstream (typically your router) otherwise your system would be completely isolated and no communications would be possible, including of course VPN connections.

Kind regards

 

Share this post


Link to post
11 hours ago, Staff said:
Network Lock is advertised to prevent any traffic leak outside the tunnel to the Internet IPv6/IPv4 addresses, it is not advertised to lock your computer out from your router (i.e. prevent traffic to your local router) .

Then Goldcrest should not print messages like Removing system DNS from the network filter and System DNS 192.168.1.1 is now rejected by the network filter. And you should not advertise Network Lock like this:
 
On 6/4/2021 at 3:46 PM, Staff said:
[...]
  • revisited Network Lock logic for additional safety
[...]
 

Notes on systemd


[...]
 

2


In Fedora 33 systemd-resolved comes pre-configured to work in "on-link" mode and network-manager works together with it.

This very peculiar, Windows-like setup kills Linux global DNS handling, causing those DNS leaks which previously occurred only on Windows. Hummingbird and Bluetit take care of preventing the brand new DNS leaks caused by such a setup.

Also note that systemd-resolved comes pre-configured with fallback DNS (Google DNS is a systemd-resolved default fallback DNS, smart choices pile up!) which will be queried if each interface DNS server fails some resolution. In such a case, if and only if you have Network Lock enabled will DNS leaks be prevented.

[...]
 

Overview and main features

[...]
  • Robust leaks prevention through Network Lock based either on iptables, nftables or pf through automatic detection
  • Proper handling of DNS push by VPN servers, working with resolv.conf as well as any operational mode of systemd-resolved additional features

And https://gitlab.com/AirVPN/AirVPN-Suite#bluetit-configuration should not advertise Network Lock like this:
 
Quote
  • networklock (string): [...] Network locking is done by a specific set of firewall rules allowing traffic to and from the connected server only.

And https://gitlab.com/AirVPN/AirVPN-Suite#goldcrest-configuration should not advertise Network Lock like this:
 
Quote
  • network-lock (string): [...] Network locking is done by a specific set of firewall rules allowing traffic to and from the connected server only.

All of this gave me a false sense of security. I was under the impression that such name resolution leaks were not possible under any circumstances when Network Lock is active, because you advertised Network Lock as being effective at preventing them at the firewall level, as quoted above. If Network Lock is unable to do what you advertised, then you have advertised falsely and Network Lock is next to useless for users dealing with similar situations. The Removing system DNS from the network filter and System DNS 192.168.1.1 is now rejected by the network filter messages printed by Goldcrest are also false information, and they mislead users into thinking that they're safe from name resolution leaks when they're actually not.
 
12 hours ago, Staff said:
Moreover you are clearly warned that running systemd-resolved and/or Network Manager is dangerous and may cause DNS leaks.

But I was also clearly assured by both you and by Goldcrest that Network Lock is effective at preventing such leaks, as explained above.
 
12 hours ago, Staff said:
We will think about it for port 53 for sure. It's not a big deal by the way: just see above the proposed solutions, in the meantime.

It might not be a big deal to you, but it is to me and to other paying customers who have been misled into believing that Network Lock protected them from such leaks when it actually didn't. This put us at greater risk, because we were not aware that we should have taken extra precautions to guard against such leaks, because we believed all this while that Network Lock prevented such leaks.

Share this post


Link to post
@Pwbkkee

Hello!

The system does exactly what it's instructed to do and you are clearly warned that such a situation may occur if your run systemd-resolved or a network manager. The traffic flows only between your router and your system and any final public destination that's not the VPN server is blocked on the system where the AirVPN Suite runs. It's not blocked on devices where Goldcrest and Bluetit don't even run. This is so obvious that we did not think it's necessary to explicitly explain it.

You can't consider Goldcrest/Bluetit responsible for something that your router, and not your system, does: Goldcrest and Bluetit do not even run on the router and they have no control over it. Thank you anyway for your point of view, we will consider to specify that the AirVPN Suite can't magically influence the behavior of devices which it doesn't run on.

Kind regards


 

Share this post


Link to post

Hello.

I'm having some problems with this suite, and recent versions of hummingbird to activate the network-lock.
I'm running 64 bit Arch Linux on a PC.
I've been happily using raw hummingbird for quite a long time but it was about time I updated it.

I decided to give this suite a try as it also came with hummingbird and I could keep using my old setup in case bluetit - goldcrest didn't meet my needs.
No issues installing the suite, I tried it directly with its installer and this last time through the "airvpn-suite-bin" aur package.

When I try to connect with goldcrest -O I get:

Goldcrest 1.1.0 - 4 June 2021

 Bluetit - AirVPN OpenVPN 3 Service 1.1.0 - 4 June 2021
 OpenVPN core 3.7 AirVPN linux x86_64 64-bit
 Bluetit is ready
 Bluetit options successfully reset
 Bluetit successfully set to command line options
 Requesting AirVPN connection to Bluetit
 Network filter and lock are using iptables-legacy
 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)
 Network filter successfully initialized
 ERROR: Cannot enable network filter and lock


Network lock does not get active.
It changes iptables from this:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

To this:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A OUTPUT -d 10.31.58.1/32 -j ACCEPT


With the version of humminhbird that comes with the suite:

Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 - 4 June 2021

 System and service manager in use is systemd
 Network filter and lock are using iptables-legacy
 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)
 Starting thread
 OpenVPN core 3.7 AirVPN linux x86_64 64-bit
 Frame=512/2048/512 mssfix-ctrl=1250
 UNUSED OPTIONS
3 [resolv-retry] [infinite]
4 [nobind]
5 [persist-key]
6 [persist-tun]
7 [auth-nocache]
8 [route-delay] [5]
9 [verb] [3]
10 [explicit-exit-notify] [5]
 2021 EVENT: RESOLVE
 2021 Local IPv4 address 192.168.1.36
 2021 Local interface wlan0
 2021 Setting up network filter and lock
 2021 Allowing system DNS 127.0.0.1 to pass through the network filter
iptables-restore: line 1 failed
 ERROR: Cannot allow system DNS to pass through network filter
 Adding IPv4 server 185.93.182.170 to network filter
iptables-restore: line 1 failed
 ERROR: Cannot activate network filter and lock

And the very same effect on iptables.

I tried bare hummingbird installs with similar results.
I had to go back until hummingbird-linux-x86_64-1.1.1 to get it working.
Although I get this errors in the log:

 Network filter and lock is using iptables-legacy
 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)
 Network filter successfully initialized

Network filter is active and running.

I would appreciate some advice on what to do about it.

Share this post


Link to post

Appears that eddie-ui and the suite (Bluetit, Goldcrest and Hummingbird) are both having issues on Arch with a newer(ish) kernel.
Recently upgraded from 5.10 to 5.15 and it appears that something may have changed with the Linux kernel in regards to IP tables.
I haven't been able to identify what exactly changed. But I can confirm that it is working on linux-lts (5.10.82-1) but nothing newer than that in my testing.
 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...