Staff

Hello! Actually account "cyberninja" is currently (at the time this admin is writing) connected and exchanging data. This is the cause of the AUTH_FAILED. The first thing that comes to mind is that you have some other OpenVPN instance still running and connected (or maybe some other computer connected with the same account?). Please make sure that you stop any other openvpn connection and try again. In order to safely kill OpenVPN and restore the previous routing table, just press CTRL-C from the console you started it, or issue a kill command (a normal kill, not a kill -9 of course) to the OpenVPN PID, or even try "[sudo] killall openvpn". Kind regards

Hello! Right, change the port in socks-proxy directive accordingly and then re-launch OpenVPN and check the connection (please send us the logs if there are still issues). You should check anyway, because if your proxy changes port at each startup you are forced to discover the port and change accordingly the configuration file each time you wish to re-connect over OpenVPN over TOR, which is very uncomfortable. Once you have set one listening port once and for all, you won't need to change configuration at each TOR startup. Kind regards

Hello! Good, now OpenVPN is using the correct configuration file and tries to connect to the proxy as you wish. The problem now is that the proxy is not responding on that port. Assuming that the proxy is running and it is a socks proxy, it does not appear to be listening to port 9050. Perhaps you're using a TBB with an experimental feature: "TBB on OSX and Linux has an experimental feature where Tor listens on random unused ports rather than a fixed port each time. The goal is to avoid conflicting with a "system" Tor install, so you can run a system Tor and TBB at the same time". If it's the case, please check here to solve the problem and predict/set which port the proxy will be listening to: https://www.torproject.org/docs/faq.html.en#TBBSocksPort If it's not the case, please make sure that the proxy is running, its type matches the type specified in the OpenVPN configuration file (socks or http) and that no firewall is blocking packets to and from 127.0.0.1. Kind regards

Hello! It's highly likely. We don't detect any problem with the forum. As you can see, network-manager is not using the configuration you mean: If configured properly to connect over your proxy, OpenVPN would connect to 127.0.0.1:9050. The fact that network-manager is misconfigured is further confirmed by: Please note that all the configuration files generated by our system have the "ns-cert-type server" directive in it (this is important for additional authentication security). First of all, please perform a connection directly with OpenVPN and send us the logs (just copy and paste the output or simply tell OpenVPN to log where you wish). cd to the directory where the configuration file is stored and issue the command ("[sudo] openvpn "), using the configuration file prepared for connections over OpenVPN over TOR, in order to ascertain that your proxy is running properly and listening to the correct port. We're looking forward to hearing from you. Kind regards

Hello! File attachments and image attachments work fine for every user, maybe it is just a problem on your side. Anyway, the OpenVPN logs are text files, so even if you can't manage to upload pictures, please just copy the logs and paste them here. They may be very useful for troubleshooting. Kind regards

Hello! If the geographical restrictions are applied by the provider of the server (e.g. Hulu) then using a server outside that provider country will not let you use that service (but we're working on that, in order to allow geo-discriminatory access also to servers outside the country where the discrimination is performed). If the restriction is applied by ISPs from a client's country, then the restriction can be bypassed even with connections to servers in that country, because datacenters are not subject to forced censorship as home ISPs are. Kind regards

Hello! Image attachment in Kunena is working properly. You can attach jpg, gif and png images, up to 150 kB in size, up to 1366x800 in pixels dimension. Kind regards

Hello! Re-testing image attachments...

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