Staff

Hello! We're sorry, we don't provide proxy services. Additionally, please consider that using uTorrent over a proxy is an insecure solution. uTorrent is well known to bypass proxy settings and expose the real IP address anyway: https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea The safest solution is to use a VPN and secure the connection against leaks in case of unexpected VPN disconnection. Please see the posts linked permanently in the announcements section of the forum. Instructions for Comodo, iptables, pf and ipfw are provided. Kind regards

Hello! Yes, that's exactly the purpose of the Routing servers: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3837&Itemid=142#3837 It is an additional, experimental service, not reported on the ToS, completely free for premium customers. The service is not yet active, but first experiments have been successful. Our purpose is to double-hop only what is strictly necessary routing for censorship circumvention, trying to leave to the "normal" routing all the origins which do not perform IP checking. At the same time, we have also to check that we don't add unnecessary routing in IP ranges. It is a long and complex task which requires extended monitoring of the data streams from hundreds or thousands origin IP addresses. We are going to launch very soon a dedicated forum in order to collect requirements for accesses to geo discriminatory services where customers can report issues, check the working status of the experimental service and suggest new routes to bypass censorship. The plan is going on, we need some more days for more testing, solving some routing problems we are facing and then we'll launch the new forum section. Kind regards

Hello! Thank you for the extensive report. We are looking into the issue. Please do not hesitate to report to us each time the problem occurs. Please specify always which server you're connected to and try to remain connected after you send the report: this may significantly help us discover whether there's some vicious/hidden bug in the port forwarding system, because we don't keep logs and the port forwarding system is completely dynamic, so when your client disconnects the forwarding rules in the relevant table are deleted. Kind regards

Hello! Unfortunately nothing obvious: the logs are just fine and the TAP-Win32 Adapter looks properly configured. Can you please send us your routing table (command "route print") before and after the connection and the output of "ipconfig /all" before and after the connection? Kind regards

Hello! That's questionable. Their AUP forbids, obviously, copyright infringements through their servers, but this infringement has not been proved and they have made no effort to prove or disprove it . However their last communications are assuming a notice as a proof. Please note that they did NOT disconnect the server, we took it offline. If we received another bogus infringement notice while the server is offline we would be able to make a general case against the detection methods of copyright infringements and the reliability of the claims of various private entities. At this stage there is no reason to do so, the service has not been suspended. There are only elements for libel and/or defamation, but then again that might be a personal liability of the man who wrote to us, not necessarily of the company. The DMCA provides extremely strong safe harbors (liability exceptions and limitations) for mere conduits of data, so the mere conduit of data such as bandwidth provider effectively does not risk anything, even if the infringement could be proven in court. Actually, as far as we know every ISP in the USA has not even been sued for liability in copyright infringements. This is a very similar principle for which in the past voice phone providers were never sued for liability in crimes committed through phone usage. It is a principle of the liability exemption of the carrier which was first affirmed in the Roman Empire, where the first mail system open to the citizens (cursus publicus) was regulated so that the postman/carrier was not responsible for the crimes committed with/through the packages content. EFF made a great job about DMCA notices, you might like to read here (republished by the TOR Project): https://www.torproject.org/eff/tor-dmca-response.html.en Kind regards

Hello! Given the above conditions, you're secured! Just for additional security, you might like to perform this test (only if you use a torrent client): http://checkmytorrentip.com/ Kind regards

Hello! No, it does not. Anyway we're ready for another UK provider which meets our requirements should BurstNet UK team act in the same way. Kind regards

Hello! Sorry, bug detected. It should be fixed for your account now, can you please check once again (you don't need to disconnect and reconnect)? Thank you for your patience. Kind regards

Hello! We just checked that the correct ports are forwarded to your account current VPN IP address on Tauri. Can you please double check? Kind regards

Hello! BurstNet USA (with which we operate Pegasi) informed us through a support technician (!) that due to alleged copyright infringements (3 notices in one week, one of them a duplicate of another, without any legal proof), that we have a "last chance" (sic) to stop infringements. BurstNet USA just takes for granted copyright trolls claims without taking into consideration its own paying customers counterclaims, which are granted by USA Digital Millennium Copyright Act. BurstNet USA has no interest in checking whether an alleged infringement is real or not, showing an unacceptable disrespect toward its customers, toward DMCA safe harbors and above all showing a total lack of interest in ascertaining facts and truth. BurstNet USA makes false and defamatory claims insinuating that we host copyrighted materials on our servers, while as you know not only we don't host copyrighted contents on our server, but we don't host anything at all. It would be so easy for BurstNet USA to ascertain that we don't host anything at all on our servers, but they prefer to try to pathetically intimidate their paying customers than to spend a few minutes to check the truth and consider the claims of the paying customers who make their business possible. We are therefore considering to cancel Pegasi server with them. Also, we will surely cancel the plans of adding various 1 Gbit/s servers with them in their 2 USA datacenters, and we recommend that you switch to another server as soon as possible. We don't need them, you don't need them and above all the open Internet does not need this kind of providers. Kind regards

Hello! Instructions for Mac OS X are available here: https://airvpn.org/macosx Do you run or have you run in the past any other VPN client in your Mac? If so, please check here: http://code.google.com/p/tunnelblick/wiki/cCommonProblems#An_OpenVPN_log_entry_says_%22Tunnelblick:_openvpnstart_status Kind regards

Hello! Air uses a double certificate verification method. Please make sure that you have set "ns-cert-type server". Additionally, you can launch OpenVPN directly in order to bypass all the problems with network-manager: https://airvpn.org/linux Kind regards

Hello! Can you please post the exact rule for eMule? Probably the problem is in it. Kind regards

Hello! Thank you. We have been able to check successfully that the ports you remotely forwarded are actually properly forwarded to you while you are connected. Therefore you should now check that the incoming packets can reach your service. Make sure that: - your service listens to the correct port(s) and take care that you have not mismatched UDP and TCP ports - your service is not blocked by any firewall We are not reporting here your ports for privacy and security reasons, anyway be aware that: port 10... is UDP forwarded; port 12... is TCP forwarded ; port 22... is forwarded both TCP & UDP. Kind regards

Hello! The commands to insert the proper rules (assuming that your router has tun0 and br0 interfaces) are: iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I INPUT -i tun0 -j REJECT iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE If you use the router DD-WRT web interface you can insert them in the appropriate section (see https://airvpn.org/ddwrt for instructions), otherwise you can insert those commands in one of your scripts. Kind regards

Hello! Yes, we can rule out a DNS problem. Please try at your convenience to upgrade to Tunnelblick 3.3beta21a: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 or, for testing purposes and comparison with Tunnelblick on the non-working servers, try Viscosity: http://www.sparklabs.com/viscosity/ Kind regards

Hello! Same symptoms (connect/disconnect cycle)? Can you please double-check your iptables rules? Also, you might consider to flash OpenWrt, if there's compatibility with any of your routers. Kind regards

Hello! As you already noted, the DNS push appears correct. Also, the routing table is correct. The odd thing is that you have problems with all the servers except Pegasi, but all the servers have the very same configuration and same OpenVPN server version, scripts etc. Can you please check the following: http://code.google.com/p/tunnelblick/wiki/cConnectedBut#If_OpenVPN_is_connected_to_the_server_but_you_can%27t_access In particular, check your Mac DNS settings in "System Preferences". Kind regards

Hello! HIPS and Antivirus are optional in Comodo. Our guide refers to Comodo Firewall, Antivirus and HIPS are not required. However Windows users may greatly benefit from the additional protection provided by Defense+ against very many threats. In order to disable permanently Comodo HIPS, set Defense+ to "Disabled". In order to disable permanently Comodo Antivirus, just install Comodo Firewall (i.e. do not install the package Firewall+Antivirus), or set "Antivirus" to "Disabled". For other readers who like the same approach: change the destination port, or add rules, in case you connect to ports 53 or 80. EDIT: please note that this approach is deprecated by us. You might need to add port 68 too. If it's a global rule, the above rule also prevents DNS leaks (and any other leak, except those toward port 443 from your physical interface) by blocking everything outside the tunnel, including svchost.exe DNS queries leaks. Therefore, after you're connected to the VPN you can activate it even though utorrent is not running. Please be aware that this rule must be inactive in order to allow DNS resolution when you don't want to be connected to the VPN etc. EDIT: finally please be aware that this approach will not prevent leaks toward port 443 (or 80 or 53). Kind regards

Hello! Tunnelblick 3.2.8 is not fully compatible with Mac OSX 10.8.x. Please install the correct version, see here: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 Kind regards

Hello! After your message it appears that your connection is stable. Can you confirm that the problem is solved? If the problem occurs again, it's likely that it's a momentary problem due to some factor such as routing, Internet congestion, peering, so you might try a connection to a TCP port on different servers in order to mitigate it. Kind regards

@ergolon Hello! It was assumed that your client was running in a *BSD machine (OpenBSD, FreeBSD, Mac OSX...) with pf. If you connect through your DD-WRT router, then you must not set the firewall rules specified by the tutorial by jessez on your *BSD device. In order to secure your connection you will have to use iptables on the DD-WRT. It's definitely correct that your forward ports in your home network. The warning pertains to forwarding ports in the router physical network interface which communicates with the "outside", which would be dangerous. Kind regards

Hello! It appears that there's absolutely nothing wrong in your configuration, so it's still likely that it's a firmware problem. In the specialized forums, we have seen tons of E2500 users reporting your very same, exact problem ("connection reset" without explanation), but no solution. So this is not a true support answer, sorry, but we'll keep investigating and keep you updated. Also, feel free to keep the thread "up". Kind regards

Hello! Can you please send us the Tunnelblick logs? It might still be a DNS problem. A side note: Polaris is no more, it was dismissed more than a year, maybe almost two years, ago (replaced with more powerful hardware)! Kind regards

Hello! It looks just fine! Kind regards