Staff

Hello, how can you know whether the other provider provides connections to the same ports with the same ciphers and same protocol tried on our servers by ddrnewb or not? And even if it did, you can't assume that ddrnewb tested exactly under the same conditions both services. Actually ddrnewb did not specify anything about that, so it's not correct to make such an assumption. And as you can see from the results he/she posted, we were right, either his/her ISP is performing traffic shaping or it's his/her system to do that. Kind regards

@CriticalRabbit Hello, according to your description no leak was possible. Network Lock in Linux operates with iptables which is a frontend to modify kernel tables. When the VM crashed, either the kernel of the guest OS did not work anymore, so the whole machine was dead even at the most basic level - a TCP/IP stack did not even exist anymore probably - or it did still work, in which case outgoing packets outside the tunnel would have been dropped. Kind regards

Hello! We don't see how it would increase security. HMAC is secure, it does not really matter if the lower layer hash is SHA1 or SHA256. SHA1 attempted hash collisions by an attacker are meaningless, because before trying that the attacker should have found the HMAC keys. HMAC SHA256 is not planned at the moment. We are hesitant with ECC for the problem with NIST parameters based curves. These have been created by NSA (by Jerry Solinas) and there are some doubts that must be taken into consideration about "cooked" constants, although unlikely. So the real paranoid person might stay away from elliptic curves based on NIST recommended constants. Please see also: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters Ideally, OpenSSL etc. should not use NIST curves, there's no reason to do that because there are better alternatives. By the way, in a more general vision, it does appear inappropriate to think about even stronger encryption in our service, either for the Data Channel or the Control Channel. Kind regards

Hello! This topic is dated 2011... now the gift voucher process is fully automated. Kind regards

Hello! How can you say that your ISP does not perform overselling and/or that traffic shaping is not applied? Please try a connection with OpenVPN over SSL to support or deny this claim. In client menu "AirVPN" -> "Preferences" -> "Protocols" select "SSL Tunnel - Port 443", click "Save" and start a new connection. Kind regards

Hello! We just tried sndbuf 8192 rcvbuf 8192 verb 5in Preferences->Advanced->OVPN directives->Custom, with OS X, and everything works fine. Maybe you have a simple typo issue, directives "sendbuf" and "recvbuf" do not exist, but "sndbuf" and "rcvbuf" do. "Opening utun (connect(AF_SYS_CONTROL)): No buffer space available" is a bug that sometimes appears on some systems. It's not related to Eddie (our client), it's related to OS X / BSD and OpenVPN. Unfortunately, we are unable to reproduce it in our labs for investigation. Does your sndbuf/rcvbuf solution resolve the issue, or does it limit it? Do you have ALWAYS the above error? Can you post a full log? Eddie doesn't have in bundle a TUN driver, because Maverick and above already have it (utun). One of the Tunnelblick solution for the 'No buffer space available' is adding a custom directive dev-node tunso that OpenVPN falls back to the older TUN driver. Maybe it could work for you if you have the older driver. Sorry but we can't reproduce this issue, so we can only speculate. Kind regards

Hello! Problem was fixed on April the 13th. Kind regards

Hello! You can use an Air account on as many devices as you wish. Up to three devices can connect simultaneously to different VPN servers using the same account. Kind regards

Hello! Warning: if nameservers are set manually in OS X, Tunnelblick will IGNORE the DNS push from OpenVPN servers. Kind regards

Hello! Performance has nothing to do with Eddie, it's OpenVPN to handle everything in this case. Which OpenVPN version were you running before and which version are you running now? Kind regards

Hello! Because client series 1 is obsolete and nowadays it poses security concerns. We recommended to stop to use client series 1 almost a year ago. Yes, you must do that if you wish to use our client. Otherwise you can run any other client, but not our client series 1. We beg your pardon but it's exactly the opposite. We started to recommend upgrade to client series 2 one year ago. Now a message tells you to upgrade. We repute that one year is enough for everyone. There is no such thing as a special compile. It's the opposite, clients series 2 Eddie are FOSS, client series 1 was closed source software. And frankly we don't see your point anywhere for an upgrade that takes 20 seconds and gives you a much more reliable software, not to mention that it's open source software and with tons of additional commodities. Kind regards

Hello! We're sorry, it's not our duty to fix OS bugs, not to mention the huge work it would require. And then it would be useless unless you have a rooted device and know how to patch Android. However, we can't see the problem, since the bug has been resolved in Android 5.0.1 and later versions, which are available since a long ago, isn't it right? Kind regards

Hello! We do not use and we have never used OpenDNS. We have our own DNS servers which resolve also NameCoin and OpenNIC names and allow you to use Geo-Location routing. OpenDNS is not even compatible with our mission and DNS features of our DNS servers are reported very clearly, in part even in the home page, anyway please see: https://airvpn.org/specs @6501166996442015 Where in the world did you get the weird, curious, creepy, strange, peculiar, bizarre (ok, enough with the Thesaurus ) idea: "but seems AirVPN is now using OpenDNS to manage their DNS."? Kind regards

Hello! This is possible only if you made an insecure transaction, for example over http instead of https. In this case all of your data travel unencrypted between the final destination and the VPN server. A VPN (or any proxy, or Tor, or whatever you can imagine) can never replace end-to-end encryption! Just use end-to-end encryption and not even the VPN operators can sniff your credit card transactions. We are quite convinced that any non-criminal service NEVER allows credit cards transactions in clear text. Either you were hijacked from inside your system or you have a spyware inside your system or the service from which you bought has a security leak of your credit cards credentials. All of these cases are obviously out of any VPN scope or purpose, it's your own responsibility only. Kind regards

Hello! Can you please re-download? Kind regards

Hello! Please see here: W 2015.04.14 09:56:33 - Recovery. Unexpected crash? When Eddie 2.8.8 and older versions (up to 2.5, where Network Lock was implemented for the first time) are killed without grace they will de-activate Network Lock at the next startup. This behavior has been modified in Eddie 2.9 Experimental. Currently the latest experimental version is 2.9.2: https://airvpn.org/topic/13957-eddie-29-experimental-available Kind regards

Thanks! News for our beta testers: a major step in Eddie development will be the support of ANY ovpn configuration, with automatic import of ovpn configuration files of our VPN service competitors. Some features depend on server-side software (DNS/Route checking and SSH/SSL tunnel for example), but major features (including Network Lock) will be available. We have planned this because our mission even focuses on helping people with FOSS software for privacy protection. Using our VPN service and servers is a sustainable method to allow us to work according to our mission. Kind regards

@rainmakerraw Hello! There was a wrong 2.8 version inside the "2.9" RPM archive, we apologize for the issue. It has been fixed, please re-download. Anyway, dpkg (in general .deb installers) has no problems in packages re-installation even if the package is the same version of the one already installed, while rpm may refuse to re-install. This may be a problem for you when we release the final 2.9: if so, try with --force Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the Netherlands is available: Nusakan. The AirVPN client will show automatically the 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, 2018 UDP and TCP. Just like every other Air server, Nusakan supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

New version 2.9.2. Re-download and re-install the experimental version. The newest version shows 2.9.2 in About. Changelog [bugfix] OpenVPN Driver Installation failure that occurs on Windows 8 and Windows 10[new] New advanced option Remove the default gateway route (Only Windows and Linux)About the new option, It removes the default route 0.0.0.0 when the VPN connection is established, and restores it at disconnection. If Eddie crashes or is killed [ungracefully], when relaunched it recovers automatically. Under Windows, if activated this option resolves the WebRTC leak. Please use with care, it's an experimental feature.

Hello, are you querying VPN DNS? Kind regards

Hello! If the problem is in the firewall, a flush of the rules while the client is not running will solve it. Should you need more specific instructions please specify the Operating System which you experience this problem on and the Eddie version you're running. Kind regards

Hello! Could those who experience tun/tap driver installation problems with 2.9.1 publish Eddie logs? Especially all lines starting with "OpenVPN Driver ..." and "Tunnel driver will be upgraded ...". Thank you! Kind regards

WINDOWS USERS, IMPORTANT: Re-download and re-install the experimental version before using Network Lock. The newest version shows 2.9.1 in About. We confirm an issue related to restoring rules in Windows Network Lock. If anyone has lost his/her rules with the previous version, activation and deactivation of Network Lock will restore them. Changelog of 2.9.1: - [bugfix] Windows - Network Lock issue - [new] Windows - Different tunnel version between XP and Vista and later versions. - [new] Windows - Tunnel driver version detection and upgrade to latest version. - [bugfix] OS X - UDP 443 selection in preferences. Nothing has changed in Linux edition that still remains 2.9.0. @athelstan: Two files backup are created in client program folder in previous (We think that it may be better to use that system path to avoid issues with accidental deletion (for example those who use the portable version and delete it when they switch to another version). But there is a bug, and we have also issues when antivirus program detects a write in system folder as 'suspicious', so we reverted in the latest 2.9.1 version the saving in the program folder. Kind regards

Hello! Our mistake, we deeply apologize. Now it has been fixed. Kind regards