Staff

Hello! Multiple keys allow you to: selectively pick remotely forwarded inbound ports by device/key connect multiple devices to the same VPN server by using a different key on each device have different, device-specific DNS block lists A dedicated panel to manage your client certificates and keys is accessible in our web site. In order to access the main control panel click Client Area while your account is logged into the AirVPN web site. The Devices button provides you with access to a panel to administer your client certificate/key pairs. The panel lets you use a multi-certificate/key support from AirVPN, a comfortable and convenient feature. You can have multiple pairs, renew them and issue completely new ones. From each device of yours you will be free to use any pair you like. Therefore you can keep all of your certificates and keys under control, administer them and also connect multiple devices to the same server and port by using a different key on each device. Eddie 2.13.6 or higher version is required. In Eddie's Overview window a menu which will let you choose a key before you start a connection will appear automatically when you create a new certificate/key par from your account control panel (note: restart Eddie and log your account out and in again if such menu does not appear). To create a new certificate/key pair click the button labeled Add a new device. The Configuration Generator has been modified as well, in order to let you generate configuration files with the certificate/key pair you wish. Let's see in details how to use the "Devices/Keys" options. Device Name and Description: these are free name and description which you can associate to any pair for your comfort. Click the pencil icon to edit. Details opens a window showing various information: Type, Creation date, Last renew date and Last VPN connection. In the same window you can find the following actions: Renew: when you click this action button, the corresponding certificate will be revoked, and a new certificate/key pair will be issued. Delete: this action button will revoke the corresponding certificate, without issuing a new one. DNS: this action button will let you enter the DNS block list panel for that specific certificate/key pair to let you define, activate or de-activate specific DNS block lists, exceptions and additions, which will apply to that pair only. View history and View Active will toggle with each other to provide you with any relevant information on the history of your actions about keys and the current active list. Some caution when using the aforementioned features: if you revoke or renew a certificate/key pair which is being used by some connected device, that device will soon be disconnected in Eddie Desktop edition, you will need to log your account out and then in again to force Eddie to pick a different pair (new or old) (*) - in Eddie Android edition this is not necessary to use new pairs, you will need to re-generate and import configuration files if you use them with some third-party software, or if you run OpenVPN or Wireguard directly (*) unchecking "Remember me" is necessary in older Eddie versions Kind regards and datalove AirVPN Staff

Hello! DISCLAIMER: this post has been written by an AirVPN co-founder (Paolo) and merges the information and the points of view elaborated by the Air founders in more than seven years. Other Air VPN staff members might add additional comments in the future. We have been asked via Twitter to reply to the following post: https://gist.github.com/joepie91/5a9909939e6ce7d09e29 We see that the issues raised by the aforementioned article may be of general interest, so we have decided to post a detailed rebuttal here, meant to fix the remarkable amount of technical misunderstandings and errors which have led the writer to astonishingly wrong conclusions and worrying generalizations. The rebuttal is based on AirVPN only; we can not and we do not want to write in the name of any other service, since most of the considerations you will read here may or may not (and sometimes we know that they will not) apply to other "VPN services". Anyway, it is our right to reply as if the writer were talking about us too, because he/she repeatedly claims that ALL VPN services act in the same way. A "VPN in this sense" is NOT a proxy. Our service encrypts and tunnels all of the client system TCP and UDP traffic to and from the VPN server. Moreover, our service, when used with our free and open source software, also makes additional steps to prevent traffic leaks outside the VPN tunnel. A proxy tunnels (and not necessarily encrypts) only TCP traffic (proxies can not support UDP), and only the traffic of those applications which are configured to connect to a proxy. UDP traffic, system traffic and traffic of applications which may be started by the system and that you failed to configure (or that you can't even configure in Windows, in some cases) are not necessarily tunneled to the proxy. Not even your system DNS queries are necessarily tunneled over the proxy. If we were really interested in logging our clients traffic, we would not allow connections to and from Tor, proxies and other VPNs. We have always made very clear how to bypass the problem of "trust us" when you can't really afford to do that, and our answer has always been "partition of trust". Please see for example our post dated March 2012 (!) about it: https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 There's more. We work under a legal framework where the safe harbors for the mere conduits are very rigidly and clearly defined (specifically, by the 2000/31/EC, the E-Commerce Directive, articles 12, 13, 14 and 15). https://eur-lex.europa.eu/legal-content/en/ALL/?uri=CELEX:32000L0031 The liability exemption for the mere conduit status would not exist if we were not mere conduits. If we inspected traffic and/or modified traffic (e.g. through content injection) and/or selected source and destination of the communications, we would not be mere conduits and we would lose the legal protection on liability exemptions. We have also two decisions of the Court of Justice of the European Union which clearly define indiscriminate data retention as infringing the fundamental rights of the citizens of the EU: https://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.pdf https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-12/cp160145en.pdf Therefore: under a legal point of view, logging and/or monitoring and/or inspecting and/or modifying the content of our customers traffic without the customers explicit and written consent would be a criminal infringement, also subject to civil prosecution by the customers themselvesunder a business point of view, that would be simply suicidal (more on this later) It is enigmatic how the writer can make such claims. We charge less than 10 USD per month for our services and we can pay a whole legal firm, 250 servers (physical, bare metal servers), the whole staff, including a tiny team of programmers. We also regularly donate money to organizations and projects whose activities are compatible with AirVPN mission. https://airvpn.org/mission https://airvpn.org/status We're not here only for the money, but if the writer wants to talk about money, so be it. He/she may rest assured that we have planned seriously a business model which remains robust if not rock solid. It is obvious that we must keep our business model solid, because our infrastructure has become large and we have duties toward the people working with us and toward our customers. At the same time we never forget that our customers have transformed into reality the dream to build a rather big project based on and aimed to privacy protection in a time when the whole world was going to the opposite direction. By changing now direction and pointing to a business based on privacy infringements and personal data commerce would not only betray our beliefs and mission and customers, but we would become a goldfish in an ocean of sharks, we could not even think to compete. After 7 years, we have the right and knowledge to claim that a privacy protection mission is not incompatible with the price the writer mentions and with a strictly agnostic network where no traffic inspection or monitoring is enforced. We can also claim confidently that any business plan based on data protection and privacy infringements not declared in the terms of service would crash dramatically in the short-term in the EU: remember the legal framework we live in and feel free to do your own research on real cases and incidents in the recent past. Last but not least, please do your own math and compute the costs to store and "hand a customer traffic data over": they imply costs of losing the mere conduit status, added to the costs of civil lawsuits from that and potentially other tens of thousands customers. Then compare them to the "costs" (in reality benefits) of no monitoring at all added to the peace of mind to strictly act in a legal/lawful way. Given all of the above, you can easily discern that the quoted assumption is false for AirVPN. The logical, unavoidable conclusion is that AirVPN best interest, even under a purely cynical, business point of view, is to NOT log (in the most extensive sense of the term) customers traffic and not commerce with their data. This is partially, only partially, true. HideMyAss was really risking to go out of serious privacy protection business soon after the incident occurred: check the massive uproar caused by the event. The AVG acquisition, with the disruptive marketing power of AVG, has probably covered the issue, but the old HideMyAss management hurried to sell the whole Privax company. Who knows, maybe just in time, maybe before the value could be hit too seriously by the incident. We can't know for sure, and the writer can't as well. Anyway, if the writer wants to claim that marketing is powerful, we agree (what a discovery!). The logical jump from HMA incident to the assumption that every service does what HMA did is long. Do not forget that what HMA did would pose a huge amount of legal problems to us, as explained. HideMyAss targeted the same persons who are happily using the new Facebook VPN. We respect the intelligence of our customers and we don't have the arrogance to think that we can change people mind and competence all over the world in a few years (or ever), and we don't even think that we can oppose the marketing power. More importantly, that's a problem pertaining to HideMyAss. It is not only unfair, but even defamatory to surreptitiously imply that the behavior (good or bad) of certain services is the same behavior of any other service, in the same field or not. We have been providing AirVPN services since 2011, when we offered the service as a beta version totally free. Now we challenge the writer of the article to provide any single proof that any single user identity has been compromised by us through a betrayal of our terms of service and our mission and/or through traffic logging or inspection and/or by any infringement of the EU legal framework on privacy and personal data protection. False. We provide our users with any tool to never make their "real" IP address appear to our servers. We have also integrated AirVPN over HTTP proxy, AirVPN over SOCKS proxy, and AirVPN over Tor usage in our free and open source software. We don't even block connections from competitor VPN servers. Finally, we accept not only Bitcoin, but Monero and ZCash as well, which are designed to provide a robust anonymity layer on the transactions. If you really don't trust us, you can easily make your IP address never visible to our servers. This is particularly important even if you trust us, but you can't afford (for the sensitivity of the data you need to transmit, for example) to assume that our servers are not monitored by hostile entities, an event that can happen with ANY service, not only VPN services. The fact that we have made every human effort to provide effective and easily usable protections against such occurrences is a proof of our interest in the protection of our customers privacy. This is ambiguous, because we would need the writer to define security scope and context exactly. Is he/she referring to integrity and security of data between your node and our servers? Or security of your system? Surely, our service is not meant as a security tool to protect against virus and spyware, and this is clearly stated at the very beginning of our Terms of Service. AirVPN can't do anything if your system is compromised. However, the above does not imply in any way that our service is a glorified proxy. See the reasons we mentioned above and verify how a loose security mention does not change anything. Additionally, while OpenVPN is the core of our service, it is complemented by an important series of features aimed to protect privacy and data in all of those cases which OpenVPN alone has not been designed for. Even if you don't run our free and open source software, we and our community have made any effort to provide guides and insights on how to get the most from our service to integrate it in a comprehensive environment aimed to protect your data and identity. We are very grateful to our community for the invaluable contributions throughout the years. If we were a "malicious VPN provider", does the writer really think that we would have allowed our forums to become a golden source of information for privacy, identity and data protection? Do you really think that we would have been provided monetary support to TorProject, OpenBSD, European Digital Rights, Tor infrastructure, etc. etc.? A part of this has been widely rebutted in our previous reply. Here it will be sufficient to add that even if you don't use end-to-end encryption, even if you don't use Tor on top of an AirVPN connection, a MITM who sniffs the packets in any point between the VPN server and the final destination (including the final destination itself of course) will see those packets coming from the VPN server exit-IP address, NOT from your real IP address and NOT from the entry-IP address of the VPN server you connect to. This is a paramount point which is incompetently (intentionally?) ignored by the writer. It is so important that in some extreme cases it makes the difference between imprisonment and freedom, or even between life and death. Imagine the case of a whistleblower giving out relevant information via VoIP or other applications relying on UDP to a self proclaimed journalist who then betrays the confidentiality of the source, or even to a serious journalist who is unaware of the fact that his/her computer is compromised, or that his/her line is wiretapped. The whistleblower can't use a proxy reliably. The journalist, or the wiretapping entity, can trace the source IP address and the identity of the whistleblower can be disclosed (just to make a trivial example which does not require any wiretapping or compromised system, think of Skype exploit, for which any party could discover the IP address of the other party). In most of these cases, end-to-end encryption would have been irrelevant for the whistleblower. Whenever the source can't trust the destination integrity, whether the recipient is in good faith or not, our service makes a vital difference. True. We have never said or written the contrary. In addition to changing IP address, which is anyway important in spite of the writer claims, further steps are strictly necessary to prevent profiling, from "separation of identities" to script blocking, from browser fingerprint changes to system settings obfuscation. Our community has widely covered this issue and provided precious suggestions. Here the writer makes a totally irrational shift: first he/she wants to make you think that our service is just a "glorified proxy", then he/she wants to insinuate that our service is useless because it is not some sort of supernatural system capable to protect users from their own behavior and from every possible tracking system which exploits the user system, not the service. The first case is true, and it is very important. However, it is totally false that you can safely rely on a proxy for the second case purpose. Many applications, including torrent software, can: bind to the physical network interface, or do some dangerous UPnPuse UDP (not supported by a proxy)send DNS queries out of the proxyinclude the assigned "real" IP address inside their layer of communications, example: https://blog.torproject.org/bittorrent-over-tor-isnt-good-ideaIn the aforementioned cases, correct usage of our service will fulfill the purpose to never disclose your real IP address and/or the UDP traffic and/or the DNS queries. A proxy will not and you can be potentially tracked back, either by copyright trolls or any hostile entity. Additionally, our service has many more use cases: tunneling UDP traffic (not available with a proxy or Tor)circumventing censorship based on IP addresses blockcircumventing censorship based on DNS poisoningpreventing injection of forged packets (not necessarily available with a proxy even in TCP, and surely not when you need UDP flow integrity)using Tor anyway when Tor usage is blocked or triggers interest of ISP or any hostile entity about youprotecting your identity when the final recipient of your communications is compromised (not available with end-to-end encryption alone, and not available with Tor when you need UDP, imagine if you need to stream a video in real time which requires source identity protection)making your services (web sites, torrent clients, FTP servers for example) reachable from the Internet when your ISP does not allow port forwarding (not available with a proxy), without exposing your IP addresshaving a static exit-IP addressbypassing various types of traffic shapingtunneling simultaneously the traffic of all the devices in your local network, even with remote port forwarding, and even those which can't run OpenVPN provided that you have a device acting as a gateway to the VPN (typical examples a pfSense box or a DD-WRT / AsusWRT / Merlin / Tomato etc. router or any computer configured to work as a router)and maybe you can see more use cases which we have missed here. The fact that the writer omitted all of the above says a lot about his/her competence and/or good faith. This is hilarious, and not only because the whole point of the writer's post ends up into advertising LowEndBox. We will not insult our readers' intelligence with an explanation of why that is a terrible idea when you seek more privacy and some anonymity layer in your interactions with the Internet. Draw your own conclusions. Kind regards and datalove Paolo AirVPN co-founder

Hello! You can consider to enforce permanent firewall rules that block all the outgoing traffic from your system. In this way, the activation of Network Lock will unlock communications to our VPN servers and bootstrap servers only. When Network Lock is disabled, the previous "block all" rules will be restored. This means also that as long as Eddie has not started, your system traffic is totally blocked (even at boot). Just make sure that you allow anyway DHCP communications to your router, they are vital to establish a connection inside your local network. Kind regards

Hello! We're sorry, this option is not available in Eddie built-in preferences. You need to implement it with custom OpenVPN directives: use "remote-random" and a list of "remote" entries. Kind regards

Hello, please have a look here as well: https://airvpn.org/topic/19909-eddie-with-other-providers-or-custom-openvpn-configuration-files/ Kind regards

Quite the opposite, in this very peculiar situation. There are some efficient ways to add an anonymity layer to BTC transactions, regardless of any intermediary. However, when the intermediary makes some precise choices of verification and so on, the anonymity layer gets thinner (not to mention the annoyance of any unnecessary step) and by the way any additional layer and intermediary does not make you use the full potential of Bitcoin. Kind regards

Hello! We have not ruled out this option, although at the moment we can't promise anything for sure. Kind regards

Hello. it's not an issue, there's nothing to fix. We're sorry, it's beyond our scope to explain what Internet Protocol version 4 and 6 are, and which layer OpenVPN works at, so we'll leave it to any person of good will, or maybe you had better consult Wikipedia and all the resources available on the Internet. Suffice to say: stop worrying. Side note: moving this topic to Off Topic forum. Kind regards

Hello! We're very glad and proud to announce that from now on we are able to accept Bitcoin directly. Any intermediary acting as a payment processor is no more required. We feel that this is an important step, since some payment processors have taken or are taking steps which are not totally privacy friendly. Moreover, cutting out any intermediary is very coherent with Bitcoin spirit and unleashes the potential of the cryptocurrency. Kind regards and datalove AirVPN Staff

Most plausible explanation according to all the gathered information is that your ISP shapes the whole line as soon as it detects an OpenVPN connection. If this were confirmed, your ISP would be really an ISP to carefully avoid. Kind regards

Hello! It depends on the complexity of the question and the problem. A key factor is when some testing to try to reproduce some issue is necessary on our side. Normally 1-12 hours when such reproducibility search is not necessary. More on special days (Christmas, New Year's Day, Easter, mid-August etc.). Kind regards

Network Lock, not block. Nothing else, that's all. Locking. Kind regards

It means that they have not implemented PFS with OpenVPN because IKE has nothing to do with OpenVPN, it's a protocol for the SA in IPsec. Sloppy, wrong OpenVPN implementation if the transiting data integrity and security is a priority. The fact that they kept fueling your confusion with even more confusing answers shows a worrying lack of competence. Maybe you should just stay away from them and move on. Kind regards

Hello, remember to activate Network Lock, this option will prevent any possible leak, including leaks caused by programs binding to the physical network interface (which is not an OpenVPN problem, it's how routing works). It will also block IPv6 when the system is not connected to IPv6-supporting servers. The screenshot shows that you had Network Lock disabled. Also remember (for other cases you might assume as suspicious) that the TCP and UDP traffic in the system connected to the VPN is not encrypted and wrapped when passing through that system tun/tap interface (and this is correct too, of course). Kind regards

Hello! That's caused by how a torrent client works. It announces directly inside the packets the port you configure in it. More details in the answers to the FAQ: https://airvpn.org/topic/9170-do-you-allow-p2p-how-can-i-optimize-performance-of-emule-and-bittorrent-with-airvpn/ Kind regards

Hello! block-outside-dns is a Windows-only directive (rightly so, since Windows is the only system with endemic DNS leaks caused by incomplete DNS implementation) and is fully effective to prevent DNS leaks. Please check the OpenVPN manual here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Warning, this directive is unsupported in OpenVPN versions older than 2.3. Windows DNS leaks, anyway, have always been prevented in the Air client software "Eddie". If you run Eddie in Windows, adding this directive is superfluous. Kind regards

Hello! Check the directive: reneg-sec n where n is in seconds in the OpenVPN manual: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN uses the previous key as long as the new key is not fully re-negotiated. Such "smart overlapping time window" ensures no communications break. Just make sure to not set extremely low values, because a re-keying adds anyway a moderate overhead in bytes, in computation power and you probably don't want that your side is willing to ask for a re-keying immediately after the previous one is over. Kind regards

Hello! No manual addition of any directive is necessary. Kind regards

Eddie is free and open source software released under GPLv3. At the moment we release under GPLv3 only the stable versions of Eddie. The various experimental versions (internal alpha, internal beta, public beta) are not released under GPLv3 and you should avoid them if you don't feel adventurous. Just stick to what you find on GitHub and do not take into consideration experimental / beta versions. This is not immutable and can change in the near future. Kind regards

Hello! Please make sure that no QoS / packet filtering tools, both on your router and system, interfere with traffic, and also test (with the connection mode that could provide you with the highest throughput) different servers in various locations around you (prefer servers with lowest round trip time). We don't see any bad packet / packet error in the log entries, so we tend to rule out MTU size problems. Some users reported in the past interesting performance boost (in Windows) after having fine tuned the TCP/IP stack with TCPOptimizer. If all else fails, you could give it a try, please see here: https://airvpn.org/topic/24126-tcp-optimizer-for-windows It looks like that with some TCP/IP stack optimization Windows can partially fill the gap with the other systems in the tun/tap interface "performance". It is not easy in Windows to match the throughput you get in the tun/tap interface when compared to other systems (you don't have fast-io, you don't have any native tun/tap support and some other problems due to bad architecture), but with TCP Optimizer and the latest tun/tap driver throughput can be improved (of course, it is assumed that your system has a powerful enough CPU). 120 Mbit/s is not bad anyway if you make a comparison with just 5-6 years ago, when beating 100 Mbit/s on the tun/tap interface with the old tun/tap driver in Windows was deemed as impossible. Kind regards

Hello, please post Eddie system report ("Logs" > life belt icon > copy all > paste), it will tell us your Operating System exact version and many other settings that might help in tuning. Kind regards

Hello, the log is fine but shows that you don't take care of DNS push, Under GNU/Linux OpenVPN does not handle the DNS push from the server, so an option to consider is that your system queries DNS servers that are inaccessible from the VPN (typically ISP DNS which accept queries only from inside the ISP network). Please check your /etc/resolv.conf file. Also consider that you can run Eddie, the free and open source Air software: it will take care of the DNS push. Without Eddie, some methods to accept the DNS push under GNU/Linux are described here: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Kind regards

This makes no sense (or worse, it makes a sinister sense ), but maybe you have just talked with someone who did not even know what you were talking about. Please note that this is not the forum to talk about competitors, not even when doing so exposes our competitors flaws. This is the correct forum to continue with comparison etc.: https://airvpn.org/forum/39-other-vpn-competitors-or-features/ Kind regards

Hello! Yes, of course. Since its birth, AirVPN always configured OpenVPN to work in TLS mode with PFS. And there's more: AirVPN uses 4096 bit DH keys and unique DH keys on each VPN server. Kind regards

@VectorXYZ Hello and thank you very much for the information. It would be nice to know why this ISP likes to block IP addresses of VPNs, although we can imagine why. Entry-IP 3 and 4 will be added to most (if not all) servers soon, probably during April. The deployment is ongoing (almost over now) and we think to activate all of them simultaneously with IPv6 support. Kind regards