Staff

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

Hello! That message shows clearly that our system was able to reach some service on your computer on your REAL IP address and that it received an answer from your real IP address. This might expose you to correlation attacks. First of all, please make sure that all your router ports matching the ports remotely forwarded on our system are NOT open. For example, if you have forwarded ports 12345 and 12346, check that ports 12345 and 12346 on your router are closed or stealth. Also, can you please let us know which service you're running when you receive that warning? Kind regards

Hello! Your system has been unable to load the certificate: which caused lack of connection since 7.08 PM till 9.52 PM. Determining why your system had this problem is impossible from the logs: the subsequent connections are just fine, except for a minor, inessential packet loss. Please make sure that you give the Air client administrator privileges when you run it. PeerBlock should have nothing to do with this problem, anyway its usage is not necessary when you're connected to the VPN. On the contrary, we would strongly recommend you to install Comodo personal firewall (free edition) and secure your connection, in order to prevent any leak and IP exposure in case of unexpected VPN disconnection and in case your system routines fail again to load files or in any other unexpected failed connection. Please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! As far as we know, this setup can work, but only if the DLink Router is set to work in pure bridge mode. Can you please check that DLink Router is in bridge mode? This may be a problem. You might like to read here for a setup extremely similar to yours which is now working: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1840&limit=6&limitstart=6&Itemid=142#1866 This is correct. Kind regards

Hello! In order to verify that, you might like to monitor the in/out traffic through the Comodo firewall "Show active connections" window or, even better, with Wireshark. http://www.wireshark.org Kind regards

Can you check Tauri ? Thank you Hello! Done, everything is in order, but we could not check your account because at this very moment it does not appear connected to Tauri. Please let us know at your convenience if it's all right. Kind regards