Staff

Hello! The mode is proposed by the VPN server [wrong, it's in the manifest specs]: for some reason the server you tried was proposing 80 TCP, even if 443 UDP was working fine. Fixed. Kind regards

Hello, nothing has changed in our obligations, we have not been notified of anything, so there are no news to inform you about and our policy on UK VPN servers remains the same. Kind regards

Hello! Yes, that's confirmed in at least another case, it is perhaps a bug in some DD-WRT builds. Generally, on a lot of builds the wrong ciphers "TLS-DHE-RSA-WITH-AES-128-CBC-SHA" or "None" (either the first or the second) work at the first shot. Kind regards

Hello! The tun interface (the virtual network card used by OpenVPN) does not come up. Please check firewall and antivirus. After that, if necessary try the following: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Kind regards

Hello! The server IP/Name is not ours. The "tun0" in the iptables rules might be tun1, please check it out (just use command "ifconfig" on the router to see the names of all interfaces). The "TLS Cipher" set to "None" might be wrong, which options do you have in that combo box? Kind regards

Hello, it was an error on our side. It has been fixed, please try again. We apologize for the inconvenience. Kind regards

Hello! It appears that Eddie packets are completely blocked. All the 8 attempts against censorship performed by Eddie fail. Please check your firewall or any other program that might be blocking them. Kind regards

More details please, if possible and at your convenience, "it installs but will not run" does not help... thanks! Kind regards

Hello, the first problem is weird and we still need to investigate it. The second issue is not a problem, it is expected and normal behavior. Eddie wants administrator privileges. Kind regards

@LBDude @snaggle @wer Hello, please re-download the .rpm package for openSUSE or Fedora. We think we have found the problem and fixed it. Kind regards

Hello! This: W 2014.10.19 00:52:30 - Tunnel not ready, interface status: Down is probably a bug fixed in Eddie 2.5 (see the changelog). Please upgrade to Eddie 2.7 stable. Kind regards

@LBDude @snaggle @wer Hello, we're going to check the .rpm package for Fedora and openSUSE. Do you confirm that the problem is in the .rpm package, while you can run the portable version? Kind regards

Hello! You did not buy "AirVPN 3.4.1(4054)", you're running Tunnelblick 3.4.1build 4054. Tunnelblick is a free and open source OpenVPN wrapper. Yosemite is on preview so it could be normal. Instead of Tunnelblick try to run our client Eddie 2.7: in the Yosemite preview of about 10 days ago it was running just fine. Our dear Eddie is free and open source as well. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.7. Please read the changelogs: https://airvpn.org/services/changelog.php?software=client&format=html 2.7 version is compatible with several Linux distributions. For very important notes about environments, please read here: https://airvpn.org/forum/35-client-software-platforms-environments Eddie 2.7 includes important bug fixes. It also implements direct TOR support for OpenVPN over TOR connections. Finally, Eddie makes OpenVPN over TOR easily available to Linux and OS X users: no needs for Virtual Machines, middle boxes or other special configurations. Windows users will find a more friendly approach as well. The logic of the connection of OpenVPN over TOR has been completely rewritten. This mode is not handled anymore as a generic connection to a socks proxy, but it is specifically designed for TOR and therefore solves multiple issues, especially in Linux and OS X, including the "infinite routing loop" problem (see for example http://tor.stackexchange.com/questions/1232/me-tor-vpn-how/1235#1235 ) As far as we know, Eddie is the first and currently the only OpenVPN wrapper that natively allows OpenVPN over TOR connections for multiple Operating Systems. https://airvpn.org/tor We recommend that you upgrade Eddie as soon as possible. Eddie 2.7 for Linux can be downloaded here: https://airvpn.org/linux Eddie 2.7 for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.7 for OS X Mavericks and Yosemite only can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.7 package includes an OpenVPN version re-compiled by us with OpenSSL 1.0.1j for security reasons and to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie 2.7 is free and open source software released under GPLv3 UPDATE Eddie 2.7 and 2.6 for OS X had a digital signature which is no more recognized because of a change in Apple logic. Eddie 2.7 has been digitally re-signed and the package has been re-uploaded. It's anyway useless to re-download it if you already did. Kind regards & datalove AirVPN Staff

Hello! Network Lock works with plug-ins for Eddie. Currently, Eddie programmers have coded the plug-in for the Windows Firewall and no other firewall for Windows. It means that if you use Network Lock in Windows, you should disable any other firewall. Eddie is free and open source, maybe someone might like to program additional Network Lock plug-ins, or maybe we will plan one day to code more of them. Kind regards

Read this http://googleonlinesecurity.blogspot.fr/2014/10/this-poodle-bites-exploiting-ssl-30.html Anything to worry about concerning airvnp connections using openvpn over SSL? Hello! Not at all. About the web site, SSL 3.0 is not supported https://www.ssllabs.com/ssltest/analyze.html?d=airvpn.org About OpenVPN, the external layers are on TLS, not SSL. About OpenVPN over SSL, even if your stunnel negotiated with SSL 3.0, the underlying security provided by OpenVPN layers ensures no problems. Kind regards

Hi, we're glad to know it. This is questionable... for security reasons Network Lock should remain active until the Eddie user explicitly turns it off or shuts down the client, because if a session is terminated abnormally but Eddie, for any reason that we have not foreseen, should not detect the anomaly, releasing the lock would be dangerous. Thank you! Kind regards

Hello! Since Eddie 2.5beta this option is implemented and its name is "Network Lock". It is implemented with plug-ins. In Linux, the available plug-in needs iptables, so all Linux systems which have iptables can use it. Eddie 2.6 is a stable version (no more beta) but the "Network Lock" option is still marked as "experimental", however no problems at all have been detected so far with iptables plug-in. See also: https://airvpn.org/topic/12175-network-lock As usual, we recommend to follow "News and announcements" forum to remain up-to-date with constant AirVPN development in all fields. https://airvpn.org/forum/9-news-and-announcement Updates are also published through "AirVPN" accounts in Twitter and Facebook. Kind regards

Hello, yes, if we had a house in the USA that would be a trivial solution, with a good residential line with high bandwidth. Kind regards

Hello, Eddie doesn't do anything with the tun/tap driver, it is "handled" indirectly by OpenVPN (in the sense that when OpenVPN brings up/accesses the tun interface, the OS relies on the tun/tap driver). We'll check your report with the programmers. Kind regards

Hello! Problem identified, a fix is ongoing. Next client release 2.7 will include the fix. Kind regards

Hello! Can you post the logs pertaining to the problem? In Windows, if you run Eddie, please click "Logs" tab, click "Copy to clipboard" icon and paste into your message. Kind regards

Hello, we do not detect this behavior. Eddie turns off the firewall only if it had to be activated by Eddie itself. Kind regards

Hello! The route check fails. Please try to un-tick "Check if the tunnel effectively works" in "AirVPN" -> "Preferences" -> "Advanced". Connect again and check whether the tunnel works manually by browsing to https://airvpn.org and checking the color of the central bottom box (it is green and displaying "Connected!" if traffic is tunneled properly). If everything is fine, then you might like to enable "Network Lock", because the initial route checking will no more be performed. Kind regards

Hello! 1. Please upgrade to Eddie 2.6. The issue should have been fixed in it. 2. Please upgrade to Eddie 2.6. The issue should have been fixed in it. 3. That's correct and intentional. 4. You need to enter administrator password anyway. A glitch on connection at program startup has been fixed in Eddie 2.6, please upgrade. 5. Ok. The route checking needs some investigation under Windows. 6. Please upgrade to Eddie 2.6. The issue should have been fixed in it. Please upgrade to Eddie 2.6. This option has been implemented in it. Yes, as you are surealy aware, you're running a beta version. Please upgrade to Eddie 2.6, which is the first stable release BUT implements experimental plug-ins (all the Network Lock plug-ins are experimental). Additionally, Eddie is being actively developed. Kind regards