Staff

Hello! The configuration file is fine. Chances are that OpenVPN is reading a different configuration file. Please make sure to launch OpenVPN with the configuration file which has the line "socks-proxy". You can consider to bypass entirely the network-manager and establish a connection by invoking directly openvpn with the correct configuration file. Kind regards

Hello! From the logs it seems that Viscosity has some problems in handling this configuration and/or there are communication problems between a TOR exit-node and the Air server. First of all, please make sure that the proxy type (http or socks) you picked matches the proxy type you're using for TOR. After that, you might try to: - change Air server - change TOR node (this will happen by itself with subsequent attempts) If the problem persists, you might try to replace Viscosity with Tunnelblick. Particularly puzzling and potentially worrying from your log is: NOTE: setsockopt TCP_NODELAY=1 failed (No kernel support) which was a FreeBSD problem in 8.0-8.3 versions with OpenVPN 2.2.2 and which seems to be present in you Mac OS X system. Kind regards

Hello! You need to instruct OpenVPN to connect over a proxy. Our configuration generator will generate the appropriate OpenVPN configuration file according to your instructions. For detailed instructions, please see: https://airvpn.org/tor Kind regards

Hello! You can put a definitive end to DNS leak by configuring properly your firewall. Please see the instructions permanently linked to the announcements section of the forum, according to your system ("Prevent leaks..."). Kind regards

Hello! Therefore you experience the same problem with 4 different datacenters (2 in Germany, 1 in Holland and 1 in UK) and 5 different networks (2 in Germany, 2 in Holland and 1 in UK) on 9 different servers. This strongly suggest that it's not a server/datacenter side problem. So there's indeed packet loss. This may be normal, especially if you have for most of your activities TCP connections. There may be an explanation for that. OpenVPN implements a packet-resending even with UDP. In order to do that, the client must verify the packets, tell the server of problems (if any), wait for lost packets to be resent and finally re-order the received packets in the appropriate order (according to the maximum allowed replay frame). During the process the client could be unable to send out new packets because it is still waiting for lost packets to be resent. So you would notice same download bw but poor ul bandwidth. A very useful tool is mtr ("My TraceRoute"), available for all Linux systems (probably it's available on BSD systems too). Try to generate consistent reports by mtr toward all the entry-IP addresses of our servers. Then you'll have some useful material that may help you pick the server which gives you the minimum packet loss. Compare also the results with hosts you frequently connect to with and without VPN. Kind regards

Hello! Your question is not stupid at all, on the contrary it underlines one of the OpenVPN excellent security features. In SSL/TLS mode, an SSL session is established with bidirectional authentication (i.e. each side of the connection must present its own certificate). If the SSL/TLS authentication succeeds, encryption/decryption and HMAC key source material is then randomly generated by OpenSSL's RAND_bytes function and exchanged over the SSL/TLS connection. Both sides of the connection contribute random source material. This mode never uses any key bidirectionally, so each peer has a distinct send HMAC, receive HMAC, packet encrypt, and packet decrypt key. If --key-method 2 is used, the actual keys are generated from the random source material using the TLS PRF function. If --key-method 1 is used, the keys are generated directly from the OpenSSL RAND_bytes function. --key-method 2 was introduced with OpenVPN 1.5.0 and will be made the default in OpenVPN 2.0. During SSL/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL/TLS renegotiations. http://openvpn.net/index.php/open-source/documentation/security-overview.html Kind regards

Hello! Please make sure that you have enabled the "proxy" type in your client configuration. To sum up, the IP you're "visible" on the Internet must be: - the Air server you're connected to exit-IP address in case you tunnel over OpenVPN; - the Air server you're connected to exit-IP address in case you tunnel over OpenVPN over TOR; - the TOR exit-node IP address in case you tunnel over TOR over OpenVPN; - the TOR exit-node IP address in case you tunnel over TOR over OpenVPN over TOR (this setup may result in very severe performance decrease) In the control panel, our server must NOT be able to see your real IP address in case you tunnel over OpenVPN over TOR. On the contrary, it can see your real-IP address if you tunnel over TOR over OpenVPN. Please send us your client connection logs at your convenience when you tunnel over OpenVPN over TOR, which seems the problematic case according to your report. Kind regards

Hello! Thank you for your subscription. In order to check whether you're connected or not to one of our servers, browse to our website and look at the central bottom box. If it's green you're connected, if it's red you're not (unless you use a proxy over OpenVPN). About the screenshot, please check the key filename and the client certificate filename. By defauly your key is named "user.key" by our configuration generator, while on the screenshot we can see that you put in the name "key.key". Please make sure that you have renamed it properly or fix the name to the correct one. The very same applies to your client certificate, which by default is "user.crt" while on your configuration is defined as "cert.crt". Kind regards

Hello! Unfortunately there's not much that can be done on the servers side. UDP is a correctionless protocol (from which its higher efficiency in conditions of "good" line and low latency), and when a packet is lost, the OpenVPN server will try to resend it within a certain timeout. TCP implements a very robust error correction, which, in conditions of "noisy" lines/high latency, will result in higher reliability at the price of decreased performance. However, it's odd that you experience bad line with ALL the datacenters where our servers are in. This is a matter that you could further investigate on your side. Are there "Window-replay backtrack occurred" occurrences in your client logs with any (or all) servers? Kind regards

Hello! You need OpenVPN, please read the message just above your own post: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=2207&Itemid=142#2208 Kind regards

Hello! AirVPN is based on OpenVPN in routing mode. The TUN device handles layer 3, IP packets, not Ethernet frames. MAC addresses are not part of IP packets at all. In order to route packets correctly OpenVPN performs "NATting". Of course there are additional rules in order to allow correct port forwarding to all clients that require it. Kind regards

Hello! Which OpenVPN version is Tunnelblick using? If it's OpenVPN 2.3alpha, can you try the latest stable release? Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA (Phoenix, Arizona) is available: Arietis. 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! The problem looks solved. Can you please check and report at your convenience? Kind regards

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