Staff

Any update on this Air? It's been a week and still unreachable. Ill add to this in the fact that it doesn't effect me as there are plenty of other servers available to chose from. I however find it strange that Air have let this go on for so long. They are normally on top of issues like this. Hello! We're very glad to inform you that a replacement server is now operating and under internal testing. Kind regards

Hello, we wish and we need to distance ourselves from such a behavior which can even imply a criminal infringement in the EU. Events like the one discovered by Mike Kuketz may cast a general climate of distrust in a delicate sector which needs first and foremost customers' confidence. Nowadays VPN "market" is polluted by shady services. Sometimes you can't even know the owners or the running company behind a service. We are confident that fiscal, legal and technical transparency of AirVPN, as well as high standards both on consumers' protection and privacy fields since the end of 2010, will allow our customers and non-customers to discern honest professionals from anybody and anything else. We have always and only released free and open source software for public scrutiny and we have always supported a variety of privacy enhancing services in fundamental ways. For example, today we contribute to run about 7% of all the existing Tor exit nodes in the world. https://airvpn.org/mission Kind regards AirVPN Staff

Hello! Thank you for the information. The whole part pertaining to auto start and auto connection at boot or reboot has been completely rewritten on Eddie 2.1. Together with other, several changes, we should be able to release a first public beta for Eddie 2.1 at the very beginning of February. The rewrite aims to resolve various issues at boot including the one you experience. We see anyway that even OpenVPN for Android and openvpn-connect fail regularly to reconnect at boot on specific devices or on specific events, and we see how it's a general issue on different devices with different Android versions. Everything is being kept into account to make such issues limited to as few devices as possible. Kind regards

Hello! Probably it's just the same, but you don't see the disconnections because OpenVPN for Android tries to reconnect every 2 seconds, while Eddie locks the communications and requires manual intervention. In such cases, OpenVPN for Android can cause traffic leaks outside the tunnel while Eddie will not. In the next Eddie version we will probably add an option to disable best effort leaks prevention and allow leaks similarly to OpenVPN for Android, since it has been widely required. Communication lock will be enabled by default and a user can opt-out only. However, if you see from the log that Eddie keeps really less stable connections, let us know and let's compare both apps configurations (protocol, port, entry-IP address, IPv6 over IPv4 enabled or disabled, OpenVPN engine (in OpenVPN for Android you can use 2.5 or 3, while Eddie uses directly OpenVPN 3). Kind regards

Hello! If you resolve a country or a continent or a planet name to determine which VPN server the system will connect to, what you experience is not a bug. When you connect multiple devices with the same key to the same OpenVPN daemon, only the last one receives properly packets, and will cause a disconnection to all the other ones. Not only this is not an OpenVPN bug, but this is a very appropriate and correct behavior: the opposite would be a real catastrophe! Each computer can't know what any other is doing, unless you query Air API to determine the status of your account and make connection decisions accordingly. However, to connect multiple devices to the same servers, we already offer the option to use multiple client certificate/key pairs by the same account: https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs The other problem you mention. i.e. that a VPN server which goes down is still the "best" server according to some FQDN, is due to TTL. Actually, our authoritative DNS update the records every 2 minutes, but TTL is 1 hour, so on average you might have some DNS server updating the records after 30 minutes. Now that you know that this is not true, let's go deeper into the matter. An OpenVPN daemon runs always in the same core of a CPU. Even with AES-NI supporting CPUs, it's impossible, with our ciphers, to squeeze the full bandwidth we have available. Therefore, some sort of balancing becomes necessary. Last year we implemented a new balancing system which turned out to work very well. Each VPN server runs as many OpenVPN daemons as possible (according to the CPU cores amount), and each daemon lives in its own private subnet. Servers welcome OpenVPN clients at kernel level by sending them to the OpenVPN daemon which is running in the least loaded core. It was a huge improvement when compared to the previous, relatively rudimentary in comparison, load balancing. In this way we have been able to break the previous 900 Mbit/s limit on a single server (we touched around 1.7 Gbit/s on a server with hundreds of connected clients). Therefore, when multiple clients with the same pair connect to the same VPN server, they might have no problems if they are sent to different OpenVPN daemons. However, the likelihood that it happens when such connections occur at the same time is very tiny, because load core competition can cause a core supremacy change in a longer time, given the redundancy of our infrastructure. Anyway, it's not the correct approach, as you experienced. Our users who want to achieve the purpose need therefore to take care, as it is perfectly normal and somehow even trivial, of their own devices by managing correctly the client pairs. It's a 30 seconds job in general and we provide all the necessary tools with an extremely comfortable graphic interface, both on our web site and in our free and open source software for Android, Linux, Mac and Windows. Kind regards P.S. We fixed the typo in the thread ("ad infinitem" --> "ad infinitum")

Hello! The digital content delivery in Amazon Prime Video (conditions might vary for other Amazon related content or products delivery, we don't know) is tied to an account. If your account is born in some country in Europe, it will make no difference to connect from any USA location: the account can access either the Prime Video content of the country it was born in, or no content at all in specific cases. To access USA restricted content, you need an account created in the USA and connecting from AirVPN (or the USA residential ISPs). Kind regards

Hello! You can run Tunnnelbick for example, instructions are included in the Mac page https://airvpn.org/macosx If you close Eddie improperly, it will have no chance to restore system settings, but it will do it at the first proper shut down. If something goes wrong, check your DNS settings: it's the most common cause of apparent loss of connectivity and it can be fixed in a few seconds. You don't need to reinstall the whole system to set DNS properly. Kind regards

Hello! Probably the most direct solution is selecting specific servers sets on each machine or different FQDNs on each device. An automated solution from us is unlikely. Say that you connect to server A with some cert/key pair. Another machine of yours connects to the same server A with a different pair. If we banned the new machine from connecting (either at server level or (even worse) at client level by intrusions on your settings) we would be adding an intrusive feature which is unwanted by many users. Probably unacceptable especially when you consider how easy is avoiding this problem with your own mind. Kind regards

Hello! YES, the script rewrite for BSD looks like a perfectly suitable solution. Kind regards

Hello! Additional updated information: with the latest implementation of load balancing system, connecting to different ports does not necessarily imply connection to different OpenVPN daemons (it's the load balancing system that decides which CPU core and therefore which OpenVPN daemon you will be "assigned" to) so this method might not work anymore. Therefore, setting different keys for different devices is now the only "guaranteed working" solution. Correct, this limitation stays in any case. Kind regards

Hello! OpenVPN for Unix-like systems can't process the DNS push, so you need to process them by yourself. Since OpenVPN allows execution of your own scripts, some Linux-related ideas (they need resolvconf or openresolv, or systemd, which luckily has never spread into *BSD systems) are here: https://wiki.archlinux.org/index.php/OpenVPN#Update_resolv-conf_script In general: a script launched by OpenVPN event "up" (launched by OpenVPN directive "up") finds the DNS push from the server, stores the current DNS settings, and change the system DNS according to the push. A script at VPN event "down" (triggered by directive "down") must restore the previous DNS settings of the system. Kind regards

Hello! But that's exactly what happens in our service. Check the pushed DNS by the OpenVPN server and make sure that your client takes care of the DNS push (of course our software "Eddie" takes care of it). Having DNS and VPN gateway addresses match will make attacks based on DNS hijack through route-injection doomed to fail (this is a vulnerability which affects as far as we know almost all of our competitors). Kind regards

Hello! IPv6 problems lead to connection failures when clients try to connect with IPv6 layer unblocked. Nunki will stay down until the datacenter does not restore IPv6 connectivity to Nunki. If such connectivity is not restored within one week from now, Nunki will be withdrawn and then replaced by a different server, also located in the UK of course. Kind regards

Hello! Thank you. It sounds like a bug. Are you running version 2.16.3 or 2.17 beta? Kind regards

Hello! Do you close Eddie properly before you shut down the system? Kind regards

Hello! That's an unexpected behavior. Can you please test: blacklist a countryselect "Exit" menu itemrestart Eddie and verify whether the country has remained black listed or not? Kind regards

Hello! You can autostart Eddie at device boot ONLY through an imported profile. Please consider that it's Android which decides when to launch autostart registered application, and that will normally happen even after the connection to some network is active, so you will have regular leaks. You might consider to disable any connectivity before shutting down the device to mitigate the issue, and bring networking back up only when bootstrap has finished. Therefore, a manual intervention is needed in any case. Master Password is not considered by us a design flaw but a key security feature, especially in devices which are more prone to be stolen or lost around. Kind regards

Hello! Please make sure that you're running Eddie 2.16.3 or higher version (check by selecting "About" menu item). Then, please log your account out and in again (through Eddie main window). A new combo box allowing you to pick any of the current certificate/key pairs should appear just under the credentials fields. Kind regards

Hello! From your description Eddie just started. Since you say that you had launched Eddie an hour before, a possible chain of events is: Eddie started, Eddie crashed, Eddie re-started. Maybe the whole OpenVPN library was brought down, maybe not (in the first case traffic leaks would have been unavoidable). Do you have the option to take a logcat? If so, please send it to us in private (open a ticket) to protect your privacy. We have edited the log you posted for the same purpose. https://developer.android.com/studio/command-line/logcat Kind regards

Hello! If OpenVPN can not maintain the connection and needs to quit, Eddie must lock communications before OpenVPN quits. Eddie features the most effective, best effort leak prevention currently available in any OpenVPN 3 based application running in an un-rooted Android system. The leak prevention system has been thoroughly tested in months of heavy usage by several hundreds of beta testers, but if you find any missed lock do not hesitate to report. Kind regards

213 servers support IPv6, 10 servers do not. The post with the list has been linked previously by giganerd. If you find any issue with IPv6 in any of the 213 servers supporting IPv6, please inform us at your convenience. Kind regards

You might've disabled the geolocation feature in your browser. Unsure about Lich. If Staff said there are issues with it which are out of their control then wait a few days and see if it gets resolved then. AFAIK the only server definitely without an IPv6 prefix is Kitalpha in Switzerland. Staff posted in another thread a list of all servers not supporting IPv6. Lich is not one of them. Hello! We inform you that Lich did have IPv6 support, but it does not have it anymore. We are waiting for more info from the datacenter to understand why their infrastructure suddenly stopped working with IPv6 and act accordingly. Lich has quite a good connectivity so we might keep it even if IPv6 is not restored in a reasonable time. Kind regards

Hello! The name can not be resolved: please check the DNS settings. Also keep in mind that VPN DNS can be accessed only from inside the VPN. Kind regards

Hello! Error 111 means "connection refused" and you get that error when packets from the Internet through our VPN server reach your node properly and are actively refused. The most common cause is a firewall dropping packets. Kind regards

Hello! Please try the following settings: - from Eddie main window select "Preferences" > "Networking" - set the "IPv6 layer" combo box to "Blocked" - click "Save" Alternative solution: upgrade to OpenVPN 2.4 or higher version. Explanation: OpenVPN versions older than 2.4 do not handle IPv6 properly. So our servers do not push IPv6 routes and related directives when they detect older versions, in order to not break retro-compatibility. However Eddie (for a bug in 2.16.3, fixed in 2.17.2beta) tries anyway to check the IPv6 route in the tunnel and it obviously fails. Kind regards