Staff

"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

Hello! Do you mean that when you forward remotely a port, everything is fine for some days and then the forwarded port does not work anymore for you on any server? If so, it's very strange, we'll investigate. We are looking forward to your confirmation (or feel free to elaborate, any detail could help us). Kind regards