Staff

Hello! Please follow this thread: https://airvpn.org/topic/14362-problems-on-authentication-servers Kind regards

UPDATE: it is now possible to download the client software. Any other previously inaccessible page of the web site is now reachable. Kind regards

Please follow this thread: https://airvpn.org/topic/14362-problems-on-authentication-servers Kind regards

UPDATE: we are aware that it's currently not possible to download any version of our client software, we're working on this as well. The main problem has been partially mitigated but we still need to work hard on some part of the infrastructure. We'll keep you updated. Kind regards

Hello, due to different causes we are experiencing issues on our authentications servers. We have been and are working on the problem in order to resolve it as soon as possible. NOTE: the problem will make VPN connections difficult or slower to be established for those using our client Eddie, but it does NOT affect VPN connections stability or performance once they are established. Additionally, VPN server might be unable to forward your reserved ports. Kind regards

Hello! We have been and are experiencing problems on the authentication servers, we're working on the issue. Kind regards

Hello! We're experiencing connectivity issue with our authorization servers, please hold on, we're working on it. Kind regards

Hello, that 443 port is a port that one of our OpenVPN daemons listen to.443 is also a listening port (in the alternative entry-IP address) for SSL connections. Both of those ports have nothing to do with your system ports or with your VPN remotely forwarded ports. Kind regards

Hello! It's harmless, you can safely ignore it. Kind regards

Hello! Every peer is peer to any other peer, hence "peer to peer": no node acts as a client only, no node acts as a server only (with a relevant exception for the initial seeder of something). For true p2p, each client must be able to accept incoming packets from the Internet. If all the nodes were unable to receive incoming connection, p2p would completely stop working. That's correct. Disable UPnP, NAT-PMP and any other auto port mapping when in the VPN, and do not forward any port from the router to the devices connected to it (assuming that it's NOT the router itself to connect to a VPN server by running OpenVPN). That will only expose you to correlation attacks. You don't need your physical network card ports. This FAQ answer may clarify concepts: https://airvpn.org/faq/what_is Kind regards

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