Staff

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

Hello! We don't detect port forwarding problems with your account or with Sirius, could you please check that: - the service is running and listening to the correct remotely forwarded port - the service has been launched after you have connected to the VPN server (in case, restart it) - no firewall is blocking packets to and from your service We're looking forward to hearing from you. Kind regards

Hello! Thank you! It might be a client glitch or bug. We'll pass the information to the Air client programmer. Kind regards

Hello! In the "Checking" phase the Air client asks airvpn.org "Which IP address do you see me connecting from?". The frontend replies and if the IP address is one of the VPN servers exit-IP addresses the Air client is sure that the tunnel is working. If the IP address is not one of them, the Air client starts a new connection. Kind regards

No, the server is not connected by OpenVPN to one of the Air servers. Hello! In this case you don't need to remotely forward port 2242. Not necessarily. Port 2242 is reserved to some other client and it is dynamically forwarded to that client only when it is connected and only on the server it connects to. Kind regards

Hello! The connections is correctly established but the check from the Air client fails. Usually there are two main reasons for this: - the connection drops immediately after it has been established, OR - after the connection the client can't access anymore airvpn.org for the security check of established connection Can you please try a connection directly with OpenVPN, or with the OpenVPN GUI? When you have connected (or tried a connection) with OpenVPN, can you please send us the output of the commands "route print" and "ipconfig /all" (from a command prompt or the PowerShell)? Kind regards

Hello! The backend server was replying to VPN servers but incorrectly and it also had a low load. So the VPN servers assumed that the 1st backend server they queried was ok and would not try a connection to the subsequent backend server. On the contrary the primary frontend (website etc.) correctly connected to a different backend server (the backend servers have a clustered database so they are constantly "aligned"). The result was a refusal of any new connection from the VPN servers, while the website was still up. Another detrimental consequence was that the monitoring system did not detect any problem, so it did not send any urgent warning message to the techies. Some changes have been applied on the backend server which had this problem. Since it has happened for the first time after we implemented, some months ago, a clustered database, we're still investigating to gain a deeper understanding of the issue. Kind regards

Sorry, I tried to upload more than 1 screenshot. Hello! Ok, now we have all the information we need. A rule is missing: iptables -I OUTPUT -o ! --dst a.b.c.d -j DROP # if destination for outgoing packet on is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects # the above line can be duplicated for as many Air servers as you wish to connect to, just insert the appropriate Air server entry-IP This is the rule which will prevent leaks. a.b.c.d is the entry-IP address of the Air server DD-WRT router connects to. is your router network interface (probably br0, determine its name with command "netstat -r"). Important! Please note if you use the last entry above in the firewall (iptables -I OUTPUT -o br0 ! --dst a.b.c.d -j DROP) you will lose access to the router. Thus if the tunnel goes down ...well you know. So you may want to leave this entry off the GUI and if/when you are set up properly and then run it from the telnet prompt. That way if you need router access you can reboot and be OK. Please see also zdrifter post for more details. Kind regards

Before there were several dns servers listed including my isp, now only my isp. Hello! Ok, this new screenshot shows what you say. We should examine the iptables rules. Kind regards

Before there were several dns servers listed including my isp, now only my isp. Hello! They are not visible on the screenshot which is pertaining to the DD-WRT web interface. You should watch at the DNS servers displayed in the leak test site. Anyway, does the dns leak site display your ISP DNS? If so, can you please post your complete iptables rules list? Kind regards

Hello! Can you please try again now? Kind regards

Hello! We don't detect any problem anymore. Should you have any further issue, please do not hesitate to contact us. Kind regards

Hello! We have detected a problem on Serpentis port forwarding and potentially on other servers. It is probably related to the previous backend problem (the VPN servers need to know which ports are to be dynamically forwarded to which IP address inside the VPN). While all the connections between all the servers are re-established, this problem will be solved automatically. Please let us know which server(s) you detect the problem if it's not solved within a few minutes. Kind regards

Hello! Thank you very much, we're very glad and proud of this review. We would love to read the whole book as well! Can you give us the coordinates to buy the book? True, especially thanks to how OpenVPN works (if properly configured). Also, the different entry-IP and exit-IP addresses of each server prevent nasty correlation attacks against which even OpenVPN is powerless (it's not an OpenVPN fault, it's how the Internet works ). You will see a constant infrastructure expansion on various countries, some of them included in your list. We are also preparing new services which will be available in the next weeks to help people connect in countries where OpenVPN connections are disrupted. Unfortunately OpenVPN does not support XTS. In the future we will evaluate a change of cypher-system, however this is a delicate operation because it will force our clients to re-download configuration files. DD-WRT users might be forced to re-flash their router with new firmwares which implement latest OpenVPN versions. Currently AES-256-CBC, RSA 2048 bit key, double certificate authentication and TLS renegotiation provide a higher-than-military degree of security on the cypher-system side, without an excessive computational burden on older CPUs. It's true that our servers are (also) networking sharing devices. Sharing a device is a necessary prerequisite to keep a strong anonymity layer. The WIMIA test software is closed and undocumented. Currently, experts suggest that WIMIA maintainers also add IP addresses and IP ranges from dedicated servers providers on their database. Therefore there's no way to fool a WIMIA test if any person sends them one of our servers exit-IP addresses (they also have a form that can be used by snitches). This may become a problem if more and more web administrators will bar access from VPNs using WIMIA, however the more privacy awareness (as well as usage of NATs from ISPs) spread, the more this problem will heap only on those websites. We're looking forward to hearing from you. Kind regards