Staff

Will this cause traffic to leak when the screen is off? Hello! No, it will not. Kind regards

Hello! The KEEPALIVE_TIMEOUT error is not recoverable since it implies a lack of communication between client and server higher than the maximum alive time (60 seconds in our service). After this error OpenVPN exits, so Eddie must lock before it's too late (i.e. before traffic starts to leak outside the VPN tunnel). Enable "Pause VPN when the screen is off" to enhance likelihood to not force lock in mobility. Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Vancouver (Canada) are available: Telescopium and Titawin. The AirVPN client will show automatically the new servers; if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). Servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Telescopium and Titawin 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. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Telescopium https://airvpn.org/servers/Titawin Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We are not convinced it's a risk. We know that current Wireguard release is experimental and the protocol is subject to change, as reported by Wireguard programmers in the home page. We will not use our customers as testers. Currently WireGuard also lacks TCP support which locks out a relevant percentage of our customers. We have already said that we are interested in it and when it is released as a stable version and properly audited we will consider it seriously. At the moment it is totally unusable in our infrastructure because it lacks TCP support, lacks dynamic VPN IP assignment, and (at least the build we have seen) lacks a strictly necessary security feature (verification of the CA certificate provided by the server, therefore the client can't be sure that on the other side some hostile entity is not impersonating a VPN server). And that would be a good thing under a security point of view because...?!? Remember that we have never liked IPsec because it works in the kernel space with a stack implementation which is poorly documented, while OpenVPN operates on userspace. Performance is irrelevant when security is the priority. There is no difference in power drain between, say, Wireguard client and our Eddie client. It's the cipher you use that is decisive, because it's the encryption and decryption to load CPU and need a lot of power. Ecnryption and decryption are handled by mbedTLS or OpenSSL, obviously, not by OpenVPN. You might see longer battery life with Wireguard or OpenVPN according to the cipher OpenVPN uses (while you can't change cipher in Wireguard). OpenVPN 3 has been updated a few weeks ago. OpenVPN is free and open source software released under GPL. There is no such thing as licensing controversy. Kind regards

Hello! The app is fully compatible with Google rules for Android TV but it needs to be approved. Quality check may take from 2 hours to several days according to our experience. In the meantime you can easily side load the application after you have downloaded it from our repository. Kind regards

Hello! Eddie has been tested and runs fine on a range of Android TV based systems, including Amazon Fire TV stick, nVidia Shield TV and Sony Bravia TV sets. Which issue have you experienced? Kind regards

Hello! We're glad to inform you that Eddie Android edition 2.0.1 has been released. Please go back to Eddie Android 2.0 thread for details, references, discussion etc. https://airvpn.org/topic/30774-eddie-android-edition-20-released/ Version 2.0.1 ensures improved Android TV compatibility and is compliant to strict Google Play Store rules pertaining to Android TV. Moreover, an important change to manage VpnService intent and a minor bug fix have been implemented. Please see the changelog for details. Changelog 2.0.1 (VC 14) - Release date: 30 November 2018 by ProMIND - [ProMIND] Created MainTVActivity class for Android TV leanback launcher - [ProMIND] Renamed class AboutActivity.java to WebViewerActivity.java. This new class is now used for external web sites and local html document to be shown within the app MainActivity.java - [ProMIND] Replaced start intent of external web browser with WebViewerActivity class in order to make the app compliant with Google's Android TV requirements VPNService.java - [ProMIND] complete rewrite of onBind() method in order to properly manage VpnService intents Kind regards

Hello, your ticket was replied just a couple of hours after you opened it. Support team replied 3 days ago, on November the 28th, asking for a system report. You sent back the system report only after you wrote this quoted message, i.e. after three days. Again support team replied after 3 hours detecting the problem (UDP or OpenVPN packets are blocked either by your system, router or ISP) and sent you suggested solutions for each one of the cases. For the readers: Kind regards

Hellio! imdb.com is perfectly accessible from nearly all of our VPN servers (except just 5 servers which are blocked by imdb.com or imdb.com authoritative DNS) as you also see from the route check page. https://airvpn.org/routes Intermittent problems did sporadically arise from misconfiguration of IMDB DNS as we and many other services have thoroughly explained repeatedly in the past, but that's an imdb.com DNS configuration problem, not ours, which affect everybody. Kind regards

Hello! With default settings Eddie accepts the VPN DNS push to allow your system to query the VPN DNS. Since each VPN server runs its own DNS server, querying the VPN DNS implies total encryption and authentication of queries and replies, as well as names resolution improved performance. You can tell Eddie to not use VPN DNS, or even to not touch your DNS configuration, in "Preferences" > "DNS". Set the appropriate value in the combo box "DNS switch mode" and untick "Check Air VPN DNS" if necessary. Note: advertisements are not allowed in forum posts and will be removed from message. Ads may also cause messages deletion. Kind regards

Hello! Currently Eddie Android does not force LAN routing to net_gateway, although this option is being seriously considered for Eddie 2.1. The solution you tried is appropriate but we have detected some unexpected behavior of OpenVPN 3: we are looking into the issue. Kind regards

Any reason when I use router tool, as suggested in the forum, it gives me 301 HTTP status instead of 200? It used to work for me till couple of days ago. Any further help would be appreciated. Thanks yelp.com is accessible from all of our VPN servers. 301 is just fine and means "Moved permanently" (yelp.com 151.101.36.116 --> www.yelp.com 151.101.12.116). Kind regards

Hello! This is normal and expected, due to how OpenVPN works, when both devices use the same certificate/key pair and connect to the same OpenVPN daemon. Just use different client certificate/key pairs on each device, Instructions can be found here: https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs Kind regards

Hello! That was planned, but we have postponed the release on F-Droid due to some rules in its policy. We will re-consider it in the future. Eddie apk is anyway available in our repository. Kind regards

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