Staff

@colorman Hello! Thanks! Can you please print all iptables-legacy rules while the connection is still active? Please enter command (from another shell) iptables-legacy-save, then copy all and paste here, thanks! Is this error occurring all the times, or occasionally? Does the error persist if you stop firewalld? Did you notice this error in some past 1.1.0 beta or RC version? Kind regards

@colorman Hello! Thank you for your tests once again. As usual, can you please send us the complete Bluetit log (output of the command sudo journalctl | grep bluetit) printed after the problem has occurred? Can you also tell us the current system firewall when the problem occurs? Kind regards

Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 3 is now available. Download URLs have been updated in this thread first message. AirVPN Suite 1.1.0 RC 3 aims at addressing RC 2 Bluetit problem or regression suffered in D-Bus message handling and found out (unfortunately not reproduced on our systems) by our community testers @pjnsmb @leori and @colorman Please keep testing RC 3! Version 1.1.0 RC 3 - 16 April 2021 - changelog [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 Kind regards

Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 2 is now available. Diownload URLs have been updated accordingly in this thread first message. AirVPN Suite 1.1.0 RC 2 includes NEW OpenVPN AirVPN library 3.7 fixing a couple of issues coming from the main branch causing the library to crash under the conditions found by our community testers and reported in this thread: thank you all! Another issue in the library was the confusion between "proto tcp-client" and "proto tcp" in OpeNVPN 3 main branch, which caused a critical problem as reported in this thread by testers. The issue has been addressed. OpenVPN AirVPN 3.7 is now 100 commits ahead of the main branch, featuring several, new important features and very many bug fixes. https://github.com/AirVPN/openvpn3-airvpn A small change in Bluetit will also cause less CPU usage, at the price of a slightly lower responsiveness (which will not be seen by the naked eye). The main load was caused by the handling of the D-Bus message queue, which is critical because D-Bus does not have a message buffer: if the listener loses a message that message will be lost for good. Through an appropriate fine tuning, now Bluetit will not lose any message but at the same time will need less CPU time. Thanks again to our community testers for having reported the matter in this thread. Please keep testing RC 2! Kind regards AirVPN Staff

@pjnsmb Hello! Under your conditions, Bluetit resolves gb3.ipv6.vpn.airdns.org. We might have some issue with records update, at least for AAAA, so the problem is not in Bluetit. We are investigating, thank you, it is a useful head up. Kind regards

@jrredho Hello and thank you! We can't reproduce the issue, can you see how Eddie runs Hummingbird in your case? If you tick "Debugging log" option in "Log" window Eddie log verbosity will increase and Eddie should print all the commands it runs. Please check also the profile that Eddie generated, which is then passed to Hummingbird. You can see it by double-clicking the "generated configuration" line in the "Stats" window. Kind regards

@c69c7kfrv48fuJ8Re44C Hello! Exactly. Maybe it's worth pointing out even in this thread that we released highly optimized Hummingbird for Apple M1 machines. If you have more than 100 Mbit/s available, you should see around 100% performance boost when compared against OpenVPN. In the download page: https://airvpn.org/macos/hummingbird/ you can clearly identify the Intel and the M1 version. Kind regards

Thank you very much for your great feedback! Nowadays, several "VPN reviews" must be paid. Since AirVPN has never paid for any review, those reviewers who only publish reviews they are paid for will never mention AirVPN, or they will mention it only to advertise other VPN services they are paid by. We prefer offering an honest service at the best of our abilities and let the market speak by itself, rather than fooling gullible people through fake, paid reviews and other dishonest practices. So far AirVPN has flourished thanks to a correct and honest behavior, which has caused a virtuous word of mouth as well as excellent unbiased reviews, and not thanks to clean and/or shady marketing (even because AirPVN has invested ~0.00 on any classical marketing). So it's very important for us that you frankly express your opinion on the service, anywhere you deem appropriate and whenever you have time and if you want to do so! Thank you! Please note that our moderator removed your link in our forum because it linked to a review of a VPN competitor. That's forbidden. The moderator did not imply that you should not comment or talk about AirVPN anywhere! Also note that we operate these forums for our community, and that moderators are members of the community too: they moderate for passion and without rewards, they do not work for AirVPN and they are not part of Staff or technical support team. Kind regards

@Jamertol Hello! Thank you for your request. We're sorry, at the moment we have no plans to offer dedicated IP addresses. Kind regards

@JonathanZR Thank you for having mentioned the review! We would like to clarify a misleading claim by @OpenSourcerer "Challenge accepted. *BSD. I won. FreeBSD, NetBSD and another BSD related system, Darwin, are supported, by most of our software and support team. You can run AirVPN software in FreeBSD, NetBSD, and macOS recent releases (both Intel and M1 based machines), and you can have competent support for each of those systems. So, the sentence by our moderator might be applied to OpenBSD, and only partially. Even if you can't run our software in OpenBSD, you can anyway run OpenVPN with the configuration files generated by the AirPVN Configuration Generator and connect successfully to any AirVPN server. Finally you can have a fully OpenBSD oriented customer care. Kind regards

@courteousorbit Hello! We're sorry, we do not want that because stunnel is meant (in our service) as a tool to bypass (even, but not only) blocks based on certificate replacement. We need to fool the blocking system making it believe that it can decrypt the flow (actually it can decrypt stunnel tunnel). Then, an OpenVPN tunnel is established inside the stunnel one, and that's where the blocking system is fooled in most cases. Data security and integrity is therefore guaranteed by OpenVPN, not by stunnel. If you need proper stunnel setup, then you do not suffer the aforementioned blocks type, so you can probably bypass completely stunnel and use OpenVPN in TCP and in TLS Crypt mode (maybe to port 443, in order to approximate very closely a TLS driven HTTPS connection). You will have even higher performance, of course. Also consider UDP, if you are not forced to use TCP. Kind regards

@air2157 Hello! Yes, it sounds definitely fine. It's 7.3% of 6.8% in the worst case, as far as we can see from your pastes, i.e. less than 0.5% of total CPU time. Kind regards

Hello and thank you! We're glad to inform you that both bugs have been reproduced, isolated and fixed. You will be able to test the fixes in the coming version in the next couple of working days.. Kind regards

@Airystocrat Hello! Eddie's Network Lock now works even for OpenVPN over Tor mode, but only in Windows. Eddie 2.18 or higher version is required. The feature is currently undocumented. Eddie developer may clarify the matter. In other systems, if you can't rely on virtualization, we would recommend Tor over OpenVPN for a 100% safe leaks prevention. Tor over OpenVPN, in terms of anonymity layer, is better than OpenVPN over Tor, because the Tor "circuit" is free and re-built at each stream, and not indefinitely fixed for the unique OpenVPN stream. Moreover you can run OpenVPN over UDP. However the final service will see that your traffic comes from Tor. Kind regards

@jrredho Hello! About Irix and Solaris mode: https://logic.edchen.org/irix-mode-vs-solaris-mode-in-top-command/ @air2157 It should be fine, but anyway let's see absolute values (i.e.: 8% of what?) as we asked. Compare the CPU relative usage you get with the global, idle CPU percentage, for example (in top switch to CPU mode to get an exact overview). Practical example for you both: in the FreeBSD system this Staff member is writing from, in this very moment top works in Irix mode and CPU mode. It shows that Xorg uses 82% of a CPU, which in turn is 97% idle, so Xorg takes 82% of 3% = 2.46% of global available CPU time.. Kind regards

@jrredho Hello! Is htop working in Irix or Solaris mode? Can you also compare with absolute values for a consistent evaluation? On equal grounds, both Hummingbird and Bluetit should need the same CPU power, because the "inner engines" which handle 99% of the math load (OpenSSL and OpenVPN) are the very same. Here, one of the most important variables which can change dramatically CPU load is the bandwidth. In Linux 64 bit both Hummingbird and Bluetit use the same OpenVPN3 version linked against OpenSSL. About Eddie, it's perfectly normal that it needs very little CPU time, because it's an interface. Again, encryption/decryption are performed by OpenVPN2/OpenSSL or Hummingbird/OpenVPN3/OpenSSL, which are invoked by Eddie. Kind regards

@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