Staff

@Coffeebean Hello! Please upgrade Eddie to the latest release available for your operating system: https://airvpn.org/download After installing it, check the version shown in Eddie to ensure that you are launching the updated application, especially if you also have an older portable copy. The symptoms you describe are consistent with an outdated client or VPN backend (and we see you're running Eddie 2.21.8, which is obsolete). Eddie filters out servers for which it cannot find a compatible connection mode. Following the deployment of OpenVPN Data Channel Offload (DCO) across our infrastructure, support for OpenVPN 2.3 and earlier versions has been discontinued. An old setup can therefore show progressively fewer servers, even though those servers remain available to compatible clients. Restarting the same outdated application would not resolve this compatibility issue. We discussed this in the following thread: https://airvpn.org/forums/topic/81119-limited-server-access/ For you and anyone else experiencing the same symptoms, please check the following: Eddie version and operating system. Install the appropriate package for your OS version and processor architecture. If the current release cannot run on your system, please tell us the exact OS version so that we can assess the available alternatives. The VPN backend Eddie actually uses. If you configured Eddie to use a custom OpenVPN executable, updating Eddie alone may leave that old executable in use. Check the OpenVPN version and executable path in the logs. OpenVPN 2.4 is the minimum compatibility threshold discussed above, but we recommend a current, maintained release. Server and country selections. Check for active search filters, allowlists or blocklists that could restrict the displayed or eligible servers. Server-list retrieval. If the list remains incomplete after updating, check Eddie’s logs for errors retrieving provider information, including DNS, TLS or connection errors. These would require a different diagnosis. For readers using older operating systems: WireGuard is not mandatory; a compatible OpenVPN client can still connect. However, Eddie, OpenVPN and WireGuard have their own OS requirements. In particular, the WireGuard version bundled with Eddie was documented as requiring macOS 12 Monterey or later; on an older compatible macOS installation, selecting OpenVPN may be necessary. See this explanation: https://airvpn.org/forums/topic/81119-limited-server-access/?do=findComment&comment=264323 Updating the VPN application also does not replace security updates for the operating system itself. If updating does not resolve the problem, please provide your exact Eddie version, operating system/version and a system report generated while the issue is present. In Eddie Desktop, open the Logs tab and use the lifebelt icon. You can send the report through a private support ticket if you prefer. Please let us know whether the full server list returns after the upgrade. Kind regards

Hello! The sustained change you describe deserves investigation, especially since the same setup previously reached 180–200 Mbps. The plateau alone does not establish an imposed bandwidth cap, and we cannot yet link it to a particular server-side change around September 2. Since you have already tried different servers, Gluetun versions and MTUs, we suggest two controlled comparisons before changing more settings: On the NAS, run the direct and VPN tests one after the other, using the same Speedtest application/version and a manually selected Speedtest server ID. Pause other downloads/uploads and record both download and upload speeds. Please confirm whether your two trackers already use the same test server, and verify that the VPN test shows an AirVPN exit IP. If another computer is available, preferably connected by Ethernet to the same router, test AirVPN with a native WireGuard client outside Docker. Use the same AirVPN server, endpoint port and Speedtest destination as the NAS test. Stop the Gluetun tunnel for this comparison, or use a separate AirVPN device key so the two clients do not share a key while connected. If the second computer reaches approximately 200 Mbps while the NAS remains near 100, that would narrow the investigation toward the NAS/container path. If both show the reduction, we should investigate the shared network path and VPN endpoint further. During the NAS test, please also check CPU usage per core and any CPU limit configured for the container. An overall reading of 60% does not rule out one core reaching its limit, although it does not by itself explain why performance changed. Please share the exact AirVPN server names and endpoint ports tested, the Speedtest server ID, download/upload results, and test times with your time zone. Those details will let us correlate your measurements with the relevant servers. Take care not to post your WireGuard private key or full configuration file. Kind regards

@matmat Hello! The problem should be resolved: can you please report back at your convenience? Kind regards

@airvpn17 Hello! We could not reproduce. Does the problem persist? Can you please re-test? Kind regards

Hello! We inform you that all of our VPN servers in Uppsala, Sweden, will cease operations during the night between 30 September and 1 October 2026. This withdrawal is part of our ongoing hardware renewal and connectivity improvement programme. These servers have already been partially replaced by brand-new servers in Northern Europe featuring more powerful hardware and 10 Gbit/s connectivity. Further deployments will complete their replacement. If you currently connect to our Uppsala servers, please select alternative servers before the withdrawal. If you use OpenVPN or WireGuard configuration files pointing specifically to these servers, please generate replacement configurations through our Config Generator in the Client Area. Do not hesitate to contact us for any information or assistance. Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Stockholm, Sweden, is available: Formosa. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Formosa supports 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 , by clicking the server name. Direct link: https://airvpn.org/servers/Formosa Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! Thank you for reporting this. Updating Eddie through APT could explain what you observed. During an upgrade, the package installation scripts can stop Eddie’s privileged service before replacing it. This normally sends a graceful termination signal to the helper, which restores the previous firewall configuration and consequently deactivates Network Lock. Losing communication with the helper can also cause Eddie’s interface to close, making the sequence look like an application crash. Please bear in mind that APT runs with root privileges, so it and the package installation scripts have the permissions needed to terminate applications and stop services. This differs from an unexpected UI crash, where Network Lock’s firewall rules remain in place. To check whether this explains your case, could you please tell us: Your Linux distribution name and version. The Eddie versions you upgraded from and to. Whether you confirmed exposure by seeing your ISP’s public IP address after Eddie closed, or whether Internet connectivity simply continued. Pending clarification, please pause any sensitive network activity before upgrading Eddie and resume it only after restarting Eddie, activating Network Lock and reconnecting to the VPN. Kind regards

Hello! Please give us more details and info to let us understand what problems you experience. Kind regards

Hello @d3adf1sh, thank you for the detailed report, and no need to apologise of course. Quite the contrary, as bug / glitch / problem reporting is appreciated and valuable. We recommend trying Eddie 2.27.2 beta first. It includes Windows adapter-management fixes, including a correction to OpenVPN driver selection on Windows 10. These changes may be relevant, but we cannot yet confirm that they address your standby issue or the blue screen. Please download it from https://airvpn.org/windows/ by selecting “Switch to EXPERIMENTAL”. Disconnect and close Eddie completely before installing the update. The beta thread is here: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Please also open a support ticket and send us an Eddie system report, specifying whether you use OpenVPN or WireGuard. If the problem occurs again and Eddie still responds, generate the report while it is stuck, before restarting it. Instructions: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do For the blue screen, please include the Windows stop code and any driver filename shown, if available. The new adapter number and the packet-loss warning alone do not identify the cause or establish a server problem. In the meantime, disconnect the VPN and wait for disconnection to finish before putting the computer into standby, then reconnect after waking it. Keep Network Lock enabled. Kind regards

Hello! Can you please test again now? If problems persist, please feel free to elaborate. Please give us as many information and details as possible to let us understand what problems you experience. Kind regards

@thirdeye868 Hello! Thanks. Getting past the username and password fields means the router accepts those entries; it does not confirm successful authentication with AirVPN. Please open the Hybrid VPN page, attempt a connection, and copy the VPN log shown on that page immediately after it fails. The general system log you posted earlier does not contain the OpenVPN error we need to identify the cause. If the VPN log is empty or you cannot find it, please send a screenshot of the Hybrid VPN page showing the connection status and any error message. Hide any passwords, configuration contents, certificates and keys. Kind regards

Hello! This issue is still under investigation by our support team and the AirVPN Suite developers. Several findings have emerged from the logs and configuration review, and further analysis is needed to establish the cause. We will post the outcome of the investigation in this thread once it is available. Kind regards

Hello! Thank you. Your screenshot shows DumaOS version 4.0.1510. The text you posted is the router’s general system log. It does not show an OpenVPN connection attempt or the error preventing the VPN from connecting. The entries mentioning “vpn proto=openvpn” belong to the router’s traffic classification system. The log also contains “time went backwards!” warnings and an earlier “time disparity of 22122 minutes detected” message. An incorrect router clock can cause TLS certificate validation to fail, so this could have prevented earlier connection attempts if the clock was incorrect at the time. However, the supplied log does not confirm a TLS failure. Please check that the router’s date and time are correct and that automatic time synchronization is working. Then try connecting once more from the Hybrid VPN page, copy the VPN log from that page immediately after the attempt and post it here, with personal information redacted. Please also tell us the connection status displayed there. Please do not post the configuration contents or screenshots showing certificates or keys. If the VPN log remains empty, please let us know whether you can save the configuration with 1 in both the Username and Password fields, and what happens when you enable the VPN. This will help us determine whether the problem occurs while saving the settings or when starting the connection. Kind regards

@thirdeye868 Hello! AirVPN servers authenticate OpenVPN connections using client certificates and keys, not a username and password. These are included in the configuration file generated for your account, so there are no separate OpenVPN login credentials to retrieve. Please try the following: 1. Log in to the AirVPN website and download an OpenVPN configuration from our Configuration Generator. Open the downloaded .ovpn file with a text editor and paste its entire contents into the router’s “VPN Config File” field, including all certificates and keys. 2. Leave Username and Password empty if the router allows it. If it requires both fields before you can save, try entering 1 as the username and 1 as the password. These are simply placeholders to satisfy the router’s interface; authentication to AirVPN will still use the certificate and key in your configuration. You do not need to enter your AirVPN account password there. Save the settings and enable the VPN. Once connected, make sure you select the devices you want to route through it in Hybrid VPN. If you still cannot save the settings or establish a connection, please tell us your R3 firmware version and provide the Hybrid VPN connection log, with personal information redacted. Do not post the full configuration file, as it contains your private key. Kind regards

@klimpix Hello! Thank you for testing 2.27.2 after upgrading and rebooting. The updated reports confirm that the issue persists on your system. The new AVC events directly document SELinux denying nft, running in the iptables_t domain, access to /var/lib/eddie-vpn/state/netlock_nftables_backup.nft. Their timestamps match the backup-file errors in Eddie’s log, during both startup recovery and subsequent Network Lock activation attempts. The helper also encounters separate denials involving DNS restoration and cleanup. This gives us clearer evidence of the SELinux access restrictions affecting the persistent-helper configuration. The exact correction still requires investigation into the helper’s execution context and the state files’ SELinux labels and permissions. We will pass these updated reports to the developers for investigation. For now, please continue using password-based elevation, which you reported works with Network Lock, while keeping SELinux enforcing and firewalld enabled. Thank you also for confirming that the tray issue persists with 2.27.2 on Plasma 6.7.5 under Wayland. We will include that information as a separate issue. Kind regards

Hello! Please test at your convenience Eddie 2.27 beta version and report back on this thread: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Kind regards

@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