Staff

Hello! Servers marked as closed for "Imminent Withdrawal" are closed to new connections because their withdrawal is imminent. Already connected clients will be disconnected only at the very last minute before the withdrawal. We also recommend that clients connected to such servers disconnect as soon as possible. Please connect to any open server. Kind regards

Hello! We had to remove that option because OpenVPN can't handle configuration files with more than 64 "remote" directives. Now, with the growth of our infrastructure, we now have various areas with more than 64 servers. The only other option we had to generate correct configuration files would have been to over-complicate the generator, adding warnings for each case exceeding 64 remote directives and stopping the generation in such cases. We have evaluated that this would have caused confusion to a lot of customers. The advanced users who need this option can anyway easily circumvent the problem, as you have noticed. Just remember that with your method, if you build a .ovpn file including more than 64 "remote" directives, you'll end up with a non-usable configuration file. Kind regards

Hi, I've exactement le same problem. Is there a solution to resolve it ? Thanks lot. bestway@sigaintorg Hello! Install all the required packages first. Please see here for a complete list of dependencies: https://airvpn.org/topic/12509-kali Kind regards

Same, but on Ubuntu 14.04 LTS I see that it will be fixed in version Eddie 2.10.In the mean time, I reverted back to 2.8 Thanks for all your hard work! Hello! If you're interested, you can try now Eddie 2.10 Experimental. Kind regards

Hello! Thanks, it will be fixed soon. Kind regards

Hello, the problem is here: I 2015.05.27 04:29:55 - Checking DNS E 2015.05.27 04:29:59 - DNS checking failed. Go to "AirVPN" -> "Preferences" -> "Advanced" -> "DNS", set "DNS Switch Mode" to "Renaming", click "Save" and try a new VPN connection. Keep us posted. Kind regards

Hello! Thank you for your subscription. Most probably you need this: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards

Hello! Not much, due to good Voxility direct peering https://www.voxility.com/shop/connectivity/internet/voxility-peerings We reputed that is enough to guarantee a comfortable experience to most customers connecting to Ruchbah. Of course the final judgment on the accuracy of our decision will come from our customers. Kind regards

Hello, as usual we needed to set some priorities and allocate resources accordingly. Netherlands LW datacenter had assumed a role which was too important, a sudden collapse of the NL servers would have caused paramount problems in the whole Europe. This is not the case with Germany. The most important situation has been fixed with addition of servers in Sweden, Netherlands itself, UK, Czech Republic, Romania, Spain and Switzerland. We can evaluate Germany situation with no time pressure in the near future. Bandwidth demand in Germany is so low that Air infrastructure is not over-depending on Germany servers (if Germany dc collapsed, impact on our customers in terms of bandwidth would be negligible). Kind regards

Hello! We inform you that the following VPN servers will be withdrawn during the next days, according to our previous informative note https://airvpn.org/topic/14291-informative-note Acrux Botein Canopus Castor Ceres Corvi Dorsum Erakis Grafias Haedi Julliet Keid Leporis Lyncis Mizar Nekkar Ophiuchi Pallas Propus Riguel Sedna Syrma Taygeta As you may have noticed the above servers have already their replacements added during the last three months. The replacement servers have the same connectivity and better hardware. Kind regards AirVPN Staff

Which OS do you experience this problem on? EDIT This is not a bug. The client does not kill OpenVPN, but communicates with OpenVPN management. Until an ongoing connection attempt succeeds or fails you can't stop it because the client must wait for management to send a command. This is a very correct way to handle OpenVPN. We could add the sending of a SIGTERM signal from the client for this situation, but is this really necessary or desirable? Not a bug, this is intentional. Which OS version do you experience this problem on? Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Romania is available: Ruchbah. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Ruchbah supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! Exactly, starting from Bernstein and Lange criticism and proposals, there appear to be plenty of good options. Thanks! But between 2010 and 2014 we anyway used 2048 bit DH, we never implemented 1024 DH in the public service. Kind regards

Hello! Not immediately, some radical changes are needed in our setup: https://community.openvpn.net/openvpn/ticket/307 https://community.openvpn.net/openvpn/ticket/410 That would be optional not to risk to break compatibility with a potentially massive percentage of our customers who do not run OpenVPN supporting/patched for ECDHE. However, at the moment this would seem unnecessary for logjam, because we use our DH group with 4096 bit prime: http://sourceforge.net/p/openvpn/mailman/message/34132515 We are hesitant with Elliptic Curves Cryptography, because we would start to use curves based on parameters recommended by NIST, which are the curves "created" by Solinas (NSA). More details on our hesitations: https://airvpn.org/topic/14086-about-updating-the-hash-message-authentication-code/?do=findComment&comment=26950 Therefore: since logjam does not seem to affect our service, we can evaluate to postpone ECC support to OpenVPN 2.4. When it will be released, we could count on generic OpenVPN ECC support (i.e. with no patches to apply), in any case after our doubts are solved, Alternatively, we could add optional ECDHE support before OpenVPN 2.4 release (keeping good old discrete log cryptography available for compatibility) but only when we can trust NSA curves (or when OpenSSL does not use NSA curves group). Kind regards

Hello, our policy stands for Etamin as well: no protocols discriminations. Is anybody else experiencing this problem? Kind regards

Hello! To all those experiencing the problem, can you please test Eddie 2.10 Experimental for Linux? It includes also a bugfix which could solve the issue. You can download that version in the usual Linux download page. Click "Other versions" then select "Experimental". We'll be looking forward to your feedback. Kind regards

Hi! Actually Eddie adds two important parameters to the formula for the servers rating: latency from the node in which it runs, and failed connection(s) to a VPN server (if any) again from the node it runs in. Eddie choice therefore can differ from the equivalent (same area) resolution of *.vpn.airdns.org, and choices of different Eddies in different systems for the same area can be different as well. Kind regards

Hello, all the original staff is still here. You can write to info (at airvpn dot org) attaching your public gpg key. Info will reply with its public gpg key. Kind regards

Hello! Could you please test and answer to the previous post? It would be an important information for us. https://airvpn.org/topic/14304-intermittent-connectivity-issue-with-eddie-airvpn-client-v292/?do=findComment&comment=28014 Kind regards

Hello! OpenVPN does not allow more than 64 "remote" entries in configuration files, but our Configuration Generator does not take that into account, it's a bug which needs to be fixed. In the meantime do NOT tick "All servers for area/region" under "Resolved hosts", or select a maximum of 64 servers. Kind regards

Hello! So it's not that the ISP blocks customers ports, it blocks non paying customers ones! Use a proxy for apt. http://askubuntu.com/questions/53146/how-do-i-get-add-apt-repository-to-work-through-a-proxy Kind regards

Hello! Ubuntu packages can be obtained with connections to port 443, for example with apt-get. Are you sure that your ISP blocks outbound port 443? Can you browse to https web sites, such as airvpn.org? Kind regards

Hello! Actually we think that zhang888 is totally right. On top of that, we would like to add that, even if an add-on were totally reliable for some browser, solving the so called "WebRTC leak" at browser level could be a false or partial solution. We would recommend solutions at firewall level, like our Eddie "Network Lock". Please see here for explanations of the above and for further considerations: http://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Kind regards

Hello, another test please... while disconnected from the VPN, with Network Lock off, go to "AirVPN" -> "Preferences" -> "Advanced" -> "General". Set the "Servers list update every:" combo box to "Never". Click "Save". Then, activate Network Lock and try to connect to a VPN server. Is the connection successful? Is it stable? If so, after you're sure that the connection is stable (for example after 30 minutes or so), go to "Servers" tab. Click the button with a white circular arrow in a green field, "Refresh the servers list". Does it cause again the problem immediately? Can you also tell us your exact distribution name and version? Kind regards

Hello! Is the problem mitigated or does it remain the same if you de-activate Network Lock? Kind regards