Staff

Hello! You'll be able to avoid any problem by fixing your unit files according to our previous directions. An updated recap after extensive tests and gdb debugging which shows no problems and no crashes (again, provided that the modifications have been implemented). 1. Change permissions of /etc/airvpn.org into 755 (default is 660) to avoid systemd errors (you must have already done this, or you have used proper directives in the unit file, otherwise Bluetit wouldn't start at all but we repeat it for reader's comfort) chmod 755 /etc/airvpn 2. Add the following directives in Bluetit unit file: KillSignal=SIGTERM SendSIGKILL=no to prevent systemd from sending an expected SIGKILL to Bluetit 3. Consider to define the dependency and sequence criteria (systemd correctly warns you that you have not defined them, so it does not know when to start the unit). Example (taken from the default Bluetit unit file): After=network-online.target firewalld.service ufw.service dbus-daemon.service dbus.socket Wants=network-online.target firewalld.service ufw.service dbus-daemon.service dbus.socket 4. Just in case you will decide to use WireGuard and/or Network Lock, you must allow Bluetit to load kernel modules (WireGuard, iptables, nft, xtables...), so this directive: ProtectKernelModules=true must be deleted or set to false to prevent a critical error. 5. Just in case you will decide to use per app traffic splitting, the following directive must be deleted or set to false RestrictNamespaces=true because per app traffic splitting is based on namespace construction. Kind regards

Hello! Thank you, most probably you are right but please do not cut the log anyway, we want to see it integrally. Kind regards

Hello! No, by design: it is intentional. If you need a permanent (surviving reboots) set of rules blocking all traffic (so that by running Eddie and enabling Network Lock you can unblock traffic to the AirVPN servers only) then you must enter the rules yourself, according to the firewall you run on your machine. Kind regards

Hello! Can you also send us the complete Bluetit log from the journal? Kind regards

Hello! We're sorry to inform you that due to sloppy support by the datacenter provider (Racklot) we have decommissioned the server Metallah. Metallah went down on June the 18th, 2025, because IP addresses were null-routed. After more than a month, in spite of various contacts and solicitations, Racklot still fails to restore the routing. Our patience is over and we're acting accordingly. This was the last server still not supporting IPv6 (again for the laziness and the sloppy behavior of Racklot), so we finally have IPv6 support on every and each server. Kind regards

Hello! You have two 10 Gbit/s servers in San Jose (3 Gbit/s full duplex each guaranteed) which usually do not exceed 2+2 Gbit/s on peak times, so according to our stats there's still plenty of bandwidth available there. We will check manually anyway. Kind regards

Hello! Does it happen in the same environment described here? https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/?do=findComment&comment=251565 Kind regards

Good to know, but it's outside our scope to force users to be rigorous. We offer the option and the proper tools to act rigorously and we try to educate through articles. We can't do much more. That was a very good suggestion but it still remains in a limbo, we will prioritize it when possible. Kind regards

It's implemented since 2012 and currently defeats any AI or not AI attempt to disclose users' identity via traffic analysis. Only the global adversary is potentially able to do it, if it exists, but by definition the global adversary can not be defeated in any case, you can only make to it the content of your communications inaccessible, not your real origin and destinations of communications. Difficult to take offense by one who does not even know (or pretends he/she doesn't know) features implemented 13 years ago. Now locking the thread for a few days to avoid trolling anyway. Kind regards

@Donwo1995 Hello! There are a couple of wrong assumptions in your scenario: We do not log origin IP addresses according to the ToS and the current legal framework, therefore we can not provide information we do not have. Not really, as ports can be deleted/changed for account inactivity, pool shifts and other actions not involving the user. This problem can be resolved with specific payment methods without intermediaries. On a different, higher priority layer we must make clear that you can't come here, declare publicly an intent of illegal usage of the service by writing from an account that does not even have a valid subscription and then expect that AirVPN aids and abets this illegal usage through additional ad hoc options. If one really claims a criminal intent and comes here to declare it publicly, he/she should not expect help from AirVPN, in fact quite the contrary. Kind regards

Hello! Yes, thanks a lot! It will be fixed very soon. Kind regards

Hello! We're very glad to inform you that Hummingbird 2.0.0 Release Candidate 3 is now available for macOS, both for Intel and M1/M2/M3/M4 based systems. The links to the latest RC 3 and the main changes have been updated in the first message of this thread. This new version is linked against the latest OpenVPN3-AirVPN library version and improves gateway detection when used in WireGuard mode. Kind regards

Hello! We're very glad to inform you that AirVPN Suite 2.0.0 Release Candidate 3 for Linux is now available. The original post is updated to show the new download URLs. The important improvements over RC 2 are: bug fixes Blutetit: added run control directive networkcheck (please see the included user's manual readme.md) Bluetit: removed run control directive airvpnconnectivitycheck (superseded by networkcheck directive) gateway is set in case it was not provided at construction time Special note for firewalld users Please read here, it's very important: https://airvpn.org/forums/topic/70164-linux-network-lock-and-firewalld/ Please note that compatibility with Debian 10 and its derivatives, that reached end of long term support and end of life on June 2024, is lost even for the legacy version, mainly because the Suite is now C++20 compliant. The legacy version remains suitable for Debian 11 and its derivatives. Kind regards

Hello! We're very glad to inform you that two new 10 Gbit/s full duplex servers located in Frankfurt, Germany, are available: Adhil and Fuyue. They will replace 1 Gbit/s servers Intercrus, Serpens, Tucana and Veritate, which will be decommissioned on 2025-07-31 as they run on hardware and lines that show first signs of inadequacy after a year of extraordinary userbase growth. The AirVPN client will show automatically the new servers; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. They support 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. You can check the status as usual in our real time servers monitor : https://airvpn.org/servers/Adhil https://airvpn.org/servers/Fuyue Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! Please note that if Eddie crashes no leak occurs because Network Lock is a set of firewall rules. Kind regards

Hello! This is by design to avoid permanent lock out on remotely accessed machines while allowing non-VPN traffic when wished. Please also note that the article is wrong in telling that there's a leak during a system reboot even when network lock is enabled: the leak may occur only if the Network Lock has not been engaged, for example if you have not started the AirVPN software. On Linux systems you also have the option of setting a persistent network lock with Bluetit daemon, a component of the AirVPN Suite. As soon as the daemon starts it enforces the network lock, no matter whether a connection is started or not. If you have a systemd based Linux distribution, please note that the asinine systemd init startup is not deterministic and this is of course not our responsibility. Therefore you can't be sure when Bluetit will be started, regardless of the priority you wish. If you need permanent blocking firewall rules surviving reboots even when the VPN software is not running the solution is straightforward: set permanent firewall rules as explained in various articles (a recent one is here https://airvpn.org/forums/topic/69097-permanent-kill-switch-for-eddie-client) or follow the suggestion included in the very same article you linked. Be aware that this setup is problematic on remotely accessed machines. Kind regards

Hello! Thank you very much for your tests! Confirmed, the new OpenVPN3-AirVPN library crashes at disconnection as we incautiously dragged in a dirty modification from the main branch. Problem identified and addressed. Kind regards

Hello! No, we do not work with them, luckily! We have different providers in Germany and new servers will be added soon with new address ranges. Probably the block is aimed at various datacenters to prevent not only usage of publicly known VPN for consumers, but also home made VPN or simply SSH access to proxy to the Internet. Kind regards

Hello! The ZeroTier network interface could be the cause of the problem. Please try to disable the interface and make sure that no ZeroTier VPN etc. related software is running, then try again and check whether the problem gets resolved or not. Kind regards

@Pwbkkee Hello! After extensive debugging we noticed that Bluetit does not crash, but WireGuard does. Please note that in your setup the following option on the bluetit.service file you created: ProtectKernelModules=true prevents Bluetit from loading firewall and WireGuard kernel modules, which are needed respectively for Network Lock and WireGuard proper functioning. The following one: RestrictNamespaces=true prevents traffic splitting. The absence of ConfigurationDirectoryMode= with ConfigurationDirectory=airvpn implies a change of permission in /etc/airvpn (by default 660) with subsequent security problems that must be seriously considered, otherwise the unit can not work in general. Running Goldcrest as a service must also be carefully considered and whenever possible Goldcrest should work as it was designed for, i.e. as a client, with the asynchronous mode in your case. Goldcrest keeps all the standard streams (stdin, stdout and stderr, including TTY access) open, whereas Bluetit does not, as it is a real daemon, not a systemd service, which is only a pale daemon surrogate if you want to be kind, or a fake if you want to call a spade a spade. Therefore running Goldcrest with root privileges by systemd is another security flaw that must be pondered. Other directives could introduce additional problems, but we haven't investigated deeply all of them, we just want to point you toward the main problems and explain the issue you experience. The whole setup introduces instability, causes WireGuard and OpenVPN3-AirVPN library to crash, lowers security and prevents important Bluetit features including Network Lock, so proceed only if you know exactly what you're doing and always consider the instability that you cause especially on WireGuard and OpenVPN library. Kind regards

Hello! After the hardware replacement the server is apparently working very well. Should you find any anomaly do not hesitate to warn us and/or update this thread. Kind regards

@name8828 Hello! Please read here: https://airvpn.org/faq/port_forwarding We kindly invite you and everyone to read manuals and FAQ answers before posting. Kind regards

Hello! The problem has been finally isolated. From the provider customer service, just a few hours ago: "We have located the issue with the cabling, and have asked to [...] swap cables and ports around. This will correct the issue. [...] We expect this work to be completed within 24hrs". Kind regards

Hello! Sulafat is now up. The problem was that some of its IP addresses remained null-routed after a flood attack. Kind regards

Thank you, under investigation. screen or any other multiplexer is unnecessary thanks to the async mode (option --async). We will keep you posted. Kind regards