Staff

Hello! You can place them where you prefer, just like you did with your first configuration file, please see here: http://code.google.com/p/tunnelblick/wiki/cConfigT#Creating_and_Installing_a_Tunnelblick_VPN_Configuration You can ignore step 4, Air configuration files already do not contain path to certificates and key. Kind regards

Hello! You can easily switch servers with different configurations. With Tunnelblick you can have any number of configurations installed; each of the configurations will be available in the drop down menu and shown as a separate entry in the "Details" window. In order to generate multiple configuration files with our configuration generator, just pick multiple servers (even all, if you wish). Kind regards

Hello! About your firewall, you just need to make sure that outbound port 443 is not "blocked", but surely it is fine, because you reach without problems OpenVPN servers listening to port 443. You should be able to access the OpenVPN configuration panel through the web access to your DD-WRT router. Once you're there, please take a snapshot of the screen. Kind regards

Hello! Before proceeding on further troubleshooting, please try a connection to 443 TCP and 80 TCP. The logs show some replay-window backtracks which suggest packet loss (or a replay attack - very unlikely but if you live in some very human rights hostile country it's an option that must be taken into consideration). Try to change VPN server as well. Finally, please attach a screenshot of the DD-WRT web interface OpenVPN configuration. Kind regards

Hello! The problem explained by shane_b occurs usually when there's a wake up on a sleeping Mac OS X system running Viscosity (an OpenVPN wrapper). As far as we can see it's a Mac problem which needs to be investigated on the client side, do you experience the very same issue? The fact that a reboot is needed suggests that OpenVPN should be checked in order to ascertain the system status, for example whether multiple instances are concurrently running. Kind regards

Thank you for the information. We'll try to reproduce the behavior in the next days and we will keep you informed. Kind regards

Hello! With the DD-WRT OpenVPN web interface, you'll need to change manually the Air server entry-IP address your router connects to each time you wish to switch server. You can automate the procedure with scripts and different configuration file. When you connect a router to an Air server, all the devices connected to the router (unless you apply Policy Routing, i.e. you set multiple routing tables to tell the router to VPN-tunnel only some devices) will tunnel their traffic transparently (even those that do not support OpenVPN, of course). Kind regards

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