Staff

You jumped to the wrong conclusions. Network Lock works just fine, the bug affecting 2.14 (which is fixed in 2.15.2, which will be released in the next hours) affects only those users who: - run Windows - changed the default settings of Network Lock by explicitly forcing a not recommended option (marked as "Not Recommended") Additionally Network Lock will prevent traffic leaks even in the event of an OpenVPN or Eddie crash. Maybe you are thinking about those "kill switches" which were claimed (incorrectly) as effective tools to prevent traffic leaks outside the VPN tunnel. Forget about them, we're on a totally different level here. It is plausible that the source of your issue is different. It's impossible to say with the information you provided, you did not even declare you exact Operating System version. You should post a system report which can provide important clues ("Logs" > life belt icon > copy all > paste in the message). Kind regards

you have to disregard what I said about pinging. I don't use the app so I didn't realize that the app by default allowed pings out even with network lock on. Yes, that's a feature that has been strongly required by an overwhelming amount of users, while in older Eddie versions ICMP was blocked by default. You can anyway block ICMP as well with a click (untick "Allow ping" in "Preferences" > "Network Lock"). Kind regards

Hello! We confirm the bug, it has been inserted starting from 2.14. Needles to say that we will review with determination our internal method of testing and testing personnel. Unfortunately not even the whole community caught this issue, since version 2.14 has been in public beta testing starting from the end of January 2018 and nobody saw this, probably because this Network Lock method is clearly reported as not recommended. Version 2.15.2 (which had been planned to be released as stable) will contain the fix. It will be released in a very reasonable time. In the meantime, Windows users should simply leave Network Lock at its default setting, or revert back to "Automatic" or "Windows Filtering Platform" if they changed the Network Lock method to "Windows Firewall (not recommended)". Kind regards

Hello! Thank you for the report. Please keep Network Lock at "Automatic" setting or "Windows Filtering Platform" while we investigate with maximum priority. Kind regards

Hello! Just to clarify, that's not an error of the software. Eddie makes you know that the bootstrap servers could not be reached. If that happens when Eddie needs them for a VPN connection, the VPN connection will be impossible. The requester also provides you with the option to enter an alternative address of some different bootstrap server not included in the source code (so that's more difficult to block). This is an important feature to bypass blocks in restrictive networks (for example the "proxy black list" of Lately, it has come to our attention the need to get rid of the "bootstrap servers unreachable" error in an environment which runs Eddie before the system is connected to the Internet. In such cases, the message could be an annoyance since it requires a manual intervention. so in 2.15.1 beta the developers have added the option to tell Eddie to NOT show that message anymore after the 1st time. Kind regards

Hello, it's still a beta version of course. By the way, use "screen" to resolve the issue you mention. screen is a terminal multiplexer which can be even used to attach and detach sessions of any kind. Exactly what you need. https://en.wikipedia.org/wiki/GNU_Screen For your information: disown has nothing to do with what you want because it detaches and removes the job from the shell jobs control, but leave every job CONNECTED to the very same terminal (or terminal emulator). You might like to get documentation on nohup - anyway screen is even better. Some more information to underline the difference between disown and nohup (compare them with "screen" power): https://unix.stackexchange.com/questions/3886/difference-between-nohup-disown-and Check the very first answer. Kind regards

If your ISP provides you with full IPv6 connectivity, in the Configuration Generator please tick "Advanced Mode" to display all the options, Then select "IPv4 & IPv6 (connect with IPv6)" and proceed as usual. Kind regards

Hello! Can you please start it from a terminal emulator (not a real terminal, the desktop environment must be running anyway), copy all and send us the whole output of the command? Kind regards

Hello! This error: . 2018.06.18 13:39:37 - Unable to compute route for 2001:ac8:27:f:c0ca:9f36:68ed:1e70: IPv6 VPN gateway not available. is apparently hinting to a problem on the server side. However, first of all could you please check OpenVPN latest release? Additionally, a system report from Eddie might provide us with additional and potentially precious clues (to send a system report: "Logs" > click life belt icon > Copy all > paste into your message). Have you already tested different Generation 2 VPN servers? If so, does the problem stay? Last but not least, can you please verify the IPv6 status for your tun/tap interface, and make sure that IPv6 is not disabled? Kind regards

Hello! The problem is here: 2018.06.18 03:48:37 - OpenVPN > UDP link remote: [AF_INET]46.21.154.82:443 . 2018.06.18 03:48:40 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100. 2018.06.18 03:49:09 - OpenVPN > [uNDEF] Inactivity timeout (--ping-exit), exiting UDP packets are blocked. Please check any antivirus, antimalware and packet filtering tool in your system, as well as any other filtering tool on your router, including QoS, SPI etc. Also note that Kaspersky KIS 2018 is currently affected by a bug which makes VPN connections (including those to our service) with OpenVPN in UDP impossible. If you run KIS 2018 please see here:https://airvpn.org/topic/27526-kaspersky-anti-virus-19001088a-conflict/ A practical work-around is also suggested (and we confirm it works): disable KIS 2018, connect to a VPN server, re-enable KIS 2018 only when the connection is established. Kind regards

Hello! That sounds odd because there are no DNS leaks in GNU/Linux. They simply don't exist. A different argument is how to accept DNS push from an OpenVPN server. That adds a little bit of complexity, but you don't have to worry about that if you run Eddie, the Air software client. If you don't, check out our reference guide in our "How To" forum: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ Kind regards

Hello! Yes, you need that. In the Configuration Generator please tick "Advanced Mode", select OpenVPN version ">= 2.4" and select "IPv4 & IPv6 (connect with IPv6)". Kind regards

Hello, odd, because we did absolutely nothing. This thread started in 2015 and we actually had a web site related problem for a day or so that year. The problem was fixed in 2015 as well. Kind regards

Hello! None of our 10 Gbit/s lines are connected to a single server. We have 10 Gbit/s lines which are used to connect 10 servers. The fact that load balancing is being deployed is the founding step which prepares the chance to break the 980/990 Mbit/s (of AES encryption-decryption in a system with dozens of OpenVPN clients) limit on AES-NI supporting CPUs. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.15beta. It is ready for public beta testing. To download Eddie 2.15beta please select "Other versions" > "Experimental" from the download page. Please see the changelog: https://eddie.website/changelog/?software=client&format=html Eddie 2.15 aims essentially to fix bugs in 2.14.5 version before building up any new feature or important change. Kind regards & datalove Air Staff

Hello! We're very glad to inform that full IPv6 support is being deployed to our VPN servers. The experimental phase ended during the first half of June and we can now reliably deploy IPv6 to any other VPN server, provided that it is in a datacenter with IPv6 infrastructure of course. This thread will be periodically updated to provide the list of VPN servers new generation setup (internally, we call this new setup "Gen 2"). FINAL UPDATE: as of September the 14th 2018, all AirVPN servers have been upgraded to 2nd generation software. New smart features: Standard protocols/ports with IPv6 support (*), updated OpenVPN server, better cipher negotiation. You can keep using AirVPN as usual, even if you have an old OpenVPN version, on entry-IP addresses 1 and 2 of each server.Additional protocols/ports with IPv6 support (*), updated OpenVPN server, better cipher negotiation, 'tls-crypt' support (*), TLS 1.2 (*) forced on entry-IP addresses 3 and 4 of Gen 2 servers. The additional protocols/ports mentioned in this paragraph require OpenVPN 2.4 or higher versions(*) OpenVPN 2.4 or higher version is required. tls-crypt plays a role even against ISPs that throttle or block OpenVPN. Something more about tls-crypt can be found here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Search for "--tls-crypt keyfile" Planning the future: internal load balancing between multiple OpenVPN daemons. This is a feature which will let OpenVPN squeeze the maximum bandwidth on each server, because OpenVPN runs in a single thread of a single core. By balancing the load on multiple OpenVPN daemons with a reliable algorithm, we overcome significantly this OpenVPN limitation. Such bandwidth would be mostly wasted without our load balancing method simply because there are no CPUs capable to process 10 Gbit/s AES-256 encryption/decryption on multiple flows to/from multiple channels (according to our empirical tests on the field, the load does not grow linearly with the growth of connected OpenVPN clients) with just one one core. Our solution is important because it's a founding prerequisite toward servers connected to 10 Gbit/s lines, even if OpenVPN multicore / multi-threading support should not become available in the near future, not to mention that it can be useful even in different environments. The internal load balancing is already active on all "Gen 2" servers. Kind regards and datalove AirVPN Staff

Ok! We'll see to do something. Kind regards

Hello! A quick way to discover IPv6 supporting servers through the Configuration Generator is just selecting "Advanced Mode" and then "Connect with IPv6". Kind regards

Hello! True. Probably the market pressure is still too low for IPv6 thorough depletion. For example, we have had (and we still have) several technical issues and blackouts with IPv6 for our tests from Italy, and our IPv6 monitoring system still detects random and frequent IPv6 blackouts in many servers in various datacenters, for example in Canada, the United Stated and the Netherlands. Things might change as the IPv4 addresses shortage will hurt more and more, and maybe when some services will be reachable only on IPv6, but we have no idea when this will happen. At the moment, it's plausible that for an average Internet user (and even for many advanced users) IPv4 is sufficient for any purpose. Our care and urgency to provide full IPv6 support is based on the need to remain the most advanced VPN service and therefore satisfy the requirements of an important niche of customers who have only IPv6 access (IPv4 available only over IPv6). For them, using a VPN based on IPv4 only is not safe, or it's even impossible on some systems. Kind regards

Hello! We are very near. Now servers supporting IPv6 and tls-crypt are twelve and no specific problems are detected. We call such servers "Generation 2" servers, and you can see them in Eddie or in the Configuration Generator by selecting the proper options. When Eddie 2.14.x reaches the stable release, we will allow some more time to get out of the experimental phase and upgrade (gradually, because it requires disconnection of all clients) every server to Generation 2. Only a tiny amount of servers (less than 7-8) will not support IPv6 because the datacenter does not have an IPv6 infrastructure. They will support anyway tls-crypt Kind regards I'm curious - how can a datacenter of all places not have an infrastructure for a protocol that's been around for 20 years now? Are you able to list such servers or at least name and shame the providers? Maybe it's a sign of a larger problem but I'd have thought IPv6 is essential now IPv4 is depleted... Is it even fair to call it a 'datacenter' if it can't route packets on what is the most essential fundamental layer of networking? Hello! The servers which are in a datacenter without IPv6 infrastructure are Baiten, Porrima and Scheat (Lithuania) and Kitalpha (Switzerland). The company operating the Kitalpha datacenter wrote to us that IPv6 support is planned in a not too distant future. Kind regards

Yes, that's because all of our *.vpn.airdns.org names rpertaining to zones (countries or continents) have their records updated every 5 minutes to resolve into the entry-IP address of the best rated VPN server in that zone. However please consider that TTL is 1 hour. remote-random enters into play when you have multiple remote entries, which is another option you might consider. Kind regards

Hello! We can gladly confirm that according to the first reports tls-crypt (only on TCP) works in China and it is faster than OpenVPN over SSL. tls-crypt with UDP also works in some networks and this is the maximum OpenVPN performance. In some other networks tls-crypt with OpenVPN in UDP does not work but not because of tls-crypt in itself, but because UDP is unconditionally blocked. Kind regards

We're sorry, no, we don't understand it. Why not, this is perfectly possible and you can keep as many accounts as you wish. Kind regards

We thank you very much for your links and interpretations. Our policy in general does not change, not even for UK. Kind regards

Hello! In the last examples "remote-random" is redundant. remote-random does not make sense when you use a single "remote" directive. Just for information. Check the manual here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Search for "--remote-random": --remote-random When multiple --remote address/ports are specified, or if connection profiles are being used, initially randomize the order of the list as a kind of basic load-balancing measure. Kind regards