Staff

Hello! As you prefer. Using our DNS will give you the following advantages: - access to internal services (currently only http://speedtest.air) - ICE censorship bypass - access to our experimental service aimed to bypass IP-based geo-location discriminations (for example you can watch BBC iPlayer from non-UK servers and access CBS and Pandora from non-USA servers) In most cases it's not a reason for concern, but if you exchange sensitive, "critical" information (for example if you are a whistleblower, or you live in a human rights hostile country) you should disconnect as soon as the critical information have been imparted or received. This attention is not necessary if you connect over OpenVPN over TOR. Which proxy server? Kind regards

Hello! In the first part of the logs apparently something was blocking UDP packets, but after that the logs show no problems at all. Let's see if it's a DNS problem. Please open a command prompt or the PowerShell, issue the following commands and send us the output: ping 10.4.0.1 ping airvpn.org ping 8.8.8.8 Kind regards

Hello! Please right-click on the Air client dock icon, select "Logs" and click on "Copy to clipboard", finally paste here. Kind regards

Hello! Your account is successfully connected to another server, can you confirm that you could manage to connect properly? Kind regards

Hello! Can you please send us your client logs? What is your OS? Kind regards

Hello! No, they are single IP addresses (each server has one entry-IP address), so pick add single IP addresses for that network zone. In this case yes, they are necessary. To add the lines to the hosts file launch a text editor (for example notepad) with administrator privileges, load the hosts file, add the lines and save the file. The file on standard Windows installation is inside the following directory: C:\Windows\system32\drivers\etc Yes, they are necessary. Correct, although it does not really matter what DNS you put in your physical network card, because any query from that card will be blocked by Comodo. Anyway you might like to put your favorite DNS in your physical network card so that you can regain full Internet connectivity when disconnected from the VPN if you decide to disable Comodo rules (just in case you need to connect to the Internet without VPN). Kind regards

Hello! Sure: you can see our guide linked in announcement section of the forum. Direct link: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! Presumably this is what happens: - the Google servers are showed for DNS queries inside the tunnel - the Comodo servers are showed for DNS queries both inside and outside the tunnel Therefore the DNS leak test in this case does not provide a clear result because you can't discern queries sent to Comodo DNS within the tunnel from those sent to Comodo outside the tunnel. After a very long discussion and evaluation, we have taken the decision to drop Google DNS. There will be no noticeable performance impact to our customers on DNS resolution and the DNS leak tests will give a much clearer response. The change is expected to take place within one week. Kind regards

Hello! It's totally normal. In order to understand which DNS server you're using to resolve names, dnsleaktest.com needs to operate its own DNS server through which it monitors which DNS server the requests to randomly-generated subdomains (transmitted to your browser) of their own domain come from. As a consequence, your system will repeatedly query your configured DNS (to resolve such subdomain names) servers which in turn send the request to the most convenient DNS server of their infrastructure (which may vary from second to second). Kind regards

Hello! Presumably this is what happens: - the Google servers are showed for DNS queries inside the tunnel - the Comodo servers are showed for DNS queries both inside and outside the tunnel Therefore the DNS leak test in this case does not provide a clear result because you can't discern queries sent to Comodo DNS within the tunnel from those sent to Comodo outside the tunnel. After a very long discussion and evaluation, we have taken the decision to drop Google DNS. There will be no noticeable performance impact to our customers on DNS resolution and the DNS leak tests will give a much clearer response. The change is expected to take place within one week. Kind regards

Hello! Can you please send us the client logs just after you get that error? Kind regards

Hello! It means all the ports which OpenVPN in our servers listen to: 53 UDP and TCP, 80 UDP and TCP, 443 UDP and TCP. Kind regards

Hello! No, it's not there (no tls-auth required). Leave it blank, just fill the server certificate, the client key and the client certificate. (EDIT: since 13 Apr 2014, TLS Auth has been introduced) Kind regards

Hello! If Gargoyle OpenVPN reads the OpenVPN configuration files, all those directives are included in the configuration file. If the router web interface lacks such options, you'll have to convince OpenVPN to read and parse the configuration file. Probably Gargoyle forums can support you in a more effective way. According to gargoyle-router.com admins, Gargoyle supports fully OpenVPN configuration files. Kind regards

Hello! You don't need to read the whole thread... only this post: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=42&Itemid=142#2756 We strongly recommend that you spend a couple of minutes to read the welcome e-mail and the FAQ. Besides sending an e-mail to everybody at the subscription explaining all the points to use our service at best (including how to prevent leaks in case of unexpected VPN disconnection), with relevant links, publishing FAQ which focus also on the issue of preventing leaks in case of unexpected VPN disconnection, keeping a forum open to everyone (although moderated to prevent spam and trolling), putting permanent links on how to prevent leaks in the announcement section and answering ten thousand times to the same ten thousand identical questions... no, we have not planned anything else to make you aware that a VPN connection can drop unexpectedly just like any packet switching based connection. Humor mode suffered by this admin tonight apart, please do not hesitate to contact us for any further information or support. Kind regards

Hello! Gargoyle parses correctly .ovpn OpenVPN configuration files. Unsure whether it has issues in supporting embedded files, probably not, anyway you can generate non-embedded files (just untick the "Embed..." option in the configuration generator). Kind regards

Hello! You need to modify your Comodo rules with the correct IP addresses (to allow the Air client to communicate not only with the VPN server(s) you picked, but also with the frontends. Allow any communication from/to 85.17.207.151 and 212.117.180.25 Kind regards

Hello! The correct lines to put in your hosts file are currently: 85.17.207.151 airvpn.org 212.117.180.25 airvpn.org 46.105.19.36 is one of the frontends which we discarded long ago. Kind regards

Hello! Yes, there's a pound symbol '#' at the beginning of the relevant lines. That symbol put at the beginning of a line in hosts tells the system that that line is a comment. That line will therefore not be evaluated. Please remove the # at the beginning of the lines for airvpn.org resolution. Kind regards

Hello! From the logs it appears that on your Windows 8 the TAP-Win32 interface does not come up.. not even with the Air client 'hack'. First, you can try a Winsock and stack reset (from a command prompt with administrator privileges): Reset WINSOCK entries to installation defaults: netsh winsock reset catalogReset IPv4 TCP/IP stack to installation defaults: netsh int ipv4 reset reset.logAfter the above commands are issued a reboot is unfortunately mandatory. If the above does not solve the problem, can you please make sure that: - no programs (especially antivirus and firewall) are interfering with airvpn.exe, openvpn.exe and tap09*.sys (the driver for the tun/tap interface) - the Air client can elevate to administrator privileges - OpenVPN can elevate to administrator privileges - the DHCP *client* service is running - TAP driver is installed correctly (in case of doubt, try to uninstall OpenVPN completely and re-install it, making sure to authorize the installation of any driver) Kind regards

Hello! Perfect, you have no DNS leaks. Just for your information, an internal Air team discussion pertaining to drop Google DNS in our service is ongoing. Kind regards

Hello! The logs show that there's no packet loss and no packet fragmentation. Do you get the SAME performance from ALL the servers you tried on ALL the ports? Kind regards

Hello! Very interesting and annoying problem, difficult to say anything for sure. Do you have Comodo installed? If so, can you please perform a test with all Comodo components in "Disabled" mode? This problem has been reported under similar conditions here: http://superuser.com/questions/4543/audio-distortion-and-dpc-latency-in-vista-during-network-usage-after-several-hou One user reported that he/she could solve the problem, unfortunately, only by disabling Comodo. If it's your case it's worth to upgrade to latest Comodo version and if the problem persists and the culprit is Comodo you might like to report to Comodo community this important problem. If you don't have Comodo installed, please see here to get some hints: http://superuser.com/questions/202254/how-do-i-get-to-the-root-cause-of-high-deferred-procedure-calls/247713#247713 The above research pertains essentially to Windows Vista, but it is probably applicable to Windows 7 as well. Finally, the AMD Athlon 3000+ does not have internal AES encryption/decryption (our OpenVPN data channel cipher is AES-256) so if you have high bandwidth (beyond 20 Mbit/s) on the fly encryption/decryption could cause highly deferred procedure calls which in turn perhaps cause the problem you detect. Please feel free to keep us informed. Kind regards

Hello! Your account is authorized to access all the VPN servers, can you please try again and report back at your convenience? Kind regards

Hello! The AirVPN client for Windows needs to resolve airvpn.org name in order to download via an encrypted connection certificates and key and then launch OpenVPN, so the quickest workaround is adding the following line to your hosts file: 46.105.19.36 airvpn.org In this way airvpn.org will be resolved without the need of a DNS query outside the tunnel which is correctly blocked with your rules when you are not connected to an Air server. You will still have to authorize packets from and to 46.105.19.36 in the firewall. Of course if we change the IP address of our frontend you will have to update your hosts file. Kind regards I don't get the part where i have to add the line "46.105.19.36 airvpn.org" to my host files. How do i do that, where should i add this line exactly? C Cause after i set the rules i get the same "The remote name could not be resolved" message. I'm a bit noob in this area Hello! The hosts file is located in %systemroot%\system32\drivers\etc\ where %systemroot% is usually C:Windows, so the path would be C:\Windows\system32\drivers\etc\ The information about airvpn.org resolution is outdated, please add the following lines: 85.17.207.151 airvpn.org 212.117.180.25 airvpn.org In order to do so run a text editor (for example notepad) with administrator privileges and load the hosts file, modify and save it. The file name is "hosts", no extensions, therefore make sure that in the text editor file requester you choose to display "All files" otherwise you will not be able to see "hosts". The updated and re-organized guide is linked in the announcements section of the forum: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards