Staff

Hello! Can you please send us the openvpn logs? Please see here: http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/ You can work with your tun interface and your physical interface (for example tun0 and eth0) in order to achieve what you want (assuming that your kernel supports policy routing and you have iproute utilities installed to handle multiple routing tables). Kind regards

Hello! Thank you for your choice. Potentially yes. However it's not possible to make any precise prediction. Therefore, test the VPN extensively after your subscription and if you see that performance is too low remember to ask for a full refund within 3 days. Kind regards

Hello! If you connect fine you can just ignore that glitch. Viscosity points OpenVPN to read for sure the correct key, otherwise our servers would not let you in. Kind regards

Hello! Did you change anything in your computer or network configuration when the performance on the UK servers dropped for you? When did it happen? Do you obtain better performance with the NL servers? Kind regards

Hello! We have checked that your account is allowed to access all the VPN servers. Can you please enable your statitistics (in your "Member Area"->"Settings") in order to help troubleshooting? On your control panel you will also find useful information about the reasons for which your last connection attempt failed. Also, please try connections on a TCP port in order to check whether the problem is solved. About the Air client problem, can you please send us the logs? Kind regards

Hello! Yes. Routers where you can flash DD-WRT, OpenWRT and Tomato firmwares (in the versions including OpenVPN) will all allow you to do that. Please see also our FAQ https://airvpn.org/faq Kind regards

Hello! Please see previous message https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=4382&limit=6&limitstart=18&Itemid=142#4429 Of course. Actually, they are never required by OpenVPN (hardened security setup). You just can't login with any password, you need both certificates and your own key. Kind regards

Hello! You managed to establish a connection over OpenVPN over TOR. Unfortunately, in that case, the connection was reset after 2 minuts (inactivity timeout), probably due to latency problems between some TOR node and the VPN server. You can safely retry with the very same settings, you should be able to have a stable connection unless some unfortunate cases. About NetworkManager, it is probably misconfigured, can we see the settings? Kind regards

Hello! For security reasons our servers authenticate users through double-certificate and key. The credentials are all there, you don't need to enter any login or password. From the logs, the double certificates are fine, and also the user.key is accessible by openvpn. Just please make sure that you don't have any other openvpn instance running and connected. Kind regards

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