Staff 10018 Posted ... 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/ 3 Stalinium, cheapsheep and colorman reacted to this Quote Share this post Link to post
cheapsheep 6 Posted ... 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 Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
sooprtruffaut 5 Posted ... 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> Quote Share this post Link to post
cheapsheep 6 Posted ... 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
sooprtruffaut 5 Posted ... @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! 1 Staff reacted to this Quote Share this post Link to post
9zkHR9tCN7bo 7 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
9zkHR9tCN7bo 7 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
9zkHR9tCN7bo 7 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. 1 Staff reacted to this Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
WYjNh056OGEG2tgNvV4iHzoNNU 3 Posted ... 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
CXX 1 Posted ... 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! 1 Staff reacted to this Quote Share this post Link to post
Pwbkkee 0 Posted ... 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. Quote Share this post Link to post
Staff 10018 Posted ... 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 Quote Share this post Link to post
Pwbkkee 0 Posted ... 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
Pwbkkee 0 Posted ... 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. Quote Share this post Link to post
Staff 10018 Posted ... @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 Quote Share this post Link to post
eburom 16 Posted ... 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. Quote Share this post Link to post
magnavoid 0 Posted ... 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. Quote Share this post Link to post
Not connected, Your IP: 18.117.151.198
Online: 26746 users - 366171 Mbit/s total BW.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png){kind=avatar}