Staff

Hello! Vulnerable IPMI, iDRAC etc. which are then kept not updated and whose access is not even communicated to the customer is a negligent and intolerable behavior, however it's not impossible. Good datacenters keep such an access restricted to a VPN, but it's plausible that in some cases access is exposed to some public Internet address. Speaking only about Dell's iDRAC, a study led in 2018 evaluated that tens of millions of servers are critically vulnerable. And that's only Dell, while other management systems add other vulnerabilities. As disabling a remote management system is not a comfortable solution, because it could be needed for any emergency remote OS installation/maintenance/reboot/whatever, since AirVPN birth we verify IPMI, DRAC, iLOM etc. etc., restrict access to them to a tiny pool of IP addresses reserved to Air management if the server is exposed to the Internet (if it's in a VPN, the risk is remarkably reduced, as the attacker should find a way to enter the VPN first and discover the address inside the VPN) and keep it up to date (datacenters sometimes do not even bother to give you an updated system). That said, inside jobs can potentially crumble any and each caution, that's why it's important to rely on reputable datacenters; furthemore, if NordVPN statement is true, as incredible as it may sound, then the datacenter committed an outstanding negligence which perhaps might even be considered malicious in court, for having failed to inform NordVPN about the existence of a remote management system capable to bypass any server defense. However, we would like to read a statement from the datacenter company, before jumping to conclusions. Eliminating hazards completely is impossible, but risk mitigation is a task which must be always pursued with due diligence. Kind regards

Hello We're sorry, OpenVPN 3 library, which is used by Eddie Android edition, currently does not handle "remote-random". All remote lines will be evaluated sequentially, with no random start. "remote-random" directive has always been missing in OpenVPN 3 main branch but now that we actively develop OpenVPN 3 AirVPN fork, we might implement it. We can't promise anything right now but stay tuned. Kind regards

Hello! Of course. Eddie handles network changes perfectly in Android 5.1, 6, 7, 8 and 9. Should problems involve Android 10 (under which current Eddie stable release was not tested) they will be properly addressed. Let's see log and logcat. Kind regards

@dinosm Hello! 1. Yes, it's possible and the only explanation we can think of (you can check the log anyway, if in doubt feel free to send it to us). 2. Please enable both "Always On VPN" and "Block connections without VPN". After that you can disable "VPN Lock" in Eddie's "Settings" > "VPN". Kind regards

Hello, can you also send us a system report ("Logs" > LIFE BELT icon > "Copy" icon > paste into your message)? From the log we see that VPN server's IPv4 push is strangely missing and that in pure IPv6 a problem arises: . 2019.10.15 01:10:00 - OpenVPN > NOTE: unable to redirect default gateway -- Cannot read current default gateway from system The IPv4 successful route check is enigmatic as well. Do you have IPv4 connectivity with your ISP, or do you have IPv6 only (and IPv4 is wrapped in IPv6)? We are looking forward to hearing from you. Kind regards

@laowai Please feel free to send the logcat in a ticket, and not here (as you prefer). Eddie has been tested extensively on dozens of Android 6, 7, 8 and 9 devices, and not on 10, so the logcat is very welcome. Is your version a beta version? Kind regards

@laowai Hello! Yes, if you need to re-enter the Master Password, then Eddie re-started. If you have the chance to take a logcat, that would help us immensely: we start to suspect that Eddie crashes in your customized Android version, and the idea is supported even by some other unexpected behaviors you report and by the fact that after your last system upgrade situation improved remarkably. About starting Eddie at (re)boot, that's entirely up to the system. Eddie registers to the list of applications that the system should launch at boot. Then it's up to the system when and if running them. In some device (for example some Asus phones and tables), a boot launcher manager pre-installed by the manufacturer and running with root privileges is active by default and manages the list of apps to run at boot, so it will bypass Eddie (and any other app) registration. Kind regards

Hello! No, they can't of course. And surely nobody would pay for such a "feature"! There is no remaining trace of your real IP address in your packets once they are not between the VPN server and you, (not like in proxies which add X-Forward etc. field, obviously) and a web site owner can not access our VPN servers (again, that's obvious) as administrator or physically to perform a correlation analysis in real time. Kind regards

Hello! If the disconnection from the previous network did not cause an unrecoverable OpenVPN error Eddie would re-connect, of course, because the VPN would have remained paused and the tunnel up (no leaks possible). Otherwise what you suggest would be terribly wrong, as it would expose you to traffic leaks during the re-connection. Anyway, since you run Android 9, you can enable proper options in your system to prevent traffic leaks outside the VPN tunnel and then disable VPN lock from "Settings" view. Doing so will let Eddie re-connect in any case, and you will not suffer traffic leaks outside the tunnel, not even during re-connections caused by unrecoverable OpenVPN error. Kind regards

Hello! Probably the servers bind to physical network interface, with explicit configuration or through UPnP, and Eddie's Network Lock is not enabled. Thus they accept incoming connections from the Internet and their traffic is outside the tunnel. Can you please confirm that Network Lock is not enabled? Kind regards

Hello! We're very glad to inform you that on October the 10th 2019, we released a new version of OpenVPN AirVPN library fixing critical bugs affecting main OpenVPN 3 branch for Linux since years ago. Please see the changelog here: https://github.com/AirVPN/openvpn3-airvpn/blob/master/CHANGELOG.txt Critical bug fixes are essential to offer an OpenVPN AirVPN library based client on Linux. As those bugs remained unresolved for years in the main branch and made OpenVPN 3 de facto unusable in a safe way in Linux, we could not wait anymore. Therefore, we will be able to release a first beta version for Linux and macOS of a command line based, light-weight client software based on OpenVPN AirVPN 3.3.2 around October the 20th. FreeBSD and OpenBSD versions remain planned for the very near future. Kind regards and datalove AirVPN Staff

@laowai Thank you! Description of point 1 makes us think that the problem is unrelated to Eddie. Anyway we'll try to reproduce it (so far we couldn't but we have tested on different hardware). About point 2, the description seems coherent with the expected behavior of a VPN lock following an unrecoverable error. In such a case human intervention is required. The operator has the option to shut down critical applications before unlocking the communications: it's what you need for the safest leaks prevention within the limits enforced by Android. If you have Android 8 or 9 you can disable VPN Lock (from the "Settings" view) and let Android handle leaks prevention with the proper system options. Anyway, feel free to elaborate and clarify if our interpretation of your description is incorrect. Kind regards

Hello! We are aware of the issue and we are investigating. Unfortunately, as it pertains to Netflix, we can't promise anything, we're sorry. Kind regards

AirVPN Canada servers (Amanah Tech servers in general mostly) Hello! Not reproducible so far. Can you please list server names for a more accurate cross-check? Kind regards

Hello! Can you both, independently, provide a list of servers you experience the various issues on? Kind regards

Hello! We're very sorry, currently we have no plans for an email service. Kind regards

Hello! Yes, if the connected device (where OpenVPN runs) is behind the router. Outgoing traffic flow is already encrypted while incoming traffic flow is still encrypted. Kind regards

Hello! Problem resolved: several NL servers, including ChaCha20 supporting servers Comae and Luhman, had a brief downtime. The roadmap is the same we informed you about during the last months: ChaCha20-Poly1305 will be available on all servers when OpenVPN 2.5 stable is released. In the meantime we will keep adding servers supporting ChaCha20 with OpenVPN 2.5 beta version whenever necessary. Kind regards

Hello! The problem got solved but it's the second time it occurs in just 10 days. A high volume router check-up has been scheduled for the next working day as the problem could be sorted out only by rebooting that router in both cases. Please do not hesitate to report again any malfunction in Dallas in the meantime. Kind regards

Hello and thank you for your testing! Please post your message again on the following thread at your convenience: https://airvpn.org/forums/topic/45326-eddie-desktop-218beta-released/ Eddie desktop devs prefer to have all the 2.18 bug reports in a single thread. Kind regards

Version 2.18.4 (Wed, 02 Oct 2019 18:20:00 +0000) [bugfix] OpenVPN > Error: Not supported OpenVPN config [bugfix] Linux - Crash "Unexpected crash of elevated helper:Elevated communication closed" during IPv6 block, if IPv6 not available [bugfix] macOS - Autorestart service if upgraded, avoid error "unknown command" [bugfix] Enforce Elevated compatibility check [change] macOS - KeepAlive in launchd [change] Minor changes [new] New deploy/build scripts MacOS users: if, when launched, it throws "Unable to obtain elevated privileges (required): Unexpected elevated version mismatch" open a terminal and launch the following commands: sudo launchctl unload /Library/LaunchDaemons/org.airvpn.eddie.ui.elevated.plist sudo rm /Library/LaunchDaemons/org.airvpn.eddie.ui.elevated.plist After that, re-enable launchd daemon service in Preferences if you want. This issue is related ONLY to a previous bug, it will not happen anymore.

Hello! The connection mode with the highest success rate (virtually 100%) according to our reports from China is toward port 443 (destination port not blocked by ISPs in China) of entry-IP address 3 (to have tsl-crypt and therefore full encryption of the Control Channel) in TCP (to bypass UDP blocks). DNS leaks are of course not a problem at all with our software. Kind regards

Hello! Yes, the Sales department is looking into the issue. No payment has been ever received for account "dshadow83", at the moment: please follow your ticket for news and recommendations. Kind regards

Hello! If you run systemd-resolved try to stop it and check again. sudo systemctl stop systemd-resolved If that's the source of the issue, you need to understand how systemd-resolved works to find a compatibility between it and Eddie (or just keep it disabled): https://wiki.archlinux.org/index.php/Systemd-resolved#Automatically Kind regards

Hello! Correct, because your whole data file is encrypted by your Master Password itself. You can anyway have Eddie run and connect automatically at boot through profiles. Consider carefully that in this way your profiles will be in clear text, exposing your client certificate and key (but not your AirVPN username and password). Eddie can even generate a profile by an AirVPN server (long-tap a server name from the VPN SERVER view). We're very glad to know that longer battery life is noted, it was one of our purposes when Eddie Android edition was designed. Should you use CHACHA20-POLY1305 cipher with our experimental servers, you should see an even longer battery life: feel free to keep us posted. Kind regards