Staff

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA (Los Angeles, California) is available: Pegasi. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! In order to prevent Hamachi nodes to see your real IP address you need to tunnel over Hamachi over OpenVPN (not OpenVPN over Hamachi). With two computers or a computer with two physical network cards you should be able to accomplish the task. Computer A acts as an Air client and a gateway for computer B. Computer B connects to computer A and launches the Hamachi client. In this way our servers will see encrypted by Hamachi traffic, while Hamachi nodes will see the exit-IP address of one of our servers. EDIT: according to one of our users, computer B may also be a Virtual Machine guest hosted in computer A (thank you bartek). Just in case you have a DD-WRT or Tomato router, you can do just the same: connect the router to an Air server, then run Hamachi client on one computer which is connected to the router. This is pure theory, none of us has tried the setup. Unfortunately Hamachi is proprietary and not well documented software, so some trial-and-error process might be necessary. Kind regards

Hello! As far as this admin knows it's not possible, because Hamachi client installs and uses a virtual network adapter (similarly to what OpenVPN does with the TUN/TAP adapter). So you just can't tell OpenVPN to connect over Hamachi, as you would normally do with a socks or http proxy, or if you wished to tunnel over OpenVPN over SSL and SSH. The most obvious solution that comes to mind would consist of a separate server which acts as an Hamachi client and an OpenVPN or ssh server, and then your device connects to that server via ssh or via OpenVPN. Hamachi would therefore see the IP address of the separate server. However, the knowledge of this admin about Hamachi is limited, so your question will be passed over to another admin for further evaluation in the next days. Kind regards

Hello! We are making extensive research for a reliable datacenter in Asia. Unfortunately none of those we have found meet our privacy and net neutrality requirements and/or they don't meet our bandwidth/traffic requirements. Exactly, those servers have a soft limit of 100 Mbit/s, but the provider allows temporary bursts. Anyway we don't recommend to connect to servers near 100% capacity. This is a dilemma for us: until now we have always left total freedom to our customers to connect to the server they wish. However, if they don't pay attention to the server loads, they might believe that the service is slow. On the other hand, capping the number of users on each server according to capacity is somehow an intrusive enforcement which does not respect customers' will. Momentarily, we'll keep pursuing our policy of constant infrastructure expansion according to needs, pushing even more on bandwidth redundancy. This might not be the optimal solution under a marketing short term point of view, but it may well be the best solution on the long run. Kind regards

Hello! We are sorry, currently SSTP support is not planned. Is there any particular reason for which you would prefer it instead of OpenVPN on port 443 TCP? Please consider that if you can use UDP, OpenVPN is much faster than SSTP, it solves all the problems of IP over TCP, while keeping a higher authentication security. Kind regards

Hello! We're very glad to inform you that a new 100 Mbit/s server located in Switzerland is available: Aquarii. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! All the problems have been fixed. Please do not hesitate to contact us for any issue. Kind regards

Hello! Please make sure to select a TCP port before you click "Enter". The next client version will forbid to select an UDP port for over proxy connections. Also, please make sure that you select the appropriate proxy type (http or socks). Kind regards

Hello! The problem now is fixed for everyone. Now we need to check the remotely forwarded ports table, if ports are not forwarded for your account do not worry at the moment, it's normal. Kind regards

Hello! The problem is now solved for approx. 95% of the customers. We're working to fix the remaining 5%, it will take several minutes. Kind regards

Hello! Backends and frontends succesfully rebooted. Problem "Account not active" mainly fixed, recovered a database disaster from backup. There are still some customers who will meet the "Account not active" message, we're working to fix that too. Kind regards

Hello! We are going to reboot all the system frontends and backends (not the VPN servers), we'll stay down for a few minutes. Kind regards

Hello! We have detected the problem and we're working on it. We will keep you updated on this thread and Twitter. Kind regards

Hello! Please hold on, we're looking into the issue. Kind regards

EDIT 15:36 CET+1 : end of maintenance, servers monitor up Hello! The real time servers monitor is under maintenance. It will be brought up again very soon. Kind regards

Hello! Currently posts needs approval by a moderator. We have enforced this a few days ago to fight spam. Kind regards

Hello! It was just a stats problem in the servers monitor, all the systems and servers are up and running. Kind regards

Hello! No, in this case OpenVPN would always contact server lists in progressive order, connecting to the next one only if the previous is unavailable. You need to add the directive "remote-random" on top of the servers "remote" list to achieve your purpose. Kind regards

Hello! We just bought the book and we're looking forward to reading it! Kind regards

Hello! Yes, they are fundamental. In their absence, you are forced to use a script to connect. Kind regards

Hello! It looks like a firmware problem. In this case it can't be solved without a different firmware re-flash. Since you have already tried 3 different versions, let's check your settings. You said that you double-checked them, but just in case... You're using the wrong Tunnelblick version. 3.2.8 is not compatible with Mac OSX 10.8.x (Mountain Lion). Please use an appropriate version: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 Kind regards

Hello! Can you please try different servers? If your ISP does not force you to use it for some reason, you can eliminate it. Can you please try a connection directly from your computer? Kind regards

Hello! Thank you very much for the information. Actually there IS a sudden decrease in connected clients, but all the systems are working. There has also been a total blackout in one backend server for some seconds, but this should not have affected connections to VPN servers (connected clients went down from 703 to 480). We have also had enormous load on the primary frontend (website), but it's impossible that this affected VPN connections as well. Some additional information important for us (if you can provide them at your convenience): - just after your disconnection from a VPN server, could you access the website? - what was the VPN server you were connected to? - can you now reconnect to the same server you were connected before and, if so, is the connection stable? - looking at the logs, can you tell us the exact time when you were disconnected from the VPN server (this is to let us check whether your disconnection had a coincidence with the enormous load of the website) Thank you in advance if you can provide any of the above information, and thank you anyway for the report. Kind regards

Hello! Can you please elaborate...? Kind regards

Hello! If you have set Comodo according to our tutorial, you are already protected (see the end of the post). In general, an attacker might correlate the activities on the VPN with your activities. He/she might manage to know which services you run behind the VPN and know that those services are yours. However, such an attacker must have the ability to monitor your line, or have previous knowledge on how you use your ISP line. A typical adversary of this kind is someone working inside your ISP, or someone inside your ISP forced to do so by some entity. Observing your connections, the attacker is no more able to discover anything when you're connected to the VPN. So, the attacker may discover which entry-IP is correlated to which exit-IP of our servers, send packets to all the ports of the exit-IP of the VPN server you're connected to, then do the same to all the matching ports on your ISP's IP. When it discovers that you respond on the same ports both on Air server exit-IP and on your real IP, he/she knows that the one responding to the matching VPN server ports is you. This is particularly dangerous for example if you run a web server behind the VPN: the attacker will get to know that that web server is operated by you. It's very easy to prevent this attack. Three safe solutions: - do not forward on your router the same ports you remotely forward on the VPN servers: you might use different ports for the services you need to run behind the VPN and for the services you need to run without VPN connection; just don't mix them up - forbid your service to respond to any packet coming from your physical adapter (for example, bind a web server like Apache or nginx to the tun adapter only); for most p2p clients, this solution is not available in the program configuration, it will need some "hack". - configure a robust firewall according to our tutorial Those who don't want to secure their connection with a firewall, don't need anyway to close ALL the ports on their routers, but only those ports that they have remotely forwarded on the Air servers. Moreover, if you have Comodo configured to prevent any VPN leak like suggested in our tutorial, the attack fails miserably, because Comodo will block anyway (independently of forwarded router ports, IP binding etc.) any outgoing packet from your service outside the tunnel, so the attacker will not receive any answer from any port on your real IP (this is another reason for which we recommend to use firewalls to prevent leaks instead of "monitor & kill" applications). Kind regards