Staff

There is no point in using OpenVPN over SSL when UDP performance is better. OpenVPN over SSL is designed to encrypt OpenVPN fingerprint thanks to an additional tunnel. This adds an additional wrapping and an additional encryption layer (warning: the additional tunnel is not designed for high security in our system - the core security layer remains up to OpenVPN). To make things worse OpenVPN is forced to work in TCP. This means that when you send out an UDP packet in your system, this will be an UDP packet wrapped in TCP wrapped in TCP: UDP over TCP over TCP! See the difference with the efficient UDP over UDP, or TCP over UDP. OpenVPN over SSL should be used only when the remarkable performance hit caused by the massive overhead is less than performance hit caused by ISP traffic shaping/management against OpenVPN specifically (if it's against UDP, direct TCP will suffice and OpenVPN over SSL will be again inappropriate). This is the only essence and purpose of OpenVPN over SSL. A very important purpose, vital in some countries (for example Iran). So, when direct and clean OpenVPN in UDP is faster than "OpenVPN over stunnel", insisting on OpenVPN over SSL not only makes no sense, but it's also masochistic. Kind regards

Yes, for each tweet he/she attached the correct piece of text (as an image, so you might need some effort to read it properly) in which you can see that OpenVPN is unrelated. It can be, sure, but then this is not a thread for "General & Suggestions" forum, which is aimed to general topics and suggestions for AirVPN service, not other ones! Feel free to move to "Off-topic" for any IPsec related issue. Kind regards

Hello! @produs Our service is not based on IPsec. This decision was taken in 2010 (even before we opened Air) because the original co-founders did not like very much two facts: IPsec running in kernel space, and important contributions by NSA to some of the development stages. @AgentSmith The tweet just after the one you linked mentions incorrectly "OpenVPN". From the document, on the contrary, you can see that it refers to IPsec, as correctly fixed in the subsequent tweet. Just a "momentary lapse of reason" by the author of the twit, probably. Kind regards

Hello, that's an unexpected issue. Please have a look here, it should help you fix the issue quickly: https://airvpn.org/topic/14829-can-only-connect-to-the-internet-browser-through-airvpn/?do=findComment&comment=30509 Also, make sure that you're running Eddie latest stable release (currently 2.12.4) and that you always shut down Eddie properly (menu "AirVPN" > "Exit") to let it restore your previous system settings. Kind regards

Hello, please follow this thread for latest updates on the issue and also momentary workaround: https://airvpn.org/topic/22207-kaspersky-users-read-here/ Note how Kaspersky is fully aware of the critical bug and that an experimental patch (available only upon request at the moment) seems to be effective in fixing it. Although with a slow pace, things are moving toward a final resolution. We underline again that the whole problem has been created by Kaspersky "Patch D" bug and that our service and/or OpenVPN are completely unrelated to the source of the problem. Kind regards

There's no huge button if you're already connected to a server. In order to enable the feature that prevents your IP from leaking, you have to do something that causes your IP to leak (disconnect). Do you see my conundrum? No conundrum here. If you have already connected to a server without Network Lock it means that you had previously disabled "Network Lock at startup" AND you decided to NOT click the button before connecting to a VPN server. The option is already persistent. The Network Lock in itself is not, and for very good reasons, persistent: previous system firewall rules will be restored either when Network Lock is explicitly disabled or when the software is properly shut down. Thread locked, it is based on nothing and the presumed problem is imaginary. Kind regards

Not domain names, but IP addresses (even in CIDR notation). Menu "AirVPN" > "Preferences" > "Routes". Effective at the next VPN connection. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Bulgaria is available: Fornax. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194 and 2018 UDP and TCP. Just like every other Air server, Fornax supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@ShareVPN It already works in that way. A prepaid gift voucher is in EUR, not in Bitcoin. If you buy it in Bitcoin, USD or any other currency, conversion to EUR is immediate, and the gift voucher can be redeemed exactly for the intended plan (unless our prices change, of course, but that would be a very exceptional circumstance). Kind regards

Yes.

Absolutely not. We don't use them. Kind regards

Also consider that we provide a Debian PPA repository, have a look at https://airvpn.org/linux/ Kind regards

Well, the EUCJ decision was the outcome of a clarification request already sent by a UK court of appeal. See also https://www.theguardian.com/world/2016/dec/21/eu-ruling-means-uk-snoopers-charter-may-be-open-to-challenge in particular last 5 paragraphs. Kind regards

The Investigatory Powers Bill scope is not applicable to our company, and it can be challenged after it has been found by the Europen Union Court of Justice incompatible with human rights and EU legal framework (EUCJ decision of December 21, 2016). After the defeat at the EUCJ, various parts of the Act pertaining to data retention are not operative and the technical implementation has been frozen. UK government announced "an appeal" against the decision. The Act provides three main lines of investigation: interception, interference and retention. The first two methods may cover datacenters in the UK, but they do not pose new challenges. The same can happen, and has happened, legally or illegally, virtually in any country in the world (see our article from 2011 about partition of trust). About retention, our policy does not change and any interferences with that will cause us to discontinue any server in the UK, just like we already did in France. When UK will finish the "Brexit" procedure, then the technical guidelines for the implementation of the Act might be unfrozen by just ignoring the EUCJ decision. However, the EUCJ decision involves infringement of human rights that are also protected by a paramount convention on human rights which the UK signed (the European Convention on Human Rights, or ECHR) which is binding to all members of the Council of Europe. The Council of Europe does not depend on the European Union (although the European Union is a very important partner of the Council of Europe). Therefore on exactly identical basis which led to the UK defeat, the law and the UK can be challenged again at the European Court of Human Rights (do not confuse this court with the European Union Court of Justice). Getting out of the EU does not affect anything about the ratification of the ECHR and the membership in the Council of Europe. Actually, the UK is a founding, original member of the Council of Europe since 1949 (and this makes even sadder how lightly a government of the Kingdom is willing to throw in the trashcan some post-WWII founding values of democracies). We'll see when and if the technical implementation of the law, in the parts pertaining to us, will be unfrozen. Before that, your argument is a theory for the future, not for now. However, we must also take into consideration illegal operations. From what happened in the past, we can not even rule out that such operations can have the support of some parts of government bodies. And history teaches that such operations could even be led by criminal organizations. For such occurrences, the only effective counter-measure is technical: partition of trust. Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Singapore are available: Aries and Reticulum. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194 and 2018 UDP and TCP. Just like every other Air server, Aries and Reticulum support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that ten new 1 Gbit/s servers located in the Netherlands are available: Andromeda, Canis, Crater, Cygnus, Edasich, Horologium, Hydrus, Musica, Orion and Pyxis.. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other Air server, they support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

In this case it is 10.3.0.1, but yes this is a good way to check if your system is updating resolv.conf correctly. Hello, 10.3.0.1 is not one of our private addresses in the VPN. It is out of any of our subnets. The problem is that you don't take care of DNS push. OpenVPN will not do that for you in Linux. Please see here for some ideas: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ Kind regards

Hello! UDP packets and/or certain IP addresses of our servers are blocked in your system. Please check your firewall rules. Also consider to enable Network Lock to replace your rules while Eddie is running (your rules will be restored). Upgrade to Eddie 2.12.4 as well. Kind regards

Hello! Problem has been solved. Kind regards

Hello, we do not enforce any cap on bandwidth, you are just meeting physical limitations. Our servers are connected to 1 Gbit/s ports and 150 Mbit/s means 300 Mbit/s on the server. In general, our infrastructure and above all our prices/business plans are designed to reliably provide 40-160 Mbit/s per client (i.e. 20-80 on the client side) - and 16 Mbit/s (server side) in the "worst case scenario" (i.e. if everybody connects at the same time AND requires maximum bandwidth constantly). Given the current oversize (redundancy) of Air infrastructure, however, you can easily reach (as you have experienced) 300-400 Mbit/s (which translates into 150-200 Mbit/s on the client side) with some care to pick a properly "not heavily loaded" server. Consider that currently it would not make much sense to get 10 Gbit/s ports for our servers, because of computation limits in encrypting/decrypting AES-256-CBC in a single core. Kind regards

Hello! The problem has re-emerged after the past fix. We confirm that we are aware of the problem and we will be working to solve it. Kind regards

To flush iptables rules enter the command (from a root terminal): iptables -F Network Lock does not cause any problem. If you kill Eddie without grace iptables rules will remain the same and this is not only expected, but it must be so. Traffic leaks prevention must remain enforced in case of OpenVPN or Eddie crash, incorrect behavior by the user etc. In such cases you can either run and shut down properly Eddie to restore your previous rules (because Eddie does backup your system iptables rules before modifying them), or just flush the rules. Both operations are a matter of a few seconds. Kind regards

In general this can imply that such VPN uses the same IP address both as entry and exit. It's an awful practice when IP addresses are shared (an essential requisite to have a better anonymity layer) and port forwarding is supported: data exchange with nodes in the same VPN will occur outside the tunnel exposing the real IP address to each other. A lot of correlation attacks can therefore be successfully achieved. Kind regards

Hello! Can you please check again your system DNS settings (while Eddie is not running), just in case the problem is related to DNS and not to firewall rules? Eddie 2.10.3 is a very old version and has a bug (only in Windows) for which, under peculiar circumstances, the DNS settings of a network interface were not restored. This bug was fixed both in the 2.11 and in 2.12 versions (upgrade to Eddie 2.12.4, the latest stable release, is highly recommended). Kind regards

Hello! Packets are forwarded to your node VPN IP address. If the guest OS is attached to the host via NAT you must take care to configure port forwarding from the host properly, because it's the host that's connected to the VPN in your system. VMWare does support this option. It's correct that this topic is in off-topic, because even according to your own description this is an issue with VMWare, not with AirVPN. Kind regards