Staff

Hello! Your ISP can see the total amount of in/out traffic (if it couldn't, it would be unable to provide you with Internet connectivity ). While you are connected to the VPN your ISP sees all packets going to and coming from a single IP address (the entry-IP address of the VPN server your computer is connected to). Your ISP can NOT see: - the real packets header - the packets payload (i.e. the content you send and receive) - the real origin and destinations of the packets - the "real" protocol you use - the applications you use Kind regards

Hello! Yes, there are many. What is your OS? Kind regards

Hello! On the home PC yes, you should run different instances of OpenVPN, one in server mode and the other, connecting to an Air server, in client mode. In other words, you should set up a home VPN, accessible from your laptop when you're around, on the same machine which connects to our servers. The PC would act simultaneously as an OpenVPN client and server, needing adjustments to routing table and gateways. The setup requires advanced networking experience. As far as we know unfortunately there are no tutorials around. Kind regards

Hello! Apparently you flashed a firmware without OpenVPN. What is your router model (not all routers have enough memory for firmware that include OpenVPN)? Kind regards

Hello! Your phone determines your exact location through GPS and Wi-Fi hot spots detections. When you don't want to be located you should at least disable location detection on your phone. Kind regards

@dcelite Hello! The TAP-Win32 adapter in your Vuze list is eth4. Kind regards

Hello! Ok, most of the work is done. Vuze is already able to receive incoming connections when behind a VPN server. Now you need to: 1) close port 35497 on your router (see your router manual) 2) bind Vuze to the TAP-Win32 adapter (see below) Performing point 2 makes point 1 superfluous. To bind Vuze to the TAP adapter: - go to "Tools"->"Options" and under "Modes" select "Advanced" - go to "Connection"->"Advanced connection settings" - detect the name assigned by Vuze to the interface "TAP-Win32 Adapter V9.xx" (for example eth1 or something similar) - insert the interface name (eth1 in our example) in the field "Bind to local address or interface" - make sure to tick "Enforce IP bindings even when interfaces are not available" (IMPORTANT!) - click "Save" and shut Vuze down Now connect to the VPN, launch Vuze and re-perform the port checking. You should get a green token. Finally, leaving Vuze running, disconnect from the VPN to be sure that Vuze bind is effective. If it is, Vuze will lose connectivity after the VPN disconnection, protecting you against leaks in case of unexpected VPN disconnection. Kind regards

Hello! Can you please describe the issues? Kind regards

Hello! Please do not proceed randomly, there are almost 65535 ports the proxy can listen to. First, please determine (or configure) the port the proxy listens to. Then modify the OpenVPN configuration accordingly (port numbers must match). Kind regards

Hello! Unfortunately, against our guide recommendations, you renamed the rules, so it's impossible to see what they really state. If the rules are correct and your hosts file has been edited according to the guide, you must be able to connect to Virginis ONLY and you must have no connectivity when disconnected from Virginis. If the problem is related to the TCP/IP stack and/or to Winsock (a not-so-rare situation with Windows, as we can see from support requests), a reset as suggested before should solve the problem. Kind regards

Hello! It appears that the proxy is not listening to port 9050, maybe it is listening to some other port, can you please check? Kind regards

Hello! Thank you for your subscription. Since you wrote this message while you were logged in the web site, this admin assumes that you solved the above problem. If not, you have the options to recover your login name and reset your password in the login page. Vuze is ok. It has the option to bind to a specific interface, an option which most torrent clients lacks. Just bind it to your tun/tap adapter only (please tell us your OS so that we can be more precise) and Vuze will be unable to communicate when the computer is not connected to the VPN, preventing dangerous leaks in case of unexpected VPN disconnection while the computer is unattended. About port forwarding, please see our FAQ: https://airvpn.org/faq#p2p Kind regards

@wazoo Do you mean that the problem does not occur when Comodo is disabled? If so, there's something wrong in Comodo rules, please feel free to send us a screenshot of the global rules and network zones. Also, please check that the application rules are not blocking anything relevant. About resetting Winsock and the TCP/IP stack, it will reset your connections. Perform it when you don't mind to lose your established connections. Don't forget to reboot after the reset. Finally try again to connect to the VPN. Kind regards

Hello! It's a bug in the OpenVPN GUI installer. Run the OpenVPN GUI with full administrator privileges (i.e. not as a user in the admin group, it will not have same effect if you have UAC enabled) and it will be able to create the key. Please see here for the bug-fix advancement state: https://community.openvpn.net/openvpn/ticket/252 https://community.openvpn.net/openvpn/ticket/249 Kind regards

Hello! The problems is the same. First, please try a Winsock and stack reset. Launch a command prompt with administrator privileges and type the following commands: Reset WINSOCK entries to installation defaults: netsh winsock reset catalog Reset IPv4 TCP/IP stack to installation defaults: netsh int ipv4 reset reset.log After the above commands please reboot your system. If the above does not solve the problem, can you please make sure that: - no programs (especially antivirus and firewall) are interfering with airvpn.exe, openvpn.exe and tap09*.sys (the driver for the tun/tap interface) - the Air client can elevate to administrator privileges - OpenVPN can elevate to administrator privileges - the DHCP *client* service is running Yes. The differences: - with TOR over Air our servers can see your real IP address but not your traffic. TOR nodes can see your traffic (if unencrypted end-to-end). The applications that you wish to tunnel over TOR over Air must be configured to connect to the TOR proxy. Your system is on the Internet with the TOR exit-node IP address. - with Air over TOR our servers can see your traffic (if unencrypted end-to-end) but not your real IP address. TOR nodes can't see your traffic (even if unencrypted end-to-end). All the applications connect transparently over OpenVPN over TOR, except those specifically configured to connect to the same TOR proxy used by OpenVPN. Your system is visible on the Internet with the Air VPN server exit-IP address. Aurora is a customized Firefox. It is pre-configured to connect over TOR, so you must NOT use it to browse if you wish to connect over Air over TOR. Aurora is included in the TOR Browser Bundle and must anyway run (shutting it down will close the proxy too). Use it if you wish TOR over Air, after OpenVPN has established a connection. Thanks! Kind regards

Hello! That's corrrect. Of course, your ISP can see that all your traffic is from/to one or more servers (not the web site) you connect to, regardless of DNS records. Kind regards

Hello! There are various problems, essentially caused by the fact that the TUN/TAP adapter does not come up. Can you please try to uninstall OpenVPN and upgrade to OpenVPN 2.3.0? When you re-install please make sure that you authorize the installation of any driver. Packages for Windows are available here: https://airvpn.org/windows About OpenVPN over TOR: you must NOT configure a browser (or any other application) to connect to TOR. About TOR over OpenVPN: you must use a browser (or any other application) configured to connect to TOR. Kind regards

Hello! It might be a DNS issue: a possible explanation is that your system constantly try to send out DNS queries out of the tunnel and Comodo blocks them (correctly). If it's the problem, you should be able to solve it by setting 10.4.0.1 as primary (preferred) DNS IP address in your physical network interface. This is yet another problem, please send us your client logs just after it happens. Yes, in order to connect over TOR over OpenVPN, first connect to an Air server, then use a browser configured to connect to TOR. Aurora, a customized Firefox included in the TOR Browser Bundle by TOR Project, is highly recommended. It is already configured to run over TOR and includes some very useful security features. Kind regards

Hello! Problem fixed, can you please try again now? Kind regards

Hello! Problem confirmed, it's on our side. Please hold on while we investigate. Kind regards

Hello! There is a bug in the configuration generator for which you can generate a corrupt archive. The bug is due to the fact that when you select an http proxy you should be forced to pick TCP. However, if you click on Generate *before* selecting TCP, the system, instead of warning you that you did not pick the protocol, tries to generate a zipped archive. While we're fixing the bug, please select TCP. You'll see that the system will NOT zip the generated .ovpn file (if you embed it with keys/certs). Actually, the generator should NOT zip anything when the selection outcome is a single file. Thank you for discovering this vicious bug. During the next week we will implement a completely new and much, much better configuration generator with new, very useful features. Kind regards

Hello! Which client or OpenVPN wrapper are you running? Kind regards

Hello! Yes, weren't you talking about that? No, keys re-negotiation are not displayed as a disconnection in the logs, just as a TLS: soft-reset. Excellent. Maybe just a temporary issue. Do you note any unusual amount of "Replay-window backtrack occurred" entries in the logs? Kind regards

Hello! It is supposed to remain always connected. Maybe connection drops? Please note that every 60 minutes the TLS keys are re-negotiated with overlapping windows, this has nothing to do with disconnections, the connection remains alive and there's no overhead, just make sure that you're not mixing two different circumstances. Kind regards

Hello! It appears clearly as an intermittent problem from your ISP (most probably caused by congestion/overselling), simply because it's impossible that dozens of different tier1 providers have all together the same problem at the same times in different countries and continents, however feel free to ask for a refund anyway, don't worry. Kind regards