Staff

Hello! While you are connected, the VPN server knows your real IP address (unless you connect over Air over TOR, in which case the VPN server knows the TOR exit-node IP address). Kind regards

Hello! You should first activate your account with the trial coupon code you have been given (if you don't have it, feel free to ask for one with the "Contact us" form), or with a subscription. Kind regards

Hello! We have not received any communication from any Dutch authority. Probably the injunction is effective only to Dutch ISPs which bring physical connections to end-users in Holland houses and facilities. At a first glance, the court order is incompatible with at least two European Court of Justice sentences (incidentally, both regarding requests for censorship) therefore chances are that the order, even if it was transmitted to us, can be safely ignored by a non-Dutch company like ours. The Pirate Bay is one tool amongst many to effectively exercise freedom of information and the right to access science, art and culture and disseminate information, therefore it will be defended in full force with all our capacities and abilities. Kind regards

Hello! There is a major issue on the Frankfurt datacenter optical fiber cables. Leaseweb is working to resolve the issue in cooperation with their optical fiber provider. The issue affects only Omicron but should be resolved really soon. We don't detect any issue with all the other servers. Kind regards

Hello! Are you able to obtain the network configuration from the system admin(s)? There's the chance that they use a firewall with a whitelist, in which case breaking through would require some additional configuration. A first attempt, if you can't obtain any information, can be to tunnel OpenVPN over an http proxy. A further, probably more effective attempt can be to perform full http-tunneling. Unfortunately, currently http-tunneling is not supported by OpenVPN. We'll evaluate in the near future whether to offer an http-tunneling service or not, which can't be considered as secure as OpenVPN access is but can be sometimes useful to circumvent some kinds of censorships. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA is available: Aurigae. The AirVPN client will show automatically this new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificate/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual, no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Therefore, we provide currently the following servers in the USA: Vega (1 Gbit/s, Oregon) Sirius (1 Gbit/s, Virginia) Aurigae (1 Gbit/s, Utah) Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! Your understanding and terminology are just fine. The address translation happens inside the server, not on on any external router, and no logs are kept. Kind regards

Hello! Ok, go on. We have carefully designed AirVPN with security in mind, any further suggestion or peer review is welcome. Kind regards

Hello! Correct, to tunnel a browser over Air over TOR, once the connection by OpenVPN is established over TOR, that browser must not use any proxy. Kind regards

@jmish Hello! Does your office network have a proxy? If so, you'll need to connect OpenVPN over that proxy. OpenVPN has full ability to connect over SOCKS and http proxies and supports all the authentication methods, if needed. If your office network does not use a proxy, maybe a firewall blocks some outbound ports. Try to connect over port 80 TCP or 53 TCP. Kind regards

Hello! Ok, in this case you don't have to worry about correlation attacks. Should you get a red token on a TCP port, then you'll need to investigate further, but at the moment, if you have no port open on your modem/router, a red token on an UDP port might be some error of our check system, we'll look into it asap. We apologize for the inconvenience. Kind regards

@hanswurst Additional note: please make sure that you have not forwarded on your router the same ports that you remotely forwarded on our servers, the typical case for which a red token is displayed. Kind regards

Why you can't just keep HASHes of username and password on each server? Hello! Because the authentication procedure on VPN servers is not based on username and password. Kind regards

Hello! In order to determine the real performance you can have from our servers (in USA and outside USA) the only safe way is to test the service. Please do not hesitate to use the "Contact us" form to ask for a free trial. About your privacy and tracking concerns, our service is designed specifically to defeat this threat too. Please see also the FAQ https://airvpn.org/faq Kind regards

Hello! The rule is meant to block uTorrent outgoing packets NOT coming from your TUN/TAP interface, which is the network virtual card used by OpenVPN. This network card has an IP addres DHCP-assigned by our OpenVPN server you're connected to. It is your IP address in the private network. In case of disconnection from the VPN, uTorrent will bind again to your physical interface, but with this rule it will not leak any packet outside the tunnel, therefore not exposing your real IP address in any way. Your doubt is legitimate, but comes out from a misinterpretation of the rule. See also: https://airvpn.org/specs Kind regards

Hello! Please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=2&id=2108&Itemid=142 We do understand that for online casinos this can be very boring (although we are curious to know why you need an anonymity layer to play online casinos... maybe censorship?) but our procedure adds a very important security layer, because in this way we can keep any account data away from any VPN server around the world, and keep them only in secure servers in countries of our choice. Kind regards

@globespy @MrConducter The first hours of the connection logs are just fine, they show that you are connected. Note that every hour the TLS key is renegotiated for additional security. During SSL/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL/TLS renegotiations. http://openvpn.net/index.php/open-source/documentation/security-overview.html About the real problem (AUTH_FAILED) it may be due to a "dirty" disconnection. For security reasons, no account database is kept on any VPN server, so each VPN server communicates (with strong encryption) to one of our backend servers to check whether your account is still connected and to determine whether the provided user.key and certificates are proper to connect. This procedure (which is necessary because we don't want to keep account database on each VPN server and we don't want to keep the database outside the EU, for your security) may lead to up to 2-minutes of connection refusal in case of "dirty" disconnections (the backend may still "think" that your account is still connected until the time-out). Usually it does not need more than 20 seconds. If you experience AUTH_FAILED problems for more than 2 minutes, please contact us again. Kind regards

Hello! Yes, it's different. Once you are connected, any application will be tunneled over Air over TOR, except those configured to use a proxy, like the TOR web browser, in which case (according to your configuration, the proxies you use and your routing table) you can have a tunnel over TOR over Air over TOR, or over a proxy over Air over TOR, or just over TOR. The first two solutions may result in very poor performance, but add yet another partition of trust and therefore they can strengthen even more the anonymity layer. In general, if you like Air over TOR, then you should not use the TOR browser to browse, but any browser configured NOT to use a proxy. Kind regards

Hello! The configuration screenshot looks perfectly ok. You can perform a test, a connection to a TCP port instead of an UDP one, just to check whether it can mitigate the packet loss problem. Finally, another test that you might perform is to connect directly with the OpenVPN client from you computer, letting the router alone (you might test with pfsense enabled and disabled). Kind regards

Hello! Something must have changed on your system. First of all you should ascertain whether you have added some Comodo rule which blocks incoming packets. Just disable Comodo firewall completely for a quick check in order to determine if it's a problem related to Comodo. Kind regards

Hello! Well, we just checked that from inside Castor and Draconis there is no packet loss at all toward 109.105.111.14 (and several additional know hosts). So it remains to be seen whether it's a problem between your ISP and those servers, or between your device and those servers. First of all, try to mtr the entry-IP or the exit-IP of Castor and Draconis while you are NOT connected to the VPN. If there's packet loss, it is highly likely that the problem is somewhere between your ISP and Castor and Draconis datacenters, and that your OpenVPN configuration and your system are just fine. In this case, it will be unfortunately very hard to detect and solve the problem in a short time. On the contrary, if you detect packet loss ONLY when connected to some Air server, try to connect to a TCP port of Castor and Draconis and see whether the issue is fixed. Finally, although it's not very likely that this will solve the problem, try to disable completely pfsense firewall and see whether there's a change. We're looking forward to hearing from you. Kind regards

Hello! As a pro-active security firewall, it appears there's no comparison between them. Comodo passes about 96% of the hardest leak tests, Bitdefender only 9% (on 64-bit systems). On 32-bit systems, Comodo passes 100% of the tests and Bitdefender 97% of them, so if you have a 32-bit system you can remain with Bitdefender, while if you have a 64-bit Windows you should seriously consider to drop it. Switching between the two should be possible without particular issues, but please first check with the Bitdefender and Comodo support teams. Our recommendations on Comodo are based on independent security experts reviews, not our own, also we have never tested Bitdefender. Kind regards

Hello! Yes, Comodo is (unfortunately) the only choice for Windows 64-bit systems, with Outpost quickly recovering form previous leaks issues from older versions: http://www.matousec.com/projects/proactive-security-challenge-64/results.php On 32-bit Windows system, there are good alternatives, but Comodo remains anyway the best firewall. Various "free" (not open source) Comodo suites are available here: https://personalfirewall.comodo.com/ Kind regards

Hello! If you look at the security tests performed by independent researchers (results linked on our forum), Bitdefender does not appear adequate to offer an effective pro-active protection on Windows 64-bit systems. Anyway, it is ok to perform the task you wish. According to matousec, Bitdefender only passes 9% of the leak tests. The remaining 91% of the tests show leaks from Bitdefender, resulting in protection "NONE": http://www.matousec.com/projects/proactive-security-challenge-64/results.php Kind regards

Hello! You can generate the files you need with our configuration generator (menu "Member Area"->"Access without our client"). You can generate as many configurations as you wish (you will need one configuration file for each server, if you switch amongst them, while the certificates and key are the same for each server). However, the recommended solution to secure your connection against accidental drops is setting up firewall rules, please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 The above solutions are recommended because forceful kills of programs in case of VPN disconnection pose issues about data integrity as well as security issues: the time between disconnection detection and program forced kill may allow anyway packets leak outside the tunnel. Kind regards