Staff

@klimpix Hello! Thank you for providing the reports and the exact versions. Your system report confirms that Eddie 2.26.2 is using the persistent helper and that Network Lock fails when nft attempts to read /var/lib/eddie-vpn/state/netlock_nftables_backup.nft. Before investigating further on 2.26.2, please test Eddie 2.27.2, currently available through the Experimental option on the download page. The 2.27 series includes corrections to systemd service creation, elevation failures caused by overly restrictive IPC directory permissions, and Network Lock failures when the shared state directory has been removed. These changes are documented in the changelog, although they do not establish that your particular issue is fixed. You mentioned previously testing a 2.27 experimental build. Could you confirm its exact version? If it was already 2.27.2, please provide the report from that version; otherwise, please upgrade, reboot to ensure the persistent helper is restarted, and repeat the failing test with SELinux enforcing, firewalld enabled and Network Lock enabled. If it still fails, please attach a fresh system report and the corresponding AVC events, with the same privacy redactions. The AVC attachment contains two denials for raw socket creation by the helper in the init_t domain. These confirm an SELinux restriction, but do not by themselves explain the backup-file access failure. The absence of the earlier file-related denials in this capture also does not rule out SELinux involvement. In the meantime, you can continue using the password-based elevation method that you report works with Network Lock. Thank you also for confirming Plasma 6.7.5 under Wayland. Please let us know whether the tray issue persists on 2.27.2. If so, we will keep it separate from the privileged-helper issue. Kind regards

@klimpix Hello! Thank you for the report and clarification. This is the correct forum for such reports, of course. The comparison between password-based elevation and the persistent systemd helper is useful. The reported SELinux denial involving nft and the Network Lock backup file points to an access issue in that execution context. However, the excerpts alone do not identify the required correction or the initial error preceding the failed restoration. NftablesTableOwner=no addresses a separate issue, so there is no need to repeat that change. To investigate further, please provide: The exact Eddie version and package source. A complete Eddie system report generated after reproducing the failure once with the persistent helper enabled. The complete SELinux audit events from the same attempt, including timestamps and source/target contexts, particularly the backup-file and rename/unlink denials. Please keep SELinux and firewalld enabled. You may redact identifying information, but retain the relevant file paths, timestamps and SELinux contexts. In the meantime, you can continue using password-based elevation, which you report works correctly with Network Lock enabled. The KDE system tray issue should be considered separately. Please also specify your Plasma version. We can't confirm a correction or release timeframe at this stage but we will warn the developers expeditiously about this thread. Kind regards

Hello! The problem was addressed on 2.27 beta versions. The latest beta version is available here, please feel free to test it, as it seems very solid even according to community testers: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Kind regards

Hello! Because the GUI is based on Mono and Mono has not been (and we're afraid it will never be) ported onto ARM architecture on Apple systems. The backend is already optimized for ARM Mx processors and the GUI will not require Rosetta anymore in the next release that will be available in due time. Kind regards

Hello! Confirmed, the problem re-occurs periodically. We're investigating. Kind regards

Hello! If you run Eddie's uninstaller script for Windows, it does not remove the configuration file in the user's directory. It leaves both the directory and the configuration file inside it, including default.profile. This is intentional as uninstalling a software does not mean purging all the configuration files that can be preserved. No erratic behavior has been detected, it's just a script. This would be catastrophic in many cases. Firefox, Thunderbird, GitLab, Microsoft SQL SRS and probably hundreds of other programs do not support inverse migration (downgrade) in general, exactly for this problem. In case of a downgrade for which the configuration file becomes incompatible with the older version, deleting or overwriting the configuration files etc. will cause serious or, in case of absence of a recent backup, even dramatic inconvenience to the user. EDIT - NOTE BY THE DECREPIT FOUNDER In Eddie, profile preservation has an excellent side effect. The profile (encrypted or not) includes the client keys and server information, and Eddie reads them locally when it can't access the bootstrap servers. When you are in a restrictive network, or typically in specific countries (Iran, China, Russia...) the bootstrap servers or the protocol to reach them are not infrequently blocked. In such cases the user must first find another connection method, establish the connection and only then let Eddie contact the bootstrap servers to download the information that will be valuable for future connections. This is a once and for all operation that may be reproducible and performed in the face of potentially great adversity, so minimization of such a requirement is good. If we want to have a sad contest to see who’s the most decrepit, we have a good competitor. The founder of AirVPN built his first natural language parser in Assembly and BASIC in 1983 with a 1,500-word dictionary, pushing the limits of an 8-bit computer (a Commodore 64). Thirty-five years ago, he was already at CERN with Tim Berners-Lee who was creating HTML and testing and improving HTTP... But rest assured, he’s not the one working on Windows - it gives him an allergic reaction. 🤣 You can bet that he was behind the earlier caustic jokes about Windows. 🤔 Kind regards

Version 2.27.2 (Mon, 14 Sep 2026 08:16:32 +0000) [fix] [macos] Traffic speed and session stats stuck at zero with many network interfaces [change] [all] Updated OpenVPN to 2.7.7 [change] [windows] Updated ovpn-dco Win11 driver to 2.8.7 [fix] [macos] Elevation and service install failed when /Library/PrivilegedHelperTools does not exist [fix] [all] Connect ignored after a session ended by itself [fix] [windows] Use tap-windows6 on Windows 10, the bundled ovpn-dco driver is Win11 only [fix] [all] Enforce OpenVPN script-security in privileged helper [fix] [all] OpenVPN config check now parses directives like OpenVPN [change] [all] Block OpenVPN management interface and pkcs11/engine modules in the privileged process [change] [all] Drop refused OpenVPN directives at config build, with a log warning [fix] [linux/macos] Elevation failed: IPC dir permissions too strict [fix] [all] Network Lock failed when shared state dir was removed

Hello! The problem is different. You pretend a downward compatibility of a configuration file with a previous software version and this is not guaranteed in general. This is the problem. You can downgrade at will Eddie, but remember that you must purge the higher version of the configuration file because sometimes it may contain new supported options, directives, fields for new features and so on that can't be parsed by the older software. This is true for any software, not only for Eddie, and it is not at all ridiculous, it is correct and sometimes strictly necessary for a natural evolution of any software relying on a configuration file. According to nowadays conventions and Microsoft recommendations the configuration file is stored by default in the AppData directory of the user who installed Eddie. See also: https://eddie.website/support/data-path/ You think you have never met this case in 31 years of Windows usage exactly because you've been using Windows for 31 years. 😋 Forgive us, this was irresistible... Kind regards

Hello! Thank you for the report, it will be put under the devs' attention. Your settings look correct. The workaround suggested by @Tech Jedi Alex can't work, as it pertains to the virtual network interface to be used for the tunnel, while here the problem seems that Eddie picks the wrong interface for the connection even when you explicitly tell it to use another one (Ethernet). Kind regards

Hello! Can you please try again now? Kind regards

Hello! We're very glad to announce a special promotion on our long term Premium plans for the end of Summer or Winter, according to the hemisphere you live in. You can get prices as low as 2.06 €/month with a three years plan, which is a 70% discount when compared to monthly plan price of 7 €. If you're already our customer and you wish to stay aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. Please check plans special prices on https://airvpn.org and https://airvpn.org/buy Promotion expires on 2026-09-28 09:00 AM UTC. Kind regards & datalove AirVPN Staff

Hello! Thanks a lot. Everything was sent to devs for deeper evaluation. Kind regards

Hello! Valuable clue. Can you re-send now that everything works fine a system report? We would like to compare the amount of interfaces you have in the system now. Kind regards

@Hellegat Hello! Ok. On macOS, Eddie reads throughput from native system interface counters, no more from Mono’s NetworkInterface.GetIPv4Statistics(), because it was known that this API returns zero there (we tend to rule out a regression here). The native macOS library calls sysctl and the core RealtimeNetworkStats job samples this data every second, matches the current VPN interface ID, and computes: download speed = delta received bytes / elapsed seconds upload speed = delta sent bytes / elapsed seconds Those values are stored and then shown in the Eddie main window. Before anything else, please make sure that all the traffic really flows in the tunnel. Please browse ipleak.net and make sure that no leak is detected at all. Kind regards

@Hellegat Hello! You have an apparently active Tailscale interface. It should be one of the 12 utun interfaces you have, but from this report we can't say which one (we can only say that during the report WireGuard was using utun11). Tailscale and WireGuard try to route the whole system traffic causing conflicts. Tailscale may try to tunnel WireGuard traffic and WireGuard will try to tunnel Tailscale traffic. Please test with Tailscale completely disabled when you run AirVPN software and check whether the problem is resolved. If that's the case, then you can think about ways to have Tailscale and WireGuard co-exist, if possible. If Tailscale is already disabled, test again with the Tailscale interface also disabled. Kind regards

Hello! Please add a system report generated by Eddie while the problem is ongoing (do not disconnect to generate it). Instructions: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! Yes: because of the high amount of simultaneous connections globally, the counters are updated in an intentional "lazy" way, in order to avoid that the stats become potentially onerous in terms of CPU load etc. Kind regards

Hello! @nwlyoc A few suggestions to improve the software, can you please check them and verify whether the detected problems are real? 1. IMPORTANT. The sudo password is piped through xargs, which turns it into a command-line argument for printf. This can make the password temporarily visible through /proc/<pid>/cmdline or process-monitoring tools. xargs can be removed and the password passed directly to sudo -S via stdin. 2. The AirVPN API key is stored in plaintext inside vpncontrol.conf, while the installation procedure does not enforce restrictive permissions. On a multi-user system, the file could therefore remain readable by other local users. The configuration directory should be 0700 and the file containing the API key 0600. 3. IMPORTANT. The nftables ruleset adds ip saddr to the whitelist after an allowed DNS query and later accepts packets whose ip saddr matches that set. In the OUTPUT chain, ip saddr can be the host's own local address, so this can unintentionally allow subsequent outbound IPv4 traffic and defeat the Network Lock. The whitelist must operate on destination addresses ip daddr, not source addresses. Kind regards

A wrapper for AirVPN's Hummingbird client to use it more easily and extensively. Free and open source software. GPLv3 license. Disclaimer: this is an independent project with no affiliation to AirVPN development teams. It uses the public AirVPN API with your personal API key. Resources GitLab repository: https://gitlab.com/nwlyoc/vpncontrol License: https://gitlab.com/nwlyoc/vpncontrol/-/blob/master/COPYING Author: Nwl Yoc https://gitlab.com/nwlyoc AirVPN community forum: https://airvpn.org/forums/forum/50-vpncontrol/ Privacy policy: not available User's manual or readme file: https://gitlab.com/nwlyoc/vpncontrol/-/blob/master/README.md?ref_type=heads Author warns that: This project is not actively maintained, but I will update and improve it from time to time. Note that the wrapper is written in bash, so it can be run on both platforms where Hummingbird is available, i.e. Linux and macOS. Main features graphical interface in the command line to connect to AirVPN with Hummingbird (no Eddie involved) runs in background, the interface can be closed/opened anytime without affecting the running connection possibility to connect to any server with just one ovpn configuration file easily connect to a random server, to a recommended server, to the recommended server of a specific country or to a specific server sortable list of all servers including info like used bandwidth, load and number of users possibility to connect to other VPNs with openconnect lock down system by default (permanently if you want), so even without AirVPN/Hummingbird running there won't be any unwanted network traffic automatically establish connection at boot (which can later be controlled via the interface) logging of Hummingbird's output (number of days to keep logs for can be adjusted) system notifications to let you know what happens in the background Kind regards

Hello! Unable to resolve does not mean unable to send data, though. Also, if the apps can reach their intended destination(s) via IP address their traffic will flow. Even more importantly, those apps with internal DNS resolution (via DNS over HTTPS for example) will keep working fine. Yes, definitely. Kind regards

@Mikeyy Hello! Yes, and on any other Android TV 9 and higher version currently available. The previous limitations have been overcome with a few workarounds. All the other apps traffic and the system traffic go to the Internet via "regular" connection. Currently this is not possible with Eddie, we're sorry. You could consider some method based on built-in features, if the manufacturer did not remove them from your Android build. Please see here for details: https://www.airdroid.com/mdm/block-apps-from-internet (method 1). Kind regards

AirDash is a native iOS dashboard for AirVPN, built with SwiftUI and the iOS 26 Liquid Glass design. Free and open source software. MIT license. Disclaimer: this is an independent project with no affiliation to AirVPN development teams. It uses the public AirVPN API with your personal API key. Resources GitHub repository: https://github.com/zlimteck/AirDash License: https://github.com/zlimteck/AirDash?tab=MIT-1-ov-file Author: zlimteck https://github.com/zlimteck Landing page: https://airdash-landing-page.vercel.app/ AirVPN community forum: https://airvpn.org/forums/forum/48-airdash/ Privacy policy: https://github.com/zlimteck/AirDash/blob/main/PRIVACY.md User's manual or readme file: https://github.com/zlimteck/AirDash?tab=readme-ov-file Main features of the full version Network: full server list with load, users, health, ping latency, sort (load / name / ping), continent filter, search and favorites (scoped per account) Best Server: automatically picked from live ping and load, weighted so a congested server can't win purely on a low ping; instantly shows the previous session's result while the fresh ping sweep is running Server history & trends (opt-in, off by default): load and connected-users charts per server over 1h/24h/7d/30d, a reliability breakdown (healthy vs warning/error) also surfaced as a badge on favorite servers and in Trends, a peak-hours chart highlighting the quietest 3-hour window from 7 days of history, and a Trends screen ranking servers by average load over a rolling window; all powered by a companion history service, not the official AirVPN API. See the Privacy Policy for exactly what that service sees. Server comparison: long-press any server to add it to a comparison (up to 3); tap the toolbar button to view them side by side, including bandwidth and (if the history feature above is enabled) an overlaid load-history chart across the compared servers. Native VPN (WireGuard): connect and disconnect straight from the app via NetworkExtension, no external VPN app required; live tunnel status card on the Dashboard with swipe to disconnect, one profile saved and reused (regenerated only on explicit action). Only available in the full build; see Full vs Lite build below Dashboard: account info (current IP, VPN status, expiration, credits, sessions, member since); swipe left on a session to disconnect (also stops the native tunnel if it's this device's own session), tap a session to jump to its server detail Server detail: WireGuard or OpenVPN profile generation, direct import into the system VPN app, share and QR code (WireGuard) in a ··· menu; a direct Connect button for WireGuard (native build only), skipping the generate/share step; recent profiles per server with one-tap reimport, shown with the protocol's logo Recent profiles page: dedicated list of all generated profiles with search, sort, filter by protocol, quick import, QR code and delete; profile history is stored securely in the Keychain Spotlight search: favorite servers and recent profiles are indexed and searchable from the system search; tapping a result opens the app directly on the right screen and many more. Find the complete list of features on the manual / README.md.

Hello! Please upgrade to OpenVPN 2.4 or higher version, or switch to WireGuard alternatively. The OpenVPN version you're running doesn't support AES-GCM (or CHACHA20) on the Data Channel. Due to remarkable demand for DCO (Data Channel Offload kernel module to speed up OpenVPN throughput and make it more scalable through multiple threads) AirVPN servers, ever since migration to DCO was completed, do not support AES-CBC because its activation, even as a fallback cipher only, would cause global OpenVPN daemon Data Channel Offload de-activation. Kind regards

Hello! It is not necessary, with the option you mention Eddie will start during the system boot either on Windows or Linux based on systemd. Starting from 2.26.2 it will start on SysV init based Linux boxes too (this is new: if you find again malfunctions on SysV init based systems please warn the developers on the thread or via ticket). If the Connect at startup option is also active, then Eddie will start AND connect during the system bootstrap. Of course you are free to start Eddie automatically in different, canonical ways on each system. Kind regards

Hello! The FIREWALL_VPN_INPUT_PORTS environment variable is not set, unless you set it in your GlueTun invocation command, therefore the incoming (unsolicited) packets on the tunnel VPN interface are dropped. See also: https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/firewall.md Note that the other variables related to firewall and inbound ports that you set on the compose file do not affect the firewall rules for the VPN interface: FIREWALL_INPUT_PORTS pertains to the default interface. You might like to delete the related line as we bet you do not want your p2p software to reply to incoming packets from the Internet and disclose your real IP address VPN_PORT_FORWARDING_LISTENING_PORTS has a totally different purpose, it re-directs a port to a custom localhost port of your choosing and will break p2p software ability to receive incoming packets. Do not use this variable with torrent clients, or any other software that publicly announces its port, as that software would not be aware of the publicly visible port and would be announcing the private port instead. Delete that line and read the documentation here for more details: https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md As a side note for you and all the readers using GlueTun: read GlueTun's good documentation if you haven't already done so! Kind regards