Staff

Hello! We're glad to inform you that new servers in Tokyo are now available: https://airvpn.org/forums/topic/45762-two-new-1-gbits-servers-available-jp/ Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Tokyo, Japan, are available: Biham and Okab. The AirVPN client will show automatically new servers, while if you use OpenVPN clients you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). Just like every other "second generation" Air server, Biham and Okab support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.. You can check servers status in our real time servers monitor: https://airvpn.org/servers/Biham https://airvpn.org/servers/Okab Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! Currently Netflix USA (and only USA) is accessible from our infrastructure, provided that you query VPN DNS. Kind regards

Hello! OpenVPN AirVPN 1.0 beta 2 has just been released! Please check the first post in this thread for updated links, instructions and changelog. Kind regards

Hello! Let's see the paper first. It will be published after the vulnerability has been patched. A paragraph from The Register says: ""This vulnerability works against OpenVPN, WireGuard, and IKEv2/IPSec, but has not been thoroughly tested against tor, but we believe it is not vulnerable since it operates in a SOCKS layer and includes authentication and encryption that happens in userspace," which is enigmatic because OpenVPN works in the userspace too, with encryption handled by OpenSSL or mbedTLS libraries. EDIT: however, tun interface lives in the kernel space. Kind regards

Hello! It's a warning and not an error. You can safely ignore it. Mutual incompatibility between "comp-lzo" and "compress" directives will cause backward compatibility break if "comp-lzo" went unsupported, so "comp-lzo" is still supported in 2.4.8, 2.5 as well as OpenVPN 3 library: OpenVPN developers might be re-planning the "transition". In any case we will intervene to preserve at the same time backward and onward compatibilities in due time, only if strictly necessary. Kind regards

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