Staff

Hello, we have experienced a problem with VPN server LetsEncrypt certificates deployment. The system procedure got stuck and failed to deploy updated certificates. In turn, such a failure caused "route check" failures on Eddie desktop editions, and ONLY on them, due to expired certificates verified by cURL during the route check phase. The problem has been affecting a wide amount of VPN servers for about 8 hours and has been resolved completely now. We deeply apologize for any inconvenience. Kind regards

Hello! Please note that we did not let the certificates expire. Deployment of new certificates always occur in due time and automatically. In this case the deployment got stuck (for a bug introduced by a human error, of course, but we are all human beings) when only a part of the VPN servers certificates were deployed. About 3/5 of the servers remained with old certificates, which expired 8 hours ago. The problem has been resolved. Kind regards

Hello, we have experienced a problem with VPN server LetsEncrypt certificates deployment. The system procedure got stuck and failed to deploy updated certificates. In turn, such a failure caused "route check" failures on Eddie desktop editions, and ONLY on it, due to expired certificates verified by cURL during the route check phase. The problem has been affecting a wide amount of VPN servers for about 8 hours and has been resolved completely now. We deeply apologize for any inconvenience. Kind regards

Hello, we have experienced a problem with VPN server LetsEncrypt certificates deployment. The system procedure got stuck and failed to deploy updated certificates. In turn, such a failure caused "route check" failures on Eddie desktop editions, and ONLY on them, due to expired certificates verified by cURL during the route check phase. The problem has been affecting a wide amount of VPN servers for about 8 hours and has been resolved completely now. We deeply apologize for any inconvenience. Kind regards AirVPN Staff

Hello! It would be interesting to know whether you have the same ISP or not, or some common "Internet security suite" (or similar tools), and a traceroute to airvpn.org Also, can you access airvpn.info? Kind regards

Hello! Can you please compare ChaCha20 with AES performance and report back? ChaCha20 is strong but even less onerous than AES-128-GCM for non-AES NI supporting machines, as you might have seen in this thread. Difficult to find a cipher that performs better. Your very specific case probably requires no encryption at all from/to the VPN servers, but we do not offer such a solution, we're sorry. Kind regards

Hello! If you are 100% sure that the Android 9 options you mention will prevent any traffic leak, you can disable "VPN lock" from "Settings" > "VPN" > "VPN Lock" . When VPN lock is disabled, Eddie will simply try to re-connect as soon as possible when a VPN connection is lost (of course other functions like VPN pause during device lock will remain available for your comfort: they are handled by different settings). The main problem in Android to prevent leaks is that Linux packet filtering table is unreachable from the upper layer on un-rooted devices, so effective firewall rules can not be enforced. When the tunnel is destroyed, traffic is totally free to flow until the tunnel is rebuilt. In the time between disconnection and reconnection traffic will flow outside the tunnel. Even worse, if a VPN server becomes unreachable, OpenVPN will try indefinitely to connect to it with no success, and you will then suffer permanent traffic leaks up to Android 8 6. We will leave to developers a comment about whether mentioned, new Android 7, 8 and 9 settings will protect you effectively when the tunnel is destroyed because the matter deserves a deeper investigation. They might even help you prevent those traffic leaks which were previously impossible to block even for Eddie (and any other app running with no root privileges), i.e. leaks of those Google or manufacturer apps (if any) running with high privileges, binding to the physical network interface (it happens in iOS with some Apple services as it was clarified in Apple policy) and bypassing therefore any VPN tunnel. Kind regards

Hello! We will not lower our OpenVPN 3 standards for his requirements. We have handed a clearly superior, under every respect, source code on a silver platter to the community and to OpenVPN Tech., authorizing the company to even use it in any way they like for their own business purposes, and all they could require in the end was related to lower the source code style (because it's compliant to the art of programming) and disclose the identity of AirVPN personnel. We are not claiming "they are stopping us", although you need to note that in the first cycle, when even the most absurd requirement was met, Schwabe came out with a new one, in an endless loop. He never came out with all requirements together, he kept posting new ones after the previous one was resolved. A strategy worth to be noted. We are claiming that we have no time to waste and that it is unfair to force us to lower programming standards. Any average developer can see that our commits are on a very high level. If we do a favor to OpenVPN Tech., it's their right to refuse it, but it's not anybody's right to ask us to spend more time to try to force the beneficiary to accept the favor. So the result is that now AirVPN users are happily using ChaCha20 on OpenVPN Data Channel with OpenVPN 3 library in Android, enjoying a battery life that's 100% longer and a 30% or higher performance boost, while OpenVPN main branch has remained obsolete, without ChaCha20 support, without the new class supporting any AEAD cipher future implementation, and risks to be wiped out by Wireguard similarly to how Apache was by Nginx. Send your complaints to Schwabe or OpenVPN Tech. please, not to us. Kind regards

Yes, OpenVPN3.3-airvpn is 22 commits ahead of the main branch. Note the objections by Schwabe to the code and the commits, then examine the source code and you will have all you need to know. You can use ChaCha20 right now in the Data Channel on OpenVPN 3 in Android with Eddie Android edition (which is released under GPLv3) or you can just compile the source code of the library, as usual we put our developments available to everybody. Coming next: OpenVPN3.3-airvpn library integrated in a client for Linux systems based on ARM 64, x86 and x64. Kind regards

That's the way it is, plug and play. It's important to know that Eddie for your Ubuntu Linux (as well as any other Debian derivative distribution) does not come pre-packaged with a specific OpenVPN version, unless you prefer a totally portable version. The .deb package ensures correct handling of dependencies so when you install Eddie, latest available OpenVPN for your distribution will be downloaded and installed by apt, through gdebi or whatever your DM environment uses for that, in a totally transparent way for you. That's a reason for which it's totally plug and play and the objection to OpenVPN pertains to OpenVPN version available in a distribution repositories, not to Eddie. About Ubuntu 18.04, we confirm, together with various users, that Eddie 2.16.3 and 2.17.2 beta run just fine, so we suspect that the problem is specific to your system, or maybe you have a corrupt default.xml, as we explained, that's why we invited you to open a ticket. Kind regards

Sorry but what does it have to do with Eddie? Eddie will run the OpenVPN binary you tell it to run. Kind regards

Hello! We inform you that for datacenter needs, IPv4 and IPv6 addresses assigned to Alkes, Merope and Sabik will change on Aug, 12 2019 at 11.00 UTC. If you run Eddie, you don't need any specific procedure, as Eddie will update data automatically and periodically. If you use some OpenVPN profile that's specific to one or more of those servers, please generate a new one through our Configuration Generator. Kind regards AirVPN Staff

In this case the "problem" does not exist, as what you define as "forcing" is in reality an ordinary DNS push performed by the VPN server. DNS push informs your system what IP address the DNS server has in the virtual network (if any) but does not force it. OpenVPN client for BSD and Linux systems by default ignores the DNS push, while OpenVPN for Windows accepts it. Eddie by default accepts it (on all supported systems), but you can tell it not to do it in "Preferences" > "DNS" > "DNS Switch Mode" (when you disable the switch, remember to untick "Check Air VPN DNS", otherwise Eddie will correctly check the DNS usage and throw an error, and set your favorite DNS server address(es) in "DNS Servers" field). You have total freedom about how to handle the DNS push: it's an optional, not a forced feature. Enjoy AirVPN! Kind regards

It's a security feature. When the DNS IP address matches the VPN gateway IP address the notorious attack based on DNS hijacking and route injection, which most commercial VPNs are vulnerable to, becomes impossible. https://www.researchgate.net/publication/274800185_A_Glance_through_the_VPN_Looking_Glass_IPv6_Leakage_and_DNS_Hijacking_in_Commercial_VPN_clients Note that the paper cites AirVPN, but that's a paramount error, as the researchers did not fix the paper, not even after we repeatedly warned them about their mistake. We are not aware of any negative consequence, please feel free to elaborate. You are anyway free to query 10.4.0.1 in case you don't like the security feature for any reason. Address 10.4.0.1 is reachable by DNS queries from any VPN subnet. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Singapore (SG) is available: Lacaille. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Lacaille supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Lacaille Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@HannaForest Hello! More simply, by using Tor (either Tor over OpenVPN or OpenVPN over Tor, supported by Eddie desktop editions) or using two connection slots from the same machine (for example with the aid of a VM attached to the host via NAT). First solutions are better because you don't multi-hop on servers all belonging to the same company (AirVPN). Kind regards

Funny marketing fluff. Since AirVPN birth we allow multi-hop connections (opt-in) between different VPN servers, between VPN servers and SOCKS or HTTPS proxies, or (better solution) between VPN servers and Tor nodes. Safer and better than marketing fluff. HOWEVER, it must be known that there are some errors in the article you linked. It mixes at least two totally different attack types and makes a lot of confusion. Timing attacks can be performed anyway even on Tor network (in any low latency mix based protocol network, in general) given an adversary with enough power to monitor vast portions of the Internet., so the general analysis provided by the article is... imaginative, to say the least. Kind regards

Hello, can you please post a complete system report generated by Eddie? "Logs" > LIFE BELT icon > Copy All button > paste into your message (remove sensitive data if any). Kind regards

Hello! 1) Network Lock is not meant to survive a reboot. It's an intended behavior and a very wise decision. 2) Network Lock will remain enforced if Eddie crashes, contrarily to what you claim. It's a set of firewall rules. BUT of course if Eddie crashes at the very start then of course Network Lock will not be set. 3) If you wish that your system is always isolated from the Internet during bootstrap, set a permanent firewall rule (or two, if you have IPv6) blocking all outbound traffic. That's all, because when Network Lock is activated, Eddie will rewrite rules to allow communications to Air VPN servers. Similarly, when Network Lock is disabled by your command, Eddie will restore your previous firewall rules, which will block again all traffic (so you don't need to worry not even during the shutdown). Kind regards

Hello! In order to avoid confusion, we have changed our GitHub repository name into openvpn3-airvpn. URL has changed and has been edited accordingly in the first thread post. Kind regards

We also confirm that Eddie runs just fine in Ubuntu 18.04 with an exception: if you use systemd-resolved with on-link DNS, Eddie will be unable to force usage of VPN DNS. Since Eddie acts on /etc/resolv.conf and systemd-resolved takes total management of resolv.conf (see https://wiki.archlinux.org/index.php/OpenVPN#DNS ) Eddie operations on DNS will be ignored. At the moment you can revert to normal UNIX handling of global DNS. In general the aforementioned, very dangerous abomination is only harmful when you use a VPN, because it has the power to give birth in Linux for the first time in history to "DNS leaks", which were notorious only in system without a global DNS like Windows. Kind regards

It doesn't. The problem is on your side. Everything works as it should on Telescopium. It's not the first time you charge to us a problem on your side, and from that you jump to defamatory conclusions and widespread forum trolling before even you open a ticket. Since you re-iterate the same mistake repeatedly, we don't think anymore that you are in good faith. To avoid any further FUD and trolling from your account in our forums we will act accordingly.

Hello! Please make sure that your system queries VPN DNS, then please post a traceroute to the host while connected to Telescopium. From a terminal: traceroute <destination IP address> "traceroute" is "tracert" in Windows. Kind regards

@laowai Hello! We're very glad you can confirm the outcome of our tests as well as reports by AirVPN users, also published in this thread. Great! Our roadmap includes availability of OpenVPN 3.3 AirVPN binary, with some client side nice additions to make the experience more comfortable. in the following systems: Linux (binaries for both x86 and ARM processors) during August 2019 FreeBSD OpenBSD in the above order. Desktop systems with AES-NI full support decrease performance with ChaCha20 encryption/decryption when compared to AES-GCM, so ChaCha20 will not be a favorite choice by those users who already enjoy AES-NI. Therefore: our priority is releasing binaries which will be particularly useful in ARM based devices, which typically run on Linux or *BSD. ChaCha20 might perhaps provide higher performance (than AES-GCM with AES-NI), with coming (in the near future) CPUs featuring AVX512, it will be interesting to test. Additionally, in desktop systems you can already run OpenVPN 2.5 beta which supports ChaCha20 on the Data Channel, while on some embedded devices building OpenVPN 2.5 may be out of the ability of the average user. You can even integrate OpenVPN 2.5 beta in Eddie desktop editions, as Eddie can be configured to use any OpenVPN binary file in "Preferences" > "Advanced" > "OpenVPN Custom Path". You then need to add the following custom directives: ncp-disable cipher CHACHA20-POLY1305 in "Preferences" > "OVPN directives", and finally connect to one of our experimental servers. By using Wireguard on Android devices, you already have roughly the same battery life you experience with Eddie Android edition which uses OpenVPN 3.3 AirVPN linked against mbedTLS, on equal terms (same bandwidth, traffic, etc.). Please feel free to report back if you experience some discrepancy, i.e. if you see longer battery life with Wireguard. Anyway we are following Wireguard closely. Currently we need a couple of new, key features, which will probably be implemented before a stable version is released, as developers told us. Without them, implementation in our systems is too problematic. For example, linking static IP addresses to client keys is a heavy threat to privacy, for the reasons we explained in another thread; and lack of TCP support would cut out a remarkable amount of our customers, whose ISPs disrupt UDP. Kind regards

@airnoob Hello! This will be fixed for sure. We will not repeat the same mistake, trust us. Stop, you misunderstood the whole matter: the patch fixed the corruption of the configuration file which was caused by the bootstrap servers output. It was not something to be fixed in the code of Eddie desktop editions, apart of course designing a software which handles in a better way corrupt configuration files. The bootstrap servers were reconfigured with a new manifest format which introduced a bug: when someone tried to log the account in without having a valid plan, the bootstrap servers returned a bad message format that caused the corruption of the default.xml file of the user who did not have a valid plan. The bug was fixed quickly in the bootstrap servers. The patch you mention fixes corrupt configuration files on the client side, as an alternative to delete them. Not essential, just an additional tool for those Windows users who tried to access the service without a valid plan. Yes, you had better stop speculating. Clodo is an Air co-founder so your assumption is wrong. We will let Clodo explain the exact reasons of such delays in development, if he wishes so. Here we just point out that any excessive work load on some department is being quickly balanced to avoid any further problem of this kind. AirVPN has both the resources and the will to continue delivering the best VPN experience in the consumers' market as it has always done in the last 8 years. About the last year you mention, you can note that AirVPN has delivered from scratch not only an Android application with unrivaled features, but it is the only VPN which actively develops OpenVPN 3. AirVPN has added to OpenVPN 3 missing features that were never seen in it after years and years of development, like ChaCha20 cipher on the Data Channel. No other VPN service has ever achieved the same results. Kind regards