Staff

@Ugh527 Hello! As soon as Mono is available natively for Apple M1 based systems, Eddie will be re-built, therefore it will not need anymore Rosetta, not even for the GUI. Other glitches and bugs will be fixed as well. Currently, you can run Hummingbird (another AirVPN free software) and have a 100% performance boost (you will notice the boost especially if you have a greater than 100 Mbit/s bandwidth). We offer Hummingbird highly optimized for M1 CPU. https://airvpn.org/macos/hummingbird/ If you decide to run an old Eddie version which is affected by the terrible "permanent banner" bug, you should be able to get rid of the banner by deleting all the AirVPN files, in particular default.profile (which was called default.xml in old versions). Kind regards

@OpenSourcerer 1) Sure. That's where the kernel filtering table may save you, while a filtering method based on the API itself can't. Proof of concept to exploit the NetworkExtension exceptions exist since months it's not FUD. Of course future research might find even newer methods and Apple decision to cancel those exceptions might even be related to security considerations, more than customer's respect. But even without those possible exploits, the behavior has been highly criticized by many Apple customers and is rightly seen as not acceptable.. 2) Yes, it was a very risky move by Apple, and no surprise they have moved away from that after a few months. On top of that you need to consider all the other 50 apps which may expose your real IP address involuntarily to the other end, not necessarily Apple, which is always a very bad thing The expansion of the attack surface with such a decision was remarkably high. Kind regards

Hello! AirVPN Suite 1.1.0 RC 1 is now available. No news from beta 2, it's just for development cycle consistency and coherency. URLs in initial post have been updated. Kind regards

Hello! Of course, that's the core of the issue and one of the purposes of NetworkExtension hard coded exceptions. Note that a VPN that does not have a kernel extension (and anyway kexts are no more supported), running in the userspace, relies on the NetworkExtension framework to tunnel traffic etc.. You can verify that no traffic is seen in the VPN tunnel and that it flows out of it (if Network Lock is disabled) with tools like tcpdump or Wireshark in the OS versions affected by the problem. That's also the problem experienced by Mac users which could not access Apple services when Network Lock was on, obviously, but only in certain macOS versions, while in other versions they had no problems. To mention one of our competitors, just to remain above any suspicion , PIA wrote in "PrivateNews" that " the Apple App store and 50 other Apple apps are allowed to bypass user based internet routing rules which means Apple could know your real IP address". (bold and underline are ours). It makes sense in the eye of a profiler: being sure that you can link a "real" IP address to a certain profile is a "good thing", because it makes profiling effective and it bypasses risks of proxy / VPN or more trivially local routing table blocks (null routing etc. etc.). Moreover, it can destroy the anonymity layer of a user who has been careful to always hide to Apple the real IP address since when she bought a certain computer. This problem existed since 2017 and Symantec publicly denounced it, Apple answered it was a feature. However, in 2017 kexts were still supported, so the problem did not seem so huge in the eye of many users because "anyway I can block via LittleSnitch etc". You can start directly from Apple itself, it's not a secret how Network Extension framework works. See the developer's documentation of the NetworkExtension framework. An overview is given here https://developer.apple.com/documentation/networkextension Kind regards

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