Staff

Hello! Unfortunately no dedicated effort by Eddie devs can solve this "problem". Eddie runs with your own privileges in Android, so there's nothing you can do against what the system administrator (which is not you) of your device decides to do. Rooting the device would give you back root access to it, however Eddie is thought for un-rooted devices, since rooting an Android device and maintain it is a procedure which is quite difficult for the average user. That said, the typical manufacturer which decided to freeze background apps (Samsung) provides you with the option to disable such a feature, so in this case the problem you mention can be solved in a few seconds. Kind regards

Hello! Yes, this is expected. It's the purpose of VPN lock: preventing leaks outside the VPN tunnel, within the limits enforced by limited privileges. You need to shut down apps before you start a new connection to prevent leaks. You can't prevent system apps traffic leaks, which would occur anyway in un-rooted devices. By setting system packet filtering rules in the Linux packet filtering table. This is possible only in rooted devices, though. By default Android devices allow only unprivileged access and you're not the administrator of your device. You can't therefore use a firewall to modify the Linux packet filtering table, or access directly Linux parts without passing through the upper Android layers. Yes, this will be possible in the next Eddie version. By disabling VPN lock Eddie will behave just like "OpenVPN for Android" or "openvpn-connect" and many other OpenVPN based applications of our competitors, allowing free leaks at any time. Disable VPN lock only when you can afford traffic leaks outside the VPN tunnel by any app at any time. Unfortunately not, for the same reason explained above: Eddie Android and you are not in control of your system. Kind regards

Hello! Use a profile (that you can generate with our Configuration Generator) and make sure that in the "Settings" view the option "Restore last imported OpenVPN profile" is enabled. If you reboot or turn off the device when OpenVPN is still connected through an imported profile, then Eddie will restart and reconnect to that last profile at the next device boot. Next Eddie version (whose first public beta release is expected on February the 15th) will let you handle multiple profiles at once and will let you generate profiles from settings (so you don't need to use the configuration generator in such cases). Kind regards

Hello! OpenVPN total overhead in routing mode (our setup, using tun and not tap) and with UDP as protocol is 69 bytes per packet (in reality with HMAC SHA-2 which we use it will be slightly more but that's negligible): https://openvpn.net/archive/openvpn-users/2004-11/msg00649.html With a packet, say, of standard 1500 bytes size, that's ~4.6% . Something else must enter into play in your case, because the overhead you report is largely unexpected. Packet retransmission (due to errors), important fragmentation are perhaps the first things to check. Kind regards

Hello and thank you for your feedback and suggestions, they are very much appreciated. We would like to explain why we can't meet all of your requirements. The remaining points are already implemented either in Eddie 2.0.1, Eddie 2.1 (next release), or will be implemented in the future. Good suggestions. thanks. This is extremely hard to implement because you can't really rely on ICMP on mobile networks. A single ping may take hundreds of milliseconds, especially in 3G networks, but even in 4G networks, so you might need hundreds of seconds to compile for all the VPN servers the round trip times with just a couple of pings to each of them. This will drain battery as well remarkably. And for what? A couple of pings in a mobile network, due to its nature, are not relevant. Here we have a different philosophy, since we consider the Master Password a basic security feature to protect your password and your certificates. You can anyway connect at device boot via a profile. Eddie 2.1 will be able to handle multiple profiles and even create profiles from the settings, no need for the Configuration Generator. About automatic AirVPN login, it's already implemented, maybe you have missed this feature. We consider it as a very friendly feature, since it's the only effective way to prevent leaks, which in mobility can be frequent. Anyway this option can be disabled in Eddie 2.1, for those who don't care about traffic leaks outside the VPN tunnel, even permanent leaks, due to their low threat model for example. This feature, available in Android 7.1 or higher versions (while Eddie is targeted even to Android 5.1 or higher versions), might not prevent traffic leaks outside the VPN tunnel during a disconnection-reconnection loop. OpenVPN talks to Eddie, not to Android directly. Then Eddie tells Android that something went wrong. No matter how fast Eddie (or any other app) is to inform the VpnService class, traffic leaks are possible, according to our developers. Again, it depends on your threat model: if you can afford the hazard you will be able to disable VPN lock. Thank you again and enjoy AirVPN! Kind regards

Hello! It's owned by M247. Kind regards

Hello! From the command line interface you can use the following option: --network.ipv6.mode=block Kind regards

Hello! Do you have the option to upgrade to OpenVPN 2.4.x? When our servers see version 2.4 or higher, they push IPv6 routes as well, solving the problem. Alternatively, you can test Eddie 2.17 beta (if you're willing to try a beta version) which fixes the bug. 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

Hello! We're very glad to inform you that a new 1 Gbit/s server located in New York City (NY, US) is available: Dimidium. The AirVPN client will show automatically the new server, while 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"). Just like every other "second generation" Air server, Dimidium 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 in our real time servers monitor: https://airvpn.org/servers/dimidium Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Japan is available: Taphao. The AirVPN client will show automatically the new server, while 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"). Just like every other "second generation" Air server, Taphao 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 in our real time servers monitor: https://airvpn.org/servers/taphao Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello and thank you! Anyone can just ask for a free trial period of three days by opening a ticket to the "Trial request" department. You can also send your request in a ticket. Eddie desktop edition is under a major revision and during the first/second quarter of 2019 you will see interesting news. Eddie Android edition development goes on as usual and version 2.1 public beta release is scheduled for the first half of February. What additional flexibility would you like to see in Eddie Android edition? Kind regards

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