Staff

Hello! Correct, DNSSEC is disabled, but we can re-enable it, especially now that DNSSEC black-outs which caused so many problems are very rare. Kind regards

Hello! For your peace of mind and to re-affirm that nobody's screwed: that's false. Our VPN infrastructure is based on 26.7% M247 servers which is approximately the same amount of M247 servers we had two years ago. Infrastructure redundancy is way more than 50%, so each provider is not critical by itself alone. Furthermore, and more importantly, you are wrong even with the amount of providers. We have never a better diversification of providers than we have now. We currently work with 31 different providers which is an all time high. Kind regards

Hello! It looks like your proxy is refusing connections: Please make sure that your proxy really runs (obviously) and listens to port 8080 and that no firewall blocks local connections to it (no blocks to/from localhost 127.0.0.1 and/or port 8080). SOCKS or HTTP? They are not equivalent. Please make sure that Eddie is configured to connect to the correct proxy type. Kind regards

Hello! We paste here an answer to a ticket with the same content for other readers' comfort. The first explanation that comes to mind is that your ISP has worse peering with M247 than with Leaseweb and our provider in the Netherlands. We add redundancy whenever possible exactly to maximize good peering likelihood with any residential ISP in the world. While you can't expect, of course, that your ISP will sooner or later have better peering with M247, you can pick those servers which can give you the best performance. Eddie (the Air client software) gives you the option to compile a white list or a black list of servers. If a white list is defined, Eddie will connect only to those servers included in that white list. If a black list is defined, Eddie will skip and ignore all the servers included in the black list. Kind regards

Hello! Ok, to clarify: Your Raspberry has an ARM 64 bit. Raspbian for Raspberry has a 32 bit architecture, while Ubuntu 64 bit. Binaries compiled for x86 can not be run in ARM processors and vice-versa. Eddie for Linux is compiled for x86-64 (and not ARM). Eddie for Raspberry is compiled for ARM 32 bit, because Raspbian is only 32 bit. OpenVPN 3 AirVPN is compiled for Linux x86-64 and Raspbian 32 bit ARM. The logic behind the above choices was that up to Raspberry PI 3+, the most commonly installed OS was Raspbian 32 bit, and various Linux 64 bit could not be installed on PI 3 and 3+ We will soon provide a solution (a matter of a week or so), by building a version of OpenVPN 3 AirVPN for ARM 64 bit, so you will be able to run it in your Raspberry with Ubuntu 64 bit. In the meantime, to connect your Raspberry Ubuntu 64 bit to our service, you can run OpenVPN 2.4.x. Instructions are here: https://airvpn.org/forums/topic/11431-using-airvpn-with-linux-from-terminal/ Kind regards

Hello! Does your Ubuntu for Raspberry have a 64 bit architecture? You might also test the following software but just like Eddie for Raspbian, it is 32 bit, so you might face the same arch problem: We don't rule out, anyway, a 64 bit release for Raspberry in a very near future. Currently it's all 32 bit because Raspbian is only available with a 32 bit arch for Raspberry:Kind regards

Hello! We're glad to inform you that a new server in Tokyo will be operational in the very near future. Kind regards

Hello! That's an unrecoverable error and, when "VPN lock" is enabled, Eddie correctly locks communications to prevent any possible traffic leak outside the VPN tunnel. If Eddie tried to re-connect when the network is again up, traffic would flow outside the VPN tunnel. Now, starting from Android 9, a robust traffic leaks prevention is implemented at system level, in a way that Eddie can't achieve as it lacks privileges. The "VPN Lock" feature, after the bootstrap of the device, is no more necessary when Android is properly set up. So you can consider to turn off "VPN lock" from Eddie's settings, and turn on "Always on VPN" and "Block connections without VPN tunnel" in Android settings. In this way Eddie will re-connect whenever possible and you will not suffer traffic leaks between a disconnection and a re-connection. Kind regards

Hello! It's also important to understand Tor limits. Let's start from here: https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea Consider also any other case involving applications or system processes binding to real network interface, or consequences of UPnP and STUN. As you can see, your "real" IP address will be revealed outside Tor usage. The same might happen with a generic proxy and even with a VPN, but not when you are connected to a VPN server with "Network Lock" enabled. In such a case, the firewall rules will block communications outside the "VPN tunnel" with the important, additional bonus that the p2p software and any other software can not "discover" your real IP address and transmit it against your will to any third party. Furthermore, consider those cases when UDP is needed: Tor does not support it. Moreover, Tor network is too slow for practical purposes meeting certain needs. For example, those who need to stream audio and/or video, or have VoIP etc., or any other system based on p2p (from cryptocurrencies networks to VoIP, from streaming to videogames) and need to keep their real IP address hidden, may rely on VPN. At the same time, nothing prevents you to launch Tor after the system has connected to a VPN with Network Lock enabled, and use Tor over OpenVPN for sensitive data exchange in TCP. Doing so provides also two side effects that are relevant in many cases, i.e. hiding Tor usage from the eyes of ISP and government, and hiding real origin and destinations you contact even to our VPN servers. At the same time, system processes, that you might be unaware of, will always have their traffic either tunneled over the VPN or blocked, so you real IP address will not be exposed. Kind regards

@mariusffm In the first log the key is wrong, that's fine (you use TLS crypt key on entry-IP address 2 whose daemons expect TLS Auth key). TLS Crypt key can be used on entry-IP addresses 3 and 4. In the second log the cipher mismatch is caused by missing "ncp-disable" directive in your configuration file. OpenVPN "ncp" directive is engineered in quite a bizarre way (check the manuals for details), so you need to disable "ncp" on the cllient side to tell the server that the client needs to negotiate (if available on server side) exclusively one specific cipher on the Data Channel. Kind regards

@airdev Correct. In this case, however, the mentioned IP address is operated by AirVPN since November the 17th, 2019, so all the reported issues are totally unrelated to AirVPN. Kind regards

Worrying development actually. Thanks. Kind regards

Hello! On the experimental servers we use OpenVPN 2.5 beta linked against mbedTLS 2.16.3 (on Comae and Chamalaeon) or OpenSSL 1.1.1d (on Luhman, Luyten and Ross). Can you publish the log showing the failure? Does the failure occur on both mbedTLS and OpenSSL "based" servers? Kind regards

Hello! Yes, you can: up to 20 ports at once for every and each connection slot. Kind regards

Unfortunately not, we do not have IP addresses assigned to residential ISPs which would allow access to DAZN services, we're sorry. However please note that Netflix USA (and only USA) is accessible from Air VPN servers. Kind regards

@dwright Hello, as an alternative, you might test OpenVPN 3 AirVPN client 1.0. beta 1, it supports CHACHA20-POLY1305 even on Data Channel: https://airvpn.org/forums/topic/45631-airvpn-client-based-on-openvpn-361-airvpn/ You will have also "Network Lock" available to prevent any traffic leak outside the VPN tunnel, as well as proper handling of DNS push (not available on OpenVPN 2). Kind regards

@AK-47 Hello! 1) Yes. You need a profile and select the proper option in "Settings". If you shut down the Shield while Eddie is running and connected through a profile, it will start automatically at next bootstrap and connect to the VPN using the same profile. NOTE: just like any other app, Eddie registers with high priority with Android to start at boot, but the exact moment Eddie starts remains as an exclusive decision of the system. 2) Normally you define a list of favorite servers in "AIRVPN SERVER" view (you can define favorite and forbidden serves), but if you need autostart and autoconnect you need a profile for a specific server. 3) Yes! "Settings" > "System" > "Application filter type". Select "Blacklist" and then pick the applications whose traffic must NOT be tunneled. Full instructions are here (web site menu "Download" > "Android" > "Eddie"): https://airvpn.org/forums/topic/29660-using-airvpn-with-eddie-client-for-android/ In Chapter 5 you can find how to generate and import a profile. Kind regards

@giganerd Kitalpha is one of the last servers without IPv6 support (the whole datacenter does not have it), were tests toward IPv6 supporting servers successful as well? Kind regards

@giganerd Thank you! We will have to dig deeply. Who knows, it might be one of those bugs that stayed there for years in the main branch, we have already hunted down and fixed many of them. Step by step we are determined to resolve everything. In the Android app, in "Settings", you have the option "Use IPv6 over IPv4". When it's on, it enforces "yes" to the same class member in the Android OpenVPN 3 AirVPN library. If you enable "Use IPv6 over IPv4", do you see the same error? We will get informed about Mono debugging tools. Just to avoid any confusion to the readers we remind that OpenVPN 3 AirVPN client and library have nothing to do with Mono, they are entirely written in C++ Kind regards

@giganerd Hello! What happens if you don't specify "-6 no"? And with "-6 yes"? And with no "-6" at all? Omitting "-6" is not equivalent to "-6 no" or "-6 yes" apparently ("apparently" because it is undocumented) so it's worth to test all 3 options. We have fixed several bugs from the main branch and if necessary we will start investigating this one too. So, first and foremost, let's ascertain that this is a bug for real. Here what you can infer from the source code comments: // IPv6 preference // no -- disable IPv6, so tunnel will be IPv4-only // yes -- request combined IPv4/IPv6 tunnel // default (or empty string) -- leave decision to server std::string ipv6; [You might ask why we don't do it ourselves, the problem now is that all developers lines and all testing servers have either IPv6 down or no IPv6 at all] Kind regards

@Dramanaught Thanks a lot! No overselling has always been our workhorse, we were the first to publish a real time servers monitor as an element showing no overselling. Load balancing inside single VPN servers came later in 2017 (general load balancing at infrastructure level was built in 2011 and improved in 2012 and 2013). About the load balancing at server level: since OpenVPN runs in a single core and does not scale, we decided to run one or two OpenVPN daemon(s) per each core, and send each new client connection to the OpenVPN daemon running in the least loaded core (according of course to the picked connection mode). As far as we know no other VPN service (based on OpenVPN) does the same. The outcome has been interesting because we can now squeeze up to 1.7 Gbit/s on AES-NI machines with 4 cores Xeon CPUs, which should be a record for OpenVPN servers on equal terms (CPUs etc.). Kind regards

Hello! We're very glad to inform you that: a macOS beta version is now available Linux 64 bit and Raspbian beta versions are now available (we recommend that you upgrade from the previous alpha versions) OpenVPN library has been updated to version OpenVPN AirVPN 3.6.1 The initial message with download links and instructions has been updated accordingly. Kind regards

Hello! We are glad to inform you that we have released a new version of OpenVPN-AirVPN library which is essential to our imminent release of a client for macOS which will be added to the clients for Linux 64 bit and Raspbian: https://github.com/AirVPN/openvpn3-airvpn/blob/master/CHANGELOG.txt Kind regards AirVPN Staff Changelog 3.6.1 AirVPN - Release date: 28 November 2019 by ProMIND - [ProMIND] [2019/11/28] openvpn/tun/builder/base.hpp: Added virtual method ignore_dns_push() to TunBuilderBase class - [ProMIND] [2019/11/28] openvpn/tun/client/tunprop.hpp: added DNS push ignore to method add_dhcp_options() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.2 AirVPN - Release date: 10 October 2019 by ProMIND - [ProMIND] [2019/09/04] fixed bug in openvpn/tun/linux/client/tunsetup.hpp: changed if(conf->txqueuelen) to if(conf->txqueuelen > 0) which made linux connection to fail - [ProMIND] [2019/09/04] openvpn/tun/linux/client/tuncli.hpp: added initialization to TunLinux::Config::txqueuelen - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed remove_cmds->execute(os) call in establish which prevented reconnection to work properly - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed connected_gw member and related code which prevented reconnection to work properly - [ProMIND] [1019/10/10] openvpn/client/cliopthelper.hpp: added method getRemoteList(). Returns remoteList member with list of profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added RemoteEntry structure to reflect profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added remoteList member - [ProMIND] [2019/10/10] client/ovpncli.cpp: OpenVPNClient::parse_config now assigns remoteList member with values of ParseClientConfig.getRemoteList() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.1 AirVPN - Release date: 31 August 2019 by ProMIND - [ProMIND] [2019/08/06] Added cipher override to client configuration - [ProMIND] [2019/08/06] Added ncp disable override to client configuration *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3 AirVPN - Release date: 13 July 2019 by ProMIND - [ProMIND] [2019/06/02] Forked master openvpn3 repository 3.2 (qa:d87f5bbc04) - [ProMIND] [2019/06/06] Implemented CHACHA20-POLY1305 cipher for both control and data channels - [ProMIND] {2019/07/10] Implemented ncp-disable profile option

Hello, each VPN server runs its own DNS server https://airvpn.org/specs Kind regards

The simplest method is through WebRTC or any other STUN based technique, which will reveal your private addresses (or more precisely the IP addresses of your interfaces, virtual or real) even with Network Lock enabled (it will NOT reveal your public IP address, of course). Check in ipleak.net for example. Kind regards