Staff

Hello, those instructions are quite outdated and are not fine for Mavericks, which should use pf as packet filtering tool, not ipfw. First of all, be informed that OpenVPN clients are available in Android 4 or higher. https://airvpn.org/android If you need to share the VPN connection on Mavericks please follow this Apple guide: http://support.apple.com/kb/PH13855 keeping in mind that the interface you wish to share is tun0 (the network card used by OpenVPN), while the interface you wish to make accessible to the Android device is the WiFi card. Kind regards

Hello, bug confirmed, under investigation. Kind regards

Hello! What about point 3? Kind regards

Hello! Thank you very much for the information! We'll check. Just an additional information, is resolvconf package installed in your system? Kind regards

Hello! The IP range is ok. About the DHCP service: Please check your Windows manual or have a look here: http://computerstepbystep.com/dhcp_client_service.html Make sure that the service is set in "Automatic" (default value when Windows is shipped). Kind regards

Hello! The problem: ROUTE: route addition failed using CreateIpForwardEntry: The object already exists. [status=5010 if_index=11] etc. Please check: 1) Is your local network IP range not overlapping with VPN one (10.4.0.0/16)? 2) Is the DHCP client service running? 3) Does the same problem occur if you disable any firewall and antivirus? Kind regards

Hello, we would recommend troubleshooting. All of these problems are not reproducible in our Debian systems. Consider that Eddie for Linux has been developed first in Debian 7 machines! Additionally, Eddie is in beta version, so we need as much feedback as possible to fix any bug. Eddie 2.2 will have a lot of fixes. This is interesting, can you provide additional information? This is not Eddie's fault, connections are handled anyway by OpenVPN, regardless of network-manager or Eddie or any other OpenVPN wrapper. Kind regards

Actually, I'm hating ipleak.net. Would it please be possible for you to provide an actual .torrent file, not a magnet link, for testing the torrent piece of ipleak? I'm using a NAS box configured to access AirVPN; the client embedded in the box doesn't support magnet links. In fact, magnet links only work on a computer, and appear to download the actual .torrent file from a peer with the file in question, so I *can't* even extract the info to make a torrent file from the magnet link. Please stop assuming that all users use your system in a single way. Thanks. Hi, probably not, we'll see what we can do... in the meantime use another service which provides torrent files instead of magnet links to test. Kind regards

Hello! You can connect to the same server but make sure to connect different devices to different ports, otherwise you will always experience the problem you report. Also, port forwarding will not work properly in any case if you connect multiple times simultaneously to the same server. Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Canada, Toronto, Ontario are available: Dheneb and Hoedus. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Dheneb and Hoedus support 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

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