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

Hello! This is a Mono problem: it tried to deallocate memory which was already free. libgdiplus (a Mono library) is the culprit, see here: Please feel free to update the thread after you have upgraded Mono from 4.8 to 5.x to see whether the crashes persist or not. Kind regards

Hello! It's an Eddie bug which checks IPv6 routing even when IPv6 routes are not pushed (our servers do not push IPv6 routes to OpenVPN versions older than 2.4 because such versions had various issues with IPv6). The bug is resolved in Eddie 2.17beta. If you don't feel like testing a beta version, the quick ,alternative workarounds are: 1. open "Preferences" > "Networking" from Eddie main windowset "IPv6 Layer" to "Block"click "Save" 2. upgrade to OpenVPN 2.4.x and don't touch Eddie IPv6 layer configuration. Solution "2." is recommended because it allows you to use IPv6 from AirVPN servers. Kind regards

Hello! When you wish to connect to the same server multiple devices simultaneously and using the same account, please make sure to use a different certificate-key pair on each device, so that OpenVPN daemons will be put in condition to handle the situation properly. Please see here for full instructions: https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs Kind regards

If you have a rooted device you would be able to perform many actions on your own, for example setting iptables rules to prevent leaks. However, at this stage, Eddie will not take advantage of this fact. Plans to run in a rooted environment do not exist at the moment, essentially because we have a roadmap with more pressing steps and aims (integration with AirVPN first and foremost) but we do not rule out anything about it in the future. Kind regards

@keikari Hello! That's expected and intended to prevent traffic leaks. It is a consequence of this event: When you get an unrecoverable OpenVPN error, you need to reconnect OpenVPN to some server. During this time, traffic leaks would be unavoidable. By catching the OpenVPN error and entering the "lock" status before it's too late, Eddie gives the user a chance to take precautions (if needed) with no time pressure to prevent leaks before trying a reconnection or deciding to un-lock. In other words, you might like to (for example) shut down programs whose traffic must not appear on the Internet as coming from your real IP address, before clicking "Disconnect" and therefore "unlocking the traffic". Compare Eddie and "OpenVPN for Android" behaviors in such a case: if you get a KEEPALIVE_TIMEOUT in "OpenVPN for Android", your traffic would start to flow outside the VPN. What's worse, if the device is unattended and the reconnection attempts fail, the traffic would continue to flow indefinitely. With Eddie, this does not happen and manual intervention is required (remember that in a non-rooted, standard Android system, firewall rules can't be set). We deem it as the most appropriate behavior as a traffic leaks prevention "best effort". Kind regards

An update (2.17.2) that addresses the issue is available now.

Hello! We're very glad to inform you that a new 1 Gbit/s servers located in Montreal (Canada) is available: Lacerta. The AirVPN client will show automatically this 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"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Lacerta 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 as usual in our real time servers monitor: https://airvpn.org/servers/Lacerta Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

For the other forum readers: yes, because some iOS 12 bugs involving even VPN usage have been fixed only recently, AND some openvpn-connecrt issues that you can experience under iOS 12 are still persisting, Please read here: https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ For the readers again, one of the reasons for which Croco says that seamless tunnel is useless is because Apple policy states that various Apple applications/services traffic will go outside any VPN tunnel in any case (see in the same above linked page the question "If my OpenVPN profile uses redirect-gateway, does that guarantee that all of my network traffic will be routed through the VPN tunnel?"!). It's important that you know all of the above. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.17beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OSClick on Other versions Click on Experimental Look at the changelog if you wishDownload and installPlease see the changelog: https://eddie.website/changelog/?software=client&format=html

Hello! That's not a problem since you can register in our service an unlimited amount of accounts without entering any single personal data, so there's totally no point in discussing it under a privacy, security or whatever point of view Even the time you need to register an account is negligible (15 seconds? maybe 10?). So let's not waste time to discuss on this trifle. Basically this method provides a couple of good things if compared to your method: - the buyer can rescue the voucher more quickly if he/she loses it - we can handle frauds more quickly Kind regards