Staff

Hello! This is interesting. We are gradually activating IPv6 on every server, but you have IPv6 disabled at OS level, and this causes a fatal error. For the moment, you can: - Reactivate IPv6 No good reason is known to disable IPv6 at OS level. If you are scared about IPv6 leak when connecting to servers without IPv6 support, a cleaner solution is simply blocking IPv6 traffic with ip6tables. OR - Append the following directives in your .ovpn files: pull-filter ignore "route-ipv6" pull-filter ignore "redirect-gateway ipv6" pull-filter ignore "dhcp-option DNS6" pull-filter ignore "tun-ipv6" pull-filter ignore "ifconfig-ipv6" redirect-gateway def1 bypass-dhcp This will skip IPv6 configuration of tunnel and avoid your error. We are considering related options to Config Generator. Kind regards

Hello, according to your report you have absolutely no reason to touch anything. Additionally network-manager developer has fixed various issues and bugs. Just enjoy AirVPN! Kind regards

Hello! As promised Eddie 2.14.3beta, which has just been released, supports additional keyboard shortcuts, i.e. hot keys. Here is a full list: Ctrl + M : Menu Ctrl + A : About Ctrl + P : Preferences Alt + F4 : Exit Ctrl + Alt + O : Overview Ctrl + Alt + S : Servers Ctrl + Alt + C : Countries Ctrl + Alt + V : Speed Ctrl + Alt + I : Stats Ctrl + Alt + L : Logs We hope that the new hot keys will help. Kind regards

Version 2.14.3 (Fri, 27 Apr 2018 15:06:02 +0000) [new] Bundled with OpenVPN 2.4.6 and OpenSSL 1.1.0h [bugfix] Events tab hidden fixed [bugfix] Custom OpenVPN directives parser in some circumstances [bugfix] Issue with IPv6 in "in-out" config with IPv4 only servers [bugfix] Better detection of IPv6 support at OS and network adapter level [bugfix] Windows - Issue when launched from a network/UNC path. [change] Windows/Linux - Better keys binding in UI [change] Other providers: If keepalive is used, don't use ping-* related directives. [bugfix] Linux - Workaround for a Mono bug if version https://github.com/mono/mono/issues/6752 [bugfix] Windows - Fix for issue 'Windows WFP, Add rule failed: Interface ID ... unknown or disabled for the layer.'. [bugfix] Windows - Fix detection issue related to IPv6 at OS level. [change] Windows - Removed option "Disable IPv6 at OS level if requested", because in Windows 10 a reboot is required. [new] MacOS - Context menu [change] Misc UI changes [change] Added hot keys support [change] Linux - Removed gksu dependency from *.deb packages

Let's clarify once and for all because this thread is derailing to FUD. Problems in ipleak.net have nothing to do with AirVPN infrastructure. This web site is powered by AirVPN funds and maintained by an AirVPN co-founder, but it is outside the VPN infrastructure. Kind regards

@prbtwl Please see https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs : "in Eddie, you will need to log your account out and then in again to force Eddie to pick a different key (new or old)". Eddie 2.13.6 or higher is required. Kind regards

Hello, you can consider to sell your goods or services for Bitcoin. Anyway, we also accept ZCash and Monero which are designed to provide a rather strong layer of anonymity on every and each transaction. Even a Bitcoin wallet which is always run behind Tor provides some anonymity layer. The problem you mention with prepaid and gift cards is not something strictly related to us: prepaid cards sold in a certain country may be restricted to be used only in that country, and of course we can't have sites in every country of the world. The reasons for which prepaid cards can be used only in the country where they are sold in are essentially based on anti money laundering considerations. Kind regards

Hello! Can you please check again now? Kind regards

Hello! We don't see any issue in resolving the names you mention, everything looks just fine. What DNS is your system querying to resolve those names? We have just tested on a wide variety of public DNS servers and we found no problems at all. Kind regards

Hello! Can you please try to disconnect your account, re-connect it and report back? On the server where that was possible, it was immediately fixed. Please verify again. Kind regards

Hello! The problem has been fixed, can you please test again? Kind regards

Hello! It means exactly that: your service is reachable through your real IP address. It's dangerous because it opens the way to correlation attacks. Please make sure to not forward ports in your router. Network Lock will also solve the problem. Kind regards

@DarkSpace-Harbinger It is not a reliable method at ISP level, too easy to bypass. But of course simpler methods are much more effective. Kind regards

Hello! We're glad to inform you that the problem has been solved. Kind regards

Hello! We're glad to inform you that the problem has been solved. Kind regards

Hello and thank you for your patience! We are working to solve the problem as soon as possible. In the meantime, please simply disable the DNS check from inside Eddie. Select "AirVPN" > "Preferences" > "DNS" and untick "Check Air VPN DNS". Click "Save" and start a new connection. That's all. DNS check is a redundant option so you can keep it disabled safely while we work to fix the issue. Side note: you are running an archaic Eddie version (2.11.15). Latest stable version is 2.13.6, you might like to upgrade. Kind regards

Hello and thank you for your patience! We are working to solve the problem as soon as possible. In the meantime, please simply disable the DNS check from inside Eddie. Select "AirVPN" > "Preferences" > "DNS" and untick "Check Air VPN DNS". Click "Save" and start a new connection. That's all. DNS check is a redundant option so you can keep it disabled safely while we work to fix the issue. Kind regards

Hello and thank you for the head up! The communications between the nodes inside the VPN have always meant to be blocked. Nodes can communicate inside the VPN only with common services, such as DNS server for example, since Air birth. We have found a flaw in the recent updated configuration and we have fixed it, can you please test again now? Should you find any further issue, please specify also which server(s) you experience the problem on. Kind regards

Hello! Yes, but it's not recommended. "europe2.vpn.airdns.org" for example is resolved to the highest rated server at the moment of the generation, if you force resolution you will always connect to the same server. As explained in the tooltip, that's useful in case of DNS poisoning (China for example). Previous versions of Config Generator had an option to dump all servers with many "remote" directives, to allow OpenVPN to pick (randomly) a server, but the option was disabled because OpenVPN doesn't accept more than 64 "remote" directives. if necessary, you might anyway emulate that option by editing the file with a text editor (with "remote-random" and then a maximum of 64 " remote" directives, see also https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses for this purpose). Anyway, europe2.all.vpn.airdns.org contain all IP servers of the picked region, as explained here: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses Kind regards

Thanks. That's helpful. I can determine the IP addresses from that. Shouldn't resolve hosts put the actual IP address in the configuration file? Hello! Yes, thanks for the head up, this is a critical bug, it will be fixed. The CG also generates invalid names when you select entry-IP 2, exactly as you reported. Going to investigate and fix. Kind regards

Hello! The names you entered do not exist. Please replace them with: america2.vpn.airdns.org asia2.vpn.airdns.org europe2.vpn.airdns.org Kind regards

Hi there! I have a FTTH 1 Gbps, without AirVPN I get 945 Mbps (that is 115+ MB/s). With Airvpn turned on it is 100 - 150 Mbps (that is max 15 MB/s). No limitation on my hardware. I think that Airvpn HAS a an uplimit. Or not? Hello! Is your system Windows? We have had some reports according to which some Windows systems can't beat 130-140 Mbit/s with the current tun/tap driver. We can't confirm or deny, but it deserves more data collection. Kind regards

Hello! All the routing servers are used and the graphs are displayed correctly, as far as we can see. About AU2, it's used, but not much. In the last year the peak bandwidth was 8 Mbit/s only! Kind regards

Hello! Note that the fact that Canada is black listed is irrelevant in your case, because according to your description you have defined lists for the servers. Try this: - delete any list both on servers and countries - white list United States - test again If the problem persists with the above list (i.e. Eddie connects to a Canada server) please send us a system report. Kind regards

Hello, this a logic flaw or a typo. Probably you meant "on the opposite of what the writer of the rebutted article meant", i.e. the writer claims that it's mandatory to build a business model based on false, lying "no traffic logging / inspection" policy in consideration of our prices, while the rebuttal shows how the legal framework and the working infrastructure of AirVPN prove the contrary after more than seven years of operations. The rebuttal also explains why lying on the no logging and no inspection policy would be catastrophic under a purely business view. This is obvious, and actually the rebuttal has been written with the account of AirVPN Staff, so there is total transparency and no ambiguity. It's not that the rebuttal has been written in the name of someone who pretends to be outside AirVPN or anyway super-partes in disguise. Luckily the fact that we fight for freedom of expression does not prevent us to exercise such fundamental right whenever we wish so. In reality we do. In a VPN where all clients are known and trusted, a client might like to share its devices with any other client, but this is a special case which does not happen normally, not even in corporate VPNs. It would be a paramount security hazard. A more common usage of shared resources in a VPN is sharing some resources not belonging to each client. This is what happens in AirVPN too, where you share some resources inside the VPN, without never going out of the VPN itself. Specifically, a client in AirVPN can use DNS inside the VPN (no query of the client gets out of the VPN itself), and access other (different than ICANN) namespaces. A client accesses also other resources (geo-routing / micro-routing etc.), always inside the VPN. We might also add additional shared resources inside the VPN in the future. With a proxy, you never share resources inside a virtual network, simply because you are not in a virtual network. The similarity you mention might be born by a confusion. When the VPN offers also a gateway to other networks, as AirVPN does, the client traffic passes through different private and public IP addresses before its traffic is routed to the final destinations from the public, exit-IP address. What happens with a proxy is profoundly different, and the similarity is misleading: the traffic that's sent through a proxy never enters a virtual network, is not necessarily encrypted between your node and the proxy node, is only a part of your system traffic (only TCP), and continues its route to the Internet from the very same public address some application in the system sends the packets to. Your system default gateway and routing table remain the same and your system does not have another network interface to rely on. Some significant examples which show how this difference in behavior is very important are also mentioned in the rebuttal and cover the predominant usage of our service, if not the totality of it. As an additional, side note, it remains to be seen how and if a proxy can prevent spoofed packet injection in your DNS queries and in incoming traffic content with the same effectiveness provided by our service, as well as in fake personification based attacks. Kind regards