Staff

Hello! That's correct: the purpose of the suggested Comodo rules in our guide is exactly to prevent any leak, so you must NOT have any connectivity to/from the Internet when disconnected from the VPN. If you need that, just switch Comodo Firewall to "Disabled" or "Safe Mode". Since Comodo rules prevent also DNS leaks, if your system insists on sending DNS queries outside the tunnel you will have a timeout in the name resolutions. Apparently the reason is therefore that your system does not use the VPN DNS now and then. This may happen with Windows, because all the Windows versions, very unfortunately, lack the concept of global DNS. Please try to force on your physical network card 10.4.0.1 as your preferred DNS server IP in order to fix the issue. Leave the "alternate DNS" to your favorite DNS, it will be used when you're not connected to the VPN (only if you need connectivity and names resolution when you're not connected to Air). Kind regards

Hello! Yes, with the above setup you would have TOR over VPN (VM) over VPN (HM). No, that's not correct. With TOR over VPN, the VPN server sees your real IP address, but can't sniff the data sent/received by the applications tunneled over TOR. No. In order to hide to any VPN server both your IP address and the packets payloads and real headers, you need TOR over VPN over TOR. In order to do that you need for example to: - connect over OpenVPN over TOR in the Host Machine https://airvpn.org/tor AND - connect over TOR in the VM - finally, use ONLY applications configured to tunnel over TOR in the VM Kind regards

Hello! It is correct, your account is not subscribed to any plan and therefore it is not authorized to access any VPN server. If you think this is a mistake, please do not hesitate to contact us (menu "Support"->"Contact us") at your earliest convenience. Kind regards

Hello! Connectivity with LeaseWeb USA has been fully restored: http://leasewebnoc.com/en/networkstatus/leaseweb-usa-network-re-routing Kind regards

Hello! Connectivity problems with Sirius, Librae and Andromedae appear now to be resolved. Kind regards

Hello! Andromedae, Librae and Sirius are suffering datacenter problems. You can check anytime the network status with our servers monitor: https://airvpn.org/status Kind regards

Hello! Unfortunately it's not possible to provide you with a definite answer. Changing ISP might give you better performance, because a different ISP may have different peering with the datacenters where our servers are located (please see also https://airvpn.org/faq#speed ). The maximum purely theoretical bandwidth our 1 Gbit/s servers can give you is 500 Mbit/s, there is no cap on our side. Before doing anything with your ISPs, please try also to connect to different servers and above all to different ports: several ISPs cap bandwidth on some ports (especially UDP ones). Please try connections to port 80 TCP and port 53 UDP on various servers in order to make a performance comparison. Kind regards

Hello! Is the RDP listening to a port which has been remotely forwarded on our servers? This is necessary to allow incoming connections. You can then reach your remote desktop behind the VPN to : You can also remap the remote port to a different local port for your convenience from your web control panel (menu "Member Area"->"Forwarded Ports"). Kind regards Only just had chance to look at this again but need some more help. As mentioned before, I RDP to my small server either using my local IP/server name while within my LAN or using dyndns name to my static IP when away from home over the internet. RDP is usually port 3389 by default but someone is already using that so I picked another port in the 6767 range and stated local port as 3389 on the AirVPN web config page. Using format 192.168.1.1:6767 or SERVER:6767 in my local LAN or mydns.com:6767 Hello! That's correct: the RDP server is not listening to port 6767. Please note that 31.192.12.75 is not an exit-IP address of any of our servers. Please determine the exit-IP address of the server your RDP server is connected to and access it (from outside the VPN) at :6767 Alternatively, you can change the listening port of your RDP server to 6767 and delete the remap to port 3389 of the remotely forwarded port 6767. Kind regards

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