Staff

Hello! For your Kali and Debian distributions we offer two software: the AirVPN Suite and Eddie. If you have picked the Suite, its user's manual is available here: https://airvpn.org/suite/readme/ It will guide you step by step from the basic installation to the advanced usage. For any issue please do not hesitate to open a ticket and include log. If you picked Eddie, see below. @yaiyaiyai7 Please post an Eddie's system report, or the log of the software you run (for example WireGuard and OpenVPN) to connect. Also feel free to open a ticket. How to generate and send a report via Eddie: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ @CriticalRabbit Assuming that you could not manage to install Eddie in Debian (if you did, please see above to send us a system report), please follow these steps: Download the deb package If you work in a Desktop Environment, right-click the icon of the downloaded deb package and select "Open with" > "Package installer" You will find Eddie in the "Internet" section of your app launcher If you don't run a DE or anyway you prefer to install via terminal, you can install the deb package via gdebi. Open a terminal and enter the commands: sudo apt install gdebi sudo gdebi "path and name of the deb package you downloaded" You will find Eddie in the "Internet" section of your app launcher. Also feel free to open a ticket. Kind regards

@Jommes Hello! In most cases you can ignore those warnings, caused by years and years old unresolved bugs in OpenVPN 2.4 and 2.5 https://forums.openvpn.net/viewtopic.php?t=29557#p89192 According to our tests, these bugs are fixed both in OpenVPN3-AirVPN and in OpenVPN 2.6, but not in any OpenVPN 2.5.x version. If the warnings are not caused by the old bugs, then you should see failures in connection or no throughput at all. Since you say that everything works great, most probably you can safely ignore the warnings. Kind regards

Hello! Please contact the AirVPN management directly at info@airvpn.org at your convenience, or select "Support" > "Contact us" and drop a message, thank you! Kind regards

Hello! To select a specific connection mode in Eddie's "Preferences" > "Protocols" window please uncheck "Automatic", select (left click) the line describing the desired connection mode (the selection is confirmed if the whole line gets highlighted, you can't miss it) and click "Save". Start a new connection to apply the change. Kind regards

Hello! What is your nominal available bandwidth? Please measure the throughput you get when: the router is connected to a small variety of VPN servers a computer is directly connected to the same servers above, while OpenVPN on the router is stopped A comparison will tell whether OpenVPN on the router is the bottleneck or not. Kind regards

@frpergflf Hello! Unexplainable... the only thing that comes to mind is that you had some character in the goldcrest.rc configuration file password directive which was not displayed by your text editor. When you finally edited it, you unknowingly removed that character. Would it be a plausible explanation? Kind regards

@tranquivox69 Hello! Linux kernel includes since decades a module for a tun virtual network interface which guarantees performances higher than the bandwidth you can get from your line. No need for additional, external drivers. On equal grounds, the throughput in modern Linux systems should be better than the throughput on modern Windows machines, but the difference can be usually noted only above sustained 600-700 Mbit/, which is anyway a limit on most machines and our servers nowadays (700 Mbit/s client side = 1400 Mbit/s server side). On Raspberry Pi machines you may test WireGuard, which might beat OpenVPN performance. Bluetit and Goldcrest do not support WireGuard currently (they use OpenVPN3-AirVPN library), so you might prefer Eddie, which fully supports WireGuard. Next Suite release will support WireGuard too. In any case always test both WireGuard and OpenVPN, because in some networks (for example those which enforce traffic shaping against UDP), OpenVPN in TCP mode can be faster than WireGuard, which works only in UDP. Traffic splitting only for one or a specific set of applications is not supported by Eddie and the Suite (next Suite version for Linux will support it, but we need still some weeks to release the first alpha version). Currently, if you need a simple solution, you may consider to install a VM, or a docker, and connect it to the VPN. Then, you run in the VM only the program (or the few programs) whose traffic must be tunneled. Free and open source software such as VirtualBox allows you to setup a fully working Linux guest in a Linux host in a matter of minutes literally. Kind regards

@frpergflf Hello! The Suite "legacy" version is linked against libssl1.1 so you can keep using it in systems offering OpenSSL 1.1.1. The username is correct, so the login failure might be caused by a wrong password. What happens if your remove this password from goldcrest.rc file and you enter the password manually in the terminal, when Goldcrest asks for it? Kind regards

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