Staff

We have several frontend servers strategically deployed around the world for any occurrence. We can change airvpn.org DNS records according to needs. Kind regards

Good, so it should be some other problem, not a specific regression of 2.11.2 (good for 2.11.2 we mean!). Maybe it's just a DNS issue, unrelated to Network Lock, that you have since you used Eddie 2.10.3 (it had a bug for which under peculiar circumstances it did not restore properly previous DNS settings in Windows interfaces). So a plausible explanation is that you have the impression you have no connectivity, but in reality you have it. It's only that the system can't resolve names. Kind regards

Hello! Understood and we repeat that it's not how Network Lock is expected to work. Is this happening with Eddie 2.11.2, or did you have this behavior on Eddie 2.10.3 as well? Kind regards

Hello, no, we're sorry, the remote-random directive will have no effect on the Air client, because the client picks a single server anyway. It picks the highest rated server (in the white list, if one is defined). You can anyway define your own white lists and of course pick manually a VPN server. Yes, that's already implemented since a long ago. You have score, latency, load and number of users. You can re-order your list (or white list) per each of these column, by clicking on the column labels. Kind regards

@LZ1 Network Lock is "not active" if Eddie is not running, unless it crashed. When you shut down the software, previous firewall rules (or WFP settings) are restored. This is precisely consistent on all system and with all previous Eddie versions, nothing has changed. Sockets buffers size are set on system defaults on all OS, except in Windows, where the size picked by the system is not acceptable (too small). See the changelog. The menu button is lighted off. When the mouse pointer slides over it turns on. Kind regards

Hello! New version 2.11.2beta is now available. Version 2.11.0beta is no more available and RC. Changelog from 2.11.0beta: [bugfix] OS X - Application Signature[change] Windows - Bundled with TAP version 9.21.2[bugfix] Countries list bugfixes.[change] Windows - Message about upgrading TAP driver[bugfix] Routes -> Outside the VPN tunnel now works[bugfix] Windows/Linux - UI glitch on Network Lock settings with the "Outside the VPN tunnel" settings.[bugfix] Windows/Linux - Minimal UI fixes[bugfix] Linux - Privileges detection on some platform (ArchLinux for example)[bugfix] Windows - WFP mode fixes about Win7/Vista compatibility issues[bugfix] Windows - WFP mode now set by default.[new] Windows/Linux - Column reorder / saving position, width, sorting for servers/areas/logs listKind regards

Hello, the domain name of this "kat" has been seized (before any due process in any jurisdiction, as far as we understand), but were the servers seized as well? Does anyone have the correct, old IP address or addresses? Kind regards

Right. Of course: making clients reachable from the Internet is the very purpose of remote port forwarding. As a side note, what you say can not be done by a client of the VPN server (because you can't communicate with nodes in a VPN if you are connected to the same VPN) but can be done by anybody else on the Internet. Also, it must be assumed that the clients that forwarded ports are in that moment connected to that VPN server, obviously. Kind regards

Hello, the higher the score the better. The lower the latency the better. Kind regards

This is and has been routinely done for years through the proper forum and the Twitter and Facebook accounts (although, as you say, luckily it was rarely necessary) but today something went wrong for a series of unfortunate events. Anyway, downtime for Eddie client did not exceed 10 hours, and there was no infrastructure inherent problem (this was the main cause of the unusual reaction delay). Kind regards

Hello! Yes, it's normal, even with Network Lock enabled. That's the VPN IP address (therefore a private address), assigned to your tun/tap interface (the virtual network interface used by OpenVPN). Please see also here: https://airvpn.org/specs It does not affect your privacy or the anonymity layer in any way. Kind regard

Hello! Only Eddie, yes. The failure was in the routes check because the certificates deployment failure caused a TLS trust relationship failure. If you didn't perform this additional check (because you disabled this option in Eddie, or used OpenVPN or any other OpenVPN wrapper/frontend) you couldn't see the problem. Kind regards

The funny thing is that you wrote this message while you are connected to a Netherlands server. Kind regards

Hello! We're glad to know it. However both the Air client and OpenVPN GUI use OpenVPN to tunnel traffic etc. Please check whether they are both using the same OpenVPN version and the sockets buffers sizes (set them to 256 KB in the Air client menu "AirVPN" > "Preferences" > "Advanced" > "General"). Kind regards

That's because we don't externalize the support service. Do you prefer a copied & pasted, pre-packaged answer after a few minutes, with a plus of a meaningless chat with some remote call center which handles hundreds of different services from dishes to computers, or a competent answer, written by the service personnel, which needs the time that it really needs? If you prefer the first type of aforementioned support then Air is not the service for you. That said, today is a special day because a certificate deployment failure on several VPN servers caused major problems (now solved) for hours, with a subsequent and dramatic surge of support requests. Anyway, all the support requests will be satisfied within a few hours, as it always happens. Only a few hours delay due to the tickets congestion. Kind regards

The deployment of an updated SSL certificate on VPN servers failed on some servers. This impacted ONLY the "Checking Route" and "Checking DNS" feature of Eddie / AirVPN Client. It's not a security issue. For this reason OpenVPN GUI and other OpenVPN clients worked anyway. The problem has been fixed. Our apologies. Kind regards

The issue is now resolved. Very sorry about the delay, we are investigating about what went wrong.

Hello, with "OpenVPN over Tor" Network Lock can not work because it should know in advance the Tor guard IP address before the circuit is created, which is of course not possible. With "Tor over OpenVPN" Network Lock works fine as usual. "OpenVPN over Tor" is the connection method you can see in the first picture and paragraph here: https://airvpn.org/tor Kind regards

Hello, if you put a server in a black list it will not show in the "Servers" list. Tick "Show all" to show all servers, even those included in the black list (and put them out of the black list if your action was unintentional). Kind regards

@UncleHunto We are testing the latest Manjaro (and Fedora 24 has a similar issue). We can reproduce the issue about the hung "Restarting with admin privileges" issue and the DNS checking failure. There is also another problem related to the 'portable' version: a crash related to the libMonPosixHelper.so. Thanks, and please wait. When we resolve the above issues, we will release an update. Kind regards

Hello, can you please test Eddie 2.11beta and report back? Kind regards

Hello, is this issue occurring with with Tor Browser 6? Can you test Eddie 2.11beta? It should have been resolved. Kind regards

Hello! In Eddie 2.10.3 and older versions Network Lock sets specific firewall rules which allow incoming packets in the tunnel and deletes your rules (to restore them when it is de-activated). When Network Lock is off you probably have rules blocking incoming packets to your service or in the tunnel or anything similar. Kind regards

Hello! 1. Please tick "Lock current" (in the "Servers" window). 2. Please define a white list of servers. Eddie will connect only to servers included in a white list if one is defined. Right-click on each server name to open the contextual menu. Kind regards

Hello! The issues with Windows Vista/7 are under investigation as well as other ones, like the OS X missing digital signature. In general, if we don't reply to a feedback, it's because it's under investigation. Acknowledged and planned, however with low priority. Ok, it will be fixed in the next 2.11.x release. The 9.21.2 TAP driver version will be bundled in the next 2.11.x release. Please provide us with more info, other people with Mint 18 don't report this issue. We are are adding Manjaro in our testing platforms today. On top of that, we are interested in an AUR release following guidelines for ArchLinux, with the correct packages dependencies like our .deb and .rpm package. https://aur.archlinux.org/packages/?O=0&K=airvpn You can still be the "Maintainer", we simply want to deploy a right/perfect package into AUR. We shall investigate about this after fixes of current issues have been deployed. Did you un-check the "Automatic" checkbox? Kind regards