Staff

@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

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Sofia (Bulgaria) are available: Apus and Grus. The AirVPN client will show automatically these new servers, while 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"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, they 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. Please note that these servers replace Fornax. Fornax has been withdrawn because its datacenter did not meet anymore our technical requirements. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! Correction, we can NOT reproduce the issue. We thought wrongly to have reproduced it because we made a foolish mistake, we entered a wrong network prefix. By testing exactly the network prefix/mask reported by you, the issue does not occur. However, we did not test under Fedora 28, but under Debian. Can you please enable "Log debug" in "Preferences" > "Logging", run again to reproduce the problem, take the log ("Logs" > "Copy to clipboard") and paste them into your message? We look forward to hearing from you. Kind regards

Hello! We can reproduce the issue. It looks like a bug and it occurs when you enter an IP address/mask instead of a single IP address. We can reproduce it on GNU/Linux. What is your Operating System? We are alerting the Eddie developers immediately for a fix in the next, imminent release. Kind regards

Hello! Eddie Android Edition 1.0 RC5 has been ported and rewritten in Java. No more Mono. It has been released just a few minutes ago, i.e a few hours after you wrote the review. Never say that we don't think about you night and day! Thank you for the massively favorable review, we will keep doing our best to deliver a 1st class service within, strictly within, the boundaries of our mission. Kind regards and datalove AirVPN Staff

Hello! We're very glad to inform you that Eddie Android Edition 1.0 RC5 (VC 8) has just been released. The application has been completely ported and rewritten in Java, Mono is no more used from this release on. Main features (compared to RC4): fix of fatal ANR issues while opening or scrolling log view, settings view and applications white/black lists caused by Mono librariesfix of crashes and ANR issues during application initialization caused by Mono librariesfix of fatal segmentation faults caused by Mono librariesfix of other crashes caused by Mono librariessmaller package size (approximately 60% smaller size than RC4)lower RAM footprint (approximately 30% lower footprint than RC4)improved detection of network status changes, OpenVPN warnings and OpenVPN errorsmore responsive user interfacenew panels with stats and information about throughput and connectionTurkish language localizationlonger battery life on equal footing (approximately +10% against RC4, +18% against OpenVPN for Android (*))(*) comparison made with OpenVPN for Android version featuring OpenVPN 2.5 linked against OpenSSL You can also read the changelog attached to this message. Just like RC4, Eddie 1.0 RC5 is also packaged with x86 support, as well as ARM32 and ARM64 of course. As usual Eddie is free and open source software released under GPLv3. Check the first post in this thread for source code URL and some more details. You can participate to the tests by joining the testing community in the Google Play Store here https://play.google.com/apps/testing/org.airvpn.eddie Alternatively, if you don't want to access (or you have no access to) the Google Play Store, the apk can be downloaded here: https://eddie.website/repository/eddie/android/1.0rc5/org.airvpn.eddie.apk Please keep testing and stress Eddie as much as you can! Any single report is important. Thanks so much to all the past and future testers! Kind regards ChangeLog.txt

Hello! In addition: some ISPs now provide IPv6 connectivity only (IPv4 is encapsulated in IPv6). In such a case, disabling IPv6 is not an option, but you can connect directly in IPv6 to every Air VPN server supporting IPv6 (all of them do with very few exceptions). OpenVPN 2.4 or higher is required. See also: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Kind regards

Hello! Although they were initially declared as temporary ones, we have received good feedback for them and we have no other servers in Arizona. If the situation remains good as it appears to be now, they are staying. Kind regards