Staff

Hello! Under a more radical point of view, if you fear that Eddie setup has become garbled and you can't restore a working setup, you can go back to the default settings by selecting "Preferences" and clicking "Reset to default settings". This procedure might be ineffective if even the configuration file is corrupt (a very rare occurrence but you never know). In this last case, delete the following file, while Eddie is not running (you can use rm command): rm ~/.config/eddie/default.profile At the next run, Eddie will re-create a clean profile with default settings (you will need to re-enter your AirVPN account credentials as well). Kind regards

We see the problem in Linux, while in other systems the tool tips are displayed. Developer will be informed. Kind regards

@Grindle222 Hello! If you mouse over any button you should see a tool tip displaying a brief description of what that button does. Alternatively, right-click on a server name, or a country name. The contextual menu will link all the icons to specific menu items self-describing the action performed by each item and thus any menu button as well. Example: Here above you can see that the arrow pointing to the door means "connect now" to the selected server, the green tick means "Allow list" and so on. This is unexpected and for this problem we invite you to open a ticket at your convenience. The support team will provide you with assistance. In general, here we can say that the "Latency" column list is compiled by sending ICMP packets (by using "ping", so to be precise it shows round trip times and not latencies) to the various servers, so it will not work if your ISP (or some packet filtering tool in your system) blocks such packets. It's anyway not essential to use Eddie. Kind regards

@AVPN0815 Hello! That's not entirely correct because we use RAM disks. It is true that an HDD or SSD is used to boot, and it contains a working boot record, grub software or similar, used in turn to load a kernel which must provide TCP/IP, network and basic services support, but anything else is downloaded via network (after the network is up, obviously). At each (re)boot the server can not start, because it is barred from downloading any relevant file until we authorize the reboot, so it will miss even the essential configuration files, scripts, keys... This allows us to check the kernel (once the network is up) and any relevant storage file against a pristine copy, especially if the reboot is unexpected. Once the TCP/IP stack, the network and their essential services have come up, and a manual authorization has been dispatched by AirVPN management, the server starts downloading any other file needed for normal operations, and all of that remains in RAM disks. Kind regards

Not only TikTok. For example the Bitcoin network can not be controlled so a transaction from an American citizen could potentially go to a citizen of a country that's "a menace" for the USA (definition of enemy and menace is discretionary, the used language seems fine tuned to allow scope enlargement at will without judiciary supervision). Since that's not controllable, we find it potentially possible that operators might be required to block "the Bitcoin network". What's worse, according to a preliminary interpretation of the text, if in some way (difficult but personal and house search, pre-selected through the usual monitoring performed by USA ISPs, can help...) it can be proved that a USA citizen has used some tool like Tor or VPN to access any of the blocked network / services etc., that citizen will be prosecuted: civil liability up to a million of dollars, and criminal behavior subjected to up to 20 years in jail - which, if we're not mistaken, is worse than in China, Russia, and various countries controlled by human rights hostile regimes. Kind regards

Hello! UPnP and NAT-PMP may easily cause binding to the physical network interface (and negotiation with the upstream router etc. for a port agreement) and therefore Deluge will never receive anything from the virtual network. As a first step please disable those options; moreover, please check again all the settings against the following guide: https://airvpn.org/faq/p2p/ Kind regards

@Visentinel According to a preliminary and very quick legal analysis the Act can be used to charge USA citizens and any company operating in the USA (even non-USA companies, of course) with civil and criminal liability for using Tor, VPN, proxy services, Bitcoin and various open source tools which facilitate encrypted communications to bypass any kind of censorship. Apparently, the language picked for the Act allows to enlarge and broaden the scope of the Act at will. Should the Act be approved as it is, and should the will to enforce it in the broader sense is strong, it is possible that there is no future for the Tor Project and consumers VPN in the USA, if not underground. Simply accessing the Bitcoin blockchain to transfer coins may be easily included as a forbidden action by the Act scope. We underline that all of the above is based on a preliminary legal analysis, which may change after more thorough examination. Sources. Wikipedia: https://en.wikipedia.org/wiki/RESTRICT_Act Vice: https://vice.com/en/article/4a3ddb/restrict-act-insanely-broad-ban-tiktok-vpns Decrypt: https://decrypt.co/124892/coin-center-restrict-act-ban-bitcoin Official current draft: https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15 We're open to more discussion, opinions and legal analysis. Kind regards

Hello! The speed measurement seems correct and it is expected that different measurements are... different, as far as we can see from @sebi clip, since you must discern the total throughput from the throughput of each network interface. The inability to establish a connection before the WiFi card is configured might be a more complex problem related to how OpenVPN and WireGuard work and it needs additional investigation. The whole issue will be brought under the attention of the developer. Feel free to report on GitHub too, if you prefer so. Kind regards

Hello! At least this behavior is exactly as intended. If you cleanly shut down Eddie, it is assumed that you don't want Eddie service anymore. On the contrary, if Eddie crashes or receives a SIGKILL then the firewall rules of the Network Lock feature remain in place and prevent any leak. If you want a permanent disconnection from the Internet even when Eddie is not running, and/or even while the system is bootstrapping, you need to set proper firewall rules and make them permanent. In this way you may have leaks theoretically only before the firewall comes up (a very short moment when the network interfaces come alive and get configured but the fw is not yet operational - immediately after that, the firewall is brought up and the packet filtering table populated), and only if some system process is incredibly quick to start and create a socket even before the firewall is fully operational. Kind regards

@cheapsheep Hello! Under investigation. We will keep you informed. Kind regards

Hello, please open a ticket and make sure you mention the account name! Alternatively write to support@airvpn.org Kind regards

@Strongduck In 13 years we have never received a single court order pertaining to copyright infringements, but you're right you never know (fingers crossed!). We accept Bitcoin for example since so many years ago... Even the data ("complaints") that we sometimes receive about alleged infringements on "p2p networks" are quite weak and technically questionable, and it's hard they hold in a court... not to mention that a magistrate in several cases would not even serve a decree to freeze and disclose personal data on the basis of file sharing upon a private request based on the scarce/weak information we see on the complaints. Kind regards

Hello! It's an "abandoned" system. Mainstream support ended on 2012 while extended support ended on April 11, 2017. Using it is therefore risky as any new discovered vulnerability is never patched. Kind regards

@sebi Hello! You need to uncheck "Use Hummingbird if available" in the "Preferences" > "Advanced" window. Eddie will then look for OpenVPN in your command path (OpenVPN must be installed in your Linux box). If you have some OpenVPN binary you want to use outside the path, then you need to tell Eddie where to find that OpenVPN binary. Note that Eddie will run with root privileges only binaries owned by root. Beta versions exist exactly because unexpected problems may (and usually will) come out. Eddie stable releases are always packaged with a tested Hummingbird version. About the Suite, we are almost ready to launch a version linked against our openvpn-airvpn fork fixing the new bugs and regressions unfortunately inherited from the main branch which we did not find with our tests (our fault, hands down). If you want to use Eddie with a working version of Hummingbird you can rely on Eddie 2.21.8, which is the latest stable release and is packaged with Hummingbird 1.2.0. This is an excellent question, and currently Eddie can not renounce to those directives for a complex reason. In a few words, with the risk of oversimplifying, it's because of how our servers are configured in order to maintain backward compatibility with OpenVPN 2.3 and 2.4. Sooner or later we will break compatibility at least with OpenVPN 2.3. From that moment on, Eddie can be re-designed with more freedom in mind and some behavior which may appear "strange" when compared with ordinary OpenVPN configuration files (as it is in this case, with the directives you mention) can be simplified or canceled. Also note that some other behavior is dictated by the fact (and this is perfectly logic as well) that Eddie adds some important features on top of OpenVPN features (routes inside and outside the tunnel, DNS management, Network Lock...). Thank you, this sounds like a bug and it's great that bugs are found during beta testing (or anyway before a stable version is out). We will forward your message to Eddie's developer. Furthermore, please feel free to report this on GitHub and on Eddie's thread in "News", if you wish so. Kind regards

Hello and thank you very much for your great feedback! Do you experience the instability with WireGuard, OpenVPN or both? If you haven't tested both, could you please do it and report whether you have the same problem or not? You can switch between them simply by tapping the VPN type icon on the main and other views. Also, we suggest that you send us a report (in a ticket, for privacy reasons) generated by Eddie while the problem is ongoing or has just occurred. In the "Log" view you can tap the paper plane icon and send the whole report to one of our web sites. Eddie will tell you back the link to it, which you should then send to us. You can anytime delete the report and anyway it will be automatically deleted in 30 days. Kind regards

Hello and thank you very much! We confirm the "swift and painless compilation". The main problem we experienced is the following one: https://github.com/OpenVPN/ovpn-dco/issues/14 Unfortunately we don't have much to add on what Schwabe already wrote. We can say that we had the issue only on a single VM (an AWS EC2 used momentarily for this purpose) during our very early testings (Debian 11, 5.10 kernel, OpenVPN 2.6/OpenSSL/DCO etc. in house built). Now that we are testing only on dedicated servers (minimal Debian 11 installation, Xeon E3 or Xeon E5 architectures on HP and Dell servers) we can not not manage to reproduce the issue anymore. Should we get some additional piece of info/dump/how to reproduce/etc. we will definitely inform you. The crashes that we had on the VM had an apparently random pattern, so we can't even say what to do to maximize the reproducibility likelihood, we're sorry. In our configuration some OpenVPN processes are working in UDP, other ones in TCP, both tls-auth and tls-crypt, in all combinations. OpenVPN on the VM was 2.6.0, we see now that you strongly recommend 2.6.2 and of course we will update. LAST MIN. ADDITION: However, we now read a brand new comment on GitHub about the issue: Maybe we already built DCO including the TCP rework (on our dedicated server)? Can you tell when the rework and simplification have been committed? Kind regards

@OpenSourcerer Just in case this is a valuable information for you, ProMind tested and could build OpenVPN+DCO on kernel 6.2.7 (in a Fedora 37 system) without any problem, through the provided Makefile and no modifications at all. Swift procedure, not even a single warning was thrown. Kind regards

@oassQ9w4cbl4AySZhhth%p36x We will keep you posted. Unfortunately, it's possible that in an initial stage DCO will be only on experimental servers, so yes, persons available to testing will be invaluable, thanks! Check here for a quick update: https://airvpn.org/forums/topic/56119-new-10-gbits-server-available-bg/ Kind regards

5.16. Correction, 5.10 We never tried to do it on 6, and we're sorry (and concerned) to hear that. Thank you for the information. Kind regards

Hello! From GitHub and yes, we have actually experienced various problems we wrote about a week ago or so, that's why you see this relevant delay in deploying DCO. Maybe DCO will have hard time to get its way into kernel.org, as we read of a lot of serious problems unresolved since months, but we'll see. We will keep you informed and we ensure you that we will not trigger a potential bomb in our kernels. If we reach an apparent stable environment, we will anyway deploy DCO very gradually. Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s (full duplex) server located in Sofia (Bulgaria) is available: Wazn. With Wazn, AirVPN infrastructure can now offer 10 Gbit/s full duplex lines and servers in strategic locations all over Europe: Switzerland, the Netherlands, Sweden and Bulgaria, all of them with direct peering with a wide variety of providers and at least two tier2 transit providers. As WireGuard diffusion increases, such servers will be able to use more and more bandwidth, while the imminent OpenVPN DCO deployment on selected AirVPN servers will also provide for more scalability and performance. According to our tests (*) from Italy, the Netherlands, the United States and Germany (from both residential and business lines) and our statistics, in the countries with a presence AirVPN remains the fastest VPN for consumers in the world, both for available bandwidth and round trip times. We are confident that the progressive increase of CPU power and available bandwidth, together with our usual commitment against overselling, will further widen the gap. (*) Tests performed from tier1 providers such as Telecom Italia Sparkle or "near-tier1" ones such as Cogent and Hurricane. Tests performed against a wide variety of well known VPN services, including the most advertised ones. 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. Wazn 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/Wazn Do not hesitate to contact us for any information or issue. Kind regards and datalove

@bidasci Use a proper language and don't be aggressive. You might use that language with your family, if they allow you to do so, but surely not with us and our community so get a grip of yourself right now. Open a ticket and the support team will assist you. Check the real time servers monitor to get convinced that the problem may very well be on your side. Acknowledging this simple fact is the first step to work to resolve your own problem with our assistance. Last but not least, advertising other VPNs in this way is severely forbidden, so the ad has been removed. Do not post other ads or you will be banned from the forum. Kind regards

@nocturnaltabernacle Hello! It might be an MTU size issue. By default, on Linux and FreeBSD, WireGuard might set a 1420 bytes MTU size, which is too big for some networks. Shrink it to 1320 or even 1280 bytes (the minimum accepted value) and test again. In order to change wg interface MTU size on your BSD system, please edit the wg configuration file with any text editor and add the line: MTU = 1320 in the [Interface] section. Kind regards

@BatteriVoltas Hello! Please feel free to open a ticket to get thorough support. In the ticket please state whether you get error 110 or 111 when you test from AirVPN web site port tester. As a preliminary check, please make sure that Deluge settings related to UPnP and NAT-PMP are all disabled and that no firewall (running in the same machine where Deluge runs too) interferes with packets to and from Deluge. A quick reference guide to check other settings: https://airvpn.org/faq/p2p/ Kind regards

Hello! Because it's not mandatory. You can open a ticket from an account which does not have any e-mail address. Kind regards