Staff

Hello! There is no difference in security. We offer both options to meet a wider range of tastes and needs. Kind regards

Hello! Thank you very much for the information. We strongly recommend all Draconis users to perform the same test on all the ports. Kind regards

Hello! Older Air client versions are not available in our website. You might like to connect via the OpenVPN GUI. About ICMP packets from your ISP DNS, there is no correlation with the Air client. See also here: http://forums.comodo.com/empty-t16873.0.html When you're connected to the VPN, you can safely drop those packets as you do now. When you're not connected, you might like to accept those packets, because they show some malfunctioning from your ISP DNS (one of your ISP DNS port 53 does not respond). Kind regards

@nobody12321 Hello! First of all, we're very glad to read that you managed to solve the problem and we would like to thank you for the detailed report. To summarize your considerations, these are our recommendations for Windows users. Of course anybody is free to ignore them. 1) Never use simultaneously two (or more) different antivirus, firewall or any other software which can run with high privileges. This is also true for any combination of programs which monitor the system 2) Never use Symantec products 3) Comodo is the ONLY firewall we recommend for Windows 64 bit. Should other product beat its reliability, we will make an update. Currently most of Windows firewall (including Microsoft Windows firewall) appear as useless toys when it comes to pro-active security and prevention of outgoing leaks. However, recently Privatefirewall (7.0.28.1 or higher) has been greatly improved and it is probably the best firewall after Comodo. It supports IP ranges (just specify a netmask). Obviously you can't pretend on Windows systems the reliability and power of packet filtering tools available in BSD and Linux systems. Our considerations are based on independent peer-reviews from the major security experts around the world. Kind regards

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