Staff

@OpenSourcerer Thanks! Something might have changed in 248 because we can't reproduce the bug with the reliability we had in all previous versions we tested (205-->246). But you just proved that the bug is still there, unfortunately. Note how systemd first did not respect the timeout between SIGTERM and SIGKILL, and then sent twice SIGKILL (SIGTERM, SIGKILL and SIGKILL are all sent, according to our tests, in a time not greater than 0.2 s). Kind regards

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

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/

@Stalinium Hello! We recommend not to use network-manager-openvpn plugin, not NM; in itself, as you and OpenSourcerer have rightly noted. Hopefully the OpenVPN plugin bugs will be fixed soon. We have no voice on it. Of course, nobody implied that you intentionally pretended to ignore the suggestion.😋 The disclaimer was anyway added and integrated in the Linux instructions some years ago, so it's not only an isolated post. We were confident that in some months the most critical issues would have been fixed but according to your report they are not (and new ones have accumulated, apparently...), after several years, so we're not optimistic anymore. Since we release a variety of software for Linux that should make nm-ovpn irrelevant and inferior, we do not follow actively that plugin development. Thank you for your feedback, suggestions noted! Kind regards

@niecoinny @OpenSourcerer Some info that might come handy for the current discussion as well as for future reference (Linux only). Various systemd versions currently used in the majority of Linux distributions, are affected by a severe bug. When the bug comes out, at the proper termination of a unit, systemd sends SIGTERM immediately followed by two SIGKILL signals, without respecting the timeout. The bug affects at least the following versions: 204, 215, 234, 246, 248 therefore most (all?) Linux-systemd distributions are involved. When the bug comes out (frequently in 204 and 215, sometimes in 234, very frequently/always in 246, under investigation in 248) Eddie can't restore DNS settings and firewall rules (of course), and the same will happen with Bluetit (a real daemon included in the AirVPN Suite). Next unit files for Bluetit will include the only known (so far) workaround for this problem, i.e. directive SendSIGKILL=no. You can find hundreds of web pages reporting the bug in details in years, in the bug tracker too, but unfortunately a definitive fix has not yet come out. Example which summarizes well the problem: https://groups.google.com/g/weewx-user/c/Yg8OJ7uot7U @niecoinny It's worth testing AirVPN Suite in Linux, if you have time. We're also very glad to know that you managed to run Eddie properly with runit after some effort In this case, the various problems caused by systemd should vanish. On the other hand, while Eddie remains a system process, Bluetit is a real daemon. Out of the box the installer supports systemd and various SysVInit-like systems, but it's untested in your specific environment, so let us know whether you decide to test it (if so, go directly with 1.1.0 RC 4 - 1.1.0 release is imminent). Even if your init system can't be handled by the installer, you can treat Bluetit according to your needs easily. Since it is a real daemon it should be possible to handle it classically in most init systems with no peculiar problem. https://airvpn.org/forums/topic/49247-linux-airvpn-suite-110-beta-available/ Are you running runit as a supervisor of some SysVinit-like system or are you using it as a total drop-in replacement for init? Your decision to avoid systemd is in our opinion very wise. systemd is much appreciated by many people coming from Windows because it replicates some Windows concepts but betrays the basic UNIX philosophy and never you have seen such a monstrosity in, for example, the vastly superior FreeBSD (where, instead, you can find even runit). And yes, with runit you should achieve under many circumstances (bootstrap for example) higher performance than with systemd and you remain safe from the interference at many system levels of systemd (which is not only an init system). Keep us posted if you test! Kind regards

@967819f75c Hello! No, they expire only when you revoke (or "renew") them. As you prefer. Anyway, it's not "key-value", it's a client certificate and a client key It's a unique client certificate and a unique client key (in the sense that they are unique to each client). They are a fundamental part of the authentication phase between a client and our servers. Each account can have multiple client certificates and keys for comfort and to connect multiple devices to the same OpenVPN process at the same time. As you prefer. The ticketing system is essential to receive support from our support team In the forum you get answers from the community and occasionally from some staff member (the "community" forums are by the community for the community, and staff members interfere only occasionally). The support team can be more effective and potentially more competent than a single staff member and sometimes it can find solutions that the community or some staff member missed. In 11 years AirVPN never outsourced customer care, so you can rely on personnel that works directly for AirVPN (someone since 2010!) and you can be sure that you're not sending information to third party generic support teams / call centers etc. Glad to know it. Thank you, enjoy AirVPN! Kind regards

Hello! You don't have different usernames and/or passwords. Credentials for web site and VPN infrastructure access are exactly the same. What you report is indeed unexpected because the very same base table is queried when an account logs in to the web site or via Eddie or Bluetit. Anything else simply does not exist. To log successfully you can enter either username or linked e-mail address (if any). EDIT: if you had some special character outside UTF-8 in your password, that might have been the reason. Eddie and the bootstrap server expect UTF-8. If in doubt about UTF-8 and ISO-xxxx-x encoding tables, rely on ASCII only. That could have been a different reason. For example, access to the infrastructure does not imply access to VPN servers if the client certificate and key pair has expired (maybe you revoked or renewed)? Check here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Complete system report by Eddie might help us clarify the issue. Kind regards

@Fly AirVPN But "Obtain a free trial" is quite visible in the "Buy" page and actually we deliver hundreds of free trials per week or so, therefore many people see it. We think that the "Buy" page, which shows plans and payment methods in details, is appropriate to offer free trials and make the home page lighter (it's already a little bit overcrowded). Who thinks that free trials should be advertised on the home page? Let us know. Kind regards

Nope, that prints only the last 18-19 lines in most versions. Insufficient. Nope, that's not supported in various journalctl versions, including the default version in openSUSE 15.2 (latest release) and many other distributions. Nope, that requires persistent journal. Disabled by default in many, maybe most, distributions. Nope, that's very rudimentary re-direction in bash and other interpreters. Bash functions are a totally different thing. If you think that a rudimentary re-direction is an "absurd shell function", maybe UNIX shells are not for you. Try Windows PowerShell. <evil grin> Kind regards

Hello! Nope, there's a big difference, at least for customer support personnel. 😀 journalctl -u option by default will force the user to press <SPACE> etc. to reach the end of the log or "q" to exit prematurely or the <END> key cutting out parts of the log. Any combo of the above has translated (and will again translate sooner or later) into users sending us only pieces of log. We could ask the user to re-direct the output to a file, then find the file, print it or open it with a text viewer, copy and paste its content on the next msg but why? It is additional work that's not really needed. We can save anyway piping and make you happier with < <(sudo journalctl) grep bluetit It seems that @bulbous_blues is in a subnet inside 192.168.0.0/16 which Bluetit always sets completely open in input and output, both with iptables[-legacy} and nftables. Can you confirm @bulbous_blues ? Kind regards

@bulbous_blues Hello! Bluetit can't interfere and should not be responsible of the issue you report. In bluetit.rc file, the following line is wrong: airport 37845, 8002 because only one port must be provided and because none of those ports are valid. Our OpenVPN processes listen to ports 53, 80, 443, 1194, 2018. In this case you might not notice the error because "airport" directive is ignored when connection mode is set to "quick" (NOTE: this feature changes in Suite 1.1.0). Anyway feel free to send us Bluetit log: sudo journalctl | grep bluetit Kind regards

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

@OpenSourcerer Hello! It must be seen how nm-ovpn handles DNS push. Historically, it has always been able to properly accept DNS push and then restore previous settings at the end of the connection. However, a double-check in those systems which run systemd-resolved configured in on-link mode and /etc/resolv.conf bypass (example: Fedora 33 by default settings) would be safer, you never know. In other systems where the global DNS is preserved and nameservers are "decided" by /etc/resolv.conf it appears that nm-ovpn properly handles DNS push, no DNS leaks are possible. A more general approach when you don't know which configuration you might encounter is (on top of usual network lock rules) blocking, via firewall, packets (both TCP and UDP) to port 53 of the router address, to prevent that local queries can be forwarded by the router in clear text to some other nameserver, potentially the ISP DNS server (it would not be a DNS leak, because the system does what you tell it to do, but the outcome is anyway a query out of the tunnel). Kind regards

Hello! Well, of course Wireguard is catastrophic in this sense, because it is very poor in options, but luckily it's not the same thing with OpenVPN, because in Wireguard by default you have 1) a permanent bijection between private IP address and client KEY (we will delete the link periodically when we offer Wireguard and re-create it when a connection is required), because Wireguard does not support any other method to dynamically handle clients (this feature might be implemented in the future) This dangerous pre-prepared static link does not exist at all in OpenVPN. 2) your real IP address is permanently stored by Wireguard even after you turn off your software or machine, because Wireguard is extremely limited and does not have any explicit-exit-notify or ping-timeout option (we will therefore force deletion and disconnections after some time there is no communications by the clients, even though this will cause some unexpected disconnections). OpenVPN does not need to do so because it realizes when one of the peers is no more there, even in UDP of course, so the real IP address for the socket etc. is immediately lost at disconnection. 3) Wireguard requires that the mentioned data is stored in files (we will keep them in RAM as usual, to mitigate the problem) But yes, we will re-consider the whole matter, just in case. Additional re-checks in security fields are always good Kind regards

Hello! This happens by explicit configuration server side. We opted for this solution because we received a large amount of requests to do so. It makes binding of specific processes which can bind only to IP addresses and not to interfaces (from inner settings) so much easier. This configuration can be changed (try Xuange server for example) but currently it will be not, because the requests to do so have been very many. Anyway this is unrelated to AirVPN Suite testing so we will split the messages to a different thread in Suggestions, therefore any user can write what he or she prefers. Kind regards

Hello and thank you! You will be able to get the special prices even during the first days of June. Kind regards

@Stalinium Hello! Maybe you talk about network-manager-openvpn plugin, as network-manager by itself does not support OpenVPN. In our configuration files the directives to cause IPv6 push are included, unless you specifically tell the CG to NOT route IPv6 over IPv4. It's not our fault if they are ignored. On the other hand we have been deprecating usage of network-manager-openvpn since years and years ago for other critical problems. If you decide to use it in spite of our recommendations, you do it at your own risk. You are not forced to run our software in Linux. You can run OpenVPN directly for example, or any other OpenVPN GUI/wrapper different than network-manager-openvpn. In this case, you will of course need by yourself to take care of DNS push and network lock, features that are handled automatically by all of our software for Linux. It's therefore a security issue by network-manager-openvpn, not by AirVPN, because it's network-manager-openvpn that ignores directives that our Configuration Generator puts in, and it's you the one who does not replicate Network Lock which would have made the problem anyway irrelevant (under a security point of view). Nonsense, a MAC address is simply is not included in IPv4 packets (there's just no room for it), while nowadays all systems mitigate the MAC problem in IPv6 addresses. Our servers never receive the MAC address of any of your physical network interfaces of the router and even less of the computer. The problem is more basic, and it's simply having IPv6 traffic outside the VPN tunnel but keep in mind that you ignored instructions and our suggestions, up to the point to use exactly the software we tell you NOT to use. About FBI... What FBI really did was something quite different and is not a Tor problem in itself (for Silk Road, for example, it was "only" social engineering, by infiltrating an agent in the core of Silk Road and exploiting administrator's trust in this infiltrated agent - in other cases it used javascript which the final user recklessly allowed execution of, on the browser, and in a Windows system) but anyway they are talking about Tor and not OpenVPN, so we can cut the FBI cracking techniques discussion here as it is irrelevant for the matter. Unfortunately not all OpenVPN versions, in client mode, can push a UV, and most versions which can't are the old ones which are also bugged with IPv6. The whole setup has been made with the purpose not to send IPv6 push to those OpenVPN versions which are bugged and would create critical errors with IPv6 push. This backward compatibility may be abandoned one day, but it's still not the right time. Anyone having new versions can send UV and therefore this solution makes everyone happy. Furthermore our Network Lock includes IPv6 rules to prevent leaks. Remember that VPN software is not designed to provide an anonymity layer. It's the environment we create with our software which makes it possible, and VPN connection is a part of the anonymity layer. If you renounce to part of this environment by not using our software, you must understand what you do and how to replicate various features, first and foremost Network Lock. If you use a software that, to make things even worse, negligently ignores our own CG directives, and it is furthermore deprecated by us, then you're running at your own risk, ça va sans dire. . Kind regards

Hello! Today we're starting AirVPN eleventh birthday celebrations offering special discounts on longer term plans. It seems like it was only yesterday that we celebrated the 10th milestone birthday, and here we are, one year later already. From a two servers service located in a single country providing a handful of Mbit/s, the baby has grown up to a wide infrastructure in 22 countries in four continents, providing now 240,000+ Mbit/s to tens of thousands of people around the world. We still define it as a "baby", but AirVPN is now the oldest VPN in the market which never changed ownership, and it's one of the last that still puts ethics well over profit, a philosophy which has been rewarded by customers and users. 2020 (and 2021 so far) have been harsh years for the mankind but we have no rights to complain too much because AirVPN was only marginally touched by those terrible repercussions which affected many other business sectors in general. In spite of that, we could not maintain our promise to deliver native software for FreeBSD and we apologize for the failure. However, releasing software for FreeBSD, specifically AirVPN Suite, remains one of our goals, so stay tuned. On the other hand, Eddie desktop edition, AirVPN Suite for Linux, Hummingbird for Linux and macOS, and OpenVPN 3 AirVPN library were updated substantially and swiftly. Moreover, Eddie Android edition development has been recently re-opened to provide a new version updated to new requirements and specifications of Android 11 during 2021. Hummingbird was natively released for M1 based Apple Mac systems too, allowing a dramatic performance boost (up to +100% in >100 Mbit/s lines). Behind the scenes, infrastructure had some paramount improvements. The whole network in the Netherlands has been enlarged with additional redundancy and several servers around the world have had hardware upgrades. In Sweden and Switzerland we started operating servers connected to exclusive 10 Gbit/s lines and ports, and we optimized the environment to obtain more bandwidth from the OpenVPN processes. We managed to beat the previous 1.7 Gbit/s barrier. The performance on the customer side has improved and reached new peaks of excellence, as you can see here: https://airvpn.org/forums/topic/48234-speedtest-comparison/?do=findComment&comment=130191 Furthermore, the infrastructure has become fully Wireguard capable and throughout 2021 we will start offering Wireguard connections, in addition to OpenVPN ones, in an hardened environment which mitigates the numerous privacy problems posed by Wireguard. Last but not least we re-started operations in a fourth continent, Oceania, with a new server in New Zealand. All AirVPN applications and libraries are free and open source software released under GPLv3. It's worth quoting literally what we wrote last year for AirVPN birthday: Kind regards and datalove AirVPN Staff

@WilDieteren Hello! Backend is already running natively. Frontend still needs Rosetta 2 because Mono does not exist yet for M1. Anyway frontend does not have any time critical duty, so it's not a big deal. The real deal is OpenVPN 2/OpenSSL which is still slow in M1 (just like it is slow on Intel Mac anyway) so you might like to have Eddie run Hummingbird for M1, or run Hummingbird for M1 directly. If you have more than 100 Mbit/s, you should get around 100% boost. Kind regards

@SeUbHS Hello! Yes, set your blocking rules as default rules while Eddie is not running and has just exited cleanly. Remember to allow local network, and special destinations such as 255.255.255.255 in order not to block DHCP (at bootstrap etc.). Since you run iptables you can simply enforce DROP policy to the OUTPUT and INPUT chains of the filter table, and then set a few rules jumping to ACCEPT for local subnet, localhost and 255.255.255.255. A very simple startup script (it's only an example, you must modify it according to your needs and the features of your network, and you can also use iptables-save to make rules permanent - also specify the correct path to iptables): iptables -F iptables -P OUTPUT DROP iptables -P INPUT DROP iptables -P FORWARD ACCEPT iptables -I INPUT -s 255.255.255.255 -j ACCEPT iptables -I OUTPUT -d 255.255.255.255 -j ACCEPT iptables -I OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -I INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -I INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT iptables -I OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT When Eddie enables Network Lock, you can communicate with AirVPN infrastructure only. When Eddie disables Network Lock (including when it quits) it will restore your blocking rule, so your machine will be isolated from the Internet. Kind regards

Hello! If you confirm that the sentence is correct ("when Eddie ISN'T running") then yes, it may be normal behavior. When Eddie is properly closed, it de-activates Network Lock. However, if Eddie isn't running because it crashed, then Network Lock remains enabled, because it's a set of firewall rules which are not modified. Kind regards

@183aTr78f9o Hello! Quite right. The feature will be available in the 1.1.0 stable release. Kind regards

@khuffmanjr Hello! Can you send us both output of Eddie when you stop it by pressing CTRL-C in the shell and when you stop it will kill -SIGTERM ... ? Kind regards

Hello! Same error code, same explanation, but in this case the cause should lie in the behavior of the machine during sleep and at wakeup. To save time, try to reset network and re-start Eddie, it might be enough and would save a reboot. Kind regards

@tronchilwelch Hello! To delete an imported profile, please go to the "Profiles" view, long-tap a profile then select "Delete" from the contextual menu. The "default" profile is the last one you have picked. It will be used even for the connection at boot, if you halted the systems while Eddie was connected through a profile and the option to connect at boot is on. Kind regards