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