Staff

Hello! Can you please send us the connection logs? Kind regards

Hello! 1. Can you please elaborate? No, we don't. We provide access with an OpenVPN based VPN. 3. All the traffic is encrypted. The routing table is pushed by our servers in order to tunnel all the traffic. Of course you can modify the routing table to split traffic, however proceed with caution (a mistake might destroy the anonymity layer). Kind regards

Hello! Your account has been and is continuously connected since various days. Can you please make sure that some other device of yours is not already connected? Or maybe some other OpenVPN instance? Kind regards

Hello! Thank you for your subscription. We have checked that your account is authorized to access all the VPN servers. Can you please make sure that your key has been properly copied & pasted in the OpenVPN configuration directory, and that OpenVPN can access it? Also, try a connection to a TCP port, it might solve your issue completely. Kind regards

Hello! There are also very good reasons not to reset connections of already running applications. Browser and applications with a unique fingerprint may allow the services those applications have active sessions with to correlate your VPN activity with your previous activity, with the chance to destroy the anonymity layer on that service(s) if the reconnection is performed in that way and you go on with the active session. About using Waterroof, please see this thread from here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142#1764 Kind regards

I need to know whether this is part of *your* server-side OpenVPN configuration. Hello! Yes. Correct, not on the client configuration from the configuration generator. This is in our opinion an unjustified behavior. Interfering with established connections (as well as interfering with processes) is an intrusive operation. We recommend to properly set firewall rules in order to secure the connection in any case (including accidental disconnection). https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 Kind regards

Hello! We confirm you that our servers push routes in order to tunnel everything. The fact that already-established connections will not necessarily be re-routed is just the way the TCP/IP stack works. You can easily secure your connection anyway, please read here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 Kind regards

Hello! The Tunnelblick configuration is generated from the Air configuration. Probably that directive is necessary for the way Tunnelblick runs OpenVPN, please ask to Tunneblick support for clarifications. In any case, it does not affect security or harm the anonymity layer in any way. Please BE AWARE that in general ONLY programs launched AFTER you have connected to the VPN will be tunneled. Obviously those who have already established a connection may go on using the same socket(s)! Kind regards

Hello! First of all, thank you for your really excellent message. Just a side note / clarification: befored sending queries to Google DNS, a first resolution attempt is performed in order to bypass DOJ / ICE censorship https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=852&Itemid=142#852 Kind regards

Hello! Securing your connection against leaks in case of accidental disconnection will also fix Windows DNS leak: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 In order to only fix DNS leaks with Windows please see here: http://www.dnsleaktest.com/how-to-fix-a-dns-leak.php Kind regards

Hello! With our configuration generator (menu "Member Area"->"Access without our client") you can download, according to your needs, all the files needed to run OpenVPN in any supported environment. Just generate the configuration, certificates and key for an USA server (Sirius or Vega, needed because Netflix will not allow access from non-USA IP addresses), then download them and use them to run OpenVPN in your box. Kind regards

Hello! There's the chance that you have two different, overlapping problems here. In addition to the steps you have already taken, please check also that: port 443 UDP is not blocked by your firewall (if it is blocked by your ISP, there's nothing you can do on that port). Furthermore (important), test a connection on port 80 TCP. Kind regards

Hello! Yes. You can also use Google ncr (No Country Redirect) to avoid the Hong Kong redirection. https://www.google.com/ncr Kind regards

Hello! Because they are already reserverd to some other customer. Kind regards

Hello! In order to secure your connection against leaks in case of accidental VPN disconnection please read here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 About your problem with the client, the most common cause is that it is blocked by some firewall. Please make sure that our client is not blocked on your system. Kind regards

Hello! This is just an IP geolocation mistake by Google. Kind regards

Hello! Can you please try to set "--tun-mtu 1500" together with the mssfix directive? We're looking forward to hearing from you. Kind regards

Hello! All of our servers have different entry and exit-IP addresses to prevent some attacks. For your purposes you just need the entry-IP address that you find on the "remote" line of the configuration file. Kind regards

UPDATE: the problem has been resolved. Hello! We are currently experiencing apparently random connectivity issues on Tauri. We are investigating and we will keep you informed. In the meantime, if you are unable to exchange data once connected to Tauri, we kindly ask you to use another server. Kind regards

Hello! Our servers push the correct DNS, you don't need to do anything. However, if Leopard is forced to use different DNS servers, this push might be ineffective. In order to check and change DNS on Leopard: http://www.cybermesa.com/DNS/Mac105.htm Kind regards

@enigma Hello! There may be various reasons for TLS negotiation failure. Please try to: - connect to a TCP port - if the above does not solve the problem, lower the MTU size: start with 1200, check whether it solves the fragmentation problem. If it does, then increase the value in small steps, until you replicate the problem - if the above does not solve the problem, insert in the air.ovpn configuration file the line "mssfix 1200". Check whether it solves the fragmentation problem. If it does, then increase the value in small steps, until you replicate the problem Please feel free to keep us informed. Kind regards

Hello! Yes, it's enough to send the DNS queries inside the tunnel, so it does not matter what DNS are hard coded in your router. This should happen by default. Please make sure that your Mac accepts DHCP-pushed DNS and if necessary force it to use the VPN DNS. You can find the IP address of our DNS here, according to the port you connect to: https://airvpn.org/specs Kind regards

Hello! Yes, it is possible. While "airvpn.org" is blocked in various China areas (IP blocking), you can access anyway our VPN servers. You can also access our website after you have established a connection to a VPN server or through a proxy or TOR. You can prepare the OpenVPN configuration files for our servers before you go to China (so that you will not need to access our website) or have us send them to you in an encrypted e-mail (gpg recommended). In case the chinese ISP that you will use tries to detect and disrupt OpenVPN connections, you can use OpenVPN over a SOCKS or an http proxy (example: https://airvpn.org/tor). Kind regards

Hello! We don't shape traffic, so every client can use up to the total bandwidth available. Load balancing is dynamic and without caps for each client. Kind regards

Hello! The AirVPN client for Windows needs to resolve airvpn.org name in order to download via an encrypted connection certificates and key and then launch OpenVPN, so the quickest workaround is adding the following line to your hosts file: 46.105.19.36 airvpn.org In this way airvpn.org will be resolved without the need of a DNS query outside the tunnel which is correctly blocked with your rules when you are not connected to an Air server. You will still have to authorize packets from and to 46.105.19.36 in the firewall. Of course if we change the IP address of our frontend you will have to update your hosts file. Kind regards