Staff

@Khariz Momentarily we need to not take into account macOS beta (or anyway not stable) versions, but we'll do when 10.12.2 becomes stable (if problems persist even with 10.12.2 stable). Current our priority (in Mac systems) is releasing a stable Eddie 2.11.x which can run fine on macOS 10.12.1 (latest stable release). Kind regards

In this case what Kaspersky reported pertained to your "real" IP address. Don't do this. You have two processes competing to modify concurrently the packet filtering tables of your system with unpredictable outcome. In Windows, if you run a third-party firewall, you must not activate Network Lock, because it uses Windows Firewall. You can test Eddie 2.11.8 beta for Windows which implements, by default, a Network Lock using Windows Filtering Platform, instead of the Windows Firewall. As long as your third-party firewall does not modify WFP rules and does not set interfering rules, you can run the third-party firewall and keep Network Lock WFP active. To download Eddie 2.11.x beta please see here: https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards

Hello! Please consult your ticket, because the problem has been solved. And you were right, a character in your username caused a problem (only from Eddie, not in the web site). Kind regards

Yes, of course. About Dual Stack. If you have only IPv6, and IPv4 goes over IPv6 only, then our service can not be used "as it is" with our client software, because it will try to block IPv6, actually disrupting your connection globally. Kind regards

New version 2.11.8beta RC5 is now available. Changelog from 2.11.7beta RC4: Version 2.11.8 (Tue, 29 Nov 2016 11:02:09 +0000)[change] Windows - Equivalent of 'register-dns' directive during "Flush DNS"[change] Linux - ifconfig in System Report[bugfix] Unknown directives from push-options do not cause fatal error anymore[change] Removed the 3 seconds delay when switching between servers[bugfix] Linux - Issue with SSH connection (immutable flag fix)[bugfix] macOS - Fixed Support Report[change] macOS - Now compiled with latest Mono / Xamarin 6.2.1[new] macOS - IEC option[bugfix] Windows - Line terminator in some logs[new] Button under settings to open logs directory[new] New stats "Profile path" and "Application path", both can be opened.Kind regards

We very strongly recommend to not apply this solution for security reasons. Kind regards

Hello, to answer to the topic title: no, we don't throttle anything. Kind regards

It's not faulty in itself, but also consider this: if you also have a pure IPv4 connection you can (at the moment) obtain a stronger anonymity layer with pure IPv4. Kind regards

IPv6 support is planned for the end of 2017 but this deadline is flexible given the uncertainty to resolve still unresolved issues which can weaken too deeply the anonymity layer. We will not discuss the details that are anyway public knowledge. Kind regards

Thanks. Eddie 2.11.7beta messing up with chattr has been already put under investigation days ago and an important bug has been discovered. It will be fixed in 2.11.8. (Note: this bug pertains only to Linux, other systems users are not affected). Kind regards

If it's not a tunnel within a tunnel, what's the purpose? We think about multi-hopping as a way to solve the problem of a wiretapped VPN server: the traffic transiting through the first hop defeats the wiretapping purposes because the "real payload" is still encrypted. But if the traffic in the first hop is not tunneled into the second hop tunnel, but it is just decrypted, re-encrypted and routed/forwarded to another server operated by the same company, the wiretapping is successful in any case. So, the REAL multi-hopping is what we already provide. The useless "multi-hopping" which is just a way to make your routing longer and nothing else is probably marketing fluff and as usual we will provide neither marketing fluff nor bloat-ware. If we miss something really useful for our mission in multi-hopping without multi-tunneling, please feel free to comment. Kind regards

Hello! We see that your system is based on systemd and not initd, so please take care to read carefully here: https://wiki.archlinux.org/index.php/OpenVPN#DNS specifically "Update systemd-resolved script" paragraph. Your script "update-resolv-conf" will probably not work properly in your system. Kind regards

That's the essence of an offer limited in time: you get the offer only in that period of time. This is a good option and we confirm you that it has been planned and will be probably implemented in 2017 first half. Currently you don't need to create a new account, just open a ticket to "Support" department asking for client certificate and key re-generation. Anyway keep in mind PFS, achieved via DHE (with 4096 bit keys size) in our service. Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Belgium are available: Diadema and Mebsuta. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Diadema and Mebsuta support 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

In repositories, you can have old OpenVPN versions that are perfectly up to date under a security point of view. Think about Debian Wheezy, using OpenVPN 2.2.1, updated for security purposes. Or even Debian Jessie, the current stable Debian distribution. Eddie developers have circumvented the compatibility problem with older OpenVPN versions by emulating the directive effects as a DNS leak prevention on Eddie 2.11.1beta and higher (NOT on Eddie 2.10.3 or older versions), Kind regards

Hello! We're very glad to inform you that starting from 9.15 PM UTC on Tuesday, November the 22nd, until Tuesday, November the 29th (UTC), we'll be offering a 35% discount off ANY AirVPN Premium subscription! If you're already our customer and you wish to jump aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. Kind regards & datalove AirVPN Staff

Hello, try to delete the AirVPN.xml file. Find its location by looking at the first log lines (click "Logs" just after you have launched Eddie). It could be corrupt. Make sure that Eddie is not running when you delete it. You will need root privileges to delete that file. In a terminal: sudo rm /complete/path/to/AirVPN.xml Consider that the file contains your settings, so you will need to re-enter your username and password at the next Eddie run. Kind regards

Internal ipleak.net problems, the maintainer will investigate soon. EDIT: problem solved. Kind regards

Select "AirVPN" > "About" menu item in Eddie main window to see the version you're running.

No, the password is not included in Eddie 2.11 system report. It's replaced by the string "(omissis)".

Yes, that's definitely interesting (and surprising). If you wish to help us reproduce the issue, please send us a system report (in a ticket). Kind regards

It depends also on the complexity of the problem. Usually from 1 minute to a few hours in working days, up to 24 hours in non-working days. Kind regards

The argument is that Network Lock was never meant to prevent DNS leaks. It could do that coincidentally in Eddie 2.10 or older versions (by blocking IPv6 outgoing DNS queries), but that's irrelevant in this context. In Eddie 2.11, it is true that WFP is used in an attempt to prevent DNS leaks, but that's unrelated to Network Lock. From the output of ipconfig you posted, all of your interfaces are set with VPN DNS in both cases, so no DNS leak is possible, Network Lock or not. Please open a ticket including a system report and screenshots of the alleged leaks for further investigation. Kind regards

Please clarify, you say a thing and the opposite of it. Also post "ipconfig /all" output taken when the problem has just occurred. Kind regards

Currently not, we're sorry. We never liked the fact (even in the 90ies when NSA appeared much less "malignant" than now) that IPsec development has been led by NSA and that it runs in kernel space. Performance is not inherent to IPsec (OpenVPN can easily near-match IPsec) but depends on several other factors, including ciphers. Kind regards