Staff

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

Hello! If you run the Air client please right-click on its dock icon, select "Logs", click on "Copy to clipboard" and paste into your message. Kind regards

Hello! Probably not, 10.7.0.1 is the DNS address DHCP-pushed by our servers when you connect to 80 TCP. Since Viscosity fails as well, probably it's worth checking something else in your system. Do you have any program which might interfere, such as LittleSnitch? Check also your firewall rules, please. Can you establish successfully connections over TOR alone? Can you please try a connection (OpenVPN over TOR again) to port 53 TCP? Kind regards

Hello! Can you please send us your client logs (while connected to 53 UDP and 443 UDP), just to check if there's packet loss or packet fragmentation? Did you test several servers? Do they ALL provide the SAME performance? Kind regards P.S. We comply to a "no questions asked" refund policy, so if the service does not meet your requirements you still have 3 days to ask and obtain a full refund.

Hello! It's not a DNS issue... apparently you have no connectivity at all when trying to connect over a proxy. Can you please try Viscosity for testing purposes? It's not open source and it's a commercial product, but Sparklabs offer 1 month free evaluation: http://www.sparklabs.com/viscosity Kind regards

Hello! Just after the unexpected disconnection, can you please send us the complete Tunnelblick logs? In order to determine if it's a DNS issue (at least during the 1 min connection...), please send us the output of the following commands (issued from a command shell): ping 10.4.0.1 ping airvpn.org Finally, if you don't connect over a proxy, does Tunnelblick connect fine? Kind regards

Hello! Please right-click on the Air dock icon after the error occurs, select "Logs" and look at the path and filename of AirVPN.xml. Then close the Air client and delete airvpn.xml. The client will re-create it automatically. Kind regards

Hello! Are you trying the connection to a TCP or an UDP port? Kind regards

Hello! It seems that the proxy is not listening to port 9050 (or it is not running). Maybe is it listening to some other port? In Vidalia, open "Settings"->"Advanced" and uncheck the box that says 'Configure ControlPort automatically'. Your SOCKS port will then be 9050. Kind regards

@RaggaMuffin Hello! Please make sure that the torrent client is not "strangling" your line with excessive upload or download bandwidth (if you have an asymmetric line, saturation of upload bw will clog download bandwidth as well). Set your torrent client upload and download limits in order not to exceed 75-80% of your total available bandwidth. Additionally, test different ports and protocols (in particular, try 53 UDP and 80 TCP) just in case your ISP performs port shaping. Kind regards