Staff

Hello! DNS queries are sent to public Google DNS. Kind regards

Hello! Please set "LZO Compression" to "Enable". Also, please send us the OpenVPN (attempted) connection logs and your router model. Kind regards

Hello! The so called six-strikes, which in reality means that your ISP actively spies on your traffic, are not affected by DNS queries. It is very, very important that you prevent leaks in case of VPN unexpected disconnection, especially when your system is unattended. While our servers are highly stable, a disconnection may occur for several reasons even out of your ISP and our control. We have several guide which will guide you step-by-step to set up firewall rules in order to prevent any leak. You can find them in the link on the forum announcements section. Click on the guide pertaining to your OS. https://airvpn.org/forums Kind regards

Hello! It's correct, our servers first perform internal resolution (to bypass ICE censorship and allow access to internal services) then, if necessary, send out a DNS query to Google DNS. Kind regards

Hello! Can you please send us the client logs just after you get that error? In the Air client logs are accessible by right-clicking on the Air dock icon and selecting "Logs". Click on "Copy to clipboard" and paste where appropriate. Kind regards

Hello! We have set the correct expiration date for your account. The problem is not caused by PayPal but by a vicious bug in our account processor (a product for which we have paid and we pay for support, but the programmers have never managed to solve the issue in their software). Within a few days we will get rid of this bug once and for all, progressively leaving forever the aforementioned account processor and replacing it with a different product. We apologize for the inconvenience and thank you for your patience. Please feel free to let us know if it's all right now. Kind regards

Hello! Thank you, but currently HostDime does not offer dedicated servers in Brazil, all their dedicated servers offers are for datacenters in the USA. We'll evaluate to deploy a server in Canada during the next weeks. Kind regards

Hello! As far as we can see, account "IDHidden" is not subscribed to any plan, so it is not authorized to access any VPN server. If you think this is a mistake please do not hesitate to contact us through the "Contact us" form. Please include your payment details. Kind regards

Hello! Thank you. You need to register a new account with a different e-mail address. Two identical e-mail addresses can't co-exist in the system for obvious reasons. Kind regards

Hello! They all have a wrong IP geo-location database. Pavonis is in Chicago. A geo-location database which provides a correct location for Pavonis is used by http://ip2location.com Kind regards

Hello! As a mere conduit, we don't monitor connections, and as you correctly state we don't keep logs that would allow ex-post detection of such an abuse. However, attacks against a tracker are a particular case of attacks against a service in the information society, that is a violation of our Terms of Service. Should we detect attacks, or should we be warned about such a problem, through special triggers we can put an end to such violations without compromising our customers privacy. Kind regards

Hello! Nothing else is needed for good torrenting. The next step you might like to evaluate is setting up firewall rules to prevent leaks of your real IP address in case of unexpected VPN disconnection. According to your Mac OS X version, please see the guides for ipfw (if you run Mac OS X 10.5 or lower) or pf (if you run Mac OS X 10.6 or higher). The guides are linked permanently in the forum announcements section https://airvpn.org/forums Kind regards

Hello! Currently we have no plans to add servers in Mexico. We do have plans for one 1 Gbit/s server in Canada, we will evaluate it in April. About the USA, new servers will be added, but only when there's a real bandwidth requirement (currently the status in the USA shows that we have a massive bandwidth redundancy in the USA). Kind regards

Hello! In general, if you use OpenVPN directly or the OpenVPN GUI you don't need those lines. There are some exceptions: those lines will help circumvent some DNS-poisoning censorship against our websites (in vast areas of China airvpn.org web site is censored), additionally they provide a "failover" in case one of the two frontends fails to respond, so we would recommend to add them in any case. Not exactly: once this is done, your system can't resolve names with DNS queries outside the VPN. The connectivity to the Internet is not broken. If you wish that your system can't connect to the Internet when disconnected from the VPN you can set your firewall, we recommend Comodo, please see our guide here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 No, you don't need to modify the DNS addresses set in your router. Those DNS will be used by devices connected to the router only if those devices send DNS queries to your router DNS. Kind regards

Hello! It's not possible, the IP address 10... is the VPN IP address of your client, it is a unique address per client per session. Additionally it's not possible for different clients to communicate with each other INSIDE the virtual network. Kind regards if clients do not communicate with each other does that mean that local peer discovery will not work in the torrent client? Hello! PEX works perfectly, peers in the swarm can't communicate with each other INSIDE the VPN, outside the VPN they can do that as usual (and this is one of the important reasons for which our VPN servers have different entry and exit-IP addresses, otherwise peers in the same swarm connected to the same VPN server would start communicating with each other without encryption outside the tunnel and they would be exposed to successful correlation attacks and real IP exposure). Kind regards

Hello! It's not possible, the IP address 10... is the VPN IP address of your client, it is a unique address per client per session. Additionally it's not possible for different clients to communicate with each other INSIDE the virtual network. Kind regards

Hello! So the problem is not on your ISP side, but in your system (please note however that to speak correctly, there are no such things as UDP connections, UDP is connectionless, so don't be fooled, just in case...). In order to locate the "culprit" try to monitor your network activities and progressively deactivate any possible interfering program, starting from firewall, "security" tools, antivirus, packet filtering programs of any kind. Kind regards

Hello! It sounds strange, we'll perform a check, does anybody else have the same problem? Kind regards

Hello! Thank you! Yes, everything seems fine. For additional security, after the VPN connection is established open your browser, browse to our web site and look at the central bottom box, it must be green and saying "Connected!". If it's red there's something wrong, in which case please send us the logs. Kind regards

Hello! The logs you posted are just fine, they show a fully successful connection to port 53 UDP and a fully successful connection to port 53 TCP of some server of ours. Considering all the information you gave us and assuming that you're 100% sure that nothing in your system prevents UDP packets to go to outbound port 443, chances are that your ISP is dropping packets to outbound port 443 UDP in which case you can continue connecting to port 53 UDP. Kind regards

Hello! The steps you describe are correct but please be aware that currently account "djonbrooks" has no remotely forwarded ports. If you deleted them from your account it's ok, but if you wish to re-perform the test please make sure that Vuze is launched after the connection to an Air server and that it is running while the port check is performed. Also, Vuze has an interesting bind feature, please make sure that you did not modify the default configuration. You might like to bind Vuze to your system tun adapter (generally "tun0" on Linux, *BSD and Unix systems, "TAP-Win32" in Windows systems), so that Vuze will not be able to send or receive packets when your system is not connected to the VPN (not applicable if you use a Tomato / DD-WRT / OpenWRT router to connect to an Air server directly from the router). Kind regards

Hello! Basically the statements by Sommerseth hold and Yonan's analysis, as well as the OpenVPN community work and the peer-review of OpenVPN after 4 months from that thread, show that there's no such vulnerability neither on OpenVPN 2.2.x nor on OpenVPN 2.3.0. Additionally, Palatinux team members have proved unable to support their claims, even after a clear invitation to do so by Bakker from PolarSSL (see his message on the very same thread). Unless Palatinux provides evidence of their claims (and in 4 months they failed to do so), all the stuff is just an attempt to inject FUD (Fear, Uncertainty and Doubt) for purposes we are not willing to comment. http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt Kind regards

Hello! The problem is not related to the Comodo general rules published in our guide to prevent any leak. The problem arises when it is necessary to connect over OpenVPN over TOR, in which case you need to authorize TCP packets to outbound port 443 (otherwise TOR can't work). In this case, if the VPN connection drops AND you're using a browser to connect to an https web site, Comodo will not prevent a new connection to that site. Kind regards

Hello! We're sorry, we don't accept physical cash in mail. If you pay with PayPal yes, we can correlate that an account has been activated through a PayPal payment (this is essential for PayPal refunds). The information is stored by PayPal itself (just like in any transaction of any other financial institution or bank does) both in the customer PayPal account and in our accounts. Neither the customer nor us can delete that information. On the contrary if you pay with Liberty Reserve or Bitcoin there is no correlation between the account and the payment. Kind regards

Hello! As clarified in the very same thread you linked, that's totally false. Either you provide the piece of code which, according to you, is a security threat, or you stop at once making such nasty insinuations. The new OpenVPN 2.3.0 solves many issues with Windows drivers and includes some new features which are useful. The stable version has been peer reviewed and such threat has not been found, as well as no other vulnerability. The source code is open so you can check yourself. As usual, you can use any OpenVPN version you like since 2.1.3 or higher. Your message is questionable because it contains a false statement, not our security policy habit. Please prove your claim as soon as possible providing the piece of code or a clear description of a successful attack according to which you can prove the presence of your alleged backdoor or your message will be categorized as FUD and also as defamatory against OpenVPN community and against our team. Regards