Staff

Hello! Ok, so this might be some new type of block against AirVPN, ignore our previous message related to a momentary problem on our side which is now resolved. Would it be possible to collect info about your ISP, a system report from Eddie, and also whether you can access airvpn.info or not? The block against ipleak.net is particularly puzzling as it is not in the AirVPN pool of servers of any kind... And also antivirus, packet filtering tools, "Internet security" suites if you run them, as we should not assume prematurely that the block comes from the ISP, it could be local. traceroute to airvpn.org, ipleak.net and airvpn.info might help as well to understand the nature of the block (or maybe of some transient routing problem). Kind regards

Hello, that's a different, unrelated problem (OpenVPN older than 2.4 version and Eddie checking IPv6 route anyway), check your ticket for a quick fix (for the readers: upgrade your Linux system to OpenVPN 2.4 or higher version, OR block "IPv6 layer" in Eddie's "Preferences" > "Networking" window). Kind regards

So it was a totally different problem, please do not hi-jack threads otherwise confusion will reign. Kind regards

@OmniNegro Hello! Each time you revoke and issue new certs/key pairs, please remember to log your account out and then in again (from Eddie main window), a necessary step to tell Eddie that he must download again pairs. If you use profiles generated by the Configuration Generator, remember to re-generate new ones, or at least the new client certificate and key, and discard the old ones. Kind regards

Hello, and yet the same bug blocked client certificate/key generation: solved. Can you please test and confirm? Kind regards

Now I am unable to login on Android Eddie. Please check Not reproducible, please open a ticket at your convenience and attach OpenVPN log (get it from the "Log" view: on the corner you have a "Share" icon). Do not hijack thread, let's keep it clear that the problem is resolved. EDIT: if you generated a new certificate and key pair for your account, please try again now (check next message too). 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. IMPORTANT: you also mention different problems (access to web sites etc.) which are probably different and separate and that we do not reproduce. For them, please open a ticket. 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

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