Staff

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

Hello! Correct, you can set 10.4.0.1 as primary (preferred) DNS and 10.5.0.1 as secondary (alternate) DNS on your physical network interface. In this case you must be aware that, when disconnected from the VPN, you system will not be able to send out DNS queries, so you should enter the following lines in your hosts file to allow connection to our VPN servers (only if you use the Air client, because it needs to contact airvpn.org): 85.17.207.151 airvpn.org 212.117.180.25 airvpn.org On most default Windows installations the hosts file is in the following directory: C:\Windows\system32\drivers\etc Kind regards

Hello! Customer service for Premium members usually responds in a few minutes or a few hours, according to the complexity of the problem. Responses to non-customers regarding questions that are already answered in the FAQ or that do not make sense can take longer or can never be sent. Kind regards

That was the first thing I tried but my dns was still leaking. Hello! That's impossible, which DNS IP addresses did you set? Ok, that's another good solution. You might like to prevent any leak (especially leaks in case of unexpected VPN disconnection) with your firewall (see our guide for Comodo, the most reliable firewall for Windows): https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 All these information are reported in the welcome e-mail which is sent automatically at each new subscription and also in the FAQ, please feel free to inform us if you found something unclear in the FAQ and/or in the welcome e-mail. Kind regards

Hello! You can publish the link and/or the site name if you wish. Prohibition of advertisements does not include helpful and informative links. Kind regards

Hello! You don't need to open any inbound port on your system to access our service (why did you think so...?). On the contrary it may be good that those ports are closed. Can you please try with both your firewall and antivirus disabled? Can you please send us your client logs? Kind regards

Hello! DNS leaks are a typical problem of Windows only, which has never had and still lacks the concept of global DNS. We will address the issue in the next release of the Air client (for those who wish to use it). Anyway our guides for Comodo prevents any leak, including DNS leaks. Alternatively (but only for DNS leaks, not other leaks) you can just set VPN DNS IP addresses in your physical network card. We prefer general solution which do not bind you to use any proprietary client like ours. Kind regards

Hello! The dock icon with two small screens belongs to OpenVPN GUI (a graphical user interface for OpenVPN). If you use the Air client, let's just leave it apart for the moment, you don't need it because the Air client is just another OpenVPN graphical 'wrapper' with additional commodities for our service. Normally you can't use simultaneously OpenVPN GUI and the Air client. In order to let us provide you proper support please do the following: - make sure that the OpenVPN GUI is not running (if it is, right-click on its dock icon and select "Exit") - run the Air client and start a connection just like you described in your message (log in, pick a server and click "Enter") - after a couple of minutes, right-click on the Air dock icon (a white cloud on a blue sky if connected, a white cloud on a gray sky if disconnected) and select "Logs" - a window will pop-up; you'll see at the bottom of the window the button "Copy to clipboard", click on it - paste on the forum, so that we can see the logs which can provide precious hints for troubleshooting Kind regards

Hello! Our servers will accept connections from any client based on OpenVPN version 2.1.3 or newer. Older versions might work but we have not tested them with our directives (all in all we're talking of at least 7 years old software). On Windows XP SP3 we would recommend to try OpenVPN 2.2.2 or the latest OpenVPN 2.3.0 which fixes a lot of issues and glitches with the tun/tap adapter driver. Old versions are available here: http://openvpn.net/index.php/open-source/downloads/471-old-releases.html Kind regards

Hello! A possible cause might be a packet filtering program in your system that wrongly identifies the UDP traffic flow from our VPN servers as an UDP attack. When you connect to an UDP port, your system receives exclusively UDP packets on your physical network card, regardless of the underlying "real" packet header which is still encrypted when arrives to your system physical network card. If you receive a lot of traffic, some misconfigured or excessively prudent packet filtering program might think of it as an UDP flood and start dropping packets. Kind regards

I am not using a router to do this. I am just doing configuration tricks on my PC. That was the point of my first post. I should point out here that I am confident that AirVPN has their IPTables (firewall) rules set up on each server to prevent any other user from connecting to my PC via the VPN, after connecting to the server themselves. Dose "admin" have any comment on this? In other words, I am am assuming that I can trust the server as I would trust a router, to provide an adequate firewall. If I start to fear that this trust is unwarranted, then I may also start using a router with OpenVPN on it. Hello! Yes, confirmed, no client can communicate with another client INSIDE the VPN. Some special notes: when you remotely forward a port, the server will forward packets directed to the : to your system local port, so it's up to you to check your security if you run services behind the VPN. By default NO ports are forwarded. Additionally, you can't be reached directly from the entry-IP address. Finally a side note, not very relevant in this context: we have a cone-NAT (p2p friendly) so be aware of programs which perform NAT punching, because we allow that. Kind regards

Hello! Apparently something is blocking outgoing OpenVPN packets. Please make sure that the new openvpn.exe you are running is not blocked by your firewall or any other program. Kind regards