Staff

Hello! Yes, it's normal, even with Network Lock enabled. That's the VPN IP address (therefore a private address), assigned to your tun/tap interface (the virtual network interface used by OpenVPN). Please see also here: https://airvpn.org/specs It does not affect your privacy or the anonymity layer in any way. Kind regard

Hello! Only Eddie, yes. The failure was in the routes check because the certificates deployment failure caused a TLS trust relationship failure. If you didn't perform this additional check (because you disabled this option in Eddie, or used OpenVPN or any other OpenVPN wrapper/frontend) you couldn't see the problem. Kind regards

The funny thing is that you wrote this message while you are connected to a Netherlands server. Kind regards

Hello! We're glad to know it. However both the Air client and OpenVPN GUI use OpenVPN to tunnel traffic etc. Please check whether they are both using the same OpenVPN version and the sockets buffers sizes (set them to 256 KB in the Air client menu "AirVPN" > "Preferences" > "Advanced" > "General"). Kind regards

That's because we don't externalize the support service. Do you prefer a copied & pasted, pre-packaged answer after a few minutes, with a plus of a meaningless chat with some remote call center which handles hundreds of different services from dishes to computers, or a competent answer, written by the service personnel, which needs the time that it really needs? If you prefer the first type of aforementioned support then Air is not the service for you. That said, today is a special day because a certificate deployment failure on several VPN servers caused major problems (now solved) for hours, with a subsequent and dramatic surge of support requests. Anyway, all the support requests will be satisfied within a few hours, as it always happens. Only a few hours delay due to the tickets congestion. Kind regards

The deployment of an updated SSL certificate on VPN servers failed on some servers. This impacted ONLY the "Checking Route" and "Checking DNS" feature of Eddie / AirVPN Client. It's not a security issue. For this reason OpenVPN GUI and other OpenVPN clients worked anyway. The problem has been fixed. Our apologies. Kind regards

The issue is now resolved. Very sorry about the delay, we are investigating about what went wrong.

Hello, with "OpenVPN over Tor" Network Lock can not work because it should know in advance the Tor guard IP address before the circuit is created, which is of course not possible. With "Tor over OpenVPN" Network Lock works fine as usual. "OpenVPN over Tor" is the connection method you can see in the first picture and paragraph here: https://airvpn.org/tor Kind regards

Hello, if you put a server in a black list it will not show in the "Servers" list. Tick "Show all" to show all servers, even those included in the black list (and put them out of the black list if your action was unintentional). Kind regards

@UncleHunto We are testing the latest Manjaro (and Fedora 24 has a similar issue). We can reproduce the issue about the hung "Restarting with admin privileges" issue and the DNS checking failure. There is also another problem related to the 'portable' version: a crash related to the libMonPosixHelper.so. Thanks, and please wait. When we resolve the above issues, we will release an update. Kind regards

Hello, can you please test Eddie 2.11beta and report back? Kind regards

Hello, is this issue occurring with with Tor Browser 6? Can you test Eddie 2.11beta? It should have been resolved. Kind regards

Hello! In Eddie 2.10.3 and older versions Network Lock sets specific firewall rules which allow incoming packets in the tunnel and deletes your rules (to restore them when it is de-activated). When Network Lock is off you probably have rules blocking incoming packets to your service or in the tunnel or anything similar. Kind regards

Hello! 1. Please tick "Lock current" (in the "Servers" window). 2. Please define a white list of servers. Eddie will connect only to servers included in a white list if one is defined. Right-click on each server name to open the contextual menu. Kind regards

Hello! The issues with Windows Vista/7 are under investigation as well as other ones, like the OS X missing digital signature. In general, if we don't reply to a feedback, it's because it's under investigation. Acknowledged and planned, however with low priority. Ok, it will be fixed in the next 2.11.x release. The 9.21.2 TAP driver version will be bundled in the next 2.11.x release. Please provide us with more info, other people with Mint 18 don't report this issue. We are are adding Manjaro in our testing platforms today. On top of that, we are interested in an AUR release following guidelines for ArchLinux, with the correct packages dependencies like our .deb and .rpm package. https://aur.archlinux.org/packages/?O=0&K=airvpn You can still be the "Maintainer", we simply want to deploy a right/perfect package into AUR. We shall investigate about this after fixes of current issues have been deployed. Did you un-check the "Automatic" checkbox? Kind regards

Hello! There are absolutely no problems with PayPal as far as we can see, so please feel free to open a ticket to the "Sales" department and they will investigate quickly. Remember to include the transaction ID you have experienced problems with. Kind regards

Thanks, your guide / tutorial has been promoted to How-To section. The delay is perfectly normal, nothing wrong in your guide or lack of time or anything else, it's just that we always wait for several feedbacks before putting anything in the How-To section. This usually requires some weeks and we normally should have waited some more time, but given your reaction we have moved it right now. Kind regards

Well, it's impossible to tell, because the client uses the round trip time between the node it runs into and the VPN servers as one of the parameters for the rating, so it heavily depends on the location of the client. In our previous message, when we said that those three servers became the best servers "for the client", we were imprecise. That was true only for those who picked or white listed the Netherlands only. For anybody else, that was possible, but not certain Kind regards

Hello! You can check the "Status" page. At the moment in the Netherlands we have 3 servers down, out of 44. In Germany we have 0 servers down. The problem arose because when those three Netherlands servers went down, the monitoring system failed in a peculiar way. The servers obtained the highest ranking in the world and one of them became the "best" server for the client software, for the NL domain name, for the Europe domain name and for the Earth domain name. Their rating skyrocketed because their latency was low as usual, they could yell to our monitoring system that all of their bandwidth was available, that their CPU load was 0, and more (and everything was true... because nobody could get their traffic through). In reality they had problems with the OpenVPN clients, but not to prevent completely the connections (so we did not even get one of our alerts, "suspicious low amount of users in a single server"). The problem is momentarily patched but we will soon investigate to understand the reasons of this odd (and somehow funny...) failure of our monitoring systems. Kind regards

Thanks LZ1. Pasting here for readers' comfort. Hello, this may help: http://android.stackexchange.com/questions/60819/can-i-share-my-androids-vpn-connection-over-a-hotspot Kind regards

Hello, perhaps your decision is biased by the assumption that a proxy-fied torrent client ensures that the torrent client does not communicate to trackers and DHT your real IP address, but that's not necessarily the case. Using a proxy to hide "your real" IP address when torrenting is simply wrong. This misconception is widespread and we don't know why (maybe marketing reasons? or just lack of knowledge?). A good report on the above has been compiled for example by the Tor Project: https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea The first reason alone shows why the assumption is wrong and why it might put you in troubles. In your case, if you want to surrender to entities which do not allow access from IP addresses assigned to business/datacenter lines, the real solution is different, i.e. just tunneling the torrent traffic and nothing else. Kind regards

Notes from Staff 1) this topic has been split to keep it readable because it contains at least two important pieces of information which deserve to not be mixed with funny flames. Off topic forum is the correct place for the split messages that you can now find in "[TOXIC WASTE] ---" topic. 2) the two persons who say that we allow this type of information for our purposes and suggesting that we should censor it are not in good faith in our opinion, because our forums have been full of marketing promotion of competitors and we never saw them advocating the censorship of such messages. The difference is that this thread reports alleged facts from various sources, it is not marketing. Additionally, when you claim that the reported facts and/or the opinions and/or the actions by a moderator of a single sub-forum of a forums set dedicated to the community and handled by the community reflect in any way any AirVPN opinion, idea or action, then you're living in a fantasy world. It should be superfluous to remind you that any message not written by "Staff" does not necessarily reflect any opinion, ideology and/or technical or non-technical knowledge of AirVPN personnel. Kind regards

Hello, it's not an issue in Eddie itself, it's a missing dependency which additionally can't be satisfied in Debian 9 by default. You can test the brand new Eddie 2.11beta, built on Mono 4. https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.11beta. This software has passed successfully internal alpha testing weeks ago, and finally passed internal beta testing now. It is ready for public beta testing and we consider it a Release Candidate of the 2.11 stable version. Anyway, remember that it's still a beta version, so if you don't feel adventurous you might like to stay with 2.10.3 (stable). To download Eddie 2.11beta please select "Other versions" > "Experimental" from the download page. UPDATE 30-Jan-17: version 2.11.15 stable has been released. UPDATE 24-Jan-17: version 2.11.12 is available. No changes from 2.11.11, just a version revision to prepare distribution via repositories properly. UPDATE 17-Jan-17: version 2.11.11beta RC8 has been released. Please see all the updates here: https://airvpn.org/topic/18625-eddie-211beta-available/page-22?do=findComment&comment=55393 Changelog: https://eddie.website/changelog/?software=client&format=html The current Eddie status: a message from the chief developer First of all, we apologize for the delay of this release. We are working on two different versions of Eddie: 2.x and 3.x. Eddie 3.x will have a new UI engine (also based on GTK+ under Linux, to drop Mono WinForms that are affected by a lot of unresolved bug) and a lot of new features. We plan to release Eddie 3.x soon, but it's not ready/stable yet, so we decided to port some of the new features back to Eddie 2.x edition. This was the cause of the delay: a lot of features are totally rewritten (for example the OpenVPN directives manager). We promise that next releases and bugfixes will be faster. Biggest changes in Eddie 2.11: - Latest versions of OpenVPN (2.3.11) and stunnel (5.32), built with OpenSSL 1.0.2h. - A new Network Lock method under Windows (Windows Firewall not used anymore) - A new IPv6 lock method under Windows - A new DNS lock method under Windows - Built with Mono 4 under GNU/Linux - New ports/protocols available - DPI-Aware UI under Windows. System fonts used both in Windows and Linux. - Various bug fixes - And so many other internal changes and minor UI updates. Please see the changelog: https://airvpn.org/services/changelog.php?software=client&format=html === Windows users, please be aware that the new Network Lock method uses the WFP in persistent mode, so the Network Lock settings will survive even a reboot, when Network Lock is not disabled properly in Eddie. If you kill Eddie without grace, or Eddie crashes, just re-run it (even after a reboot) to cancel Network Lock. We might change this behavior according to your feedback. Eddie 2.11beta for GNU Linux can be downloaded here: https://airvpn.org/linux Eddie 2.11beta for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.11beta for OS X Mavericks, Yosemite and El Capitan only can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.11.10beta package includes an OpenVPN version re-compiled by us from OpenVPN 2.4 source code with OpenSSL 1.0.2h for security reasons and to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie 2.11 is free and open source software released under GPLv3. GitHub repository https://github.com/AirVPN/airvpn-client Kind regards & datalove AirVPN Staff

That creature is a troll!