Staff

Hello! We're very glad to inform you that new 1 Gbit/s servers located in UK are available: Arion and Orbitar, respectively in London and Manchester. The AirVPN client will show automatically the new servers. If you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Arion and Orbitar support 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. Arion and Orbitar replace Algedi and Nunki, which will be withdrawn as they consistently failed to meet the quality of service we require. You can check the servers status as usual in our real time servers monitor: https://airvpn.org/servers/arion https://airvpn.org/servers/orbitar Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! The workaround has been deployed on every Air VPN server. Can you please test now? Kind regards

Hello! There is no way to recover/reset a Master Password which is used to decrypt and encrypt your sensitive data. You need to disinstall the app (so that all the app data are deleted) and re-install it. Kind regards

Hello! Thank you very much for the report. Under investigation. Additional information which can help us remarkably: brand, model and Android version of your device (included anyway in the Eddie log)Eddie log (in the "Log" view you can share log in various ways by tapping the "Share" icon)optionally, the logcat, if you know how to get it and you have timeKind regards

Hello! We have detected an issue related to IPv6 (and not tls-crypt) and Windows which breaks micro-routing on the client side. Micro-routing works just fine and the issue affects WIndows machines only, because of a peculiar behavior of Windows DNS implementation. Customers with anything different than Windows can ignore this message. Although the problem is WIndows-related on client side, we think we can patch it from the server side without harming Android, Linux, Mac etc. We are testing. If the tests are good, deployment on all VPN servers will not take a long time. We will keep you informed. Kind regards

Agree so my subject and original post is valid and it IS a bug as BOTH servers are getting disconnected exactly in sync Hello! It's an expected and correct behavior due to how OpenVPN and more in general the Internet work. See our previous reply for more details, it looks like you missed the meaning of it. Kind regards

Hello! Eddie is under a wide and deep "re-engineering" which needs some more time. A lot of work has been done anyway, and you will see news soon! Kind regards

@NickAtNight Hello! Is it possible to take a logcat from the machine you experience this problem on? The fact that you need to re-enter credentials implies that Eddie restarted (probably crashed) and a logcat could show the cause of the problem. Keep us posted! Kind regards

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