Leaderboard

@wireguard User "wireguard" is not an account with a valid AirVPN plan If you really wanted to show your support to AirVPN and prove that you are a customer, you would have written from an account with a valid plan. In reality, accounts like "wireguard" seem to be created with the only purpose to pump something and defame something else. From now on, write only from an account that has valid plan, to show that you are in good faith. Our plans about putting Wireguard into production in the near future have been published with a lot of details, albeit without a precise release date (and we have thoroughly explained why), so we will not write again for the nth time about them. About performance, please provide details as we do frequently. Currently we outperform Wireguard with our setup in AES-NI supporting systems, as you can see from our and our customers' tests, while Wireguard can outperform OpenVPN in CHACHA20 in non-AES-NI supporting systems. . When we put Wireguard into production, OpenVPN will stay, so investing in our own OpenVPN development is perfectly fine. Just a few reasons that make OpenVPN superior to Wireguard for many, different needs: it's faster than Wireguard in AES-NI supporting systems when it uses AES. Have a look here! it can be connected over stunnel, SSH, SOCKS5 and HTTP proxies, and Tor swiftly even for the above reason, for an ISP it's not so easy to block OpenVPN, while it's trivial to block Wireguard it supports TCP it supports dynamic IP address assignment it supports DNS push it does not hold in a file your real IP address when a connection is closed a significant part of our customers will not be able to use Wireguard effectively, simply because UDP is totally blocked in their countries or by their ISPs UDP blocking and heavy shaping are becoming more and more widespread among mobile ISPs, making Wireguard slower than OpenVPN in TCP even in mobile devices, or not working at all in mobility About Torvalds and Linux kernel, you only tell a part of the story. Wireguard was first put in some Linux kernel line when Wireguard was still in beta testing and no serious audit was performed, and not put in a kernel milestone release. A further note about battery draining you mentioned in one of your previous messages: our app Eddie Android edition and Wireguard, when used with the SAME bandwidth and the SAME cipher (CHACHA20-POLY1305), consume battery approximately in the same way, so that's yet another inessential point that does not support your arguments and show once more that our investments have been wise. Finally, let's spread a veil on your embarrassing considerations on ciphers, security, privacy and NSA. Let's underline only that CHACHA20.-POLY1305 is very strong, the cipher algorithm in itself (if implemented correctly) is not a Wireguard problem in any way. It would be a reason of deep concern if Wireguard needed OpenVPN defamation to convince us that it's a good software. Unfortunately various bogus accounts have been created with such assumption and purpose, and the hidden agenda is no more hidden. Kind regards

Hi, I found the cause of the speedproblem. It was the Wireless AC 7260 driver after the last Windows 10 update. Here is what I did to solve the problem: 1. Deinstallation of Eddie. 2. Deinstallation of the current driver and deactivation of the Wlan Adapter. 3. Restart of Windows. Windows installs the driver version 17.15.0.5. Don't update it to the newest Intel driver!!! 4. Reinstallation of Eddie No Speed and connection problems after login with Eddie. Hope this is helpful. BR

For the Arch users among us, I wrote a simple PKGBUILD to allow quick install, future upgrading and removal. Nothing serious, but you may use it. Simple means, it's not on AUR or something; let's wait for the release before uploading it there. PKGBUILD-RC1.tar $ tar -x PKGBUILD.tar $ makepkg $ sudo pacman -U *.tar.zst .

@arteryshelby We do not log and/or inspect our customers' traffic. Since 2010 you can't produce any single case, and not even the slightest clue, in which the identity of an AirVPN customer has been disclosed through traffic log and/or inspection and/or any other invasive method. It means a lot, given that various younger VPN services have been caught lying (ascertained court cases) and that AirVPN is now the oldest still active VPN service, with the exception of a minor service which anyway changed ownership twice in the last 12 years. By the way we have never asked our customers to blindly believe in our words. We do not block Tor and we even integrate its usage in our software, so you can be even safer if you can't afford to trust us OR some datacenter. For example you can use Tor over OpenVPN, to hide Tor usage to your country and ISP, and at the same time hide your traffic real origin, destination, protocol etc. to us and the datacenter the server is connected into. Last but not least, we invest a lo of money in Tor infrastructure and in 2017, 2018 and 2019 more than 2.5% of global world Tor network traffic transited on Tor exit-nodes paid by AirVPN. It is an important achievement we're proud of, and it hints to good faith. Kind regards

https://restoreprivacy.com/wireguard/ AirVPN has also chimed in over WireGuard’s implications for anonymity, as explained in their forum: Wireguard, in its current state, not only is dangerous because it lacks basic features and is an experimental software, but it also weakens dangerously the anonymity layer. Our service aims to provide some anonymity layer, therefore we can’t take into consideration something that weakens it so deeply. We will gladly take Wireguard into consideration when it reaches a stable release AND offers at least the most basic options which OpenVPN has been able to offer since 15 years ago. The infrastructure can be adapted, our mission can’t. In their forums, AirVPN further explained why WireGuard simply does not meet their requirements: Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server. The impact on the anonymity layer is catastrophic; Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high; TCP support is missing (third party or anyway additional code is required to use TCP as the tunneling protocol, as you suggest, and that’s a horrible regression when compared to OpenVPN); there is no support to connect Wireguard to a VPN server over some proxy with a variety of authentication methods. Despite these concerns, many VPN services are already rolling out full WireGuard support. Other VPNs are watching the project and are interested in implementing WireGuard after it has been thoroughly audited and improved. In the meantime, however, as AirVPN stated in their forum: “We will not use our customers as testers.”

Hello! The connection mode with the highest success rate (virtually 100%) according to our reports from China is toward port 443 (destination port not blocked by ISPs in China) of entry-IP address 3 (to have tsl-crypt and therefore full encryption of the Control Channel) in TCP (to bypass UDP blocks). DNS leaks are of course not a problem at all with our software. Kind regards

Last update: 16 May 2018 - Related to version: Eddie 2.14.4 Any Linux distribution has at least:a different graphics server (X11, Wayland)a different desktop environment (GNOME, KDE, LXTE etc.)a package manager with a specific format (deb, rpm, tar.xf etc.)a different packaging signature for trust and securitya different method to obtain administrative privileges, required by advanced features of Eddie (also because OpenVPN requires them)a different set of packages used by our client, that sometimes have different names (for example 'stunnel4' under Debian, 'stunnel' for Fedora)maybe a different DNS management.We are working at our best to support every kind of configuration managed by our source code directly, when possible. Tested without known issuesDebian (tested 7/8/9)Ubuntu (18.04 GNOME tested)Ubuntu Mate (18.04 tested)Devuan (tested Ascii)MintArch (XFCE tested)Fedora (28 tested) With minimal issuesopenSUSE (Tumbleweed KDE tested) openSUSE (Tumbleweed GNOME tested) Works, with no tray icon.Elementary Works, but tray icon, web and folder links don't work. Fatal issues None known. Tech notesSometimes Tray icon works, but it is not shown because the desktop environment hides it. For example, latest GNOME may require a separate shell extension (generally TopIcons).Currently Eddie 2.x under Linux requires root privileges (like GParted or Synaptic Manager). Elevation is generally obtained with a polkit policy file (pkexec) if installed, otherwise fallback methods are used when available (gksu, kdesu, beesu etc.). When the UI runs as root, there are four -optional- actions that are performed as normal user: tray icon, notifications, open web links and open file folders. If it is not possible to act as a normal user, such actions are not performed at all. A totally separated UI (as a normal user) vs. root-actions (as root user, service or separate process) is currently under development. Needed improvementsMinimal lintian warnings on .deb editionGeneral info details on .deb edition (for example, reporting Proprietary as License, not true.)General info details on .rpm edition (for example, reporting Proprietary as License, not true.)Create official package for AUR and other distributions.Create packages also for CLI-only edition.Create packages based on direct source compilation.Procedures to include Eddie in official/standard repository