Staff

How can I prevent leaks in case of unexpected VPN disconnection? We strongly recommend that you set the proper firewall rules. Different solutions are deprecated for security reasons. We provide instructions for Comodo, pf, ipfw and iptables. The rules can be easily adapted for any other good firewall. On the forum announcements section you can find the links to the instructions for each firewall.If you run the free and open source Air software client "Eddie", you can enable "Network Lock" option: https://airvpn.org/topic/12175-network-lock/ In this case, you don't need any instruction for any firewall.

What is the difference between TCP and UDP ports? Which port should I choose? UDP is a connectionless protocol, so during the handshake it is not always possible to do an effective error correction. As a result, when there's high ping or low quality line during the OpenVPN login, the handshake may fail, although you could see no significant problem after (if) the connection is established. TCP is capable of handling these problems. On the other hand, UDP is more efficient once the connection is established. If you experience problems with VoIP video/audio conversations when connected to the VPN through a TCP port, a typical case for which a difference may be visible (VoIP over TCP - for example UDP over TCP - is clearly inferior to VoIP over UDP because TCP implements ARQ, UDP does not), then go for an UDP connection. In general, you should always try an UDP connection if your ISP allows it and you don't experience any problem during the handshake. A particular case is a connection over TOR or over an http-proxy. In this case, TCP is mandatory. Variety of ports (53, 80, 443) is an additional option to try to bypass country or ISPs blocks, or bandwidth management.

You provide Remote Port Forwarding, what is it? "Remote port forwarding" forwards traffic coming from the Internet to our VPN server ports to a specified local port of your client. By default, your account has no forwarded ports, and this is good as long as you don't wish to have a service reachable from the Internet. For example, suppose that you want to run a web server behind our VPN, or that you wish to receive incoming connections to your BitTorrent client in order to improve p2p performance, or to seed a file. Without at least one remotely forwarded port, your service could not be reached from the outside, because our VPN server would reject the proper packets to your service. Usually this is a good security measure against attacks, but it prevents your services to be reached from the Internet. When you remotely forward an inbound port, our servers will open that port (TCP, UDP or both, according to your selection) and will properly forward incoming packets to you on that port. The service will be reachable from the exit-IP address of the VPN server your system is connected to. You can forward up to 20 ports simultaneously. You can do that on our website, in your account "Client Area". You can't forward ports lower than 2048. You can map a remotely forwarded port to a different local port: this is useful for a variety of cases, for example when your service listens to a port lower than 2048 or when the port is already reserved. More details about it here below. Once you reserve an inbound remote port for your account, you have two options: 1) Leave the "Local" field empty. In this case, packets arriving to the VPN server exit-IP address port n will be forwarded to your machine IP address inbound local port with the very same number n 2) Fill in the "Local" field with a different port number x. In this case packets arriving to port n will be forwarded to your system inbound local port x. In both cases you need to reach the service on the VPN server exit-IP address port n. IMPORTANT: do NOT forward on your router the same ports you use on your listening services while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes unencrypted packets to be sent outside the tunnel from your client. However, if you connect a router (for example DD-WRT, Tomato based firmware router) an additional step is required, please see https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/ NOTE: you can't reach your listening service(s) through the VPN server exit-IP address from the very same machine that's running it/them and is connected to a VPN server, or from any other machine connected to that same VPN server.

Hello! We have identified the problem and we'll work to fix the bug in the next days. The problem arises only if you access your forwarded ports panel just after you have switched one or more VPN servers (i.e. if you connect to 2 or more servers in less than 2-3 minutes). It will take some time to fix the bug. In the meantime, if you meet again the problem, all you have to do is waiting 2-3 minutes without switching servers, or avoid to access the port forwarding panel for 2-3 minutes since your last server switch. We apologize for the inconvenience. Kind regards

Hello! Your question has been already answered in the previous post. Kind regards

Hello! We're looking into the issue, thank you for the warning. Kind regards

Hello! As you can see, we have deeply modified our system: new forum, new account processor, new support implementation and more. The forum enables you to use several functions that were previously unavailable, including the repeatedly required PMs between members, while the new account processor is much more flexible, eliminates some irritating defects of the previous one and offers additional features. The new support system allows us to follow and handle your requests and tickets more quickly and effectively. Don't hesitate to post your feedback if you wish so! Kind regards AirVPN Team

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