Staff

Hello! Most probably you are not talking with your ISP DNS server. Comodo correctly drops those unsolicited ICMP packets. Why your ISP DNS sends you ICMP packets remains to be seen, but a good hint is given on the last message of this thread: http://forums.comodo.com/empty-t16873.0.html Anyway, you can additionally (if you haven't already done so) configure Comodo to prevent any leak (including DNS leaks, which are Windows "endemic") for total security: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! Can you please send us information about your DD-WRT OpenVPN setup (if you use the DD-WRT web interface, screenshots are just fine)? Kind regards

Hello! Can you please describe your setup (especially how and why you use Vidalia, for example if you are trying to connect over OpenVPN over a proxy), specify your OS and send us the logs of the client you use to connect to an Air server? We're looking forward to hearing from you. Kind regards

Hello! Hibernation will cause every and each connection to be lost, of course. When your computer comes up from an hibernation, OpenVPN will immediately try a reconnection. The missing Air dock icon is an issue we are going to check (currently we are unable to reproduce it on a Windows 7 64 bit system) and we'll transmit the information to the Air client programmer. Can you please tell us your Windows version? Kind regards

Hello! We recommend to use Comodo Firewall in order to fix not only the Windows-endemic DNS leaks, but also to prevent ANY leak. Please see the permanent links in Announcements section of the forum (displayed every time you select "Support"->"Forum") to see how to prevent leaks with Comodo, pf and iptables. Direct link for Windows+Comodo: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 DNS leaks (and above all leaks due to unexpected VPN disconnection) may be worrying for people who live in human-rights hostile countries or in countries where p2p swarm monitoring is legal, so we recommend to spend a few minutes to install and configure a good firewall, it's really worth the (little) effort. Kind regards

Hello! That's absolutely and totally false. It's very sad to see how someone spread misinformation, when the author of the article himself clearly stated MORE THAN TWO YEARS AGO that his considerations must NOT be used as an authoritative source: http://www.wilderssecurity.com/showpost.php?p=2108920&postcount=3 We follow laws on data retention in every country we have servers in, so any information which contradicts the non-obligation to log anything MUST be documented at least with the citation of the EXACT law which supposedly would force us to log. Please be sure that we don't work superficially or with misleading information on this critical issue like a lot of "false" anonymity layers providers do. Kind regards

Hello! We didn't change anything on Serpentis (the SE server) as well... very odd, anyway we're very glad to know that the problem is solved. Please do not hesitate to contact us again if the problem occurs again. Kind regards

Hello! Do not expect something with the power and versatility of iptables or pf, anyway Comodo is the best (and sadly the only reliable one) software firewall available for Windows. Kind regards

Hello and thank you for the information! Please do not hesitate to send us the OpenVPN logs if the problem occurs again. Kind regards

Hello! Can you please send us the Tunnelblick logs which include the disconnection process? Also, please make sure that you're using a Tunnelblick version which is compatible with Mac OSX Mountain Lion, i.e. Tunnelblick 3.3beta20 or higher. Please note that any other Tunnelblick version, including 3.2.8, is not fully compatible with Mountain Lion. Kind regards

Hello! Thank you for the information. We're very glad to know that the problem is solved. Please feel free to post the logs if the problem occurs again. Kind regards

Hello! Very glad to know that you managed to solve the problem. For your information, Tunnelblick 3.2.8 failed for the kext problem (which you correctly spotted) but please consider also that you were using a version (3.2.8) which is incompatible with Mac OSX Mountain Lion. With Mac OSX Mountain Lion, Tunnelblick 3.3beta20 or higher must be used: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 Kind regards

Hello! Your ISP can see that you are connected to a server on a specific port and that all your outgoing and incoming traffic goes to and comes from that server. Your ISP can't see in any way: - the real origin and destination of the outgoing and incoming packets; - the applications and protocol you use; - the content of your outgoing and incoming packets (real header and payload) Kind regards

Hello! We don't detect any problem with the configuration generator. Can you please send us the logs of your client? Kind regards

Hello! Just a side note: our clients are "visible" from the Internet with the exit-IP address of the server they are connected to. The 10.4.0.0->10.9.255.255 IP addresses are internal, private IP addresses in our virtual private network. Kind regards

Hello! Please clarify: is the service which listens to port 2242 running in a server connected as an OpenVPN client to one of our Air servers or not? Kind regards

Hello! Please determine your router gateway (192.168.1.1 looks ok on most DD-WRT default setup). Please do not forget to read all our replies on your open ticket in the HelpDesk, we have detected several problems on your iptables rules. Kind regards

Hello! It's technically impossible to give out any password: they are encrypted and therefore can't be known by Air administrators or anybody else. Kind regards

Hello! You can't remotely forward ports Kind regards

Hello! The Air client logs do not show any particular problem, except an odd triple PUSH just after the initial handshake. The Tunnelblick logs show just one "Replay-window backtrack occurred [1]", which is not worrying. It might be an apparently random DNS problem. Please try to force 10.4.0.1 DNS server to test whether the problem is solved (please see here, especially if you change connection port: https://airvpn.org/specs ). Kind regards

Hello! This is totally normal and it's related to how Windows checks network "access". Additionally, you might secure your connection against leaks in case of unexpected VPN disconnection. As you probably have already seen, we have a complete guide for Comodo for Windows to achieve this purpose. Kind regards

Hello! If it is, you should be able to solve it with Tunnelblick. It's definitely worth a try. If you test it, please send us the logs at your convenience if you find any issue. Kind regards

Hello! Can you please send us the complete Viscosity logs? From the piece of logs you have sent us, Viscosity is very clear about it: Kind regards

UPDATE After further investigation, you should be able to accomplish your task simply adding in the routing table specified above the following IP range: 208.79.64.0/22 Kind regards

Hello! Can you please make sure that you properly copied & pasted the .ovpn configuration file generated by our configuration generator, and that it is accessible by Viscosity? Kind regards