Staff

Hello! Very strange, we can't reproduce the issue in any way. Everything appears fine on several devices we tested. Everything is correct even in the account "Client Area". Kind regards

Hello! We can't reproduce the issue: we see no difference between "Quick" and "Server" connection views reports. However we are not sure we have understood correctly what you mean. Would you like to elaborate? Kind regards

Thank you very much for your feedback and thorough report. ProMIND thanks you back. Understood. You talk about two separate issues. They are both under consideration for a resolutive implementation in a future Eddie version. In the first case, it's the OS that revokes from any already running VPN application the permission to operate the VPN connection when another application instantiates the VPN class. The different behavior you noticed is confirmed and is caused by the fact that Eddie instantiates VPN class at launch or at focus, and not when a VPN connection is required by the user. The second issue requires an implementation from scratch in order to catch new kind of events and take actions accordingly. It has been planned as well. In the meantime, always remember (we write it for the readers too) that running in parallel multiple OpenVPN based applications (or multiple OpenVPN instances) is a risky business on any system if you don't know exactly what you're doing. Kind regards

Hello! The Pirate Bay remains accessible from a significant portion of our infrastructure. Please check here: https://airvpn.org/routes to have an updated report and immediately find suitable servers. Kind regards

Hello! Unfortunately not, we're terribly sorry. Kind regards

Hello! We can reproduce the issue on Windows. On some Windows machines, but not all of them, when IPv6 over IPv4 is active, micro-routing is no more possible. Interestingly, any other system (Mac, GNU/Linux, Android, iOS), does NOT suffer this problem, even when IPv6 over IPv4 is active of course. Considering the above, we think that micro-routing is just fine and we suspect that something goes wrong when Windows prefers DNS6 over DNS4. We are moving this thread to the "Troubleshooting" forum because this issue has been already reported in the past by another user, but at that time we failed to reproduce it. Eddie for Windows developers will be informed too. Thank you very much for your thorough report. Kind regards

Telus is just as bad as Bell and Rogers. You are not alone in this, happens to everybody in Canada.(Vancouver Toronto Montreal etc.) Yes they mess with VPN traffic....they "don't like it". Hello! If you set the following connection mode: - entry-IP address 3 - protocol TCP - port 443 you will make OpenVPN fingerprint non-detectable, not even with DPI. Thus you will dramatically lower the likelihood that they can detect your traffic as "VPN traffic". Also remember to rotate servers periodically to avoid high volumes of traffic to/from the same IP address. Kind regards

So, is this option possible and if not, planned? English is just better when it comes to IT terms... Hello! Yes, it's possible and its implementation is planned. Kind regards

Hello! Thank you for your feedback. We are aware of the issue you report. It will be fixed very soon. Kind regards

Hello, we can't reproduce the issue for the web sites in Italy you report. The route check seems fine as well. Please make sure that your system queries VPN DNS (it happens by default with Eddie anyway) because some of the web sites you mention are under geo-routing. If the problem persists, can you please list the VPN server(s) you experience this problem on at your convenience? About amazon.com, on the contrary, we confirm some problems which seem related to our routing to make Amazon Prime Video accessible. We are investigating. Kind regards

But what about streaming? Hello! BBC iPlayer is inaccessible from our infrastructure. Netflix USA is fine from all servers. Kind regards

Hello, when you wrote "two days", you meant "two days ago", right? If so, something is not right: please open a ticket at your convenience to the "Sales" department. We will examine the issue to understand the cause of the problem and we will gladly fix it. Kind regards

Hello! That's puzzling then. Try to purge the whole Eddie installation and re-install it as a last resort. Kind regards

Hello! Currently it is not planned, we're sorry. The app is designed to work with limited privileges and is thought for the majority of Android devices and users. On the other hand, if you root a device, nothing prevents you to set proper firewall rules to implement a robust leak prevention. Kind regards

Hello! Modification of the system packet filtering table achieves a real, theoretically optimal, leak prevention. Root privileges are required to modify the table. You (and as a direct consequence your apps, including Eddie) do not have root control of your Android device. You're just a normal user, at least on un-rooted devices. Kind regards

Hello! We confirm that the app is fully compatible with nVidia Shield TV. It has been thoroughly tested on an Shield TV with Android 7. Did you try to install the apk with a side load? If so, which problems did you experience? If you looked for the app in the Google Play Store, it's normal that you did not find it, since we are still waiting for the revision by Google (applications for TV must comply to an additional set of rules). Kind regards

Hello! You have not deleted the default.xml file. Kind regards

Hello! The "public" bootstrap servers have been recently blocked in China (only in some limited areas at the moment). We have ways to circumvent the block. Currently you can connect because Eddie can retrieve the servers info from your HDD. In the future, you might need to re-bootstrap Eddie. In such a case: 1) if you have followed LZ1 advice, restore the option to the previous settings, so that you get again the prompt for the bootstrap server 2) open a ticket to receive a random, secret bootstrap server URL to enter in the prompt Kind regards

Hello! Please use the correct terminology. A crash never enters into play. It is possible, but it will unavoidably cause momentary or permanent traffic leaks, as explained above. Adding the option would be a deliberate, intentional implementation of a security flaw in the app, so we must evaluate it carefully. The "best" effort would no more be "best", even though that would be a user's choice. In the meantime, but only if traffic leaks are not a cause of concern for you, you might consider to use "OpenVPN for Android". Kind regards

I guess the question then becomes WHY did the Eddie Library become invalidated? Or, if the cause and effect is the other way around, WHY did OpenVPN3 Keepalive time out? Hello! UDP is connectionless. In order to keep the the session alive the parties must "ping" each other (inside the tunnel). A KEEPALIVE_TIMEOUT occurs when during any given time frame one of the party does not receive any reply to any of the previous "pings". OpenVPN solves brilliantly any UDP (and other, such as packet re-ordering) potentially related problem so you have UDP efficiency without UDP issues for a stable communication: you have re-ordering and "other side awareness" (so to speak) with a connectionless protocol. In our service, the parties send each other a ping every 10 seconds, and if no ping is replied in a 60 seconds time frame, a party assumes that the other one is no more there. Of course you can connect in TCP. In such a case, aforementioned OpenVPN smart functions are not necessary, everything is handled directly at another layer (at TCP level), at the price of a performance hit (unavoidable if you're in a network blocking or shaping UDP). Kind regards

Hello! Something terribly wrong happened with the configuration file, caused perhaps by a bug which has been detected and fixed in Eddie 2.17 beta (if the mentioned bug is indeed the cause of the problem, upgrading will let you prevent the problem to re-occur). While Eddie is not running, delete (administrator privileges required) the following file (NOTE: you will lose your settings, so you will need to re-enter your credentials and custom settings at the next run): C:\Program Files\AirVPN\default.xml At the next run Eddie will create a new configuration file with default settings and the problem will be sorted out. Kind regards

Hello! We re-publish here below the ticket reply for readers' comfort. ======= Hello and thank you for your choice! It's not a crash at all. Eddie locks the connection when a non-recoverable error in OpenVPN is going to cause traffic leaks outside the VPN, according to the philosophy "better safe than sorry". When the above occurs, Eddie will prevent leaks by locking communications and provide the user with the ability to close applications whose traffic must not be leaked before the user himself/herself decides to unlock the network. In particular, in your case the error that caused the lock was the following one: OpenVPN3 KEEPALIVE_TIMEOUT: Eddie Library Session invalidated: KEEPALIVE_TIMEOUT When you get a KEEPALIVE_TIMEOUT, and you're still successfully connected to your physical network (WiFi, mobile...), communications to the server have become impossible. If Eddie did not lock communications promptly, your device would start to send out packets out of the VPN tunnel. In such cases, all OpenVPN applications for Android will allow leaks of traffic, while they retry to re-establish a connection, except Eddie. The exclusive feature could appear annoying but it will literally save you from dangerous situations, since our service is primarily aimed to keep a reasonably strong anonymity layer under the limitations enforced by the Android system. Of course we do not enforce the usage of Eddie to connect to our service. You may for example run "OpenVPN for Android" or "openvpn-connect" and you will not have to manually intervene in the aforementioned cases, but you must be aware that you will have traffic leaks if similar errors occur, during all the time between the disconnection and the re-connection (several seconds, OR PERMANENT should the server on the other side go down). Kind regards AirVPN Support Team

Hello! The imbd.com problem has been thoroughly discusses and it does not depend on us. If you have read the previous thread you now know the source of the problem. Currently the main problem is the block at authoritative DNS level, on top of other wrong settings of theirs (which anyway play their role as you can see from the failures reported by specialized services which are mentioned in the thread). However, you also mention wikipedia.org etc., which we do not detect any problem with, at all. Have you experienced this block on some specific server? Does your system query VPN DNS or some third-party DNS? Note: we see that wikipedia.org does not allow some writing functions when you connect from VPN or Tor, but that's a general limitation which is not aimed specifically against AirVPN. Kind regards

Hello! Please test the following settings: from Eddie main window select "Preferences" > "Protocols"untick "Automatic"select the line with entry-IP address 3, protocol TCP, port 443, and click "Save"test again connections to various servers in various locations Kind regards

Hello! You need to put some string in the "e-mail" field (otherwise we would face some challenging technical problem with IPB, because accounts must be able to log in to the board even by using the e-mail address as username) but you don't need to enter a valid e-mail address. If you enter an invalid e-mail address, or a disposable one, remember that the function of "password reset" will not work, of course. Other than that, you will not receive some courtesy e-mail for tickets (if any) so it's not a big deal to not have a valid e-mail address provided that you never forget your account password. Kind regards