Staff

Hello! They are not able (at the moment) to block AirVPN. They try to do it with a different method which is specific against Eddie and not against OpenVPN. To bypass this block you need support from our support team (or just don't use Eddie). Bypassing the block with Eddie can take just a few seconds. Note: we will split this thread because your and our last messages are off-topic. Kind regards

Apple forbids and fights free and open source software on its store and at the moment we have no plans to release closed source software. On top of that Apple underlines that any Apple application traffic can bypass any VPN anytime. Before entering development in such a locked, dangerous and somehow contrary to our mission environment we need to consider every aspect carefully. Kind regards

Hello! We're glad to inform you that we plan to keep serving VPN even from the Vancouver area. We are testing a new provider to check if it fits our requirements since the current one does not. Kind regards

Hello! Yes, we're glad to inform you that this is planned for version 2. You will see something new during October. Kind regards

Thank you! We are proud to see a confirmation to our tests. At the moment we see that Eddie, on equal terms, is much more battery conscious than OVPN for Android and openvpn-connect. You can expect a 15-20% longer battery life on the same footing. Kind regards

Please contact the respective VPN services customer care. Eddie is based on OpenVPN 3 and OpenVPN 3 is configured by the profiles provided by each VPN service. It's not up to us to provide support for what you mention. Kind regards

Hello! A simpler setup with the same anti-blocking effectiveness can be achieved with the following connection mode which does not require any additional SSL tunnel: - entry-IP address 3 - protocol TCP - port 443 In the Configuration Generator, please tick "Advanced Mode" to display all the available connection modes. If you run Eddie on a desktop computer, connection modes are available in "Preferences" > "Protocols" and they are selectable after you untick "Automatic". Kind regards

Hello! We're glad to inform you that Eddie can work with additional SSL tunnels as usual but you don't need them with tls-crypt. tls-crypt already encrypts the whole OpenVPN Control Channel. Combining tls-crypt with TCP, you will have the same result without the additional burden of the SSL tunnel and in some cases you will not even need TCP (making OpenVPN more efficient). This has been tested from China by a dozen of users living there (we thank them for their thorough tests and reports) and tls-crypt to port 443 in TCP is able to bypass blocks always. That said, failure to connect to an established SSL tunnel to our VPN servers may be caused by some misconfiguration that deserves to be investigated (a trivial example, you generated an UDP config), but in any case you might like to get rid of the additional SSL tunnel which only adds burden to your Android device without adding any significant security layer. Remember that any obfuscation is weaker than real encryption of the whole Control Channel. We have chosen a stronger method than simple obfuscation and that's the reason for which our VPN service works where most other competitor VPNs fail. A special note on the remark you made: "VPN immediately fails upon connecting to my SSL tunnel profile, and then proceeds to leak all of my traffic anyway instead of warning me and keeping the network locked.". First of all, you ARE notified, because Eddie sends a notification of "Disconnected". Second, if no VPN tunnel has ever been established there's no way to pause or lock the VPN or the network (at least on an un-rooted device). This is an obvious limitation on ALL systems in which the app does not have root access and you will find the exact same limitation on any other OpenVPN based app for Android. The huge difference between Eddie and, say, OpenVPN for Android you mention, is that Eddie can prevent leaks in many situations under which OVPN for Android fails to do so. For example, test Eddie under the condition of an ongoing VPN failure for KEEPALIVE_TIMEOUT or TCP EOF. You can simulate this condition (which will occur when communications to the VPN fail definitively for any reason, a common situation in mobility) by revoking your client certificate/key pair and then forcing a disconnection from your account "Client Area". You will see that Eddie will properly lock, and prevent leaks, while OVPN for Android will not. Kind regards

Hello! That was a painful but due choice. In Android 5.0.1 known bugs in Android ConnectivityManager may affect network pause/resume/failover. Because of such bugs, we would have been unable to release an application capable of robust leaks prevention in various circumstances and we might have met additional problems. Samsung phones with Android versions older than 5.1 also suffer of additional bugs affecting VPN operations and VPN DNS. Kind regards

Hello! We are very glad to inform you that Eddie 1.0 for Android systems has been released. Eddie Android edition is a free and open source OpenVPN 3 GUI released under GPLv3. Source code is available here: https://gitlab.com/AirVPN/EddieAndroid Main features: Free and open source application based on OpenVPN 3Only official application by AirVPNRobust, best effort prevention of traffic leaks outside the VPN tunnelBattery-conscious applicationLow RAM footprintOption to start and connect the application at device bootOption to define which apps must have traffic inside or outside the VPN tunnel through white and black listOpenVPN linked against mbedTLS libraryAndroid 5.1 or higher requiredfully localized (current available languages: English, French, Italian, Spanish, Turkish)The traffic leak prevention has proved to be stronger than the one implemented in OVPN for Android. A thorough OpenVPN error detection allows Eddie to "lock" the network in case of unrecoverable disconnection (for example when communications to the VPN server get broken). Direct link to the Google Play Store: https://play.google.com/store/apps/details?id=org.airvpn.eddie Direct link to download Eddie Android edition from our Eddie web site: https://eddie.website/repository/eddie/android/1.0/org.airvpn.eddie.apk A quick tutorial is available here: https://airvpn.org/topic/29660-using-airvpn-with-eddie-client-for-android/ The APK will soon be available in F-Droid repository too. This is a starting point: development of a new version which includes stricter AirVPN integration is already ongoing and we are confident to provide you with updates in a very near future. Kind regards and datalove AirVPN Staff

Hello! First of all, it should not crash: we have worked hard to remove the numerous crashes and have a very stable application. Removal of Mono and Java rewrite/porting have been decisive and starting from RC5 we do not detect anymore the plethora of anr and crashes which plagued the previous versions. Anyway, if a crash occurs, it depends on its gravity: if the whole OpenVPN library is brought down, then Android will soon re-establish connectivity and your traffic will go outside the VPN. In every other case, for example if the communications between your device and the VPN server are interrupted, or your ISP renews the lease, you will not suffer leaks, because Eddie will either pause the VPN or "lock" the network. Kind regards

Will full AirVPN integration be in Eddie for Android when it releases from beta? Hello! The first integration is planned for version 2.0 coming out during October (initially as a beta version). Eddie Android edition 1.0 stable has the features you may have seen in RC5. The integration is particularly important because it can make Eddie work (at least with AirVPN) even in a device without SAF, so we are pushing for a quick development. Kind regards

Allow LAN/Private ticked indeed in both instances, leaving but one difference between the two versions over here, namely the empty Addresses Allowed box. Which your original answer kindly straightened out. Yours gratefully, PS - perhaps Little Snitch obfuscates these here LAN doings Hello! Yes, the problem must lie elsewhere. Again, we wish to underline that you must ignore the previous answer (it was deleted, but clearly the deletion arrived too late). The reason is that those options influence Network Lock behavior in its entirety, and NOT only in relation to the allowed addresses. A recommendation to the devs to cause Eddie to issue a warning when using those options has been already sent. Kind regards

Hello! Eddie Android edition has a much better leaks prevention than OpenVPN for Android. When Eddie Android edition exits the beta stage (stay tuned during this weekend...) it will be available for Android TV too. However, beware: some Android TV systems miss the SAF which is necessary to Eddie for the file chooser. Anyway if OpenVPN for Android runs in your Android TV device, Eddie will do too, because even OVPN for Android needs the SAF. In the future, Eddie will run even in Android TV versions featuring no SAF. Current status of Eddie Android edition: https://airvpn.org/topic/26549-eddie-android-edition/ Kind regards

Hello! By enabling "Allow LAN/Private" in "Preferences" > "Network Lock" Eddie window you already allow Bonjor protocol IP addresses. Since you experience a different behavior by Eddie 2.13.6 and 2.16.3 on this matter, would you please post two system reports generated by those Eddie versions, to let us investigate? We guess that you have kept the same configuration in both cases, is this correct? Kind regards

Hello! the quickest and safest solution is running the VPN client on the tethered devices. We provide five, simultaneous connection slots for each account. Kind regards

@rohko Yes, the important change to tun0 by the OpenVPN script is the DNS global scope and this is sufficient to have your system use only the VPN DNS. Eddie 2.17beta should not be used in your (and any similar) environment until the detected bugs are not resolved because you can't even patch the issue with the OpenVPN scripts, we're sorry. After all this is a beta version so it's not upsetting that bugs can come out. Please go back to Eddie 2.16.3 and keep using OpenVPN scripts which work impeccably. Eddie developers have been already informed, of course. Kind regards

@keikari Hello! In general, tethering through a VPN is not allowed by Android. See also: https://forums.openvpn.net/viewtopic.php?t=13183 James Yonan wrote: Android doesn't allow tethered connections to route through the VPN. This is an Android rule that applies to all VPN apps running on non-rooted devices. This is done for security, out of concern that if a malicious individual was able to get access to your tether, they could piggy back onto the VPN connection. A better, more secure solution is to run a VPN client on the tethered machine. If you run a rooted device, you should be able to bypass this limitation, see here: https://forum.xda-developers.com/showpost.php?p=33749904&postcount=10 but consider the security hazard mentioned by Yonan. Kind regards

@rohko The first test Here the scripts are not executed: Eddie 2.17.2, for intended security purposes, sets script-security to 1. Your custom directive: script-security 2 ensures that your "up" and "down" scripts will be executed by OpenVPN but they are not. The fact that in Eddie 2.16.3 you did not experience this issue might be related to a wrong bypass of the aforementioned directive. We will investigate with Eddie devs. The second test Here things become interesting. As you can see in the status printout, systemd-resolve acknowledges the DNS set by Eddie in resolv.conf and considers them as global DNS, according to the usual global DNS paradigm, as you correctly point out. However, you/we can see that 1.1.1.1 remains set for "ppp0" link. This implies that systemd-resolved works with "per-interface domain names".. Additionally, the Current Scopes of ppp0 are "DNS", while in tun0 they are set to "None". This cause a priority of names resolution toward the DNS specified in the ppp0 link: According to https://www.freedesktop.org/software/systemd/man/resolved.conf.html : DNS requests are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from systemd-networkd.service(8) or set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS servers listed in /etc/resolv.conf are used instead, if that file exists and any servers are configured in it. This setting defaults to the empty list. Again, you considerations are correct. This is an important "paradigm shift" from the global DNS (uniquely specified in resolv.conf) which allows to mimic the dangerous Windows DNS implementation (where there is no global DNS at all): since systemd 229, systemd-networkd has exposed an API through DBus allowing management of DNS configuration on a per-link basis. We will carefully consider this behavior with our techies. It appears (according to your last test, when OpenVPN is run directly) that the script handles correctly this case (no DNS for ppp0, from the output you pasted, and tun0 scope set to DNS) while Eddie doesn't. Thank you for the invaluable report, it will be thoroughly investigated to improve Eddie. In the meantime, can you please check the "DNS=" option in your [Resolve] section of your resolved.conf file in each of the tests (before and after each test) you performed and report back? Can you also test with DNS= option empty (remember to restart the service after you have saved the file) and check whether the problem is resolved with Eddie (leaving to Eddie the resolv.conf handling, without scripts of course)? With DNS setting left to empty, systemd will use nameservers specified in resolv.conf Kind regards

Hello, the servers are not compromised and this is not a coincidence. According to your description the final beneficiary received a payment from your credit card and from an IP address that's geo-located in the USA, so in the "not so sane" view of all or part of the payment chain you were using the card in the USA. Kind regards

@rohko Correct, DNS leaks do not exist in Linux. This is a different issue and must be investigated anyway, but it's not related to DNS leaks. How does Eddie handle DNS (check "Preferences" > "DNS")? Since you rely on that script to handle the DNS push, Eddie must not interfere and you can focus on why your script does not work. Make sure to set "DNS Switch Mode" to "None" in "Preferences" > "DNS". Alternatively, disable your script, enable DNS push handling by Eddie itself (try with "DNS switch mode" set to "Automatic") and check whether the problem persists or not. If it does send a full system report generated by Eddie and taken just after the problem has occurred, please ("Logs" > LIIFE BELT icon > "Copy All" icon > paste into your message). Kind regards

Hello! Eddie Android edition features OpenVPN linked against mbedTLS which is light and efficient. On the other hand, our Data Channel cipher (AES-256-GCM, but we are considering to make AES-128-GCM available) is heavy (security comes first) and OpenVPN runs in a single core. What is your box CPU exact model? Kind regards

@avpnhome Hello! 10.4.0.1 is reachable by DNS queries on Alphard (just remember that it will not reply to pings). The DNS server works fine, so we can't confirm the issue. Any other server for an additional cross check? Kind regards

Hello! Therefore it sounds like a totally different problem but without log or system report it's not possible to say anything more. Remember to always include them otherwise you might get random, useless help or no help at all. Also consider to open a ticket, our support team will assist you quickly. Kind regards

Hello! It's a different problem. In your case UDP packets are blocked. Please check any packet filtering tool both in your system and router. If the problem is not caused by any of those maybe your ISP is blocking UDP and/or OpenVPN. In such a case please test the following connection mode: entry-IP address 3protocol TCPport 443You can change connection mode in Eddie window "Preferences" > "Protocols": untick "Automatic", pick the appropriate mode (the related row will be highlighted in blue) and click "Save". Kind regards