Staff

Hello! Apparently it's the wireless connection that impairs the performance. This is not uncommon: WiFi limitations typically cause effective throughput degradation. Yes, please see here as well: https://airvpn.org/faq#speed Kind regards

Hello! The relocation of Sirius, Librae and Andromedae has been completed. The three servers are now back on line and fully operational. Kind regards

Hello! Yes, that's normal. Yes, it is mandatory: replace tun0 with tun1. It appears correct, assuming that the network card of the device you wish to forward port 3389 TCP to is 192.168.2.102. Of course do not forget to remotely forward port(s) on our system (menu "Member Area"->"Forwarded ports"). Kind regards

Hello! Can you please tell us the error that Windows 7 reports when you try to install OpenVPN 2.2.2? Kind regards

Hello! Maybe (this is just speculation) uTorrent is trying to punch your own router NAT. Comodo will block these attempts as you have noticed. We will further investigate this strange behavior anyway: what is the exact uTorrent version you're running? EDIT: from what you can see on the Comodo firewall events logs, is the blocked packet coming from uTorrent? Kind regards

Hello! Can you please send us the client logs? After you have solved the previous problem: - forward a TCP port on our system (menu "Member Area"->"Forwarded ports") - remap that port to local port 80 - reach your web server on http://<Air server exit-IP address>:<remotely forwarded port> Alternatively: - forward a TCP port on our system - configure your web server to listen to that port - reach your web server on http://<Air server exit-IP address>:<remotely forwarded port> Kind regards

Hello! Only your router/NAS is connected to the VPN, so the service you want to be reachable from the Internet must listen to tun11. The DNAT must forward ports to your devices IP address(es) (192.168...). Kind regards

Hello! The correct interface is tun11. Please check that, when the router is connected to an Air server, the IP is 10.*.*.*. Please consult the manual of your router in order to determine how to bind the service you wish to tun11 (10.*.*.*). Kind regards

Hello! Yes, it's just fine. Also, 30 seconds for an OpenVPN client to connect to an OpenVPN server with gateway and routing tables pushes are totally normal. Kind regards

Hello! Please check the exit-IP address while you're connected to a server (for example browse to http://www.ip2location.com). In case of any doubt, feel free to ask us. You can remotely forward a port with or without local port remap. If you don't remap the forwarded port, packets will be forwarded to the same local port. Kind regards

Hello! If you don't have a proxy, please do not activate that option in the Air client. If you use the OpenVPN GUI, or OpenVPN directly, generate the configuration(s) you wish with our configuration generator (menu "Member Area"-->"Access without our client"). As above, do not tell the configuration generator the you use a proxy if you don't have one. Usage of proxies implies a severe performance degradation. Kind regards

Hello! You can activate that option if you wish to connect over OpenVPN over a proxy. If you don't have a proxy, do not activate it, otherwise OpenVPN will try a connection toward a proxy that simply does not exist. Usually, you use a connection over Air over a proxy if you want to hide to our servers your real IP address even while you are connected to the VPN server(s), or if your ISP disrupts OpenVPN connections. A significant example: https://airvpn.org/tor Kind regards

Hello! Your proxy is not responding or refusing connections on port 9050. Please make sure that your proxy is running AND listening to port 9050. What proxy are you using? Kind regards

Hello! Your Network Zones and Global Rules are just fine. Probably the problem does not lie in Comodo settings. Do you notice any difference if you perform a connection with Comodo Firewall set to "Disabled"? Also, can you please send us the connection logs of your client pertaining to the issue? Kind regards

@unr3al21 Hello! First of all please note that your account does not have any remotely forwarded port remapped to local port 1900. Once you have remotely forwarded the appropriate ports in our system, make sure that the router service which should be listening behind the VPN server binds to the correct router interface (probably tun+) and listens to the correct port(s). After that the service is reachable on : Please note that Air servers entry and exit IP addresses are different. Kind regards

Hello! Is router B trying to connect to AirVPN? If so, the OpenVPN configuration has several mistakes (wrong authentication type with username/password, wrong tls client directive - beware it's repeated twice..), please revert to the configuration provided by our configuraton generator. Kind regards

Hello! We're glad to know that the problem is solved. If OpenVPN is suddenly working again without any change in your system, it's a reported (but unsolved), apparently random Windows bug we have seen on XP, Vista and 7. Usually the issue is solved with a reboot, sometimes (but not always) an "ipconfig /renew" is effective. Kind regards

@PowerSoul Hello! Can you please check whether .NET Framework 2.0 is installed on your system? Kind regards

Hello! The tun/tap network adapter does not come up. Assuming that it is enabled (please see https://airvpn.org/index.php?option=com_kunena&func=view&catid=2&id=6247&Itemid=142#6248), please to try to remove and then re-install a TAP-Win32 Adapter (menu "Start"->"All Programs"->"OpenVPN"->"Utilities"). If the problem persists, try a reboot. If the problem is still there after a reboot, there might be a problem with the driver, please try to uninstall completely OpenVPN and re-install it, making sure to authorize the installer to install all the drivers. Kind regards

Hello! If you could not connect after a reboot, the suggested behavior can not be the cause. When you reboot any process is of course killed. Please do not hesitate to contact us if the problem persists even when you use OpenVPN directly. Kind regards

@candtalan Ok, this admin has monitored your attempts. Apparently, your first re-connection attempt failed because your client was already connected. It was at least kept alive with pings, there was a continuous exchange of packets up and down. After approximately 35 seconds, your client really disconnected. When you failed the re-connections attempt, did you look for other OpenVPN instances, to check whether they were still running for example with sudo ps aux | grep openvpn ? Maybe there's some delay between the network-manager disconnection command and the client disconnecting for real. Kind regards

Hello! Yes, please, do it as soon as you read this message with network-manager. About running OpenVPN directly for another test: - put all the files (user.crt, user.key, ca.crt, and every .ovpn configuration file) in one directory - cd to that directory - issue the command sudo openvpn "name of the ovpn configuration file here" Send us the output of the command. Try to disconnect simply by pressing CTRL-C (on the same shell window) and please re-connect again after 10 seconds (to the same server or any other server, it's the same). Please note the double quotes around the .ovpn file name (it contains spaces from our configuration generator). Kind regards

Hello! Account "candtalan" was connected to some server before you wrote the quoted message and successfully exchanging data. It is still connected and exchanging data at the time of this writing. This may suggest that network-manager maybe does not perform an OpenVPN disconnection... did you check if you had still OpenVPN instances running while you were testing? Kind regards

Hello! When you have this issue can you please contact the support team through the "Contact us" form, so that it will be possible to see what's happening in real time? Do you see that the problem occurs only with network-manager, or does it occur even when you launch OpenVPN directly? A reboot should never be necessary. Also, can you please check (when the problem occurs) whether some OpenVPN instance is still running, just in case network-manager in reality does not disconnect the client? Kind regards

Hello! Tunnelblick is only for Mac OS X, but OpenVPN is supported by various firmwares (DD-WRT, OpenWRT, Tomato...) which are good for several routers. Which router brand and model do you have? If it is supported according to the list (do you refer to the DD-WRT list?) then you can flash it with DD-WRT or some other firmware (usually we see that OpenWRT and Tomato do not suffer of some DD-WRT issues and bugs). Kind regards