Jump to content
Not connected, Your IP: 216.73.216.248

Staff

Staff
  • Content Count

    11389
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1978

Everything posted by Staff

  1. @drewwheelerosman Hello! From the second post you published everything seems fine. Can you also send us the output of ping google.com as usual while you are connected to the VPN. Kind regards
  2. 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
  3. 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
  4. Hello! Please right-click on the Air client dock icon, select "Logs" and click on "Copy to clipboard", finally paste here. Kind regards
  5. Hello! Your account is successfully connected to another server, can you confirm that you could manage to connect properly? Kind regards
  6. Hello! Can you please send us your client logs? What is your OS? Kind regards
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. Hello! Can you please send us the client logs just after you get that error? Kind regards
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. Hello! Your account is authorized to access all the VPN servers, can you please try again and report back at your convenience? Kind regards
×
×
  • Create New...