Staff

Not on systemd based systems like yours. The script you're using will work only on initd based systems. Use Eddie (only 2.11.x beta, because 2.10.3 is not compatible with Mono 4) or see here about the issue, as specified in our "How-To": https://wiki.archlinux.org/index.php/OpenVPN#DNS Kind regards

We see thousands of downloads every day from the web site and no complaints or warning about malfunctions at all. The problem is not on our end, check your connectivity (including MTU) and try different browsers. Kind regards

Which is based on lies as we proved in a discussion in our forums (the identity of the account is confirmed). The author (account "thatoneprivacyguy" in the thread linked below) was unable to support his opinions. When he was put in front of compelling evidence all he was able to do was stating that he did not change his mind. This behavior made him lose any credibility. See yourself: https://airvpn.org/topic/19586-a-review-on-another-site/ Therefore you can't trust the author, unfortunately not even when he writes good things about us. By the way, the web site lacks the most essential information about VPN settings and security (it does not even say if VPN gateway and DNS IP addresses match or not, for example, or how OpenVPN is exactly configured). Not to mention the hilarious "No" AirVPN got in some boxes, like "Gives back to privacy causes" (compare our mission https://airvpn.org/mission and who we are to check what a macroscopic lie it is). Kind regards

Personally I would stop using AirVPN's UK servers from within the UK. also move your email provider elsewhere, preferably to a datacentre in the same country as your VPN. Your traffic is anonymous, but they'll be sniffing your mail as it leaves the data centre. And of course always encrypt mail content with gpg. Kind regards

Hello! Can you be more specific? Do you mean that Network Lock does not "lock" anymore anything else? Kind regards

Hello! $ airvpn -cli -help | grep buf openvpn.sndbuf TCP/UDP send buffer size. Special values: '-2': Automatic, '-1': OpenVPN default. Default: '-2' openvpn.rcvbuf TCP/UDP receive buffer size. Special values: '-2': Automatic, '-1': OpenVPN default. Default: '-2' WARNING: only in Eddie 2.11.x. Kind regards

"Start minimized" bug in Windows confirmed. Under investigation. Kind regards

Hello, 1) enlarge considerably torrent client RAM buffer, so that it writes to the HDD less frequently 2) if you have an asymmetric line make sure that the upload bw of the torrent client does not choke the line (set stricter limits from the torrent client options) 3) if you have some file system that has no effective algorithm to avoid fragmentation, defragment the HDD 4) consider zhang888 suggestion. If you have USB 3, even a good USB key might be enough. Make sure to take one that can support at least 28 MB/s in writing and set the external storage in the torrent client options. Kind regards

Hello! Are you sure that your proxy is running and listening to the correct port, and that no firewall blocks packets to/from it? Which proxy is it? Can you post the complete logs? Kind regards

Hello, can you reliably verify that with VT-x disabled the route check is always (or most of the times) successful? Is this surely the only BIOS setting that you vary to get a different Eddie behavior? Do you run Eddie in some VM? Can you please upgrade to Eddie 2.11.8beta and verify whether the problem remains the same (with VT-x enabled)? To download the latest Eddie beta version please see here: https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards

It's a problem in our web site and we'll solve it soon. We apologize for any inconvenience, thank you for your patience. EDIT: problem solved. Kind regards

Hello! Before anything else please check your DNS settings. A plausible explanation is that Eddie was unable to restore your system DNS settings, either because it was not shut down properly or for a rare but nasty bug in 2.10.3 and earlier versions. The bug has been fixed in Eddie 2.11.x beta, try it to prevent the problem to re-occur: https://airvpn.org/topic/18625-eddie-211beta-available/ How to change DNS settings in Windows 10: http://www.geeksquad.co.uk/articles/how-to-change-your-dns-windows-10 If you are unsure about a good public DNS, we would recommend OpenNIC for their commitment to privacy and neutrality, please see: https://www.opennicproject.org Kind regards AirVPN Support Team

Hello, it's still working as far as we can see. Maybe "micro-routing" is not working on some specific server, can you specify the server(s) you experience this problem on? Kind regards

@philips The error is on our web site, the signatures you published for that package are correct, we're going to investigate the issue very soon. To make it clearer, on the 64 bit package: $ openssl sha256 eddie-ui_2.11_windows8_x64_installer.exe SHA256(eddie-ui_2.11_windows8_x64_installer.exe)= cebb75efb0630b53edfceb17fa348d62ed2c19a88db641f73fb0ba6a884295fe Kind regards

@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