Staff

Hello! A guide to prevent any leak (including DNS leaks and leaks in case of unexpected VPN disconnection) for Windows with Comodo firewall: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 If you just want to prevent DNS leaks, you can either follow the guide in http://dnsleaktest.com or force the following DNS in your physical network card (ethernet and/or wireless): 10.4.0.1 as primary (preferred) DNS 10.5.0.1 as secondary (alternate) DNS In the above case please consider that your system will not be able to resolve names when disconnected from the VPN, therefore you'll need to edit your hosts file to add the resolution for airvpn.org in order to allow connection in case you use the Air client (future release of the Air client will adopt a different approach which will solve this issue and will be much more aggressive against censorship). See the above guide for more details about the hosts file. Kind regards

If you're behind a VPN, even if your DNS is leaking, your IP cannot be determined directly. If a site manages to find out your real IP, that's because it was likely done via cookies. Other mechanisms exist as well, via Javascript, Java and Flash. There may be other ways, as well. If you clear out your cache and cookies, then install a bunch of gatekeeper add-ons via Firefox, you should be alright. Maybe I'll write another guide on how to do this... Hello! Javascript by itself does not allow to read your network cards. If you accept to run .NET, Java and Flash code with administrator/root privileges, they can read your network cards. However, this operation by itself in general is not sufficient to disclose your real IP address with OpenVPN in routing mode, because none of your network cards know the real IP address assigned to you by your ISP: the tun adapter has the internal VPN address, while the IP address of the physical network adapters is the one assigned to the computer by the router (if the system is behind a router NAT, a very common situation). You can imagine malware which tries to read the router configuration, but then again you must provide the malware with root privileges AND give it the password to access the router configuration, unless the router is totally unprotected, or unless the router publishes on the home page of its web interface the assigned ISP IP address, in which case the malware can detect the router IP address by reading your network cards and then access the router http interface and parse it to extract the real IP address. If your router publishes on its home page the IP address assigned by your ISP, a trivial but effective protection against such malware is dropping packets toward your router IP address port 80. For example, in Comodo, defining a top global rule (before the Allow rules in our guide) like the following: Block TCP Out From IP In [Home Network] To IP Where Source Port Is Any And Destination Port Is 80 (remember to delete this rule when you need to access your router configuration page via http). Important: if any of your network cards contains the IP address assigned to you by your ISP (for example if your computer is directly connected to the ISP network without any NAT router) then letting root privileges to any unknown application is an unacceptable risk. But also in general no application that you don't know very well should be authorized to run with elevated privileges and it is mandatory, as a general rule, not to leave the configuration router settings accessible without a password. Kind regards

Hello! The alleged "NL menace" is currently a fantasy, the cited legal framework is a mix od draft proposals which can't in any way infringe the EU legal framework on privacy and data protection, the ECHR and the Charter of Fundamental Rights of the European Union. That said, if you assume that your adversary has the power to wiretap in real time (even illegally) all the VPN servers, capture the traffic, correlate the incoming and outgoing traffic, you can defeat such an adversary with partition of trust. You might like to read the following article: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards

Hello! The problem is caused by your proxy, either it is not running, refusing connections or not listening to port 9050. Please make sure that your proxy is properly configured and that the proxy type (http or socks) matches the proxy type you have chosen in the client settings. If you don't have a proxy (i.e. you don't want to connect over OpenVPN over a proxy), please set back to default (Proxy-->Type: "None") the Proxy combo box in the Air client "Preferences" window (right-click on the dock icon and select "Preferences"). Kind regards

Hello! Can you please send us the connection logs? Kind regards

Hello! Probably it's just a false positive from the UDP system check. We'll look into the issue. Kind regards

Hello! As far as this admin knows no, it is not possible on Windows with our setup and our server pushes. You can anyway achieve the same purpose by running a VM and performing an OpenVPN connection on the host and a different OpenVPN connection on the guest OS. Connect the guest OS to the host via NAT, not bridged mode. In this way in the guest OS you will have connections over OpenVPN over OpenVPN. Kind regards

Hello! Don't worry, it's a problem easily fixable. It is caused by the fact that Tunneblick 3.2.8 is not compatible with Mac OS X 10.8.x. Please upgrade to Tunnelblick 3.3beta21b: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 Kind regards

Hello! Excellent! Everything you did is correct and the tests you have performed confirm that you are protected against any leak. The uTorrent application rules are superfluous but you can keep them, they do no harm (but see below). As a side note, you might like to disable logging for the "Allow" rule in the uTorrent application rules in order not to overload Comodo logging which in some cases might slow down your system slightly. Kind regards

Hello! This is a copy & paste of an e-mail from the support team you should have received a few minutes ago, this admins pastes it here for general knowledge: On 02/06/2013 04:55 AM, fawkesguy wrote: > I have port forwarding enabled, and it's working for my web server and webcam, but I can't get it setup for Xbox Live. Xbox Live needs port 3074 UDP & TCP opened. I have my AirVPN forwarded port set to UDP & TCP, local port 3074. I've also tried it without setting the local port. Doesn't work either way. I'm also using DNAT. Below is what's in my firewall. The Xbox is 192.168.1.50 I've deleted the entries for the web server and webcam. > > iptables -I FORWARD -i br0 -o tun1 -j ACCEPT > iptables -I FORWARD -i tun1 -o br0 -j ACCEPT > iptables -I FORWARD -i br0 -o eth0 -j DROP > iptables -I INPUT -i tun1 -j REJECT > iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE Hello! The rule iptables -I FORWARD -i br0 -o eth0 -j DROP might be right or wrong (it depends on your setup) try to delete it for testing purposes (only after you have corrected another rule, see below). > > iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 2127 -j DNAT --to-destination 192.168.1.50 > iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 2127 -j DNAT --to-destination 192.168.1.50 Why the above rules are duplicated? Maybe the Xbox needs UDP packets as well, try to change the second one to: iptables -t nat -I PREROUTING -i tun1 -p udp --dport 2127 -j DNAT --to-destination 192.168.1.50 (note "-p udp" instead of "-p tcp" on the second rule) Kind regards AirVPN Support Team

Hello! Please note that 4 Mbit/s is the minimum guaranteed allocated bandwidth per each user, please see here for more details: https://airvpn.org/faq#speed In order to pick the server which can provide you with the best performance please: - connect to various server which are NOT at 100% capacity on different ports (in particular try 443 UDP, 53 UDP and 80 TCP) - perform the internal speed test on different times for each connection to every server, every port and every protocol, so that results are not biased by further, external servers and time fluctuations: http://speedtest.air Kind regards

Hello! The Air client is portable, it is not installed in the system. OpenVPN installation does not change anything pertaining to port forwarding. If you could be more specific, we should be able to provide you with additional support. Kind regards

Hello! About web sites, you might like to check for DNS leaks here while your system is connected to an Air VPN server: http://dnsleaktest.com If you run a torrent client, you can check that there are no leaks here (remember to launch your torrent client AFTER your system is connected to the VPN: http://checkmytorrentip.com/ For a general check of a successful connection, see your client logs, also browse to our web site from the connected to the VPN system and look at the central bottom box, it must be green showing "Connected!" and the server name your system is connected to. Kind regards

Hello! Yes, but not with OpenVPN. Have you ever managed to disclose a real IP address from a client behind an OpenVPN server with Flash? If so, in which environment? Kind regards

Hello! Can you please make sure that you select a TCP port in the "Modes" tab of the Air client just before you start the connection over the proxy? Kind regards

Hello! Yes, please select "Enter" menu and click the iOS icon to see instructions for iOS, direct link: https://airvpn.org/ios Kind regards

Hello! The performance you experience may be normal in optimal conditions. After you have connected please browse to our web site with the same connected computer and look at the central bottom box. If it's green your system is really connected, if it's red it's not. In this latter case, please send us the client connection logs. Kind regards

Hello! Let's determine if it's a DNS issue. When you connect to a VPN server and you can't browse, please open a command prompt and issue the following commands: ping 10.4.0.1 ping google.com ping 212.117.180.25 and send us the output at your convenience. Kind regards

Please see here: https://airvpn.org/faq#speed Correct. Yes, it is possible, and yes, you can use external desktop connection in the same network. Kind regards

Hello! Maybe they are two distinct problems. Can you please send us your client logs? After you have tried a connection and the problem occurs, please right-click the Air client dock icon, select "Logs", click "Copy to clipboard" and paste in the forum message. Kaspersky might interfere if not configured properly, let's see if the logs can help in troubleshooting. Kind regards

Hello! Can you please tell us your exact OS version? Kind regards

Hello! Great news, thank you for keeping us informed. About Replay-window backtrack, a few of them may be unavoidable with UDP, due to network congestion, sporadic packet loss... if it's a replay attack, OpenVPN can defeat it easily. A connection toward a TCP port will prevent that error (and it is also an additional security layer against replay attacks at the price of a performance hit due to full error correction implemented in TCP). There is some admin's article about that in the forum, you might find it interesting: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784 We strongly recommend NOT to alter OpenVPN replay protection sliding-window size and time unless absolutely necessary. Modofying such parameters in a human rights hostile country is an unacceptable risk. Increasing replay protection sliding-window size and/or time on an UDP connection may significantly weaken OpenVPN ability to defeat replay attacks, exposing you to injection of forged packets from malignant governments or entities with the ability to monitor your ISP lines. Kind regards

Hello! It's UDP, please see here: https://airvpn.org/faq#udp_vs_tcp Kind regards

Hello! Let's determine if it's a DNS issue. When you connect to a VPN server and you can't browse, please open a command prompt and issue the following commands: ping 10.4.0.1 ping google.com ping 212.117.180.25 and send us the output at your convenience. Kind regards

Hello! Yes, in order to determine if it's your ISP fault you need to be disconnected from the VPN when you perform tracert and ping. Kind regards