Staff

UPDATE Due to multiple, critical problems in network-manager-openvpn which after years have not been solved we recommend to NOT use it. Please understand that we will not provide support to network-manager-openvpn. In GNU/Linux we recommend that you run our free and open source software "Eddie", or our free and open source software "Hummingbird", or OpenVPN directly 21/04/2014: network-manager-openvpn runs OpenVPN so that OpenVPN does not check the server certificate. Therefore we DO NOT RECOMMEND usage of network-manager for security reasons. This issue is already fixed in newest version not yet available in Debian 7 Wheezy Download your configuration file from the page Config Generator Select "Advanced Mode" Tick "Separate certs/keys from .ovpn files" Save the downloaded zip-file somewhere, say in ~/.airvpn. Unzip it. Five files should be extracted. Try to make sure nobody but you can read the file user.key, because that one is secret. Erase the zip-file. Or at least, make sure only you can read it (since it contains the secret user.key file inside) Install the package named network-manager-openvpn-gnome, which is a plugin to NetworkManager handling OpenVPN connections. The install will automatically include all needed packages, like openvpn etc. Perhaps you'll have to log out and log in again, or even restart the computer or something. To check that openvpn plugin was properly installed in NetworkManager, click on the nm-applet (the NetworkManager icon) => VPN Connections => Configure VPN. In the little window that comes up, click the Add button. Is there an OpenVPN option in the menu? Good. But don't click on it. Just close the windows. This was just a check. Click on the nm-applet (the NetworkManager icon) => VPN Connections => Configure VPN In the little window that comes up, click the Import button. In the file chooser that comes up, find the previously downloaded file air.ovpn (perhaps you stored it in the ~/.airvpn directory?) A new little window comes up. It is pre-filled with the necessary airvpn-configuration stuff. Click the NetworkManager applet. Under VPN-connections, you should now be able to select the VPN-connection named air. After a little while, the applet icon should be decorated with a little padlock. For any comment or feedback, you can find the discussion here. Thanks to HugeHedon for this article.

Hello! It implies that the VPN server has been listed as a TOR exit-node in the TOR exit-nodes list. This is caused by the fact that someone is running a TOR exit-node from behind our server (the exit-IP of the VPN server is shared). Since AirVPN does not discriminate against any protocol or application and we strictly comply to the broadest definition of Net Neutrality, this is not forbidden. Of course this does NOT mean in any way that you're in the TOR network. Kind regards

Thanks for the suggestion. I tried setting the speed limit as you suggested. Unfortunately, there was no change. Downloading starts, lasts for about 1 or 2 minutes, then drops out. Something strange I've noticed, when looking at the "Client Area" page on the AirVPN site, it shows how long you've been connected to the AirVPN service ("Connected since"). If I refresh the page, the "Connected since" time keeps growing. But at around 1m 30s, when I refresh the page again, it shows something like "Connected since: 12s ago". And it does this over and over. It makes me think that something is causing the AirVPN connection to constantly disconnect and reconnect every 1 or 2 minutes. Hello! Yes, your assumption according to that information looks correct. Please post the OpenVPN logs to see what happens. Kind regards

Hello! No, the Data Channel remains encrypted with AES-256-CBC cipher, regardless of what DD-WRT pretends. Our servers are not configured to provide an AES-128 OpenVPN Data Channel cipher. It's just one of the many DD-WRT OpenVPN configuration page bugs. Kind regards

Hello! We can't do much on our side: it's Omegle that bans VPNs (not only AirVPN according to anonymous reports), not the other way round. We don't block any web site, of course. So the question should be asked to Omegle administrators in the first place. Kind regards

Hello! In the "How-To" section you find two guides. One for ipfw: https://airvpn.org/topic/9147-prevent-leaks-with-bsd-unix-mac-os-x-ipfw-thanks-to-jessez/ and one for pf: https://airvpn.org/topic/9140-prevent-leaks-with-bsd-mac-os-x-pf-thanks-to-jessez/ If you have an OS X version with pf, then it is recommended by Apple to prefer pf over ipfw (ipfw usage has been deprecated in favor of pf). Kind regards

Hello! Two users will be on the count. Kind regards

Hello! There was a change of program on the fly. The various user.key keys have been all re-generated by the system and the option to re-generate a user.key has been postponed for a while. Currently the timeline of most important changes, which are being worked simultaneously, is: - DDNS fix (completed) - port forwarding panel fix (nearly completed) - re-checking access to RAI from non-Italy servers - re-evaluation of slight changes to DDNS - release of Eddie (new Air client) beta usable version for Linux and Windows (maybe 10 days) - building up the option to generate new user.key and integrate it in the users web panel Kind regards

Hello! Please allow 12/72 hours for your free trial code. Please note that if a request is performed from the same account or same e-mail address it will be not replied. The quickest way to have a free trial, if you are in a hurry, is buying a 3 days plan for 1 EUR and ask for a refund within 3 days. Kind regards

Hello! A remotely forwarded port is necessary when a service needs to be reached from the Internet. This is not the case of Firefox or any other web browser. Units: 8 Mbit/s ("megabit per second") = 1 MB/s ("megabyte per second") = 1024 kB/s ("kilobyte per second"). That said, your system in-tunnel performance appears to be too low. Given that you have already tried all ports and modes on several servers, check whether your system has some non-standard network manager (such as Asus SmartConnect and similar) because some of them have been reported as dramatically slowing down tun adapter throughput (the tun/tap adapter is the virtual network card used by OpenVPN). Additionally, please make sure that either on your router or on your computer no packets inspection tools are active (inspection of encrypted packets is not only useless but can slow down your system). Last but probably most importantly, do not miss the following post: https://airvpn.org/topic/11067-how-to-improve-average-speed/?do=findComment&comment=15415 Kind regards AirVPN Support Team

Thank you for the information! An investigation on this has been already planned. We will keep you informed. Kind regards

Hello! Oh yes... you're right, unfortunately RAI uses Silverlight. Mobile Safari on the iPad will not support or play Microsoft Silverlight content. Apple has also restricted the use of Silverlight on the iPhone. Kind regards

Hello! No, it does not. Traffic is traffic, encryption or not. Kind regards

Hello! You can watch RAI channels from any AirVPN server in the world. It's important that you use the VPN DNS (10.4.0.1) once the device is connected to a server. Kind regards

Hello! You might be able to discover the credentials (besides of course asking for them to the network administrator) by looking at the configuration of those programs in your computer that already work properly in the network. IMPORTANT: the Air client does NOT support proxy authentication. Once you have the credentials, you should generate an appropriate file through our Configuration Generator and then run OpenVPN GUI or OpenVPN directly. Kind regards

Hello! Ah yes, that's an important clarification, we apologize if this fact was not clear in the instructions for Tomato. Kind regards

Hello! The 7 EUR full refund has been sent within the terms prescribed by the ToS. While it's true that we are usually much faster on refund requests and we comply to them in a shorter time than what prescribed on the contract, that's not a strict obligation but a courtesy. Kind regards

I checked the session archive again and noticed that I connected Windows via UDP and Android via TCP. This in connection with your quoted answer might be the reason why it worked. Nothing wrong here, I suppose. Thank you for the explanation! Hello! Correct. However, please note that we edited the message, because port forwarding will not work anyway with multiple connections to the same server (which is obvious, but we forgot to mention). Kind regards

Hello! By default the Configuration Generator generates embedded with certificates and keys .ovpn files. Please tick "Advanced Mode" then tick "Separate certs/keys from .ovpn files". Kind regards

Hello! That's our new speed test Kind regards

Hello! Please follow the instructions for Android by clicking "Enter" from the upper menu and then clicking the Android icon. Direct link: https://airvpn.org/android Kind regards

Hello! It's 10.4.0.1 in any case. Kind regards

@gigan3rd Thank you very much for the update! Kind regards

I found this to be wrong. Yesterday I connected with my OpenVPN client to Seginus, DE. Then I connected with my Android device to Germany (connection to the best server). It connected me to Seginus, DE. So basically I had two connections to the same server. MESSAGE EDITED Hello! You are partially right. You can NOT connect the same account twice or thrice to the same AirVPN server, port and protocol, because in this case your different devices will be assigned the same VPN IP address, causing a continuous conflict which will disconnect them both in turn in a never ending loop. In your case you (if you connected both devices to the same server, port and protocol) could have had the feeling that both were connected at the same time, but in reality they were not: only one was really tunneling at a given time. It is possible to break this limitation with OpenVPN, but the more immediate solutions would create potential problems, in particular potential problems to Windows clients, so we decided to not apply them because in any case this limitation is not very serious and the beta testing with this setup (i.e. the current setup you are currently using) went very well. An immediate but partial workaround, however, does exist: you can just connect to the same server on two different ports and/or protocols. In this case the devices will "go into" different subnets, will be handled by different OpenVPN daemons and there will be no conflict, except for port forwarding, which will NOT work properly. Kind regards

Hello! Maybe some process that's multicasting on local subnetwork? Are you able to determine which process is sending out such a massive quantity of data (it could be something that sends data locally, for example to one of the multicast addresses in the range 224.0.0.0 - 224.0.0.255)? Kind regards