Staff

Hello! That's the way it has always been. A pop-up is displayed only when Eddie is launched. Again, that's the way they work (except for the flashing of the tray icon, which is not implemented). There can be only ONE pop-up. Furthermore the pop up is displayed in an asynchronous window, i.e it does not interfere with other windows and does not stop Eddie operations (for example if it must enable Network Lock and connect at startup, it will do so even if you ignore the pop-up). In other words, Eddie's pop-ups are not invasive and everything continues to go on even if you ignore the pop up window and never click on it (exception: in Android views, you will have to change view or dismiss pop-up, according to Google Android guidelines). And the feedback is clear: no pop-ups, something like several hundreds of complaints. Pop-ups, less than 20 complaints. Last but not least, pop-ups are sent only to users whose plan's expiration date is nearer than a certain amount of days. Yes, and a further confirmation comes from the fact that NordVPN Android app sends your data to various trackers. Proof: https://reports.exodus-privacy.eu.org/en/reports/com.nordvpn.android/latest/ Kind regards

@esjalistas Please open a ticket as well at your earliest convenience. The connection times you report are totally unexpected: Eddie must connect your system in less than 30 seconds, even in Windows. Note: you forgot to attach the system report you mention. Kind regards

Hello! All Air VPN servers do not keep any account data, not even client key, so no worries under this respect. VPN servers also don't keep log. We also remind you that you are not required to enter personal information in your account, not even a real e-mail address. Please note that the investigation that was disclosed by the press pertains to datacenter owners and a few web sites hosted in it, and did not involve AirVPN and/or AirVPN servers in any way at any stage. Air VPN servers were not seized and were not disconnected: we decided to drop the datacenter and withdraw the servers because of repeated lack of IPv6 connectivity, frequent drop-outs and packet loss, as well as very slow customer care reactions (maybe an impact from the investigation when it was made public? we don't know) to solve problems. As you know our technical requirements are quite precise and if a datacenter fails repeatedly to meet them we are forced to look elsewhere, otherwise the overall perceived quality by our customers will go down. Kind regards

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

Hello! Do you mean that you still see the popup when you re-run Eddie? It was no more sent after Black Friday sales ended, and anyway it was never sent to anyone already having a long plan. When we did not send it during the past deals, we always received a massive, massive amount of tickets for weeks, from people complaining that they were not aware of a special offer and they missed it because Eddie did not tell them anything and they discovered the special offer when it was too late. If you still see the popup can you please report at your convenience? Kind regards

@Maggie144 The vulnerability is still unknown so let's wait for the paper. Vulnerability will be disclosed to the public only when a patch is available. Please do not discuss the issue here as it is off-topic for Eddie: another thread is already available, although there's almost nothing to say until the vulnerability is secret, except that the attacker must control your router/access point or be an adjacent to it user, so you know in general how to prevent the potential attack in the meantime. Kind regards

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