Staff

Hello! Thank you for reporting this and sharing the workaround. The distinction you found between working IP connectivity and failing hostname resolution is useful. The explanation is consistent with a DNS configuration problem inside the namespace. 127.0.0.53 is systemd-resolved’s local DNS stub address. Since a network namespace has its own loopback interface, that address inside aircuckoo does not reach the resolver running in the main namespace. Unless a resolver is also listening inside aircuckoo, DNS requests sent there cannot succeed. See the systemd-resolved documentation. https://www.man7.org/linux/man-pages/man8/systemd-resolved.service.8.html Providing reachable DNS servers through /etc/netns/aircuckoo/resolv.conf is therefore a reasonable workaround for the reported symptoms. The namespace-specific configuration mechanism is documented in ip-netns https://www.man7.org/linux/man-pages/man8/ip-netns.8.html, and Cuckoo also applies the namespace’s configuration files when launching an application. Two clarifications: This does not establish that Network Lock caused the problem. Disabling networklockpersist would not make the main namespace’s loopback resolver accessible inside aircuckoo. There is no need to disable that protection to address this DNS issue. Also, the Suite 2.1.0 manual documents networklockpersist as off by default. Please do not assume the manual DNS override will survive namespace recreation. Bluetit manages this directory and can remove and regenerate its contents during the traffic-splitting lifecycle. Cuckoo intentionally runs applications outside the VPN. DNS requests made to Cloudflare or Google through this configuration also follow the non-VPN path; choosing those resolvers changes who receives the queries. To investigate why the stub address was selected, please share your distribution and Suite version, relevant traffic-splitting and Network Lock settings, and: readlink -f /etc/resolv.conf cat /etc/resolv.conf cat /etc/netns/aircuckoo/resolv.conf resolvectl status The Bluetit startup log, particularly the “Found system … DNS” entries, would also help. Please remove credentials and other sensitive information before posting. There is no need to undo the working workaround. Next Bluetit and Cuckoo versions will feature respectively a dedicated directive and option to set the DNS for the namespace. Kind regards

Hello! Any problem related to IPv4 seems resolved. IPv6 related problems persist. The warning on packet loss you can see on the servers monitor is caused by IPv6 related problems: intermittent but very frequent packet loss. These problems do not affect Athebyne, Dorado and Toliman. We are in touch with the dc engineers while investigating this problem. Kind regards

@19990909jp @alrosm@sbcglobal.net Hello! If you prefer to keep Windows 7 for now, you can still connect to AirVPN using OpenVPN 2.4.12 for Windows 7, independently of Eddie. The installer is available from the official OpenVPN archive: https://build.openvpn.net/downloads/releases/openvpn-install-2.4.12-I601-Win7.exe. Generate your configuration files using the AirVPN Configuration Generator, selecting compatibility with OpenVPN 2.4, then import the downloaded .ovpn files into OpenVPN GUI: https://airvpn.org/generator/. Please consider this a temporary workaround. OpenVPN 2.4.12 itself is no longer supported, as indicated here: https://community.openvpn.net/Pages/Supported versions. A long-term solution requires moving to a more modern, actively supported operating system, whether a supported Windows version, FreeBSD or a Linux distribution compatible with your hardware. Microsoft ended Windows 7 support in January 2020, and its Extended Security Updates programme ended in January 2023. Continuing to use Windows 7, especially for Internet access, exposes you to vulnerabilities that no longer receive fixes from Microsoft: https://learn.microsoft.com/en-us/lifecycle/products/windows-7 A VPN protects traffic through the VPN tunnel, but it cannot fix operating system vulnerabilities or protect your data from malware already running on your computer. Restoring the VPN connection does not eliminate these risks. Kind regards

@Fragmented Sentinel Hello! Thank you for publishing your investigation and explaining the limits of what client-side testing can establish. We agree with the distinction between observing traffic on the client and verifying what happens to data on a provider's servers. Having reviewed version 1.0, we would like to suggest a few clarifications to help readers understand exactly what was tested and what the results establish. 1. Identify the firewall that failed The setup uses wg-quick with a separate persistent nftables ruleset. The reported boot failure concerns that local ruleset; the experiment does not demonstrate a failure of Eddie or Network Lock. Section 10 makes this distinction, but it would help to state it in the abstract and Section 3 as well. For example: "The test VM's custom persistent nftables firewall failed to load at boot." If the origin of those rules is known, please identify it. The comparison with RTINGS should specify the client version, operating system and startup conditions involved. A result from this custom Linux configuration can't confirm or refute the behavior of a different client setup. 2. Separate IPv6 connectivity from IPv6 firewall enforcement The successful IPv6 request through the tunnel demonstrates IPv6 connectivity through AirVPN in the tested configuration. However, "Network unreachable" on the direct-interface test could also mean that the VM had no usable non-VPN IPv6 route. Without a baseline demonstrating a working alternative IPv6 path, the supported conclusion is that no IPv6 escape was observed in this environment. Establishing that the firewall blocked an otherwise viable connection requires that additional control. The VMware NAT configuration is relevant here and should be documented. 3. Distinguish reboot persistence from protection throughout startup Finding the expected rules and service state after reboot supports persistence. It does not, by itself, establish that no traffic escaped during shutdown or startup. The systemd directives also need to be considered together with the complete unit dependencies. network-pre.target is passive and must be pulled into the transaction; the network-management service must participate in the ordering. Ordering alone does not make successful firewall loading a prerequisite for networking. https://systemd.io/NETWORK_ONLINE/ A capture from outside the rebooting VM, covering the whole transition, would provide stronger evidence. This is a limitation of the published evidence, not a finding that the repaired configuration leaks. 4. Identify how DNS settings were applied WireGuard itself does not negotiate or push DNS settings. In a wg-quick setup, those settings are applied locally through the profile and through supporting tools or hooks. Please specify the mechanism that configured systemd-resolved, including the ~. routing domain. https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8 The ~. domain is also not an unconditional guarantee of exclusive DNS routing through one link: the complete resolver configuration matters. This does not invalidate the capture results for the queries you tested. Ordinary DNS carried inside the encrypted tunnel is not, merely because it is ordinary DNS, a DNS leak. 5. Make the experiment reproducible The reviewed deposit provides the paper and representative commands, but not the underlying artifacts. Sanitized original and repaired firewall rules, the WireGuard profile, software versions, routing and resolver state, service dependencies, and capture records would make independent checking much easier. Capture duration and dropped-packet statistics are useful too. For the infrastructure identification, please include the relevant public-address lookup records. Address registration, BGP origin and a DNS identity string are different kinds of evidence; none alone establishes physical placement. 6. Keep the no-logging conclusion within its evidential scope We agree that these tests cannot establish server-side non-retention, and that the absence of a published audit does not demonstrate logging. Provider statements, published source code, historical reports and operational audits should be assessed separately. Source availability does not prove what is deployed. Historical claims need supporting records. An audit has a defined scope and period rather than establishing a permanent guarantee. The central observation remains useful: after the local firewall was repaired, the reported tests found that the examined configuration carried the tested traffic through the VPN. These clarifications would make the attribution more precise and help others reproduce and extend your work. Kind regards

Hello! Yes, totally expected, and not an Eddie's fault as explained earlier. It is intentional that when Eddie is shut down gracefully it releases Network Lock (i.e. it restores previous system firewall rules). It remains anyway to be seen how the pm and systemd act on a case by case basis on each distribution: Network Lock should not be relied on to remain active during an Eddie upgrade that stops its privileged service. Your approach of downloading first and installing offline avoids Internet traffic during installation. Please also take care when reconnecting: download the package and any required dependencies beforehand, disconnect the network, and install the update. Then start Eddie and activate Network Lock before restoring network connectivity. Resume sensitive activity only once the VPN connection is established. Kind regards

@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