Staff

Hello! Can you please try to connect to port 53 UDP and port 80 TCP of various servers to make a performance comparison? Kind regards

Hello! Yes, routers ports have nothing to do with remotely forwarded ports. When your computer is in the VPN all packets go to and come from the same port (in our service, either 53, 80, 443 or 2018). In your case, you have yellow tokens which show that your system is reachable on real IP:port. This shows that your housing router has those ports opened, contrarily to your assumption, and that your game client listens to your physical interface. Try to bind it to the tun/tap adapter with ForceBindIP: http://www.r1ch.net/stuff/forcebindip Kind regards

Hello! Either because, at the very moment of the check, the service is not listening to those ports, it is not replying or it is not running. Kind regards

Hello! You can download the Air client and OpenVPN appropriate package here: https://airvpn.org/windows Install OpenVPN. Make sure you authorize the installer to install any driver. Download Comodo Personal Firewall here: https://personalfirewall.comodo.com Install Comodo and make sure that Windows firewall is disabled. Kind regards

Hello! "Yellow" token in your case means that your service could be reached via TCP and not UDP. Probably it listens to TCP port only. [EDIT] Wrong, in your case it shows that your service is reachable on the real IP. "Gray" token means that the service was either not running or not listening to the specified local port. Kind regards

Hello! Thanks for your subscription. You need to remotely forward 5 ports (menu "Member Area"->"Forwarded ports"), all of them both TCP and UDP. Remap the first port to local port 80, the 2nd to local port 3074, the 3rd to local port 88 etc. You don't need the access the housing router. Kind regards

Hello! Probably 1.0.3 is the OpenVPN GUI version. Latest client version is currently 1.8, latest OpenVPN version is currently 2.3.0. Can you please send us the logs of the Air client just after the problem occurs? Kind regards

Hello! OpenVPN Data Channel uses AES-256-CBC cipher. RSA keys are 2048 bit long. Packet authentication is performed through HMAC SHA 160 bit. TLS keys are renegotiated every 60 minutes with overlapping windows. 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. Client/server authentication is performed through double certificate and key. Cryptocat encrypts your chat end-to-end and it does not hide your IP address. As you say a VPN is a totally different service, encrypting everything from/to the server to/from the client. Out of this tunnel data are decrypted (of course) but your real IP address is no more in the packets. Nothing prevents you to use additional end-to-end encryption layers in addition to the VPN, especially if you need to protect your data while they transit out of the tunnel. Kind regards

Hello! It works even for virtual interfaces like the tun/tap adapter. Kind regards

Hello! Yes, of course, this is one of the most basic features of the service. Kind regards

Hello! What Air client version and OpenVPN version are you running? Kind regards

Hello! For your router, please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=6525&Itemid=142#6612 The cited firmware has been reported as fully working with our service by different persons. Kind regards

Hello! If you run the Air client, please right-click on its dock icon, select "Logs", click "Copy to clipboard" and paste here. Please take the logs after some minutes your computer is connected to a VPN server. Kind regards

Hello! Your mail was not received. Can you please send us your client connection logs and information about your OS? Kind regards

Hello! The socks proxy can be external as well, for example on a server with a public IP address, or on another device in the LAN. OpenVPN needs to communicate with such a node outside the tunnel, needing therefore to reach the proxy server (in your case 127.0.0.1) through the default gateway (in this case 10.1.1.1). Actually, since 127.0.0.1 is the localhost, that route is superfluous (but in no way harmful) in this particular case, OpenVPN just include it without discerning peculiar cases. We have tried to replicate the behavior on yet another Linux box without success, eveything works swiftly. IF it's the bug that was mentioned in a previous post in this thread, it might be related to your box. Unfortunately we have currently no CentOS 6.2 available, we will investigate further. In the meantime you might like to post in CentOS and OpenVPN community support forums. Kind regards

@airbreathe Hello! Apparently you edited the OpenVPN configuration file with the directive "remote 127.0.0.1". However, in order to allow OpenVPN to connect over a socks proxy, you must specify it through the "socks-proxy" directive. The "remote" directive must always point to the entry-IP of the VPN server you wish to connect to (over the proxy) otherwise OpenVPN has no way to set the correct routing table. Compare your configuration file with the configuration files generated by our configuration generator with the proxy option enabled. If you did so, is there any particular reason for which you needed this solution? If it is mandatory for you to keep this setup, probably adding a route manually could solve. Otherwise you should revert to the "canonical" OpenVPN setup to connect over a proxy. We're looking forward to hearing from you. Kind regards

Hello! Any chance that you can try OpenVPN 2.3.0? Kind regards

@airbreathe Hello! It might be an OpenVPN 2.2.x bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657964 See also these messages: http://readlist.com/lists/lists.sourceforge.net/openvpn-users/2/12784.html http://readlist.com/lists/lists.sourceforge.net/openvpn-users/2/12785.html However, we are currently unable to reproduce the behavior with OpenVPN 2.2.1 on Debian 6 and Debian 7 64 bit. Which OpenVPN version are you running? Kind regards

Hello! Thank you for your subscription! Unfortunately it seems an undocumented bug. What is your Mac OS X version? Is it possible to catch the logs before the crash? Kind regards

Hello! What is your router model? Also, please evaluate Tomato, now that you need anyway to re-flash a new firmware. If you just need an OpenVPN client on the router, by our and our customers' experience we can say that Tomato is more friendly. Also, several DD-WRT firmwares have a fatal OpenVPN implementation bug. But DD-WRT has some attractive features for the advanced user, so evaluate your needs before picking Tomato instead of DD-WRT. Kind regards

Hello! Some options for Windows: http://superuser.com/questions/106078/per-process-network-activity-monitor More options for Windows: https://duckduckgo.com/?q=windows+display+"network"+activity+"per-process" Kind regards

Hello! We're sorry, we have some issues in understanding,can you please elaborate? Kind regards

sorry' date=' MB/s[/quote'] Hello! Well, 10 MB/s == 80 Mbit/s looks like a GREAT performance. Why aren't you satisfied with it? What is your nominal peak download and upload bw according to your ISP? Kind regards

Hello! What do you mean with "meg"? MB/s or Mbit/s? Kind regards

Hello! It is a consequence of a bug in the OpenVPN GUI installer. Try to launch OpenVPN GUI with administrator privileges, it should be able to create the key. Anyway with our client for Windows you could just ignore OpenVPN GUI. You can't launch the Air client and OpenVPN, or the Air client and OpenVPN GUI, at the same time. Make sure that OpenVPN and OpenVPN GUI are NOT running when you launch the Air client. Kind regards