Staff

Hello! With quick connect as well as manual server choice Eddie must fall back to TCP when UDP is blocked, provided that the user did not force UDP in the settings. Specifically, Eddie must try a connection over TCP to ports 443 if attempts in UDP to port 443 and 53 have failed. Can you please make sure that you have not forced custom configuration in "Settings" view? Please feel free to report back. About "Restore last profile at boot", can you also tell us your device and Android version? Kind regards

Hello! Eddie can't count on the options you mention since it must prevent leaks even in Android versions older than 8 (from 5.1 to 7.x). However, if you can start a VPN application at boot, the options you mention (in Android 8 or higher versions), when active and when the VPN application had already started at boot and never terminated during device usage (otherwise the block will not work anymore), should ensure an equivalent leaks prevention. We need a deeper experimental testing to confirm or deny. Currently we can not say with absolute certainty that your described setup leaks prevention is equally effective than Eddie lock method. Eddie can start at boot, when "Restore last profile at boot" is active, so the Android 8 new VPN related options umbrella can cover Eddie as well, but of course Eddie will super-impose its own communications lock in case of fatal OpenVPN connection error. Kind regards

Nice; but I wonder why that option is only available on Android, and not on PC, when Android is a more restricted platform (without root). Unless it is available, and I am missing it. Hello! This feature might be implemented in a near future on Linux systems and maybe Mac and *BSD. However, such implementation in Windows is challenging or, perhaps, impossible, unless you think of vicious, deranged solutions like code injections to bind binaries to a certain network interface. The cause lies again on Windows bad architecture: it does not even support features which are nowadays quite obvious in modern systems, such as multiple routing tables. Going back to GNU/Linux, thanks to cgroups, traffic splitting on an application basis is already available to all AirVPN customers, in the software "Qomui", developed and programmed by corrado, who is also a member of AirVPN community, in Python. Qomui has reached a very good integration with AirVPN. Please see here: https://airvpn.org/topic/26327-alternative-airvpn-client-with-provider-independent-double-hop-support-gnulinux/ 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). If you have this event 5-15 times a day, then Eddie saves you from traffic leaks outside the VPN tunnel 5-15 times a day. Kind regards

Hello! Different aim and scope and also a nice idea. It's based on Tor too, although scaled down so that a single tab of a single browser of your system communicates with a remote desktop acting as an interface to Tor network . If you use Tor (directly in your system we mean) you get a stronger anonymity layer, while with a VPN you can tunnel the whole traffic of your system. On top of that, you need to consider that with Tor or VPN you can run your own programs locally, which in many circumstances can be a nicer solution. When using a remote desktop not owned by yourself you also need to consider that end-to-end encryption with final services is performed by the remote desktop, and not by your system. So, those who have access to the sadd system may potentially have access to all of your "end-to-end" encrypted communications, because one of the ends is not your system but the remote desktop. Probably not acceptable in most circumstances. Kind regards

Hello! it looks like you still miss the point. Wireguard, in its current state, not only is dangerous because it lacks basic features and is an experimental software, but it also weakens dangerously the anonymity layer. Our service aims to provide some anonymity layer, therefore we can't take into consideration something that weakens it so deeply. We will gladly take Wireguard into consideration when it reaches a stable release AND offers at least the most basic options which OpenVPN has been able to offer since 15 years ago. The infrastructure can be adapted, our mission can't. We provided a list of missing features causing real, objective security flaws in Wireguard (when meant to provide specific features). We will expand them here below since it looks like you missed the huge implications of the mentioned issues. It's not a matter to "cover their asses" as you say. First, it's a matter of security. If you followed some basic IT security principle, you would know how wrong and dangerous a claim like the one quoted here above is. If you are really in the position to certify that "Wireguard is fine", then do it officially. If you can't do it officially, your words must be considered irrelevant, because they go against the claims of the very Wireguard developers themselves. Second, it is a matter of lacking features that are essential for any service which aims to provide a decent layer of anonymity. Wireguard, in its current state, does not meet our requirements. Here below, once again, some points which need to be considered and addressed: Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server. The impact on the anonymity layer is catastrophic;Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high;TCP support is missing (third party or anyway additional code is required to use TCP as the tunneling protocol, as you suggest, and that's a problematic regression when compared to OpenVPN);there is no support to connect Wireguard to a VPN server over some proxy with a variety of authentication methods. Kind regards

Hello, you don't need to link OpenVPN against OpenSSL. For example in Android we link it against mbedTLS. Kind regards

Hello! Please see here: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards

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