Staff

Hello! Yes, it's possible. Kind regards

Hello! It's 10.4.0.1. It is reachable from any other subnet, even in Generation 2 servers, where subnets are smaller (/24) and unique for each server, port and protocol (a modification which makes multi-homing much simpler). Alternatively, consider to accept the DNS push from the server, if possible. Accepting the DNS push has a relevant advantage: it makes attacks based on DNS hijacking through route injection impossible, because the default VPN gateway address matches the DNS server address. Kind regards

Hello! Thanks, this needs an investigation. When you test in IPv4, you have no problems with port forwarding, is this right? Does the same happen if you run Eddie with Network Lock enabled and disabled? Have you checked the firewall rules pertaining to IPv6, especially when you run some other software to connect? This is a matter we are aware of, but we still don't have a definite explanation. https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/ We counted on some feedback and additional investigation, but the never ending black outs with IPv6 and the poor implementation in Italy ISPs made this impossible and we have postponed an additional investigation. On top of that, the issue does not affect the most important achievements we wanted with IPv6 support. i.e. the ability to provide at the same time: - a comfortable experience without any connectivity breaks to those who have only IPv6 connectivity - access to IPv6 services even to those who only have IPv4 - definitive resolution of IPv6 leaks with no need to completely block or disable globally IPv6 (unless explicitly required by the user) for those users who don't run Eddie We have dropped support to network-manager-openvpn since a long ago. We might investigate the issue in the future, but currently the official recommendation from the techies is just to not use it. Thanks, that needs an investigation too. Kind regards

Also curious to know this and also how it managed 1.7Gbit/s when it's only connected to a 1Gbit/s line? Hello! We are not yet well equipped to break the laws of physics. Servers in the NL are connected to 10 Gbit/s lines and ports. However, the lines are shared by 11 servers, so in the worst case scenario of maximum, simultaneous bandwidth requirement, theoretically and optimistically (and boldly assuming that a perfect balance is possible) each server can have 909 Mbit/s. Kind regards

Hello! No, we wouldn't make a stress test with customers. However, a system error caused the overload and we took advantage to take a look (ex post) to see how the server reacted to this mistake. When we realized what happened, it had already happened: at least we now have an interesting set of data coming from a "real life" test. The set of data is comfortably surprising, even because Atik is NOT YET a Gen 2 server, so the latest load balancing system is not yet implemented. This means that now we expect even more from Gen 2 servers which share 10 Gbit/s lines. Kind regards

Hello! Because you need to compare changes against version 2.14.5, since 2.15.1 has not been promoted to stable. Bug fixes and changes on version 2.15.1 have been kept in version 2.15.2 for Linux and Mac. In this way Linux, Mac and Windows systems are "aligned" to use the same release number for the latest stable version. Kind regards

Hello! Eddie 2.15.2 has just been released: https://airvpn.org/topic/28343-eddie-2152-released/ Kind regards

That's correct. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.15.2. As usual, Eddie is released as free and open source software under GPLv3. Eddie 2.15.2 includes an important bug fix for Windows users who change the default settings and force Network Lock to work with "Windows Firewall" (an option that anyway remains not recommended, Windows Filtering Platform should be preferred). You can see the changelog here: https://airvpn.org/services/changelog.php?software=client&format=html Network Lock is an Eddie feature that prevents any type of traffic leak outside the VPN tunnel https://airvpn.org/faq/software_lock Eddie includes a full, seamless and integrated IPv6 support, as well as new features which will let you use our latest service additions including IPv6 and tls-crypt: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Users who have only IPv4 connectivity will be able to access IPv6 services, At the same time users who have only IPv6 (and not IPv4) connectivity, will be able to use our service as well. tls-crypt implementation provides a new, interesting way to efficiently bypass blocks and throttling against OpenVPN. This version has been released for GNU/Linux, OS X (Mavericks or higher is required), macOS and Windows (Vista or higher is required). 2.15.2 version is compatible with several Linux distributions. For important notes about environments, please read here: https://airvpn.org/topic/27259-status-of-eddie-on-linux-distributions/ Just like previous versions, Eddie implements direct Tor support for OpenVPN over Tor connections. Eddie makes OpenVPN over Tor easily available to Linux, OS X and macOS users: no needs for Virtual Machines, middle boxes or other special configurations. Windows users will find a more friendly approach as well. This mode is specifically designed for Tor and therefore solves multiple issues, especially in Linux and OS X/macOS, including the "infinite routing loop" problem (see for example http://tor.stackexchange.com/questions/1232/me-tor-vpn-how/1235#1235 ) As far as we know, Eddie is the first and currently the only OpenVPN wrapper that natively allows OpenVPN over Tor connections for multiple Operating Systems. https://airvpn.org/tor Since version 2.14, Eddie sends a NEWNYM signal to Tor to ensure the use of a new circuit in every connection. We recommend that you upgrade Eddie as soon as possible. Eddie 2.15.2 for GNU/Linux can be downloaded here: https://airvpn.org/linux Eddie 2.15.2 for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.15.2 for OS X Mavericks, Yosemite, El Capitan and macOS Sierra and High Sierra can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.15.2 package includes an OpenVPN version re-compiled by us from OpenVPN 2.4 source code to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie is free and open source software released under GPLv3. GitHub repository: https://github.com/AirVPN/airvpn-client Kind regards & datalove AirVPN Staff

Hello! We inform you that IPv4 addresses of the servers mentioned in the subject have been changed. The change was mandatory to have the servers communicate in a different sub network in the same datacenter. The old IP addresses were behind a peculiar DDoS protection which was impacting performance heavily (maybe due to some sub-optimal configuration against UDP). From now on the three mentioned servers should go back to the normal and expected high performance. If you run Eddie, just update servers data (Eddie will do that automatically anyway, unless you explicitly disabled this function). If you don't run Eddie, please remember to generate new configuration files for those servers, if you wish to connect to them. Kind regards AirVPN 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