Staff

Hello! We confirm that the linked table includes several errors. We take this opportunity to clarify that: all VPN servers use RAM disks. After a minimal bootstrap which must bring up the TCP/IP stack, the network and essential services to operate on the network, vital files (including secrets, configuration files and scripts) are downloaded on RAM from the network, from selected storage and strong authentication ensuring integrity. What's more, if a server reboots unexpectedly, the AirVPN management must confirm the authorization for the server to be re-admitted in the infrastructure, making it possible to understand the cause of the reboot and to verify (thanks to pristine copies) whether the server has been tampered before it comes back operational WireGuard is available since 2022 (in beta testing since the last quarter of 2021) and it also includes pre-shared keys, just in case they are needed for a quick additional cipher deployment in an unlikely post-quantum world. The API has been improved to offer the option to re-generate keys on the fly, resolving the privacy problems posed by WireGuard ads, trackers etc. blocking lists are available since 2021. In our opinion our system is unrivaled on any VPN service, as you can configure it, add additional blocks or specific exceptions to lift blocks, and link different lists, additions and exceptions to different devices. Last but not least you can operate via API to get the available list information. Note that the ad blocking system is opt-in for a precise choice: by default the network must remain agnostic and neutral. Blocks are enforced only when explicitly wanted by the users. additional connection modes include OpenVPN connecting through HTTP(S) and SOCKS proxies, OpenVPN over Tor (not available on Android), OpenVPN over previously established TLS and SSH tunnels (OpenVPN over stunnel and OpenVPN over SSH), OpenVPN tls-auth for backward compatibility, OpenVPN tls-crypt for enhanced block bypassing Kind regards

Hello! For the readers: the problem affecting @konijntjes has been resolved by disabling Windows "Fast startup" option. We are still investigating to understand more closely the source of the issue. Thanks to @konijntjes precious reports flowed in during the last hours, it might be something related to network interface handling before and after a system suspension or hibernation, but it's premature to say anything more detailed. In the meantime, anybody suffering similar problems may try to disable "Fast startup" to resolve the issue, which is anyway an option infamously known to pose a lot of different problems even on latest Windows versions and even to system commands. Kind regards

Hello! There's a part of an old urban legend here. Eddie's source code is available on GitHub (including the current 2.22.2 which is still considered "beta", according to the unorthodox release cycle of Eddie), anyway the essence of the urban legend is assuming that a license enforces restrictions on future releases of a certain work on the copyright holders themselves. The copyright holders are not restricted on future development or re-arrangement of a work of mind by any previous license since they are the "legal owners" (according to the international treaties which overlap intellectual monopoly with intellectual property and the EU legal framework on intellectual monopolies). On subsequent releases, the license of the current work always defines and/or restricts the rights of third parties, and not the rights of the legal owners. At the same time, the license we agreed to pick grants third parties that no retroactive restrictions are possible. If Eddie's developer decided to distribute an Eddie version without source code he would have the legal right to do so, provided that Eddie does not include third-party code licensed with restrictions against closed source code. It doesn't happen because of AirVPN mission (and Eddie's developer is also an AirVPN co-founder), but legally it would be Eddie's developer right. An identical right is reserved to AirVPN Suite developers, and exercised on both senses. If you notice, when a Suite alpha or beta version is made available to community testers, the OpenVPN3-AirVPN library against which the Suite is linked is always open source, while the proprietary preview code is closed. It is then re-licensed and opened (usually under GPLv3 but we're not ruling out different, more permissive licenses, for the parts we have exclusive rights on) only when the development team considers the software as "stable". Even in this case, releasing a copyrighted software as a preview does not prevent the developers to re-license and open it in the future (so far to make it open source under GPL). You did not miss anything. Eddie 2.22.2 is still the latest "experimental", but the testing work is over. If nothing serious comes out (fingers crossed) you will see a new stable release very soon. Kind regards

@konijntjes Hello! Thank you for having contacted the support team. We have reviewed your ticket and we re-publish the relevant part here just in case some other user has experienced the same Windows malfunction and for general knowledge which might be relevant to this thread. It seems that the problem is related to Windows (and specifically to ipconfig.exe utility) and not to Eddie. If anyone has relevant information about this, please feel free to write here, as we have never seen something like this on any of our Windows testing systems. ---- TICKET REPLY BY CUSTOMER SUPPORT --- The quoted error is a system error. ipconfig.exe is a system application. You have an anomaly of a system application used by Eddie and by OpenVPN, but only at the first boot. This might be a Windows bug related to "fast startup". Can you please check whether fast boot is enabled or disabled? If it's enabled, please disable it and test again. See also here: https://www.windowscentral.com/how-disable-windows-10-fast-startup What's more, if you run third-party antimalware or packet filtering tool, try to disable them as well and test again. It's possible that such tools prevent the system utility (ipconfig) to start under some peculiar situation. We can't reproduce this problem at the moment and we have no other reports related to ipconfig unable to start, but now everything suggests that the problem is related to Windows and networking, or some antimalware tool interfering with network configuration, and not to Eddie itself. We're looking forward to hearing from you. Kind regards AirVPN Support Team --- CUT --- Kind regards

Hello, you didn't open any ticket about this problem, so.... please open a ticket, as the support team is here to assist, just use the customer service! Kind regards

Hello! Like many other well behaving programs, Eddie stores a configuration file in the home directory of the user(s) who launched it. Please see also: https://eddie.website/support/data-path/ Kind regards

Hello! It's a problem affecting intermittently three Dallas servers, apparently, which fail to compute the correct bandwidth due to network interface traffic counters premature reset. So you see the correct amount of connections, but a much lower bandwidth. Chamaeleon, Pegasus and Mensa are currently suffering this issue. A new investigation will be opened. Kind regards

Hello! Thank you for your suggestion. Network Lock remains enabled if the AirVPN app crashes or suffers any abnormal termination. On the contrary, if the AirVPN app is cleanly closed, or the Network Lock is explicitly disabled through the proper option, then the previous system firewall settings are restored. This is by community driven design in the early 2010s and it's still the correct design according to the idea that the AirVPN app, once shut down properly, must not be invasive and must restore all the system settings. It's then administrator's competence, by settings the proper rules, to decide whether the packet filtering tool must block Internet connectivity when the AirVPN app is cleanly shut down or has not been launched, or not. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Sao Paulo (Brazil) is available: Fulu. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 and 47107 UDP for WireGuard. Fulu supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Fulu Please note that Fulu will replace Peony and Lalande, which unfortunately in the last 6 months performed very poorly. Peony and Lalande are currently down (again). Unfortunately the uptime of Peony and Lalande has become unacceptably low, so we are forced to decommission them. Fulu can replace both servers as our tests confirm that its superior hardware and connectivity outperform Peony and Lalande together. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 

Hello and special thanks! Please see here for an explanation and a quick solution: https://airvpn.org/forums/topic/53004-openssl-error-restart-every-3-seconds/ Kind regards

Hello! For the readers, an update from the support team. The problem of the OP was caused by the fact that he/she disabled Eddie's Network Lock inadvertently by setting "Allow outgoing" and "Allow incoming" connections outside the VPN tunnel in the network lock fine tuning settings. This event pushes us to recommend the following: do not change advanced settings if you don't understand what they do. Read the documentation first and if you still have doubts contact the customer service. Kind regards

Hello! It is possible that you're still running OpenVPN 2.4. That message is slightly misleading: in reality, it usually means that some directive in the ovpn file has not been recognized. Our Configuration Generator, now, by default creates ovpn files compatible with OpenVPN 2.5, 2.6 and 3. If you still run OpenVPN 2.4, you must generate a configuration file with the following options in the CG: - check "Advanced Mode" - in the "OpenVPN version" combo box select ">= 2.4". The above settings will force the CG to generate an ovpn file fully compatible with OpenVPN 2.4.x. Let us know whether the above solves the problem. Kind regards

Hello! Please follow the thread here: https://airvpn.org/forums/topic/56119-new-10-gbits-server-available-bg/ The message by Antonio Quartulli on the end of March implies that our tests had to re-start almost from scratch with the new DCO and the new OpenVPN 2.6.2. Remember that DCO, as reported in the GitHub repository https://github.com/OpenVPN/ovpn-dco ovpn-dco is currently under heavy development, therefore neither its userspace API nor the code itself is considered stable and may change radically over time. Remember also that every time the code changes radically our tests must re-start almost from scratch. About the stability, with 2.6.2 and latest current experimental DCO 0.2 module we have not had anymore kernel panics. Given the above you can easily understand that DCO is not ready for production on the server side of course, so we're planning to put a highly experimental server to let the community test with no stability or backward compatibility commitments. For latest issues and updates about them, please follow GitHub as well: https://github.com/OpenVPN/ovpn-dco/issues Kind regards

Hello! If you run Eddie Windows edition (if not, please specify the software you run), it's because Eddie Windows edition runs external binaries and performs various operations which are not necessary in Eddie Android edition. Furthermore, in Android, the round trip times calculations are completely skipped as quite a different method is employed to pick a server when the user leaves the choice to the program. Here some tricks to speed up the connection phase to a VPN server in Windows: 1) keep Network Lock enabled and disable both route and DNS check. In Preferences > Advanced window uncheck Check if the tunnel works and click "Save" In Preferences > DNS window uncheck Check Air VPN DNS 2) If you already have your set of favorite servers and you don't need that Eddie re-computes at each new connection the whole round trip times table, in Preferences > Advanced uncheck Enable latency tests and click "Save". With the above settings met, your initial connection will become noticeably faster. Kind regards

Hello! The first problem is caused by a bug. In some cases Eddie enters a race condition and remains stuck during the latency tests. This bug has been fixed in Eddie 2.22.2 which you can get from the usual Linux download page https://airvpn.org/linux/eddie/ by clicking "Switch to experimental". The stability problem must be investigated. Do you experience the issue both with WireGuard and OpenVPN? Please feel free to provide a system report and/or open a ticket to get support from the dedicated tech support personnel. How to generate and send us a system report: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-%E2%80%93-heres-what-to-do/ Kind regards

Hello! We have brought the lists in and we will be testing them very soon. In this case some care in testing is needed because we're talking about 900'000 records (6 lists made of ~150k records each). If everything goes well you will have them available in the DNS panel at the end of the next week or so. Kind regards

Hello! OK, we'll soon verify when we perform some tuning to check. In general, connected users on Xuange are more than on Ain and Wazn. True. The goal is not to consolidate the constellation with a lesser amount of 10 Gbit/s servers, because that would imply loss of redundancy and other centralization problems. Currently the goal is decommissioning old hardware servers, improve current lines which struggle to meet our demands (example: Brazil) and increase 10 Gbit/s presence. On the long run, we'll see. Kind regards

Hello! Thank you for your feedback. Maybe we are loading Xuange too much (*), we will look into the issue you report. Actually Xuange is not with M247 or Softronics, but with AltusHost, a very reliable company with excellent peering agreements. Now, it is possible that you have bad peering (if you have time, check with tools like mtr) with the AltusHost transit providers, but anyway a fresh look into Xuange will not hurt. There is no realistic availability of 10/100 Gbit/s NICs and lines for Kitalpha, unfortunately, so that's not an option. If upgraded, Kitalpha would anyway remain a "1 Gbit/s" server. (*) Not in terms of bandwidth but in terms of amount of users. With OpenVPN the load grows more than linearly with the amount of connected clients and the majority of the users prefer OpenVPN over WireGuard at the moment. If we manage to determine that Xuange is over loaded we will act appropriately. Kind regards

Hello! Your ticket dated April the 2nd has been replied in a record time of 10 minutes. You never replied back and the ticket was closed after 10 days or so. Please note that courtesy e-mail has been properly sent too. If you have problems with your e-mail inbox please check your control panel of your AirVPN account in the airvpn.org web site. The original text from the support personnel was: As soon as you reply and send what they ask for, the support team will have something to work on, in order to understand the source of the problem and suggest solutions. Kind regards

Hello! From your description, and assuming that it's not an IPv6 related problem (make sure that your system supports it) we suspect an old problem occurring with "translations" in some Linux systems which run with nftables but by default do not have the userspace utility nft. In such cases, both Eddie and the Suite fall back to iptables utilities, which are in turn linked to iptables-nftables or similar utilities to translate rules etc. for the new netfilter environment. We found that the translation process has a subtle bug which might cause serious problems to Eddie. (*) You can't renounce at the moment to the translation burden because, as far as we know, ufw does not support nftables, but you can at least have Eddie use nft directly. Please check whether you have nft in your command path and if not, install it (usually you can install nft utility by installing the complete nftables package, example sudo apt install nftables ). Once nft is available, Eddie will use it and if the problem were the one we mentioned above, it should get resolved. There might still be potential problems caused by the fact that ufw will keep using iptables syntax with custom chains, but Eddie will save the system rules and restore them (respectively when Network Lock is turned on and off) in nft format. If that's a problem too, try to disable completely ufw before you start Eddie, and re-start ufw only after Eddie has been shut down. Please keep us posted at your convenience. Kind regards (*) Eddie 2.22.2 takes into account this "translation bug" and features new code which should resolve it.

Hello! OK, thank you for the correction and the precious help! @bumwolf Did you manage to resolve the problem in the meantime? Kind regards AirVPN Support Team

Hello! Try to log on file and let's see whether some entry on the file which can provide for some clue is written before the "hang". You can configure Eddie to log on file in the "Preferences" > "Log" window. Then reproduce the issue and finally read the file with any text editor (and feel free to send it, of course). Kind regards

@OpenSourcerer Hello! We have had a discussion about Kitalpha and the datacenter it is inside. Kitalpha now supports IPv6 (a few months ago addition by the datacenter), but it has an old hardware which should be improved. With the same commitment we have with Kitalpha, even if we did not consider the price for an upgrade to a more modern hardware, we could replace it with one 10 Gbit/s server with powerful CPU, more traffic etc., in the same datacenter hosting Xuange. So we're seriously considering to do so. But before anything else, can you please tell us why you would prefer or need a server in the same datacenter and/or AS? Kind regards

Hello! Note to readers: problem resolved by upgrading Eddie (the 2.13.6 version was used on an Operating System which did not exist when 2.13.6 was released many years ago). Kind regards

Hello! It's a security feature. The GUI does not run with root privileges and any event based script or software will not be automatically run as root, so your attack surface is not enlarged. It's your own responsibility, as a system administrator, to decide whether a script or software run by Eddie GUI (or any other software running without root privileges) must gain root privileges or not. Kind regards