Staff

Version 2.21.1 (Thu, 19 Aug 2021 12:19:20 +0000) [change] [windows] OpenVPN 2.5.3 also in Windows 7/8 [change] [linux] Removed "libappindicator1" dependency in .deb package [bugfix] [linux] Fixed an issue with portable/AppImage packages ('cannot open shared object file') [bugfix] [windows] Fixed Windows 7 issues [bugfix] [all] Fixed an issue when IPv6 is disabled at system level [bugfix] [windows] Updated libcurl [change] [all] New ping engine Windows users: now if Wintun is used (default from this version), a network adapter is created when session starts and destroyed when session ends. Wintun driver is installed (or upgraded) when the adapter is created and removed when the adapter is removed. We added an option to keep the adapter in Preferences->Advanced window. Windows/Linux/macOS: we rewrote the latency/ping system to make it work better and faster, resolve some UI issues in Linux and provide more accurate results in macOS. @airvpnforumuser and other: issues after system suspension, and the error "Windows WFP, unexpected: Rule 'ipv6_block_all' already exists" is still under investigation, it is our next priority. About Windows OS compatibility: Windows 8 works exactly like Windows 10. In Windows 7 the latest Wintun driver doesn't work for some currently unknown reason, so it is not used (OpenVPN works with the tapdriver6), and for the same reason Wireguard (which can use ONLY Wintun) will not be supported on Win7. Kind regards and datalove

@PugConsultant Hello! In the host machine, your setup will force all traffic over OpenVPN over a Tor fixed circuit. You can't compare it with Tor-ification because the Tor circuit is fixed. However, what happens to the traffic from and to the VM depends on how the VM connects to the physical network interface: if the VM connects directly to some physical network interface, i.e. it works in "bridge mode", the tunnel(s) in the host machine are "bypassed" completely if the VM is attached to the host via NAT, all the VM traffic will also be tunneled over VPN over Tor The latter setup 2 is particularly important when your threat model includes powerful adversaries. OpenVPN over Tor tunnels OpenVPN over a fixed Tor circuit. Now, if you use Tor on the VM attached to the host via NAT, you add another Tor circuit, this time dynamic (i.e. re-built for every and each new TCP stream), where the traffic will end up before getting on to the Internet (your node -> Tor circuit 1 -> Air VPN server -> Tor different circuit -> the Internet). A significant improvement of the anonymity layer (on the VM) at the price of slower performance. Kind regards

@hardknox Hello! Network Lock already includes a rule which allows any TCP and UDP packet from 192.168.0.0/16 to 192.168.0.0/16. If you need to reach different subnet inside 192.168.0.0/16 between different network interfaces, remember to enable IP forwarding. Also remember that Network Lock does not allow data exchange between different private blocks, for example from 10.0.0.0/8 to 192.168.0.0/16. Should that be your need you must add additional firewall rules on top, after each Network Lock activation. Kind regards

@Monotremata Hello! Yes, please send us (in a ticket maybe, because this thread is for Eddie) the complete Eddie log (Eddie log will include any log by Hummingbird) pertaining to the event. From your description it definitely sounds like some unexpected OpenVPN3-AirVPN library problem. Do you connect in TCP or UDP? Kind regards

@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