Staff

@Erquint Hello! Thank you for your tests! Beta 2 has multiple problems and it turned out to be too unstable on various Android versions. Please hold on, beta 3 is addressing the problems you experienced and coming out soon. Kind regards

Hello! Holy moly... If you have disabled IPv6 on your system but you kept IPv6 layer on Eddie then the IPv6 DNS and route check correctly fail. Kind regards

Hello! On the contrary. This means that Eddie could not resolve names on the specific DNS set on the system after the connection was established. If the handshake failed there was no communication between your system WireGuard and the VPN server. If the DNS check is disabled and the connection works, then the handshake is successful and the previous DNS check failure was a false positive. On your Arch Linux machine: the handshake is successful. DNS check fails on IPv6 while it is successful over IPv4. However, on Alphecca IPv6 and DNS6 work fine (just tested). Alkaid was decommissioned in 2019, so it must not appear on Eddie and you should discard Alkaid-specific profiles. Maybe you meant a different server? Try to disable Eddie's DNS check just in case it's a false positive or it is related to IPv6 problems in your machine. On your macOS machine: the handshake fails, so DNS is not (and can not) be checked. WireGuard does not communicate with the servers at all. Any anti-malware tool that might block communications? Kind regards

Hello! That's a totally separate issue which involved authoritative nameservers of airvpn.org more than two days ago and was completely resolved in a very short time, as the users writing in that thread correctly reported. Moreover it did not have any impact on VPN infrastructure. We can't reproduce this issue and by examining tickets on the last 24 hours there's not even one complaint about it. Can you list the specific servers you experience this problem on? Please note that DNS is set locally by WireGuard related script according to the DNS address(es) included in the profile (wg-quick on Linux tries to call resolvconf). DNS is not pushed by the VPN server, because WireGuard does not have any DHCP function. However, WireGuard handshake is not related to DNS, keep in mind. Kind regards

Hello! OK, if you see Eddie simpler then go for it, we're glad to know that it meets your needs. In the way you're running Eddie, it will already select the server with the best rating. The round trip time with your node among the ones it considers has a significant weight to pick the server. If you want to narrow down Eddie measurements to make the choice more appropriate for your needs you can consider to define a white list of your favorite servers or pick a specific country to connect to. In that case, Eddie will pick the best scoring server included in the white list, or the best scoring server in the specific country. If you want to determine unconditionally the server with the lowest round trip time, you can use specific tools and then tell Eddie to connect to the specific server you find with the best round trip time. Consider these sh commands by @OinkOink: https://airvpn.org/forums/topic/47335-solved-find-the-best-server-lowest-ping/?do=findComment&comment=259294 Kind regards

Hello! If you are OK with a CLI please consider the AirVPN Suite for Linux. It is very light and you can get rid of Mono. The Suite can be fully controlled via a command line interface and offers a thorough user's manual that documents every feature and will guide you through every step. https://airvpn.org/forums/topic/79336-airvpn-suite-resources/ Kind regards

Thank you. We're still struggling to reproduce the problem. The problem with cuckoo is caused by the fact that Bluetit can not create a namespace because no suitable IP address can be found: Feb 26 19:15:52 <redacted> bluetit[207809]: ERROR: Cannot find a free IPv4 in 's network. Please specify a valid IPv4 address in file /etc/airvpn/bluetit.rc by using 'trafficsplitipv4' directive. Traffic splitting is disabled. Mentioning the user's manual: However, given that your system is behind a NAT (your gateway address is 192.168.1.1, can you confirm?), we might be experiencing a failure of Bluetit's method to determine a free IP address for the namespace. If so, can you please force manually (according to the above instructions) an address for your namespace? Please make sure it is an address inside your subnet and not used by any other machine in your local network. Then, (re)start Bluetit and check whether the namespace is created properly. Can you also send us the output of the following commands please? ip addr show ip -6 r Kind regards

The AirVPN Suite for Linux is a software suite composed of the following components: Bluetit: lightweight D-Bus controlled system daemon providing full connectivity to AirVPN servers and generic OpenVPN and WireGuard servers with the ability to connect the system to AirVPN during the bootstrap. Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN and WireGuard servers Hummingbird: lightweight and standalone client for generic OpenVPN and WireGuard connection. Cuckoo: traffic split manager, granting full access and functionality to AirVPN's traffic split infrastructure Airsu: a "run and forget" tool to automatically set and enable the user environment for the X.Org or Wayland based ecosystem without any user input At the moment, Hummingbird is the only component available for macOS too. Resources Suite download page: https://airvpn.org/linux/suite/ Hummingbird macOS edition download page: https://airvpn.org/macos/hummingbird/ Suite User's Manual: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/README.md Hummingbird User's Manual: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/README-hummingbird.md Bluetit Developer's Reference Manual: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/docs/Bluetit-Developers-Reference-Manual.pdf Source code repository: https://gitlab.com/AirVPN/AirVPN-Suite/ Dedicated AirVPN community forum: https://airvpn.org/forums/forum/47-airvpn-suite Requirements Linux systems based either on SysV-Style init (chckconfig support implemented as well) or systemd Linux kernel 5.10 or higher version on x86-64, armv7l and aarch64 architectures GNU C library 2.38 or higher version D-Bus 1.12.20 or higher version Hummingbird for macOS: macOS 10.14 Mojave or higher version

@Posh1698 Hello and thank you for your report! The function you mention loops through all routing messages requested from the kernel, until NLMSG_DONE is returned. It does not store anything in arrays or fixed memory. The error message you see is thrown only if the kernel returns an empty message or NLMSG_ERROR. Can you please tell us whether by running dockerd alone, with only one or no virtual interfaces, the problem persists? The problem will be investigated soon in order to reproduce and address it for the next Suite release, thank you again! Kind regards

@Pi77Bull Hello! Thanks for all the logs. They will help us address the waiting for network loop problem which is under investigation. The traffic splitting configuration is "dirty" for unknown reasons. You might resolve this specific problem by deleting the /etc/netns/aircuckoo directory content while Bluetit is not running. Please let us know whether this operation solves the problem or not. Kind regards

Hello! The problem seems resolved now. Apparently it was caused by the authoritative nameservers of airvpn.org, the only ones that we do not operate directly. It looks like it was limited in time as we did not detect a significant loss in the flow so when we analyzed the situation to send out announcements the problem was already resolved almost everywhere. In such cases, you can rely on airvpn.info (a totally separated mirror: different machines, different nameservers) to get informed or access the services, as well as on AirVPN Twitter account. There was no impact on VPN services and DDNS as the nameservers for other services are different. We are monitoring the situation. Kind regards

@Pi77Bull Hello! 1. This is a bug experienced on different distributions by a few users but not reproducible on our systems at the moment. A comprehensive inquiry to understand and fix the issue is slated for the near future. In the meantime, can you please also test this: networkcheck airvpn and verify what happens? Remember to re-start Bluetit each time you edit its configuration file, of course. Can you also tell us whether the Docker daemon dockerd is running in your system? According to another report, when this daemon runs (even if no containers are created) the problem you experience appears, and when the daemon is stopped networkcheck works fine but only in airvpn mode and not in gateway mode. 2. This is unexpected. Can you please send us a complete Bluetit log taken after the problem has occurred? sudo journalctl | grep bluetit > bluetit.log 3. This is expected as the reconnect option is intended solely for the re-establishment of an extant session. A more contextually apposite, tailored to your specific circumstance, error message will be duly considered. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.25 beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OS Click the button Switch to EXPERIMENTAL Download and install This is a new version of Eddie Desktop (Windows / Linux / MacOS). The primary purpose of this release is to address several specific issues, including a significant CVE affecting macOS only. We expect it to be promoted to STABLE shortly. We are currently working on a substantial codebase refactoring aimed at evolving Eddie Desktop into a more modern client. Main changelog: [change] [all] Encrypted profiles: save with PBKDF2-SHA256; backward-compatible decrypt of SHA-1 profiles [bugfix] [linux] Fix for distro without systemd [change] [all] Fine-tuning of "netlock.allow_ping" option [new] [all] "netlock.allow_ndp", default true [change] [all] OpenVPN 2.6.17 [bugfix] [macOS] CVE-2025-14979: fix (shortcut-cli removed) [change] [windows] hardened SSH key file permissions to reliably remove orphaned ACL entries and prevent "bad permissions" errors [change] [windows] Updated projects and scripts to Visual Studio 2026 Kind regards & datalove AirVPN Staff

Hello! The servers are almost ready and will be available not later than 2026-02-25 (UTC). Because of the unforeseen delay, we are considering to extend the current 1 Gbit/s UK servers operations up to the end of March 2026. Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you that six new 10 Gbit/s full duplex servers located in Manchester and London (UK) are available: Amansinaya, Arber, Baiduri (London), Bubup, Cebo, Caophraya (Manchester). The first three mentioned servers are located in London, the other ones in Manchester. This addition replaces any previous UK 1 Gbit/s server in order to upgrade the whole UK infrastructure to 10 Gbit/s only servers, with per server 10 Gbit/s dedicated lines and ports, and modern hardware as announced here: https://airvpn.org/forums/topic/79154-uk-infrastructure-upgrade-to-10-gbits-full-duplex/ 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 . Click a server name to display specific server stats. Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff