Staff

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

Hello! Please see this thread: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=7718&Itemid=142 Kind regards

Hello! Thank YOU for sharing! Just out of curiosity, readers can compare your rules with those suggested in our guide "Prevent Leaks with Linux & iptables": https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 Kind regards

Hello! The problem seems to be here; Kind regards

Hello! It is your VPN IP address, it has been DHCP-pushed by our server to your client. About the rest we don't see any clear mistake. Can you check that the iptables rules have been properly created (check with "iptables -L")? Kind regards

Hello! A general solution is not possible, each mistake must be fixed on its own. About the case you're probably referring to, the error was in the Network Zones, in particular see the recommendation in our guide, just in case you have the same mistake. In any other case please send us all we need according to the guide thread. Kind regards

Hello! Please check that the interface name is correct (type "ifconfig" and check that it is tun0, not tun1 or anything else) and that in the iptables rule the names and "debian-transmission" are correct (use the command "ps aux | grep transmission" to check that). What is that 192.168.0.100? Kind regards

Hello! Contrarily to BBC iPlayer, UK Netflix is not accessible from our german servers. You can access it only from our UK servers. Also, we ignore the geographical detection system of Netflix: if the problem persists try to prevent your iOS to send out your real location by disabling location detection (iOS can determine your real location and send it not only from IP address, but also from GPS and surrounding WiFi hot-spots). Additionally, some iOS apps might try (without your consent) to extract your geolocation information from photographs and send them to a 3rd party (example: http://arstechnica.com/apple/2013/02/path-promises-fix-for-new-privacy-liberties-taken-by-ios-app/ ). Kind regards

Hello! We can't see the Network Zones here in the forum, by the way the Network Zones we could see from your e-mail show a mistake which causes the problem. Please check your inbox. Kind regards

Hello! Your Global Rules look fine, can you send us the Network Zones as well? Kind regards