Staff

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

Hello! You should have the identical behavior if you disable "VPN Lock" in Eddie (you can do that in the "Settings" view). Note that in such a case you will have traffic leaks outside the tunnel just like you have with any other OpenVPN based app (VPN lock is an exclusive Eddie feature). Android 8 and 9 implement new systems settings which will make "VPN Lock" superfluous. If you run Android 8 or 9 you can consider to prevent leaks with system settings and keep VPN lock disabled. Kind regards

Version 2.18.3 (Fri, 27 Sep 2019 11:07:42 +0000) [change] Switched 'ping' method in Linux and macOS [change] Code cleanup [change] macOS - Direct invocation with AuthorizationExecuteWithPrivileges for superuser privileges [change] Linux - "Minimize to tray" false by default [change] Linux - Mono, Portable and AppImage editions [change] Minor UI improvements [change] Better log of issues [change] Better log of dns flush actions [bugfix] Linux - Icon and Window glitch in KDE [bugfix] macOS - SSH connection [bugfix] macOS - Show/Hide Main Window issues [bugfix] OS Keyring conflicts with multiple profiles [bugfix] Linux - Raspberry, ARMHF build, fixed issue 'file_getasroot' [bugfix] Linux - Fixed a fatal crash with some UI tray icon issues [bugfix] Linux - Detect and use iptables-legacy (nft transition) [bugfix] Linux - Fixed a SSL connection issue (related to error 'Cannot create pid file') [bugfix] Parser of OpenVPN version [new] Linux - WM_CLASS registration [new] Linux - New IPv6 block [new] Latency test only about servers in whitelist [deprecated] Option "Remove Default Gateway" (routes.remove_default) removed [deprecated] Windows - Option "Switch DHCP to Static" (windows.dhcp_disable) removed

Hello! What is your exact distribution name and version? Do you run systemd-resolved? Can you check whether your /etc/resolv.conf file is a symbolic link or not, both when Eddie is connected and when Eddie is not running? What Eddie version are you running? Kind regards

Hello, once again: we wish (in our setup, we mean) that stunnel accepts any connection to bypass restrictions, even when it will have certificate replacement and therefore it is subjected to MITM exploits. The integrity and data security layer is ensured by the underlying OpenVPN tunnel. stunnel is not there to add anything to security when you use OpenVPN over SSL, it is there to try to punch a hole in the filters through which OpenVPN can establish its tunnel. In other words, the stunnel configuration is intentionally "insecure", as in our case stunnel must "punch a hole" and nothing else, while all the packets security, integrity, authentication etc. is up to the underlying ("inside" stunnel) OpenVPN tunnel. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Singapore (SG) is available: Struve. The AirVPN client will show automatically the new server; if you use any other 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, Struve 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/Struve Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! Username and password are encrypted, and not simply obfuscated, before they leave your system in Eddie desktop editions as well. However this thread is reserved to Eddie Android edition: please report your evidence on the threads dedicated to Eddie desktop edition at your convenience for thorough investigations. Kind regards

Hello! On Eddie Android Edition it is impossible. We need evidence as username/password pair is encrypted BEFORE leaving the system (check yourself on the source code and through deep packet inspection tools) so at the moment we must rule out what you say, in Eddie Android edition. Kind regards

Hello! Thank you for your suggestions. First and second ones are clear. We would like to clarify the third one. Your username, e-mail or password are never exposed, during any interaction with our "auth" or "bootstrap" servers, while with the VPN servers they are not even sent out (they are not necessary to connect to our VPN servers). Also, you can prevent Fortinet to understand that an OpenVPN tunnel has been built by using "tls-crypt", which is anyway the default Eddie setting. tls-crypt mode encrypts the whole OpenVPN Control Channel, so it is actually a pure TLS connection. It is available to entry-IP addresses 3 and 4 of our VPN servers. Please feel free to clarify what you mean with "changing headers for the VPN" at your convenience, we're afraid we don't understand. Kind regards

Hello! Does anyone experience the following problem with "OpenVPN over SSL" connections in Linux, or similar issues in other systems? We have been asked to post it here by one of our customers. Can you please test on your systems? Hello, I have just installed your new Eddie client (2.18.2 beta) to try out i was on the previous (stable) version until now.Operation system is Debian based with latest update's However SSL protocol connections do not seam to work for me now thay did work before the Eddie update, and ssl works with the previous Eddie version on a windows client. I have attached logs for each connection attempt all are successful except for the SSL option. All UDP SSH and other protocols/servers connect fine except when using SSL Is there any issues with ssl at the moment. Please let me know how to proceed or if any further information is required. Thank you for your time. SSL I 2019.09.13 14:05:58 - Checking authorization ... ! 2019.09.13 14:05:59 - Connecting to Lacerta (Canada, Montreal) . 2019.09.13 14:05:59 - Routes, added a new route, 87.101.92.172 for gateway 192.168.239.2 . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: stunnel 5.55 on x86_64-pc-linux-gnu platform . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: Compiled/running with OpenSSL 1.1.1c 28 May 2019 . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: Reading configuration from file /home/unknown/.config/eddie/33e6d2ca44d2221880152d327a2db718cd5ffb8384b6377c13b1ffe5fb94550f.tmp.ssl . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: UTF-8 byte order mark detected . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: FIPS mode disabled . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG6[ui]: Initializing service [openvpn] . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG4[ui]: Service [openvpn] needs authentication to prevent MITM attacks . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG5[ui]: Configuration successful . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG6[ui]: Service [openvpn] (FD=9) bound to 127.0.0.1:37073 . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG3[ui]: Cannot create pid file /var/run/stunnel4.pid . 2019.09.13 14:05:59 - SSL > 2019.09.13 14:05:59 LOG3[ui]: create: Permission denied (13) ! 2019.09.13 14:05:59 - Disconnecting

@amilino Older than 2.18 Eddie version stored a profile in ~/.airvpn with the name "default.xml". Eddie 2.18.2 stores the profile in ~/.config/eddie and names it default.profile. So default.xml comes from some older Eddie that you were running with user "root" (and NOT with a normal user in the sudoers). What does su have to do with sudo? Just to verify whether Eddie has at least created the proper directory, can you tell us whether the following directories of your regular account: ~/.config/eddie ~/.config exist or not? Kind regards

This folder does not exist. Hello! That might be the problem. If you have removed ~/.config for your account please re-create it and try to re-run Eddie. If you are connecting to your Raspberry as superuser please switch to a normal user and then run Eddie. Another potential cause which may explain the error message you reported might be when your user is not a sudoer. In this case Eddie UI can't launch Eddie backend (another binary file) with root privileges from the account itself, so it will try to do it from root account, if possible (on some systems like Ubuntu root account exists but is disabled by default). Kind regards

Hello! What problem do you experience? Default location for Eddie's default.profile file is ~/.config/eddie Kind regards

Hello! OpenVPN is correct: 19700101 00:00:21 N VERIFY ERROR: depth=1 error=certificate is not yet valid: C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org Our certificate is not valid on 01 Jan 70. Setting the correct date and time will solve the issue. Kind regards

Version 2.18.2 beta (Thu, 12 Sep 2019 15:59:45 +0000) [change] Linux - FIxed a Lintian error on some distributions [bugfix] Linux - Netlock issue if IPv6 is disabled via GRUB ('Address family not supported by protocol' error) [bugfix] Linux - Sometimes Eddie doesn't close [bugfix] Linux - Arch issue with elevation, also restored .xz packages [bugfix] Windows - Issues with username with spaces [bugfix] macOS - Dump PF output and file in logs in case of failure [change] macOS - Notifications, better layout with icons [change] Added Boost in Libraries [bugfix] Minor UI changes

Hello @Blimeychum we are very glad to know it. Eddie's default settings are fine in most cases: you can fine tune Eddie from the "Settings" view but if you are comfortable right now there's no reason to change settings. A new Eddie Android edition guide is almost ready and will be published soon. Kind regards

Hello! Yes. it might be the problem we underlined. What happens if you run Eddie Android edition in your FireStick? Eddie Android edition is available in the Amazon Appstore too: https://www.amazon.com/Eddie-AirVPN-official-OpenVPN-GUI/dp/B07KTD6DH9/ref=sr_1_1?keywords=eddie+airvpn&qid=1568227286&s=gateway&sr=8-1 Kind regards

Hello! What is the browser you used to download the generated configuration files? The error you get is usually caused by the fact that the browser downloads the whole HTTP page instead of the actual file. This happens for example with Chrome for iOS and the old "Android browser". We are looking forward to hearing from you. Kind regards