Staff

@hardknox Hello! Whereas you have set connectatboot server in bluetit.rc, when started Bluetit will propound the aircipher specified AES-128-GCM cipher, which is supported by all of our servers, for the OpenVPN Data Channel. If you want to try CHACHA20-POLY1305 just change aircipher into CHACHA20-POLY1305 and re-start Bluetit, or use Goldcrest with the proper options to disconnect and start a new connection. However, if your system does support AES New Instructions, you may lose performance with CHACHA20. Not all systems take advantage of AES-NI, even when they are implemented in the CPU, thus a test with CHACHA20 is worth its time. Furthermore, please make sure to test different servers in various locations, in order to maximize likelihood of good peering between our and your transit providers. If performance remains low, test TCP, according to @OpenSourcerer suggestion, just in case your ISP enforces some cap on UDP. Just change airproto into tcp and restart Bluetit. Kind regards

Hello! We're very glad to inform you that we have just published the Developer's Reference Manual for Bluetit by promind. Bluetit, a core component of the AirVPN-SUITE, is a lightweight D-Bus controlled system daemon providing VPN connectivity through OpenVPN 3 AirVPN. Bluetit exposes a D-Bus interface which can be used by client applications in order to control the daemon and provide full interaction and connectivity with the whole AirVPN infrastructure. The manual covers Bluetit infrastructure and architecture and provides a complete reference for all the AirVPN’s classes on which the suite is based. The goal is to give any developer who wishes to write a Bluetit client, or a tool providing AirVPN inter-connectivity, a complete reference about the internals of both Bluetit daemon and the AirVPN–SUITE C++ classes. The tool to swiftly interact with the AirVPN infrastructure, repeatedly required by multiple AirVPN client developers in the past, is available and fully documented now. The document is a significant step forward in the VPN market and a further AirVPN's commitment to transparency and openness..The availability of a Developer's Reference Manual allows, in fact, any user or developer to successfully and proficiently build an AirVPN client to best suit her or his own needs. Should you decide to have a paper copy of the document, please consider that it is typeset for double side printing. Bluetit Developer's Reference Manual has been written and typeset in the unrivaled (ça va sans dire) LaTeX 2ε and it is released under CC BY-NC-SA 4.0 International You can download the manual here: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/docs/Bluetit-Developers-Reference-Manual.pdf directly from this message: Bluetit-Developers-Reference-Manual.pdf or in the AirVPN Suite for Linux download section. Kind regards & datalove AirVPN Staff

@MarxBrother Please make sure that no firewall blocks incoming packets while the system is in the VPN and that the listening software does not bind, even as an aftermath of UPnP or other automated port mapping, to the physical network interface and/or localhost. Therefore, please check any bind option and also check any UPnP and similar option. If the above has been already verified and the problem endures, please open a ticket. The support team, in private, may support you more effectively. Kind regards

@MarxBrother Hello! You forwarded remotely several ports, but port 55555 is not one of them, can you please check? Kind regards

Hello! Are you sure that your UDP port (in your local network interface) exists? Maybe the listening software accepts TCP packets, not UDP ones. Anyway UDP tests are not reliable for the very UDP nature (it's connectionless). Kind regards

@debu Hello! We're sorry, this version can't run in Windows XP. On our side we do not test Eddie on Vista anymore we're sorry. However, it should run fine in Windows 7. Windows 7 end of life was reached on January 2020. https://www.microsoft.com/en-US/windows/windows-7-end-of-life-support-information Kind regards

Hello! Of course every security model can have different approaches and settings, but in general this approach of yours is very good. "sudo" is sometimes (frequently?) used improperly in Linux and can potentially do more harm than good. Now imagine that you, the superuser, wants to give some other user (even your regular user, for example) the privilege to drive Bluetit (which performs even root actions, such as changing network) but not any other root privilege. With the current permission model, you can do it swiftly and comfortably. Without the airvpn group, you would be blocked and you should implement the current permission model by hand by yourself, which would be a very inelegant flaw of ours, the daemon developers and distributors. Even in your system, therefore, the default configuration is more comfortable for you, should any more refined need arise. No, it's already set to maximum verbosity, and such setting can't be modified in the current release, it's a gabby daemon. 😋 Kind regards

@Stack of computer parts Hello! Very strange issue indeed, and it's also stranger that it solved "by itself". If it re-occurs, please take all log and configuration files and open a ticket. This is a question that's ignominious for any UNIX administrator, let's pretend it was born during a momentary lapse of reason or some nefarious Windows-ish influence 😀 Joking apart: Bluetit is a daemon and runs with high privileges to modify your inner system settings (routing table, kernel packet filtering table...). By default policy, Bluetit accepts commands from clients that are run by any user in the airvpn group. Creation of airvpn user in the airvpn group is an additional comfort provided by the installer. It allows superusers to have fine grained selection according to the most classical and robust UNIX permission model (remember CUPS, X server and other tons of daemons permission scheme? same thing). For example, nowadays many Linux users routinely log into their machines with a user that can also gain all the root privileges, and they might like to NOT allow this user to send commands to Bluetit for trivial security reasons. They can do so simply by not adding their regular login user to the airvpn group. Another good, very similar example is having users that can not gain root privileges but can send commands to Bluetit. Of course the above is the default permission scheme set up by the installer and the provided files, nothing prevents a superuser to change it and adopt a different one. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.21 beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OS Click on Other versions Click on Experimental Look at the changelog if you wish Download and install Please see the changelog: https://eddie.website/changelog/?software=client&format=html This version contains an almost completely rewritten code for routes management, DNS and more, so please report any difference from the latest stable release 2.20. This version implements WireGuard support. AirVPN servers will offer it, during an opt-in beta-testing phase, within September. WireGuard support is expected to work out-of-the-box (no need to install anything else but Eddie) in Windows and macOS. In Linux it works if kernel supports it (WG support by kernel is required). PLEASE CONSIDER THIS AS A BETA VERSION. Don't use it for real connections it's only for those who want to collaborate to the project as beta-testers.

@Stalinium Hello! We might have underrated the non-linear growth of load over clients amount, which is very difficult to compute in advance because it depends not only on bandwidth required by a client, but (also) on an unknown variable, that is the amount of half.-connections established by single clients, which varies enormously over time and by single clients (different usages). We are fine tuning and resolve the issue if necessary, thank you for the head up. Kind regards

@WilDieteren Excellent, thank you for the information. Enjoy AirVPN! Kind regards

@WilDieteren Hello! The AirVPN Suite is a software suite for LInux which includes Hummingbird, Bluetit and Goldcrest. Hummingbird is already available for macOS High Sierra or higher version, while the other software of the suite (Bluetit and Goldcrest, which is a client of the Bluetit daemon) are planned to be ported to macOS. TUI is a Terminal (or Text-Based) User Interface, ncurses is a library which offers an API to build terminal independent TUIs. We have plans to implement an ncurses based TUI in Goldcrest. Eddie various problems in Rosetta 2 will be solved by having Mono native for M1, but as we wrote it's not available at the moment. Kind regards

@amazeballs Hello! Unfortunately the matter is not entirely in our hands because Eddie frontend (the GUI and CLI) runs in Mono framework, and a native Mono "M1" version still doesn't exist. For Mac we also have plans to port the AirVPN Suite, which includes Goldcrest client and Bluetit daemon. Goldcrest will have an ncurses based TUI. Of course, if in the meantime Mono is released for M1, we will quickly re-build Eddie fronted native for M1. Currently you can anyway run Eddie in M1 (frontend will run in Rosetta 2) and have it run Hummingbird for M1, to have anyway the performance boost. Only Eddie GUI will run in Rosetta, Hummingbird will run natively, and you don't need the CLI anymore. Kind regards

@m1ster Hello! You can't build Hummingbird or the AirPVN Suite in FreeBSD because OpenVPN3 AirVPN library needs various modification for FreeBSD, you will not be able to even compile it at the moment. We have plans to port the AirVPN Suite to FreeBSD later this year, but first we need to adapt the library, which might be or not a trivial task, and we must release a new Eddie Android edition version before the summer is over. At the moment you only have the Linux binary compatibility mode option (try with Hummingbird, as Eddie will have too many complications due to Mono), and of course OpenVPN 2.5.2. Hummingbird and the Suite support and have always supported pf, the default FreeBSD firewall, but different directory tree and some other issue may cause trouble. https://docs.freebsd.org/en/books/handbook/linuxemu/ Anyway we assure you that FreeBSD support improvement with native applications remains our goal for 2021. Our FreeBSD users are many (25% of our Windows customers, and 20% of our Linux customers, who are currently the absolute majority), not to mention the system outstanding superiority, so stay tuned. Kind regards

@Similiar Hello! if your router CPU does not support AES-NI (New Instructions) you may enhance performance by using CHACHA20-POLY1305 cipher on the Data Channel. It's supported by all AirVPN servers and requires OpenVPN 2.5 or higher version. Kind regards

@56rohrschach2u Thank you for your tests! Can you please try again now? Kind regards

Hello! It's possible that the first "bootstrap server" that Eddie tries to contact is not working well or is unreachable from your nodes. After the timeout, Eddie goes on to the next available "bootstrap" server, that's why it works but you notice a delay each time Eddie wants to download the "manifest file" from any bootstrap server (we offer wide redundancy of bootstrap servers, but Eddie will try them always in the same order). We will start an investigation soon. Can you confirm that the problem is still ongoing? Kind regards

@YLwpLUbcf77U Hello! Yes. To confirm that OpenVPN works over TCP just have a look at the OpenVPN log. To confirm that OpenVPN has used TLS Crypt for negotiation check your TLS key. If it's ta.key then TLS Auth mode was used for negotiation, if it's tls-crypt.key then TLS Crypt was. Another way is checking the VPN server IP address you connect to. Entry-IP addresses 3 and 4 are reserved to TLS Crypt and won't work with TLS Auth. Entry-IP addresses 1 and 2 are reserved to TLS Auth and won't work with TLS Crypt. Kind regards

Hello! We're very sorry, Apple notarization modifies the binary file. Use the non-notarized version to have the binary that we really developed and programmed. We will see how to handle this issue very soon, maybe we can re-package the notarized version with the new checksum after Apple has changed our binary. EDIT: no, we can't do that, as it would imply to re-modify the archive provided by Apple. We will therefore eliminate the checksum control in the binary for the notarized version. Checksum control for the archive remains. We underline once again that we publish the non-notarized versions to offer you the option to have binaries which have not been modified by Apple. Kind regards

@Hotty Capy Hello! Thank you! We will investigate, because when the network is online, network online target should have been reached: that's exactly network-online.target purpose! But we have learned that we can't trust many Linux infecting wrecks, so this might be one of those cases. In the meantime, a quick workaround to harden your setup is enforcing permanent firewall rules blocking any communications except communications to/from 255.255.255.255 (to allow DHCP) and to/from the local network and localhost. In this way your machine can't reach the Internet until Bluetit starts (in such a setup, Network Lock becomes strictly necessary, to lift the total block). Another workaround might be editing the unit file, telling that Bluetit must be started regardless of network status, because Blueitt has its own internal verification to avoid critical errors when network interfaces are not configured and/or default gateway is not available etc. We will think about it and we will let you know. Kind regards

@Hotty Capy Hello! Thank you for the information you published. When Bluetit is started by systemd it activates Network Lock and connects to a server in just a few seconds. The decision to start Bluetit is up to systemd according to the target rules specified in the unit file. Contrarily to what you can do with any serious init system, determining the exact moment when a daemon or a process is started by systemd is not possible: this is one of the notorious, countless systemd flaws. The default unit file tells systemd to start Bluetit when network-online has started. Once network-online has started, systemd will start Bluetit according to its own internal priorities. Can we see how network-online is configured in your system? sudo systemctl status network-online.target sudo journalctl | grep bluetit In this way we can see the exact timing of both. Enter those commands after Bluetit has started. Kind regards

Hello! Only with profiles because of the Master Password, and only at bootstrap. Open "Settings" view, expand "System" menu, enable "Restore last imported OpenVPN profile at boot". From that moment on, each time you shut down the device while Eddie is connected through a profile, Edie will restart and connect at the next boot. This will not work in Android 10 and 11 due to a change of permission registration and methods to auto-start apps at the bootstrap. Eddie will run just fine when launched manually, but will not be authorized to auto-start at boot by the system. If you run Android 10 or 11 you will need the new version 2.5 which is currently being developed, or you can try OpenVPN for Android. Kind regards

@Hotty Capy Hello and thank you very much for your great feedback! Let's try and understand what happens with Bluetit during the system bootstrap. Please send us Bluetit log (cut out sensitive info if necessary) after the system has completed its startup sequence. From a terminal [emulator}: sudo journalctl | grep bluetit Kind regards

@YLwpLUbcf77U Hello! It's not something DD-WRT specific, it's an OpenVPN working mode. TLS mode is essential to use all the OpenVPN security features, including PFS. We only operate OpenVPN in TLS mode. When OpenVPN works in TLS mode, TLS Crypt encrypts the whole Control Channel from the very beginning, while TLS Auth does not. Therefore TLS Crypt hides to DPI OpenVPN protocol fingerprint and it's much harder blocking OpenVPN in TLS Crypt mode than blocking OpenVPN in TLS Auth mode. TLS Crypt and TLS Auth are mutually incompatible, and each OpenVPN daemon working as server can only work with TLS Auth or TLS Crypt. That's why we offer different IP addresses for TLS Crypt and TLS Auth modes: Also note that TLS Auth and TLS Crypt keys are different. A more elaborated and precise description can be found here (1st answer): https://serverfault.com/questions/929484/openvpn-2-4-security-differences-between-tls-crypt-and-tls-auth Kind regards

@Maggie144 Hello! To resolve names Hummingbird queries (via system) the DNS servers set in your system, can you please check those settings? Please make sure that publicly available DNS servers are set. If necessary, how to change DNS settings in macOS: https://serverguy.com/kb/change-dns-server-settings-mac-os/ Kind regards