Staff

EDIT: UPGRADE HAS BEEN COMPLETED Hello! In the next hours we will be upgrading OpenSSL on all of our servers to fix newly discovered OpenSSL vulnerabilities. In particular, we want to close CVE-2014-0224 immediately, that's why we will proceed to the upgrade without early warnings. In order to make sure that no previous OpenSSL functions remain loaded we will restart various services including OpenVPN. Your client will be therefore briefly disconnected from the VPN server. The web sites will remain unavailable just for a fraction of a second and established HTTPS connections will be reset. What you need to do on your side. Nothing urgent: the exploit can be performed only when both client and server sides run OpenSSL vulnerable versions. Therefore the patch on our servers will prevent the exploit. Anyway, as an additional precaution: Linux/FreeBSD/OpenBSD/Unix users: upgrade OpenSSL to latest version of your branch. Windows users: a patch is not currently available for OpenSSL included in OpenVPN binaries. As soon as it is available we will update our packages. At that time, you will need to upgrade OpenVPN. Upgrade to OpenVPN 2.3.4I002 which includes a non-vulnerable OpenSSL version. Android / iOS users: if you run "openvpn-connect" nothing is required since it does not use OpenSSL but PolarSSL. If you run "OpenVPN for Android" stand by for instructions. OS X users: a patch is not currently available for Tunnelblick. When a new version will be released, please upgrade. A new version of Viscosity that includes non-vulnerable OpenSSL is available, please upgrade. Tunnelblick users, please upgrade to versions built on 12 Jun 2014 or later. Kind regards AirVPN Staff

Hello! We remind you that May projects funding poll is open and will close on Jun the 21th. Which project shall we fund? AirVPN community has selected the candidate projects during April and May and the community will decide the one to be funded! Feel free to express your preference here https://airvpn.org/topic/11686-poll-may-2014-projects-funding NOTE: already funded projects are not included in the current contest. All projects are compatible with our mission. Kind regards AirVPN Staff

Only persons who have contributed to our forums with at least 5 posts are allowed to vote. Anyone can vote with a single or multiple choice. Who votes for what is NOT a public information. We can change this if the community prefers so.

05/06/2014, Funded with 1000€ (1355 USD). https://airvpn.org/mission/

Hello! We're glad to inform you that a donation of 1000 EUR has just been delivered to OpenBSD Foundation. Kind regards AirVPN Staff

Hello! Thanks, but that's undeserved, we did not do anything. The system was working just like it is working now. Under our point of view and according to our status/health monitoring systems, there's absolutely no difference. Kind regards

Hello @ghostp, please open a ticket at your convenience and send us the Eddie logs taken after the problem occurs (click "Logs" tab, click "Copy to clipboard" and paste into your ticket). Kind regards

If you run the older client 1.92, does this problem disappear or is it the same? Kind regards

Hello! The ETA is 20 Jun. It will run under Mavericks only (upgrade from previous versions of OS X is free). Kind regards

Hello! The winner is: OpenBSD Foundation - LibreSSL We will provide details of the donation in the next days. Thank you for your votes and for your commitment! Kind regards

Hello! The problem in those configuration files is that the OpenVPN "fingerprint" is always visible in the headers, so the connection can be disrupted. We solved the problem by encrypting the OpenVPN header, tunneling OpenVPN in SSL or SSH (OpenVPN over SSL/SSH, a tunnel inside a tunnel). This solution works in China and Iran, the two countries in which OpenVPN connections are actively disrupted, but as far as we know (we will investigate further anyway) it can't be implemented on Android or iOS because openvpn-connect client does not support connections of OpenVPN over SSH or SSL. Kind regards

Hello! No flames please. Especially no flames for nothing. Under a technical point of view, having 4096 bit RSA keys instead of 2048 RSA bit keys does not worsen or improve performance of the Data Channel. The Data Channel cipher was and remains AES-256-CBC. 4096 bit sized RSA keys, in comparison to 2048 bit ones, slow down the first handshake of about 1-5 seconds (according to the CPU power), which is totally negligible. The additional security provided by RSA-4096 is well worth this barely noticeable difference. Even the TLS re-keying, which occurs every hour, will take some seconds more, but you can't notice that, because OpenVPN TLS re-keying occurs with overlapping windows (until the new key pair is negotiated, the previous one is used). After the TLS Auth (2048 bit) and the initial negotiation with RSA 4096, your system never uses RSA to encrypt or decrypt or authenticate packets: the ciphers to be taken into consideration for performance are those of the Data Channel (in our case AES-256-CBC, unchanged) and those of the Control Channel (in our case HMAC, again unchanged, and probably negligible if compared to AES-256-CBC and the volume of data of the Data Channel). The fact that the CPU is 5 degrees hotter should not depend on RSA keys size. Although the temperature difference does not seem worrying, if an investigation is led it should consider different causes. Kind regards

Hello! Any packet with destination our server exit-IP:port is forwarded to your system VPN IP:port. In IPv4 MAC addresses are NOT included in packets, your computer network card MAC address never gets out of your local network. Kind regards

Hi, this is some other problem, it's not related to DNS: from your logs the resolution is correct. At the moment we can only confirm you that there are no problems at all to connect to port 443, in UDP, to the NL servers (including Grafias, whose entry-IP is showed in your logs). Might it be a block by your ISP or by some system firewall to port 443 UDP? Kind regards It isn't a firewall issue as the problem is replicated across two devices running Linux and Mac OS X Mavericks respectively. I can connect sometimes and not at other times (it just disconnects then refuses to reconnect for a while). Also two other users are suggesting the exact same issue today, so it's not just me. I find it highly unlikely Virgin Media would be blocking access to some AirVPN servers, only some times. Plus I have now experienced a disconnection and failure to reconnect over port 80 also. Strange. EDIT: I have now managed to reconnect to NL over port 443 UDP. It would seem that an ISP block is very unlikely. Remember I didn't start this thread, I only replied to it. Currently the top two threads listed in the applet at the side of the forum are both about this issue, from two other different users. Hello! There are around 800 clients currently connected to port 443 UDP of some NL server, globally. We have performed connections to 443 UDP from different ISPs (from Italy) to all the NL servers. No problem on our side has been detected. Maybe it's just a routing problem or some other problem between Virgin and Leaseweb (and optionally from the Solex1's ISP). Hopefully momentary. It must be said that this problem may overlap with the DNS issue. They might be two different problems that sometimes overlap, giving the feeling of erratic behavior. Kind regards

Hi, this is some other problem, it's not related to DNS: from your logs the resolution is correct. At the moment we can only confirm you that there are no problems at all to connect to port 443, in UDP, to the NL servers (including Grafias, whose entry-IP is showed in your logs). Might it be a block by your ISP or by some system firewall to port 443 UDP? Kind regards

Hello! The problem with Google DNS has suddenly disappeared now, without any intervention from our side. We'll keep an eye on it. Kind regards

Sadly true... Anyway, OpenSSL should be getting soon enough money from the CII (currently made of Google, Microsoft, IBM, Facebook, Amazon, The Linux Foundation, Bloomberg, HP, Huawei and Salesforce). Funds to hire permanently two additional developers have been already delivered and many more should be arriving soon.According to some online articles CII should be funding soon OpenSSH (by OpenBSD Foundation) and NTP. See for example http://threatpost.com/openssl-receives-funding-for-developers-will-undergo-security-audit/106349 Kind regards

Hello! Eddie for OS X is not available at the moment. We're running internally an alpha version which is not ready to be released. Eddie for Linux is available here: https://airvpn.org/linux_ex (if you run different distros, other than your current Ubuntu, make sure to read the platforms/environments notes here: https://airvpn.org/forum/35-client-software-platforms-environments ). About your case with OS X: Tunnelblick takes care about the VPN server DNS push, EXCEPT when "ServerAddresses" is set manually (as it was in your case, according to the logs). Kind regards

Hello! Do you have resolvconf installed? If so, there are several ways to force Ubuntu to use one and only one (or two, three...) nameserver, regardless of DHCP and anything else, and without having to uninstall resolvconf, have a look here: http://askubuntu.com/a/310407 Ignore other messages in the thread marked with bad ratings (0, -1, -2), they offer incorrect solutions. Kind regards

Hello! Can you open a command line in your system, issue the following commands and send us the output? traceroute airvpn.org (in Windows: "tracert airvpn.org") ping airvpn.org Kind regards

Hello! In OS X 10.9.x, each network card has it own DNS. This is a DNS implementation that causes exactly the bad problems Windows is affected and that you're experiencing. In Eddie 2.2 for OS X a "forced VPN DNS" option is planned. In the meantime, in order to prevent DNS leaks you should make sure that no network card DNS is set to query the router. The VPN DNS server IP address, reachable regardless of the port you connect to, is 10.4.0.1. Kind regards

Hello! The instructions are the same, just like for 2.0beta, at the usual announced link https://airvpn.org/software (only direct link, not available in web site menus at the moment). Kind regards

Hello! DNS leaks are impossible on Linux. Your system is explicitly configured to send DNS queries to your ISP DNS servers, and that's not a DNS leak: Linux just does what it is ordered to do. In order to use VPN DNS with OpenVPN (resolvconf required): https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Alternatively, run Eddie 2.1beta (resolvconf required again): https://airvpn.org/linux_ex As another option, in case you don't want resolvconf, just set yourself the appropriate nameservers in /etc/resolv.conf Kind regards

Those services are supported by our system as means to perform payments. If you do not have Bitcoins and you want to exchange them with a government currency, that's a totally different subject that has nothing to do with this argument, and we don't see how you can purchase Bitcoins via a bank transfer without using your bank account coordinates. Additionally, as we already wrote, all the older methods to pay with Bitcoin are still available as usual. Kind regards

Hello, the "dilemma" will be no more when Eddie will have total leaks prevention as built-in function which can be activated with a click. This is planned and will probably be added in the next release, during the 1st week of June. About your other considerations, it's sufficient to say that we don't force any usage of proprietary software and that Eddie is open source, which is very important for peer-reviews. Kind regards