Staff

Hello! Interesting, this looks like a completely different problem. Assuming that you started your torrent client after you connected to the VPN, new torrents work with or without port forwarding (except when you are the initial seed). It may be caused by very many different factors (DHT disabled and private trackers, unconnectable trackers etc.), so that old torrents continued to work because the client had cached at least the IP address of one active peer and peer-exchange was enabled, while new torrents could not start, missing both the DHT and tracker bootstrap. Kind regards

Hello! Can you please try a connection with the OpenVPN GUI, with the very same Comodo rules (you don't need to modify anything), and see whether the problem is solved or not? Kind regards

Hello! Just a remark: torrent clients work with Air "out of the box". They can run without any port forwarding (as millions of users behind a NAT without port forwarding know well ). Port forwarding is an additional option to improve performance and allow initial seeding, while at the same time maintaining the added security of a shared exit-IP address. Kind regards

Hello! Thank you! Just for future reference, could you briefly explain what the problem was at your convenience? We're going to increase the timeout time for post-writing in the forum. Kind regards Hello. The problem was arguably just my own stupidity. I was expecting to get a green light when checking the ports without having first input the port numbers into any software (uTorrent, Dc++, etc.). I've forwarded ports via the router before, but never had to use a separate interface like yours with a VPN service before. Even though I'm sure it seems obvious from your standpoint, you might want to put a message on the port forwarding page for noobs like myself, that says basically, "Before checking (testing) your new forwarded port, be sure to manually input the same port number into your uTorrent/hub/P2P client...", something like that. Hello and thank you again! Just in case someone is interested, we have detailed instructions for port forwarding in the FAQ, including instructions for torrent clients and eMule. FAQ are available at "More"->"Frequently Asked Question" menu, direct link https://airvpn.org/faq Kind regards

Hello! Thank you! Just for future reference, could you briefly explain what the problem was at your convenience? We're going to increase the session lifetime in the forum. Kind regards

Hello! The above line is incorrect. You should replace it with authorization for the range [10.4.0.0 - 10.9.255.255], see also here: https://airvpn.org/specs The range 10.4.0.0->10.9.255.255 covers the whole IP range of the virtual private network. 10.5.0.0->10.5.0.8 covers a very minimal, insufficient range of the private network on port 443 TCP. This apparently shows that your system is unable to resolve airvpn.org. Please make sure that the lined you added to your hosts file (hosts, not host) is really there. The hosts file is used by Windows to resolve domain names before any DNS query. Furthermore, either apply the rule for svchost.exe only after you're connected to the VPN, or use the rules for securing the VPN connection (which will also prevent DNS leaks). Alternatively, use the OpenVPN GUI to connect. Kind regards

Hello! The new configuration generator is available in menu "Client Area"->"Config generator" (on the left tabs), direct link: https://airvpn.org/generator OpenVPN clients need certificates, keys and configuration to run. You can download all of them, in any combination of server/ports/protocols, with the configuration generator. Kind regards

@imno007 Hello! Is the listening service (your torrent client in your case) running when the test is performed? Does it listen to the correct port (the same port you have remotely forwarded)? Kind regards

Hello! Yes, of course, sharing the exit-IP has the advantage to strengthen the anonymity layer but the negative side is exactly what you point out. Since the main purpose of our service is an anonymity layer as strong as possible with care for performance, we must accept the negative side and keep ready to servers and/or IP changes. Kind regards

Hello! Network congestion and latency may cause the UDP to drop packets. When this happens you can see a 'Replay window backtrack occurred' in the OpenVPN log. Unless you completely lose connectivity, this is only a overhead issue, because the OpenVPN server is able to resend lost packets even with UDP, that's why your connection works just fine. One solution is to switch to TCP if the errors become so frequent to cause a disconnection from the VPN server(s). See also: http://openvpn.net/archive/openvpn-users/2004-09/msg00068.html Kind regards

Hello! Can you please inquire Felix on how to achieve this with OpenVPN? In the statement he does not specify any detail, so it's not easy to interpret his words (unless he refers to PPTP, which we throw away for security reasons). Kind regards

Hello! While OpenVPN supports multiple VPN connections with multiple TUN/TAP adapters and it also supports connections over proxies, it is not designed to chain VPNs ("OpenVPN over OpenVPN"). You should make your own reasearch in order to check if that is even possible. Kind regards

Hello! It's not a problem of server load: Cygnus can handle many more connections. It has just 10-15% busy bandwidth and an average load next to 0. Probably you have peering issues with it, please try to change server to check. Kind regards

Hello! EDIT First of all please make sure that you refer to svchost.exe because snchost.exe is a trojan/backdoor That's correct, because your system must not be able to send out DNS queries when you're not connected to the VPN. You have three options: 1) If you use the Air client, add to your hosts file the line: 46.105.19.36 airvpn.org then connect to the VPN to restore your connectivity 2) If you use OpenVPN GUI (or OpenVPN directly), just connect to a VPN server to restore your connectivity 3) (not practical, unless you use the VPN rarely) put back svchost.exe to trusted application (or delete the rule) then reinstate the rule once connected to the VPN Kind regards

Hello! Yes, apparently you have a DNS leak. In order to prevent it, please see here (please read also the EDIT in the bottom): https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=2377&Itemid=142#2377 Kind regards

Hello! Perhaps you've added some firewall rule to secure your VPN connection in case of unexpected disconnection? If so, try to add to your hosts file the line: 46.105.19.36 airvpn.org and check whether it solves the issue. Kind regards

Hello! The routing tables and the logs are just fine. We can see that your account is currently connected and exchanging data as well. If you browse to http://ip2location.com while you're connected to the VPN, is the exit-IP of the VPN server displayed? Kind regards

Hello! "When attempting to connect to a VPN, Tunnelblick may fail to load tun.kext or tap.kext. This can happen when another program, or another version of Tunnelblick, has loaded different versions of tun.kext and tap.kext. A For example, the Cisco VPN client loads conflicting kexts at system startup, and they must be unloaded for Tunnelblick to work. Viscosity loads tun.kext and tap.kext when it is running. This problem may be avoided (for Viscosity) by quitting Viscosity, or (for Cisco) by using the user-contributed script designed for that purpose" Please see http://code.google.com/p/tunnelblick/wiki/cKnown Kind regards

Hello! The Air client programmer has been informed about this and will investigate. Kind regards

Hello! Thank you for your inquiry. The subscription plans are fixed, you can't get fractions of them. Kind regards

Hello! Our servers push routes so that all the traffic is anyway tunneled over the VPN. You can ask for clarifications to Viscosity support. About your Tunnelblick problem, can you please send us the logs for troubleshooting? Kind regards

Any update on Virgo?, it's been offline for a few days now. Hello! We'll keep you informed. We are confident to solve the issue in a few days. Kind regards

Hello! If the VPN is continuously up and there's no leak, you might ignore that, but it would be safer to investigate. We'll look into this apparent problem as soon as possible, you might also like to report it in the DD-WRT support forum. Kind regards

Hello! You're substantially right, a PayPal payment might be considered a proof that you are or have been an AirVPN's customer, but there's no possible correlation with your activities on our servers. Bitcoin is strongly recommended to those who need to hide their identities completely, even to us. Imagine a person who needs to spread sensitive information about organized crime, or whistleblowing, or someone who lives in human rights hostile countries. He/she might need this additional protection. See also here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards

Hello! It should not be a client bug, because, as far as it concerns the effective connection, the Air client is just an OpenVPN wrapper. The next time you experience this problem, instead of rebooting your system try to issue the command "ipconfig /renew" from a command prompt or the PowerShell (with administrator privileges) and then relaunch the Air client to see whether it solves the problem. Kind regards