Staff

Hello! Network Lock stops macOS telemetry by blocking any traffic outside the VPN tunnel via pf rules. When Apple programs try to bind their socket to the physical network interface, their packets are blocked by the kernel filtering table set up by Network Lock. Therefore our customers were fully protected even during those months in which LittleSnitch and Lulu etc. were ineffective against the nasty Apple "exceptions". Note for the readers: it's not possible to do that in iOS, due to the fact that an iOS user has limited privileges to her device (in this case, you have no way to reach and set the kernel filtering table or set arbitrary routes outside the limits enforced by Apple to VPN service). In iOS, traffic of some Apple services will always bypass the VPN, by policy, and Apple can bypass a VPN in any case with any future program. Contrarily to what happened in Big Sur, in iOS some Apple programs will continue to bypass the VPN tunnel. Kind regards

Hello! That's expected. Remember the auth directive scope as we underlined in a previous message: it does not apply to AEAD ciphers, in the Data Channel (and we use only AEAD ciphers fix: not true, we still support AES-CBC). In the Control Channel, it applies only to TLS Auth (not to TLS Crypt according to documentation) and (obviously) only when compatible with the tls-ciphers list (check both data-ciphers and tls-ciphers set on servers in our previous message). To check the digest, see the rest of the log pertaining to Control Channel cipher and Data Channel cipher in IANA convention. Unfortunately a working verbosity option is not implemented in OpenVPN3, maybe one day we'll implement it in our fork. Kind regards

Hello! macOS Sierra and later versions (up to Big Sur 11.1) services had hard coded exceptions ("ContentFilterExclusionList") in the Network Extensions Framework to have their traffic go through any policy enforced via Network Extensions API (which is not anyway the correct API to use to enforce a filtering table). The problem became relevant in Big Sur only, and not earlier, and only for people using improper firewalls, because it was only on Big Sur that Apple dropped support to Network Kernel Extensions. Please note that Network Kernel Extensions usage was deprecated since years and support drop was announced like one year earlier the fact or so, thus the fact that some apps still relied on them is a developers' fault. However, the traffic of all Apple services could be blocked as usual with proper firewall rules, nothing changed, You could use pf for example as a pre-installed userspace tool (and probably the best firewall known to mankind ever) to the kernel filtering table, which is a method to properly craft filtering rules without adding custom kexts which have absolute power on the system and which must be blindly trusted by the user (they have been a cause of problems and crashes in Mac). Network Lock in our applications did not allow ANYTHING out of the tunnel, including Apple telemetry service and any other process included in the exceptions, even during the period where the exceptions were enforced (from Sierra to Big Sur), because Network Lock uses pf in Mac, as it is appropriate. The "ContentFilterExclusionList" has been removed by Apple in January 2021 from Big Sur 11.2 beta 2, so the problem at API level is no more, starting from Big Sur 11.2, and in general the issue never existed for people using our software Network Lock. Kind regards

@foDkc4UySz Hello! Your memory does not fail. At that time, the infamous "anti-encryption" framework was not law in Australia. Later on, the "anti-encryption" laws were enforced. It is currently the main problem in Australia which prevents us from operating VPN servers there (we operate only geo-routing ones). Kind regards

Hello! Thank YOU for your testing. Let's clarify a thing that you wrongly assumed, especially for the readers. Contrarily to what you say, it is possible "for a client process (ie goldcrest) to override (all of) the default settings", when such settings are not specified in bluetit.rc.. In other words, Goldcrest settings can override Bluetit default settings when they (Bluetit's) are omitted in bluetit.rc. What it's not possible is a totally different thing, i.e. overriding Bluetit and Goldcrest settings via an OpenVPN profile. For example, if you invoke Goldcrest with --proto option, or you specify it in goldcrest.rc, you can pick between udp and tcp. Bluetit will connect accordingly, if bluetit.rc does not include any proto directive. Kind regards

Hello! In the documentation you find all the Bluetit options with their default value, and it is explained that Bluetit configuration file overrides anything coming from Goldcrest or any other client: https://airvpn.org/suite/readme/#run-control-file However, "proto" and "port" default values are reported as "empty" and this is a mistake, as they are respectively "udp" and "443". We will fix this soon, we apologize if it created confusion. In general, the profile (as well as Goldcrest options) can be created and enforced by airvpn group users, while bluetit.rc is exclusive root competence, so the final word must come from bluetit.rc, that plays the watchdog role, coherently with the access model of a client/daemon architecture in UNIX (further improved by D-Bus in this case). Therefore, the system administrator can have at the same time both a fine grained control over access to a sensitive service which modifies extremely important system parts (gateway, DNS, firewall rules, routing table, virtual network interface) and additional security against some types of attacks aimed at the user(s) who can launch Goldcrest. We consider it as a very sensible and proper approach. If you prefer a "root or nothing" approach then you don't need a client, a daemon and an access policy via D-Bus. We offer the simpler Hummingbird, which can be run by root only, needs a profile but adds important features not offered by OpenVPN, in particular refined DNS handling covering all the numerous DNS "modes" available in Linux, and Network Lock supporting the major Linux firewalls. Kind regards

Hello! Exactly. Kind regards

Hello! Bluetit settings can't be overridden by a profile. The logic behind it is that a profile can be used by anyone in the airvpn group, while bluetit.rc is strictly reserved to root. If not otherwise specified either in Bluetit configuration file, Goldcrest command line options, or Goldcrest configuration file, proto is set to UDP and port to 443. Change them according to your preferences, for example when you invoke Goldcrest (options --proto and --port in this case), or specify the options in goldcrest.rc (while an airvpn group user can bypass goldcrest.rc settings, she can't bypass bluetit.rc settings, except the default ones) . Also remember that Bluetit is fully integrated with AirVPN, so you don't need ovpn profiles/configuration files. Kind regards

Hello! @sooprtruffaut What is your Linux distribution name and exact version? When you get the error can you please check whether the tun network interface is still up? According to your distribution you might enter from a shell the command ifconfig or ip a . @pjnsmb Your system can't (at the moment of the error) resolve names. Eddie checks whether the network is up by looking for a valid gateway, it does not check whether nameservers are set and/or work, and it will not enforce a Network Lock exception, not even to resolve ipleak.net, during bootstrap. Implementing such a function is very questionable, because it would require a query to the external world as soon as the network is up, which might not be what the administrator wants when she sets permanent network lock. Resolve the issue easily either by forcing your country in the bluetit.rc as you already did (recommended solution) or by having ipleak.net resolved by the /etc/hosts file. In general setting the proper country in bluetit.rc is recommended because you won't depend anymore on ipleak.net and at the same time you will not need another entry in hosts . Everybody running OSMC, Raspbian or any other 32 bit Linux: you do not have crashes anymore, right? We already have a few confirmations that the problem is resolved, but we'd love hearing from you as well. Kind regards

@dziga_vertov Hello! The problem you detected has been addressed in the new version and it should have been resolved. Can you please test AirVPN Suite 1.1.0 beta 2 and verify? Please see here: https://airvpn.org/forums/topic/49247-linux-airvpn-suite-110-beta-avaialble/ Please do not hesitate to report after you have tested. Kind regards

@air2157 Hello! The Bluetit log is strangely cut and the missing part is exactly what we need to see to understand what options Bluetit receives from Goldcrest. Please try again, we need a complete log. The cut part is about the initial dozen entries just before the following one: Apr 04 13:56:40 air-eur bluetit[797]: Requested method "version" What we can see from the log is that the auth behavior is perfect, no problems here, while comp-lzo no doubts remain. We will investigate the issue. In the meantime, if you urgently need a TCP connection (but of course use UDP whenever possible), bypass the configuration file by forcing TCP mode by Goldcrest command line or Bluetit configuration file. As a side note (totally unrelated to the current matter anyway), we see that you run Goldcrest with root privileges, so you discard an important part of the client-daemon security model. You might like to avoid unnecessary privileges to Goldcrest and run Goldcrest from any user in the airvpn group. Kind regards

@air2157 Hello! Thanks for your tests. Some information you need to consider for a preliminary check: bluetit.rc directives overrde Goldcrest options, Goldrect configuraiton file directives, and profile directives Goldcrest command line options override Goldcrest configuration file and ovpn profile That said, the tiny log excerpts you publish do not help. Please send us complete log, especially by Bluetit, and make sure you don't cut entries. Try also directive proto tcp in place of proto tcp-client. From a shell with root privileges (or you can use sudo if you have it installed) in a systemd based system you can print the whole Bluetit log with the following command: journalctl | grep bluetit Please edit any personal information if necessary and publish integrally. comp-lzo no behavior in OpenPVN3 is under out attention already. We have fixed several disconcerting bugs from OpenVPN 3 main branch into our fork. Please be patient, if it comes out that it's another bug, we will fix it too. auth behavior seems fine, though. What is the anomaly you detect? Before you answer, make sure that you understand how auth directive works (check in https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/). Remember that auth does not affect AEAD ciphers in the Data Channel and does not affect tls-crypt based connections. Furthermore, compare with the tls-ciphers and data-cipher directives in our servers reported here below (you can see them by clicking any server name in the server monitor (https://airvpn.org/status): Ciphers TLS: TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 TLS-DHE-RSA-WITH-AES-256-CBC-SHA Ciphers Data: CHACHA20-POLY1305 AES-256-GCM AES-256-CBC AES-192-GCM AES-192-CBC AES-128-GCM AES-128-CBC Kind regards

Hello! We're glad to announce that AirVPN Suite 1.1.0 beta 2 is now available. Download URLs and changelog have been updated accordingly in the first topic message. Most important changes: Bluetit crash in some 32 bit systems (e.g. Raspbian) has been addressed and resolved Bluetit now waits for the system to set up properly gateway and gateway interface. Therefore, even when launched by some init system prematurely during bootstrap, and in any other circumstance, Bluetit can autonomously decide when it's time to proceed, as soon as the network link is up, avoiding errors due to network unavailability Bluetit recognizes new directive aircipher allowing to pick a specific cipher for Data Channel even when Bluetit is configured to start automatically at system bootstrap Bluetit recognizes new directive maxconnretries which tells Bluetit how many connection retries must be attempted (default: 10) in case of connection failure Goldcrest new line option --bluetit-stats allows to fetch connection stats from Bluetit Thank you for testing! Kind regards AirVPN Staff

@RameshK Hello! Please try and run Hummingbird with the option suggested by Hummingbird output you reported ("--recover-network"). If the problem does not get sorted out, enter the following commands, but please send us first the content of your /etc/airvpn directory (we would like to see why --recover-network does not resolve the problem by itself) sudo rm /etc/airvpn/hummingbird.lock sudo rm /etc/airvpn/*airvpnbackup sudo rm /etc/airvpn/*save.txt then run Hummingbird again. Kind regards

@Terry Stanford Hello! You may consider AirVPN Suite, so you can even uninstall Mono (which is needed even if you run Eddie in CLI mode only). https://airvpn.org/suite/readme/ Evaluate which solution between Hummingbird and Bluetit+Goldcrest couple suits your needs.. In both cases you will save about 200 MB of RAM, and in some cases up to 1 GB RAM, which can be very precious in general and especially in a VPS. Kind regards

Hello! Thank you for the suggestion. It's already a supported option. Please open a ticket at your convenience and the support team will handle the request.and inform you about the price. Kind regards

@dL4l7dY6 Hello! Uninstalling an older version should not be necessary as the installation script takes care of everything. Which problem did you experience exactly? Stopping and re-starting Bluetit is up to systemd. Can you show us how systemd failed to do that (just copy & paste the whole output), and why you needed a reboot of the whole system? The crash you show us might be identical to the one reported by @tOjO which we are trying to reproduce: can you tell us the system activity when the crash occurred? In particular, were you using bandwidth continuously? Do you run PiHole? Were you running any torrent client? Kind regards

@9uKm3y Hello! We confirm that Ain is connected to a 10 Gbit/s line and port, and does have a 10 Gbit/s NIC. The actual capacity of the CPU with load balancing of one OpenVPN process per thread and proper clients assignment to the appropriate, least loaded process has not allowed, so far, to use all the available bandwidth, but we have managed to reach peaks of more than 2.5 Gbit/s already. We are studying additional optimizations and we don't rule out that we can opt for a more powerful CPU in the future. Kind regards

@pjnsmb Hello! Thank you very much. From line 171 onward Goldcrest log is included, not Bluetit log, apparently. We would need complete Bluetit log too, even for that successful connection. About your DNS setup, it appears that your system can't resolve gb3.ipv6.vpn.airdns.org, which is necessary when you specify a country (as a connection destination) and "ipv6 on" in Goldcrest configuration. In such a case both Bluetit (for Network Lock rules) and OpenVPN 3 (for connection purposes), need to get the AAAA record of the <country ISO - entry-IP>.ipv6.vpn.airdns.org If you can confirm that your system can't resolve gb3.ipv6.vpn.airdns.org, at least this issue is explained. The problem does not occur when you specify a specific server as a connection destination because in that case Bluetit reads the IPv6 address from the manifest file (downloaded from the bootstrap servers) and passes it to OpenVPN3, therefore neither Bluetit nor OpenVPN3 need a name resolution. The other unexpected behavior during system bootstrap is under investigation too: it reminds us an extremely similar problem we have in OSMC and Arch. We have also spotted another anomaly, thanks to your logs, which is under investigation as well. We will keep you posted .Stay tuned, 1.1.0 beta 2 is imminent. Kind regards

@pjnsmb Thanks! One more request, if possible: Bluetit log even for the successful connection to Denebola (which is the only piece of log missing), goldcrest.rc and /etc/resolv.conf (while the system is not connected to the VPN). We need to ascertain a couple of things, thank you in advance. Can you also tell us which (if any) DNS resolver you run (bind, powerDNS....)? Kind regards

@pjnsmb Hello and thank you for your tests! Can you please tell us your system name and version? Can you also send us bluetit.rc file (cut out sensitive data) as well as the complete Bluetit log for each incident you report? To print the complete Bluetit log enter the command (as root): journalctl | grep bluetit Kind regards

Hello! Thank you very much for your reports. So, when you connect via WiFi you have the issue you reported in Arch. When you connect via simulated wired connection the problem disappears, right? Kind regards

@tOjO Hello! Thanks. We are investigating. Kind regards

UPDATE 2021-04-07: 1.1.0 RELEASE CANDIDATE 1 IS AVAILABLE UPDATE 2021-04-15: 1.1.0 RELEASE CANDIDATE 2 IS AVAILABLE UPDATE 2021-04-17: 1.10 RELEASE CANDIDATE 3 IS AVAILABLE UPDATE 2021-05-14: 1.10 RELEASE CANDIDATE 4 IS AVAILABLE UPDATE 2021-06-04: 1.1.0 HAS BEEN RELEASED Hello! We're very glad to introduce a new AirVPN Suite version for Linux. 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. AirVPN Suite changelog 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 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.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 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-resolved 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 (*) Developer documentation to create custom software clients for Bluetit will be published in the near future. Download links: Linux x86-64: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-x86_64-1.1.0-RC4.tar.gz Linux x-86-64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-x86_64-1.1.0-RC4.tar.gz.sha512 Linux i686: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-i686-1.1.0-RC4.tar.gz Linux i686 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-armv7l-1.1.0-RC4.tar.gz.sha5123 Linux arm7l: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-armv7l-1.1.0-RC4.tar.gz Linux arm7l sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-armv7l-1.1.0-RC4.tar.gz.sha512 Linux aarch64: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-aarch64-1.1.0-RC4.tar.gz Linux aarch64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.1-RC4/AirVPN-Suite-aarch64-1.1.0-RC4.tar.gz.sha512 Kind regards AirVPN Staff

This is mainly a bug fix release. Windows users: Preferences -> Advanced -> Use wintun driver is still disabled by default in this version, but we recommend to our beta testers to check it and report any issue, thanks. Kind regards