Staff

Hello! We're very glad to introduce native support for OpenVPN over SSL and OpenVPN over SSH, and a completely re-designed configuration generator which includes exciting, additional AirVPN services and features. Our service becomes more censorship resistant and easier to use with a wide range of OpenVPN GUIs and wrappers. UPDATE OCT 2014: EDDIE CLIENT AirVPN client version 2, codename Eddie, gets out of the beta testing with version 2.6. Free and open source, it is a major breakthrough from client versions 1.x. Available for Linux, Windows and OS X Mavericks and Yosemite. Eddie includes Network Lock, full integrated TOR support for OpenVPN over TOR, support for OpenVPN over SSL and SSH, "intelligent" anti-censorship circumvention technique, "intelligent" VPN servers efficiency and rating calculations and much, much more. https://airvpn.org/topic/12464-eddie-27-available Currently the only open source OpenVPN wrapper in the world which allows OpenVPN over TOR connections without middle boxes or VM on three different OS. NEW SERVICES: OPENVPN OVER SSL - OPENVPN OVER SSH OpenVPN over SSL and OpenVPN over SSH will allow you to bypass OpenVPN connections disruption. Known ISP countries where the disruption takes place are China, Iran, Syria, Egypt. The connection disruption is possible because OpenVPN connections have a typical fingerprint which lets Deep Packet Inspection discern them from pure SSL/TLS connections. Connecting OpenVPN over SSL or OpenVPN over SSH will make your connection undiscernable from pure SSL or SSH connections, rendering DPI fingerprint identification powerless. OpenVPN over SSL/SSH is included in every Premium subscription without any additional payment. Use OpenVPN over SSL/SSH only when necessary: a slight performance hit is the price to pay. The performance hit is kept as low as possible because the "double-tunneling" is performed directly on our servers without additional hops. NEW FEATURES A new system for host resolution (not available for Windows) and dynamic VPN server choice is available. This will let you have OpenVPN configuration files which will try connections to various servers (according to your preferences) if one or more servers are unavailable. A new connection port (2018) is now available on all Air VPN servers. A new, alternative entry-IP address is now available on all Air VPN servers. NEW CONFIGURATION GENERATOR FEATURES - You can now select servers by countries, continents and planets (currently only one planet) or any combination between single servers and countries. - You can now select an alternative entry-IP address. Each Air server has now an additional entry-IP address to help you bypass IP blocking. - You can now choose a wide variety of compressing options: zip, 7zip, tar, tar & gzip, tar & bzip2. - You can now choose not to compress the files and download them uncompressed one by one NEW CONFIGURATION GENERATOR "ADVANCED MODE" FEATURES - Total connection ports range available, including new port 2018 in addition to 53, 80, 443 and (for SSH) 22. - Option to generate non-embedded configuration files, mandatory if you use network-manager as OpenVPN wrapper under Linux or just in case you use any wrapper that does not support embedded with certificates and keys OpenVPN configurations. - Option to generate files and scripts for OpenVPN over SSL/SSH connections by clicking on "Advanced Mode" - Option to select "Windows" or "Linux and others". Make sure you select the correct option according to your OS, because connections over SSL/SSH in Windows require different files than those required for Linux, *BSD and Unix-like / POSIX compliant systems such as Mac OSX. - New options to generate configuration files that support proxy authentication for OpenVPN over a proxy connections, particularly useful if you're behind a corporate or college proxy which requires authentication. A significant example of usage of OpenVPN over a proxy is OpenVPN over TOR: https://airvpn.org/tor Instruction page for OpenVPN over SSL (only if you don't run our client Eddie): https://airvpn.org/ssl Instruction page for OpenVPN over SSH (only if you don't run our client Eddie): https://airvpn.org/ssh Please do not hesitate to contact us for any additional information. Kind regards & Datalove AirVPN admins

"airvpn.org" blocked (DNS poisoning) Solution: hosts file edit OpenVPN connections are frequently disrupted (reported in Shangai and Beijing) Solution: OpenVPN over SSL works just fine UNCONFIRMED: momentary blocks of Internet domestic lines if a high percentage of encrypted traffic is detected

Extreme port shaping on outbound ports 443 UDP and 80 UDP. Solution: high performance to port 53 UDP

"airvpn.org" blocked. Advisory did not report if the cause is DNS poisoning or IP block. Solution in any case: hosts file edit and alternative AirVPN frontend access.

Vodafone (at least, Vodafone Italia and UK) redirect any external request to UDP 53 to their DNS servers. So it's impossible to connect to AirVPN servers through UDP 53 with this ISP. Under this ISP, connection to UDP 53 may not work at all, or may return this error: TLS Error: client->client or server->server connection attempted from [AF_INET]...

In order to prevent leaks on *BSD and Mac OS X systems with pf, please see this guide by jessez: https://airvpn.org/topic/1713-win-mac-bsd-block-traffic-when-vpn-disconnects/page-2?do=findComment&comment=2532 Thank you very much jessez! Kind regards

EDITED ON 21 Aug 12 EDITED ON 24 Nov 12: added important note for some Linux users, see bottom of message EDITED ON 02 Jun 15: please refer to https://airvpn.org/faq/software_lock for a more advanced set of rules WARNING: this guide assumes that you have no IPv6 connectivity. If you have, you should block outgoing IPv6 packets while connected to the VPN with "ip6tables". Please see https://airvpn.org/faq/software_lock Hello! You can use iptables, a very powerful packet filtering and NAT program (probably one of the most powerful, if not the most powerful of all). iptables is already included in all official Ubuntu distros and most Linux distros, anyway if you don't have it just install it with aptitude. Adding the following simple rules will prevent leaks in case of [accidental] VPN disconnection. In this example, it is assumed that your network interface is eth+ (change it as appropriate; for example, you might have wlan0 for a WiFi connection). a.b.c.d is the entry-IP address of the Air server you connect to. You can find out the address simply looking at the line "remote" of your air.ovpn configuration file. In case of doubts, just ask us. Some of the following rules might be redundant if you have already chains. Assumptions: you are in a 192.168.0.0/16 network and your router is a DHCP server. You have a a physical network interface named eth*. The tun adapter is tun* and the loopback interface is lo. iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #allow loopback access iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server iptables -A INPUT -s 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server iptables -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT #make sure that you can communicate within your own network iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i eth+ -o tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth+ -j ACCEPT # make sure that eth+ and tun+ can communicate iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE # in the POSTROUTING chain of the NAT table, map the tun+ interface outgoing packet IP address, cease examining rules and let the header be modified, so that we don't have to worry about ports or any other issue - please check this rule with care if you have already a NAT table in your chain iptables -A OUTPUT -o eth+ ! -d a.b.c.d -j DROP # if destination for outgoing packet on eth+ is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects When you add the above rules, take care about pre-existing rules, if you have already some tables, and always perform a test to verify that the subsequent behavior is what you expect: when you disconnect from the VPN, all outgoing traffic should be blocked, except for a reconnection to an Air server. In order to block specific programs only, some more sophisticated usage of iptables is needed, and you will also need to know which ports those programs use. See "man iptables" for all the features and how to make the above rules persistent or not according to your needs. Warning: the following applies ONLY for Linux users who don't have resolvconf installed and don't use up & down OpenVPN directives with update-resolv-conf script In this case, your system has no way to process the DNS push from our servers. Therefore your system will just tunnel the DNS queries with destination the DNS IP address specified in the "nameserver" lines of the /etc/resolv.conf file. But if your first nameserver is your router IP, the queries will be sent to your router which in turn will send them out unencrypted. Solution is straightforward: edit the /etc/resolv.conf file and add the following line at the top (just an example, of course you can use any of your favorite DNS, as long as it is NOT your router): nameserver 10.4.0.1 # in order to use AirVPN DNS nameserver 31.220.5.106 # in order to use OpenNIC DNS only if AirVPN DNS is unavailable Kind regards Original thread post: https://airvpn.org/topic/1713-win-mac-bsd-block-traffic-when-vpn-disconnects/page-2?do=findComment&comment=2010

Hello! It looks like a known OpenVPN 2.1 and 2.2 bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657964 This bug shows up only under very particular circumstances (we are unable to reproduce it on many systems we have tried), as you can read. If possible, try on your OpenSUSE to upgrade to OpenVPN 2.3. Kind regards

Hello! It can't work, because uTorrent must be able to receive incoming packets from every IP address and must be able to send out packets to any IP address. Remember that when you're inside the VPN, packets to/from any application pass through the tun adapter. When they touch your computer physical network card they are still/already encrypted. So, a much faster solution is simply dropping any packet out from uTorrent not coming from the IP range 10.4.0.1-->10.9.255.254. That's because: https://airvpn.org/specs - so when you're connected to an Air server your tun adapter will always have an IP inside this range. If the VPN connection unexpectedly fails, packets from uTorrent will no more pass through your tun adapter, therefore they will not come from the aforementioned IP range and will be dropped by the firewall. If your firewall does not support application rules, you can set global rules for your physical network interface that: - accept packets from any address to the entry-IP address of the Air servers - accept packets from the entry-IP address of the Air servers to any address - accept packets from your internal network IP range to your internal network IP range (to allow communications inside your own net) - accept packets to 255.255.255.255 (to allow DHCP) - drop anything else Please see here for more details: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! No, with JavaScript alone it is not technically possible to enumerate a system network interfaces, so JavaScript is not harmful in this context and can't leak you real IP address. Kind regards

Hello! Clearly that was the key. It would be really interesting to know which data you have now deleted, that you did not previously delete, because in those data there's the key to understand how YouTube could locate you (wrongly or rightfully, it does not matter) in Germany. Kind regards

Hello! You can bind the applications that you do NOT want to be tunneled to your physical network adapter with ForceBindIP: http://www.r1ch.net/stuff/forcebindip/ Please see also here for potential problems with Windows 7/8 64 bit: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=6621&limit=6&limitstart=12&Itemid=142#9103 Kind regards

Hello! We could manage to solve the problem on a Windows 7 64 bit system by disabling UAC and running ForceBindIP from a command prompt launched with administrator privileges. Hopefully this will work in your system too. Kind regards

Hello! Problem solved: BBC and iPlayer are again accessible from Phoenicis (Romania). Kind regards

Hello! We're currently experiencing port forwarding problems on Phoenicis only [EDIT: problem solved]. The fact that it works for a couple of days is quite puzzling, does it happen on every and each server? For example, if you change server without changing forwarded port, does it work again? Kind regards

Hello! It's a permission problem. Anyway, you must not generate a key. Your key is generated by our servers and can be downloaded through the configuration generator (menu "Member Area"->"Access without our client"). It only means that your system suffers of DNS leaks, please see here to fix: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=9049&Itemid=142#9051 Kind regards

Hello! According to some reports, ForceBindIP does not work anymore on Windows 7 64 bit after latest updates, but you might solve the issue by disabling UAC. Also, please check here: http://john.jhw.co.za/?p=161 Kind regards

Hello! We confirm you that the video you have embedded is accessible from every Air server except Phoenicis. The video you have linked is accessible from our Germany servers as well. You have already made sure that HTML5 geo location is disabled, that cookies and flash cookies have been wiped out and that you are not logged in YouTube with a German account, correct? If so, just for an additional check, please read here about a user in the USA who had your same problem and make sure that your system is clean from malware: http://productforums.google.com/forum/#!topic/youtube/zWnsZsxXa0c Please also test, if possible, with another machine where you run a portable browser to make a comparison. Kind regards

Hello! We recommend Comodo for Windows on the basis of objective tests on pro-active security. The PCMag article you refer to unfortunately lacks the depth and the objectiveness of such tests. Although the writer is a very competent person, the article seems to be targeted unfortunately to readers with rudimentary or none technical knowledge (the sentence "Super-techie users will love it; ordinary folks may be a bit overwhelmed." is disconcerting, to say the least). Compare the poorly mentioned tests of the PCMag article (for Comodo but also for ZoneAlarm) with the detailed and reproducible tests performed here: http://www.matousec.com/projects/proactive-security-challenge-64/results.php That said, we have always underlined that Windows lacks a real powerful packet filtering tool. If compared to iptables and pf, Windows firewalls are weak and lacking important functions. But there's no alternative for Windows users, so we recommend to use the firewall that at least passes successfully the highest number of leak tests, and Comodo performs better than any other software firewall for Windows. This is just a recommendation, of course we also recommend that you form your own, informed opinion and pick your firewall accordingly. Kind regards

Hello! Yes, the VPN server sees your IP address while your machine is connected to it and until it closes the connection, that's quite obvious (it's how the Internet is possible). If you need to hide your real IP address to our servers you have some options, for example: https://airvpn.org/tor We have widely discussed on this important argument since years ago, when a stronger anonymity layer is needed (typically for whistleblowers or persons operating in human rights hostile countries, or in any case in which you simply can't afford to trust us), for example here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards

Hello! In this case no possible correlation is visible to this admin. If anybody has some idea (which does not rely on web server intrusion/security breach) please feel free to post. Kind regards

Hello! We don't detect any problem in YouTube geo-location of all the other Air servers, so it's your browser or your system that's telling YouTube that you're in Germany. Please do not hesitate to inform us if you find the "guilty" leaker. HTML5 geo-location is disabled, right? EDIT: can you also post a link to a YouTube video not available in Germany that you can't access from Air servers (except Phoenicis)? Kind regards

Hello! As long as you don't allow correlations no security concerns are apparent. To make an example (it's a stupid example, but just to make it clear), assume that you want to run an FTP server behind an Air VPN server (for privacy reasons, for example), on a machine which also runs a web server which does not need that privacy. If you allow the web server to be reachable from the physical network interface and the FTP server only from the tun adapter, your machine may become vulnerable to correlations, i.e. it could be possible to discover that the web server runs on the same machine where the FTP server runs and therefore it would be possible to discover the real IP of the FTP server too. Kind regards

Hello! Understood, just one more question, the torrent client does not connect at all, or does it just display a yellow token and works anyway? In other words, the torrent client is unable to receive incoming connections or is it completely unable to work? Kind regards

Hello! If you're connected to Phoenicis, YouTube wrongly identifies Phoenicis exit-IP address as coming from Germany. It's a YouTube mistake, nothing more. Kind regards