Staff

Hello! The logs show that the connection was fully successful. Could you access the Internet from your DD-WRT connected devices ? Kind regards

Hello! When Serpentis is under flood / DDoS attacks, the hardware firewall in front of it drops UDP packets [EDIT: correction, it shapes UDP traffic against flooding] in order to let Serpentis continue providing the service on TCP ports. Kind regards

Hello! We don't detect any problem on any Serpentis port. All the monitoring & supervision systems show that Serpentis is up and running, listening to and accepting connections on all the designed ports. Is anybody else facing the same problem? Kind regards

Hello! In general no, you should not (anyway you can change your mind whenever you wish) because in that case DNS queries and answers will be tunneled through servers, instead of resolving names directly with our DNS, with a slight performance decrease. Please note that if you wish to use Comodo DNS, you will have to force them on your TAP-Win32 adapter, because our OpenVPN servers will always push the internal DNS server IP address https://airvpn.org/specs Kind regards

Hello! SSL (as well as OpenSSL) fully supports AES. Your browser will pick one of the supported encryption and key exchange systems available on your computer. By default, browsers like Firefox have RC4-40 bit disabled. Examine the airvpn.org certificate and encryption from your browser for more details. In Firefox you can enable and disable ciphersuites through the advanced settings accessible in about:config page (look at the security.* entries). You can force your browser to employ AES 256 with https, which is fully supported on our web frontend, if you prefer to connect in this way with our website. Your guess is right but maybe for the wrong reasons. However, connecting to our site when already connected to the VPN gives different advantages (bypass IP blocking, DNS poisoning, avoid mitm attacks and site forgery and prevent your ISP to see that you connect to this website). Kind regards

Hello! Yes, your assumption is correct. Inside the zipped archive you will find not only the certificates but also your private key. No prompt for username and password should be issued by your client. From the logs, apparently your client is correctly accessing both certificates (ca.crt and user.crt), but not the key (user.key), can you please check? Kind regards

Hello! Can you please try a connection to a TCP port in order to determine whether the problem lies in outbound 443 UDP? Kind regards

Hello! Can you please make sure that your ISP router is working in bridge mode? Also, can you please try connections to a TCP port in different servers, to check whether you have problems with outbund port 443 UDP? Kind regards

Hello! Can you please clarify? OpenVPN connections in Air use AES-256-CBC packets encryption. You might like to read here: http://en.wikipedia.org/wiki/Transport_Layer_Security Kind regards

Hello! We're sorry, even if Viscosity supported that, while an account can switch servers without limits, it can connect only to one server at a time. If you wish to achieve a "multi-hop" encrypted chaining, please consider https://airvpn.org/tor Kind regards

@gpiper Hello! The attached screenshot show a correct configuration. Can you please check iptables rules and make sure that certificates and key have been properly copied and pasted? Can you also send us the OpenVPN logs? Please not that the image links have been removed because of spam and incorrect behavior of the image hosting service used, anyway they have been correctly displayed before the deletion. You can freely attach images directly on out forum. Kind regards

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