Staff

Hello, You are not missing a step. "Don't ask elevation every run" makes Eddie install a systemd unit, eddie-elevated.service. When that unit cannot be created, the option switches itself off again, which is what you see. The AUR eddie-ui package is currently Eddie 2.26.2, the latest stable release. In that version the elevated helper creates the unit only when systemd-resolved is active. Otherwise it logs "Can't create service in this OS", even on a regular systemd system. Arch does not enable systemd-resolved by default, so this check fails there. Running Eddie with sudo makes no difference. Please check that this is your case: pacman -Q eddie-ui systemctl is-active systemd-resolved If the first shows 2.26.2 and the second says "inactive", that is the cause. This is fixed in Eddie 2.27.x, currently 2.27.2 (experimental). It is available on AUR as eddie-ui-git, which replaces eddie-ui. To use it: 1. Install eddie-ui-git with your AUR helper, accepting the removal of eddie-ui. 2. Start Eddie as your normal user, not with sudo. Eddie elevates only its helper and asks for your password through polkit. 3. Enable "Don't ask elevation every run" in Preferences and authenticate once. 4. Check that the service is active: systemctl status eddie-elevated If you prefer to stay on the stable 2.26.2 release, Eddie works normally, but it will ask for elevation at each start. If your output is different, or the option still does not persist on 2.27.2, please post both command outputs and a system report, following the instructions here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

Hello, "Failed - Network error" is the message Chrome, Edge and other Chromium browsers show when a download is interrupted before it completes, so we need a few details to understand where it breaks: 1. What are you trying to download? Eddie (which version and operating system), another file from our website, or any file while you are connected to AirVPN? 2. Does the same download work when you are NOT connected to the VPN? And when connected, does it fail on every server or only on some? 3. If you are connected through AirVPN when it fails: which client (Eddie, WireGuard, OpenVPN), which protocol and which server? In the meantime, please try: another browser (for example Firefox), or a private window with extensions disabled; temporarily disabling the download/web scanning of your antivirus, which often interrupts downloads with exactly this error; if you are on the VPN, another server, or switching between WireGuard and OpenVPN. Kind regards

@Nitrox Hello! Thank you for the report, it shows the cause. Your system has two Eddie tunnel adapters, "Eddie" and "Eddie 1". "Eddie 1" was left behind by an earlier session that did not close properly (the log starts with "Recovery. Unexpected crash?"): even after Eddie has disconnected, it is still up with a VPN address and it still holds the VPN routes 0.0.0.0/1 and 128.0.0.0/1. When Eddie connects, the new tunnel itself works (the WireGuard handshake succeeds), but Windows answers that the VPN routes "already exist", so your traffic goes to the stale adapter instead of the new tunnel. The route check then times out, Eddie disconnects and tries the next server, which is the loop you see. After Eddie gives up, those leftover routes still capture all your traffic, which is why the internet stays blocked until you restart: the restart removes the stale adapter. To fix it: 1. Close Eddie completely. 2. Restart Windows using Start > Power > Restart, not Shut down followed by powering on. With Windows Fast Startup enabled (the default), a shutdown does not fully reset the system, while Restart always does. 3. If the problem comes back, close Eddie, open Device Manager, select View > Show hidden devices, expand "Network adapters" and uninstall every "Eddie Tunnel" entry (for example "Eddie Tunnel" and "Eddie Tunnel #2"). Then restart Windows (Restart, as above) and start Eddie, which will create a new adapter when it connects. If the problem persists after these steps, please attach a new system report generated right after a failed connection attempt, before closing Eddie or restarting Windows. Kind regards

Hello! Please ignore our previous message in this thread: it was meant for another topic. Deleted. This error is caused by a bug of Eddie 2.26.2 (and earlier) on macOS. To check the application's integrity, Eddie stores a small file in the system folder /Library/PrivilegedHelperTools. On Macs where that folder does not exist yet, because no other application has created it, the file cannot be saved and Eddie refuses to start with exactly this message. The bug is fixed in Eddie 2.27.2 beta. Please download it from here: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Select the right package for your Mac (Apple Silicon or Intel), quit Eddie, copy the new Eddie into your Applications folder replacing the old one, then open it from Applications. Your settings are kept. If the error still appears with 2.27.2, please post the complete message: this version also prints the reason of the failure in parentheses, which tells us what is going wrong. Kind regards

@dmandingo Hello! The cause is the very old Eddie version. After our recent server upgrades, Eddie 2.16.3 no longer recognizes the connection modes offered by our servers as compatible, so it has no server it can connect to, even though nothing changed on your computer. This is why the "Connect to a recommended server" button is grayed out and why the protocol choice cannot be saved. Your account is not the problem. Windows 7 is no longer supported: current Eddie releases (2.26 and later) do not run on it, and no fixes are planned for it. Two options remain, both without guarantee: 1. Eddie 2.24.6, the last version that runs on Windows 7: https://airvpn.org/windows/ > "Other versions" > 2.24.6 > "Windows 8 / 7". It needs Microsoft .NET Framework 4.8, and on some Windows 7 computers it cannot install its network drivers. OR 2. The official WireGuard client 0.5.3, the last release for Windows 7, with a configuration file from our Config Generator (https://airvpn.org/generator/). Support team sent you the detailed step-by-step instructions for both options in reply to your support ticket. The reliable long-term solution is a computer with a supported operating system (Windows 10 or 11, Linux or macOS) and the current Eddie, which works with the same account. Kind regards

Hello! Assuming that you run Eddie Android edition, please check (tick) "Do not show anymore" at the bottom of the image, then select "Ok". Kind regards

Problem solved. Kind regards

@after_lunch Hello! Thank you for the complete report, it shows what is happening. Your Wi-Fi adapter gets its DNS servers from your router: 194.168.4.100 and 194.168.8.100, which are your ISP's resolvers. Eddie 2.26.2 sets the AirVPN DNS (10.128.0.1) only on its own adapter, and in some circumstances its DNS leak protection fails to block queries sent to the resolvers of the other adapters. This is a known bug of 2.26.2, and your report matches it: Network Lock is active and the log says "DNS leak protection with packet filtering enabled", yet Windows still reaches your ISP's resolvers. You can solve it in one of two ways: 1. Stay on 2.26.2 and apply a workaround: open Eddie's Preferences > DNS, enable "Force all network interfaces for DNS", save, then disconnect and reconnect. OR 2. Upgrade to Eddie 2.27.2 beta, which contains the fix: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Then repeat the test on ipleak.net while connected: only AirVPN DNS servers should be listed. If your ISP's resolvers still appear after the workaround, please switch to 2.27.2, and if they persist there too, post a new system report. About hiding long text: the forum does not convert spoiler tags typed by hand. Use the Spoiler button in the editor toolbar and paste the text inside the box that appears, or simply attach the report as a .txt file. Kind regards

@zlump Hello! Thank you for the update, and sorry to hear about the restore. Not seeing any WireGuard adapter in Device Manager is expected at this point: both Eddie and the WireGuard application create that adapter only while a WireGuard connection is active, and remove it when the connection ends. There is nothing left to uninstall. About the TechRadar article: that bug affects "Always On VPN", a feature of the VPN client built into Windows (SSTP and IKEv2 connections). Eddie and the WireGuard application do not use it, so it does not explain the "cyclic redundancy check" error. Please continue like this: Let sfc, DISM and chkdsk finish, then tell us whether any of them reported errors it could not fix. If chkdsk finds disk errors, back up your files before anything else. A system restore can roll back or remove programs installed or updated after the restore point, so Eddie may be in an inconsistent state now. Exit Eddie, reinstall it from https://airvpn.org/windows/, restart Windows and try to connect with WireGuard again. If you get the same error, switch Eddie to OpenVPN as described in our previous message (Preferences > Protocols, uncheck "Automatic", select UDP 443) and tell us whether that connects. If you test the WireGuard application again, exit Eddie first, so that the two programs do not interfere. If it still does not connect, open the "Log" tab of the WireGuard application, activate the tunnel and paste here the lines of that attempt. They show whether Windows cannot create the adapter, as in Eddie, or whether the adapter is created but the connection does not complete. If the problem persists, a system report generated by Eddie right after a failed attempt is the most useful thing you can send us: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

Hello! What you describe usually means that the Ethernet adapter has been left with the VPN DNS servers. When Eddie connects, it sets AirVPN's DNS on your network adapters, and it puts the previous settings back when it disconnects. If Eddie is closed abruptly (a crash or a forced shutdown, for example), that restore may not happen. The Ethernet adapter then keeps a DNS server that can be reached only through the VPN, so Windows reports "no internet" unless Eddie is connected. Wi-Fi is not affected because it keeps its own settings. You can check it in a few seconds. With Eddie disconnected, open Command Prompt and run: ping 1.1.1.1 ipconfig /all If the ping gets replies while websites do not open, and the Ethernet adapter section of ipconfig shows "DNS Servers" starting with 10., this is the cause. To fix it: 1. Exit Eddie. 2. Press Windows+R, type ncpa.cpl and press Enter. 3. Right-click your Ethernet adapter > Properties. 4. Select "Internet Protocol Version 4 (TCP/IPv4)" > Properties, choose "Obtain DNS server address automatically" and confirm with OK. 5. Do the same for "Internet Protocol Version 6 (TCP/IPv6)", then close the window. Alternatively, run these two commands in a Command Prompt opened as administrator, replacing Ethernet with the exact name of your adapter if it is different: netsh interface ipv4 set dnsservers name="Ethernet" source=dhcp netsh interface ipv6 set dnsservers name="Ethernet" source=dhcp If the problem persists, please post the output of ipconfig /all, or send us a system report generated by Eddie following these instructions: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

@zlump Hello! Thank you for the log. Eddie reaches the server every time, but Windows refuses to create Eddie's WireGuard network adapter, with the error "Data error (cyclic redundancy check)". Eddie creates that adapter when it connects and removes it when it disconnects, so it is normal that you no longer see it among your network connections. Since the adapter cannot be created, every attempt fails after a few seconds and Eddie tries again, which is the loop you see. "Cyclic redundancy check" is a Windows error for data that cannot be read correctly. It usually means that a file of the WireGuard driver is damaged, which can happen after an interrupted Windows update or because of a disk problem. Please try these steps in order: 1. To get connected right away, open Eddie's Preferences > Protocols, uncheck "Automatic", select an OpenVPN protocol (for example UDP 443), save and connect. OpenVPN does not use the WireGuard driver. 2. To repair WireGuard, exit Eddie completely. Open Device Manager, choose View > Show hidden devices and expand "Network adapters". Uninstall every "WireGuard Tunnel" adapter you find, including greyed out ones, and if Windows offers to delete the driver, select that option. Restart Windows, reinstall Eddie from https://airvpn.org/windows/ and try WireGuard again. 3. If the error persists, open Command Prompt as administrator and run these commands one at a time, then restart Windows: sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth chkdsk C: /scan If chkdsk reports errors, consider to back up your files, because the disk may be failing. If none of this helps, please send us a system report generated by Eddie right after a failed attempt, following these instructions: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards

Hello! Yes, the previous answer includes this option. Read it. Kind regards

Hello! We have tested Bubup: the server works correctly. The problem is on Windy's side: their service refuses one of Bubup's exit IP addresses (it answers with HTTP 403 "Forbidden"), and your connections through Bubup leave from that address. Bubup's other exit addresses and the other UK servers are not affected. The solution is simple: add Bubup to the blacklist in Eddie, and you will always be connected to the other five UK servers in London and Manchester, without any delay. If you use a WireGuard configuration file instead, generate it in the Configuration Generator for a specific UK server other than Bubup. Offering several servers in each country is meant exactly for situations like this one, when a third-party service blocks a single address. Kind regards

Update: restrictions lifted Hello! The PHP project released the fixed versions earlier than scheduled, and we have installed them on every system of our infrastructure. The temporary restrictions described above have now been removed: The forum is writable again: you can post new topics and replies, edit posts, upload attachments,date your profile. The support ticket area works normally: you can open new tickets and reply to existing ones from the website. Password recovery works again. The customer API (https://airvpn.org/api/) accepts multipart/form-data requests again. If you wrote to support@airvpn.org in the meantime, there is no need to open a ticket as well: we will answer you there. If any of the functions above still fails for you, please clear your browser cache and try again; if the problem persists, open a ticket or write to support@airvpn.org. VPN connections, Eddie and the AirVPN Suite were not affected at any time. Thank you for your patience and understanding. AirVPN Staff

Hello! Two critical vulnerabilities in PHP, the language that powers our website, forum and support system, became public before an official fix was available (CVE-2026-109618 and CVE-2026-109619). They affect every PHP version in existence and allow an attacker to run code on a web server by sending a specially crafted request. The PHP project has scheduled fixed versions for today, 21 October, at 14:00 UTC, and attacks exploiting the flaws have already been reported by several security firms. The flaws are triggered by a specific kind of web request, the one browsers use to submit forms with file uploads, and they act before any application code runs. Until the fix is installed, the only effective protection is to refuse that kind of request at the web server. EDIT: this sentence was not accurate. We have done so on all our systems. What this means for you, starting now and until further notice: The forum is read-only. You can read and search everything, but you cannot post new topics or replies, edit posts, upload attachments, send private messages or change your profile. The support ticket area is read-only as well. You can read your tickets and our replies, but you cannot open a new ticket or reply to an existing one from the website. We keep answering existing tickets, and you will keep receiving email notifications for our replies. The customer API (https://airvpn.org/api/) keeps working, but it rejects requests sent as multipart/form-data: if your script posts that way, send the parameters url-encoded or as JSON instead. Support remains available by email: write to support@airvpn.org and we will assist you as usual. Everything else works normally: VPN connections, Eddie and the AirVPN Suite, login, registration, purchases and the client area. These restrictions will be lifted as soon as the official patches are available and applied to every affected component of our infrastructure. We expect most of this to happen within hours of the release; if any component takes longer, we will update this announcement. We apologize for the inconvenience and thank you for your patience. AirVPN Staff

@gtrman Hello! Thank you, the backup file shows the remaining cause. The backup was saved before step 2, so it still shows the old ALL APPLICATION PACKAGES entry (AC) with FA; that is expected. The second entry that blocks Eddie is this one: (A;OICIIO;FA;;;CO) It is the CREATOR OWNER entry, which the normal icacls output shows as CREATOR OWNER:(OI)(CI)(IO)(F). On a default installation it is stored as (A;OICIIO;GA;;;CO). GA (generic all) and FA (explicit full access) grant the same permissions in practice, but Eddie's check reads the stored value as it is: it accepts GA and rejects FA. Because icacls displays both as (F), the difference was not visible in the first output. This entry does not give anyone access to System32 itself, only to files created there later, and only for their owner. Eddie's check does not make this distinction yet, and we will report it to the developers. Please open a Command Prompt as administrator again and run the following commands. 1. Save a backup of the current permissions: icacls "%SystemRoot%\System32" /save "%USERPROFILE%\system32-acl-backup2.txt" 2. Store the CREATOR OWNER entry in its default form: icacls "%SystemRoot%\System32" /grant:r "*S-1-3-0:(OI)(CI)(IO)(GA)" S-1-3-0 is the fixed identifier of CREATOR OWNER, so the command works with any Windows language. As before, it may take a minute; wait until it reports "Successfully processed 1 files". 3. Save the new permissions to a second file, to check them:Open icacls "%SystemRoot%\System32" /save "%USERPROFILE%\system32-acl-check.txt" system32-acl-check.txt with your favorite text editor. It should contain (A;OICIIO;GA;;;CO) and (A;OICI;0x1200a9;;;AC), and no entry ending with FA;;;CO or FA;;;AC. Then start Eddie. If it still shows the same error, please post the content of system32-acl-check.txt here. To undo only today's change, you can run: icacls "%SystemRoot%" /restore "%USERPROFILE%\system32-acl-backup2.txt" Kind regards

@gtrman Hello! Thank you, the output confirms the cause. This is the entry that blocks Eddie: APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(F) It gives Full control of System32 to every Store (UWP) app on the system. On a default installation this group can only read and execute files in System32. The other entries do not need to be changed for Eddie. Please open a Command Prompt as administrator (right-click Command Prompt, then "Run as administrator") and run the following commands. 1. Save a backup of the current permissions of the folder: icacls "%SystemRoot%\System32" /save "%USERPROFILE%\system32-acl-backup.txt" 2. Replace the Full control entry with the default read and execute permission: icacls "%SystemRoot%\System32" /grant:r "*S-1-15-2-1:(OI)(CI)(RX)" S-1-15-2-1 is the fixed identifier of ALL APPLICATION PACKAGES, so the command works with any Windows language. Please do not simply remove the entry: Store apps, including parts of the Start menu and Settings, need read access to System32. Windows also applies the change to the files and subfolders that inherit from System32, so the command may take a minute. Wait until it reports "Successfully processed 1 files". 3. Run icacls "%SystemRoot%\System32" again. The ALL APPLICATION PACKAGES line should now end with (OI)(CI)(RX). Then start Eddie. If Eddie still shows the same error, please open system32-acl-backup.txt in your user folder with Notepad and post its content here. It is a single line that shows the exact permission values, which the normal icacls output does not show. If you ever need to undo the change, this command restores the saved permissions: icacls "%SystemRoot%" /restore "%USERPROFILE%\system32-acl-backup.txt" Eddie does not check wuauclt.exe and wuaueng.dll, so the ownership change on those two files is not related to this error. And when you move to Linux, Eddie is available there as well. Kind regards

Hello! We're very glad to inform you that AirVPN Suite version 2.2.0 is now available for x86-64 and ARM based Linux systems. This is a maintenance and security hardening release focused on the traffic split infrastructure. The 2.2.0 Suite includes: Bluetit: lightweight, ultra-fast D-Bus controlled system daemon providing full connectivity and integration to AirVPN servers, or generic OpenVPN and WireGuard servers. Bluetit can also enforce Network Lock and/or connect the system to AirVPN during the system 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 binary for generic OpenVPN and WireGuard server connections 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 WHAT'S NEW NEW: Cuckoo security hardening: namespace directories are now opened with additional ownership and permission checks NEW: once root privileges have been dropped, Cuckoo can no longer regain them (no_new_privs is now set) NEW: traffic split namespace names are now validated by both Bluetit (trafficsplitnamespace run control directive) and Cuckoo, and are limited to 32 characters WireGuard and network namespace runtime directories now use /run/wireguard and /run/netns (legacy /var paths removed) improved POSIX compliance of the installation script Please note: if you have set a custom trafficsplitnamespace longer than 32 characters, you need to shorten it before upgrading. AirVPN Suite 2.2.0 is free and open source software released under GPLv3. Source code is available on GitLab: https://gitlab.com/AirVPN/AirVPN-Suite AirVPN Suite 2.2.0 is available for x86-64, AArch64 (ARM 64 bit) and armv7l (ARM 32 bit) architectures. Legacy versions are also available. https://airvpn.org/linux/suite/ AirVPN Suite resources, links and forum: https://airvpn.org/forums/topic/79336-airvpn-suite-resources/ Kind regards & datalove AirVPN Staff

Hello! The problem seems completely resolved. Kind regards

@gtrman Hello! Thank you for the detailed list of checks. The error comes from a security check in Eddie, not from netsh.exe itself. Eddie runs netsh.exe and other Windows tools with administrator privileges, so before running them it verifies that neither the executable nor its folder can be modified by an account other than SYSTEM, Administrators or TrustedInstaller. Otherwise a non-administrator could replace the tool and have it run with elevated privileges. The empty text after "not allowed:" in your screenshot indicates that netsh.exe itself passed the check, but its folder, C:\Windows\System32, did not: some other account is allowed to create files in it. This is not the default Windows configuration. It is usually left behind by a "take ownership" or "grant full access" tweak or tool applied to system folders in the past. This also explains why sfc, DISM and reinstalling Eddie, portable or installer, did not help: they do not reset the permissions of the System32 folder. To confirm, please open a Command Prompt and run the following command. It only displays the permissions and does not change anything: icacls "%SystemRoot%\System32" Then post the output here. If you prefer, you can replace your computer name and user name with placeholders, but please leave the rest unchanged. On a default installation only NT SERVICE\TrustedInstaller, NT AUTHORITY\SYSTEM and BUILTIN\Administrators can write to that folder. An additional entry with (F), (M), (W) or (WD) for your user account, Users, Authenticated Users or Everyone is the likely cause. Please do not take ownership of System32 or change its permissions recursively in the meantime. Once we see the output, we will tell you how to remove only the extra entry. Kind regards

@0range Hello! The option you used on LineageOS is a LineageOS addition, not a feature of stock Android. On stock Android, and on systems based on it such as HyperOS, a VPN app works through the Android VpnService API, which applies the VPN only to traffic generated by apps running on the phone itself. Traffic coming from tethered devices (Wi-Fi hotspot, USB or Bluetooth) is forwarded by the system directly to the mobile data connection and never enters the VPN interface. Changing that routing requires root, so no VPN app can do it on a non-rooted phone. We are not aware of an equivalent setting in HyperOS. Please note that this means that, while the VPN is connected on the phone, the devices connected to its hotspot are NOT protected: their traffic goes out with the IP address of your mobile operator. Possible solutions without root: 1. Run AirVPN on each device. Eddie is available for Windows, macOS, Linux and Android, and you can also use OpenVPN or WireGuard configuration files generated by our Config Generator. Connect the devices to the phone hotspot as usual, then connect each of them to AirVPN. Your account allows up to 5 simultaneous connections. This is the recommended solution, because every device gets full protection. 2. Use a travel router with a VPN client (for example an OpenWrt based router running WireGuard) connected to the phone through Wi-Fi or USB tethering, and connect your devices to the router. All the devices behind the router then share a single VPN connection. Kind regards

Hello! With Bluetit's network lock active, this cannot work, but there is a different approach that is well worth trying. Why the pods become unreachable: Bluetit's network lock is a kill switch for the whole host. It sets the default policy of the FORWARD chain to drop and only accepts forwarded traffic coming from the VPN tunnel. Pods that don't use hostNetwork are reached through forwarding (LAN or ingress, then NAT to the pod address on the cni0/flannel interfaces), so their traffic is dropped, while hostNetwork pods use the host's own input/output path and keep working. The "allow private network" exception only covers input and output on the host, not forwarding, and when the lock is applied Bluetit replaces the whole firewall ruleset, k3s rules included. There is no Bluetit option to exempt container interfaces or forwarded traffic. The better approach is to turn it around: leave the host and k3s outside the VPN, and put only Firefox and BiglyBT inside it, in a dedicated network namespace whose only way out is a WireGuard interface. If the tunnel goes down, the applications in the namespace simply have no network, so you get a kill switch by design without touching the host firewall, and k3s, the Cloudflare tunnel and your LAN are not affected at all. Please note that this is a suggestion we believe is worth a try, but we have not tested it on a setup like yours, so treat it as a starting point and let us know what happens. 1. Generate a WireGuard configuration file with our Configuration Generator (Client Area > Config Generator, Linux, WireGuard, one specific server) and save it, for example, as /etc/wireguard/airvpn.conf. Take note of the Address, DNS and MTU lines in its [Interface] section. Stop Bluetit or at least disable its network lock. 2. Create the namespace and the tunnel, as root and in bash (the wg setconf line uses a bash feature that plain sh does not support). The WireGuard interface is created and configured in the main namespace, so its encrypted UDP traffic leaves through your normal connection, and then it is moved into the namespace: ip netns add vpn ip -n vpn link set lo up ip link add wg0 type wireguard wg setconf wg0 <(wg-quick strip /etc/wireguard/airvpn.conf) ip link set wg0 netns vpn ip -n vpn addr add <IPv4 Address from the file> dev wg0 ip -n vpn addr add <IPv6 Address from the file> dev wg0 ip -n vpn link set wg0 mtu <MTU from the file> up ip -n vpn route add default dev wg0 ip -n vpn -6 route add default dev wg0 mkdir -p /etc/netns/vpn echo "nameserver 10.128.0.1" > /etc/netns/vpn/resolv.conf Use the Address and DNS values from your own file if they differ. "ip netns exec" mounts /etc/netns/vpn/resolv.conf in place of /etc/resolv.conf, so programs in the namespace use our DNS through the tunnel. Please also check that the "hosts:" line in /etc/nsswitch.conf does not contain "resolve": that module asks systemd-resolved on the host directly and would bypass the namespace resolver. 3. Check that it works: ip netns exec vpn wg show ip netns exec vpn curl https://ipleak.net/json/ wg show should report a recent handshake and curl should show the AirVPN exit address. 4. Start the applications inside the namespace, as your normal user: sudo ip netns exec vpn sudo -u $USER env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY WAYLAND_DISPLAY=$WAYLAND_DISPLAY XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR firefox --no-remote -P vpn --no-remote and a separate profile (create "vpn" once with firefox -P) are important: otherwise, if Firefox is already running outside the namespace, the command just opens a new window of the existing instance, outside the VPN. The snap version of Firefox shipped with Ubuntu may not like being started this way; if it fails, the Mozilla .deb or tarball build should behave better. BiglyBT can be started the same way. If you use port forwarding, set the forwarded port from your Client Area as BiglyBT's incoming port: it reaches the namespace through the tunnel. To remove everything: ip netns del vpn (wg0 is deleted with it). The commands in step 2 can later go into a small script or systemd unit to run at boot. As an alternative for BiglyBT only, since you already run k3s: you can run it as a pod together with a VPN sidecar container such as Gluetun configured for AirVPN WireGuard, so that the pod can only reach the Internet through the tunnel. Firefox would still need the namespace approach above. Please let us know how it goes, especially if something in the steps above needs adjusting on your system. Kind regards

@183aTr78f9o Hello! Thank you for the very detailed report, and sorry for the long wait. Your analysis was right: the problem is that Bluetit assumes a standard filesystem layout (FHS), which NixOS doesn't provide. We checked the Suite source code and there are two specific causes: 1. Bluetit does not use PATH to find external tools (systemctl, nft, iptables, ip...). It only looks in a fixed list of directories: /bin, /usr/bin, /sbin, /usr/sbin, /usr/local/bin and /usr/local/sbin. That's why Environment=PATH=... had no effect and why your symlinks in /bin worked. 2. Before loading the WireGuard module, Bluetit requires /lib/modules/$(uname -r)/modules.builtin to exist, and it fails if the file is missing, even when the module is already loaded. On NixOS the modules live in /run/booted-system/kernel-modules/lib/modules, so you get "system 'modules.builtin' does not exist" and "cannot load wireguard system module". Until these assumptions are relaxed upstream (but for point 1, probably they will not be implemented for security reasons), you can work around both of them declaratively, without manual symlinks in /bin. Below is a reworked version of your module (Suite 2.1.0, x86_64). Please note that this reworked version has been generated through an LLM, verified by human, but we have not been able to test it in depth on a NixOS machine, so please treat it as a starting point: { config, lib, pkgs, ... }: let version = "2.1.0"; suite = pkgs.stdenv.mkDerivation { pname = "airvpn-suite"; inherit version; src = pkgs.fetchurl { url = "https://eddie.website/repository/AirVPN-Suite/${version}/AirVPN-Suite-x86_64-${version}.tar.gz"; hash = lib.fakeHash; # replace with the hash reported by the first build }; nativeBuildInputs = [ pkgs.autoPatchelfHook ]; # no need for nix-ld buildInputs = with pkgs; [ dbus openssl stdenv.cc.cc.lib zlib xz zstd ]; installPhase = '' install -Dm0755 bin/bluetit $out/sbin/bluetit for f in goldcrest hummingbird airsu; do install -Dm0755 bin/$f $out/bin/$f; done install -Dm0644 -t $out/share/airvpn etc/airvpn/* install -Dm0644 -t $out/share/dbus-1/system.d etc/dbus-1/system.d/* install -Dm0644 -t $out/share/zsh/site-functions etc/site-functions/* ''; }; # tools Bluetit looks up in the fixed directories tools = [ "systemctl" "resolvectl" "ip" "nft" "iptables" "iptables-save" "iptables-restore" "ip6tables" "ip6tables-save" "ip6tables-restore" ]; in { environment.systemPackages = [ suite ] ++ (with pkgs; [ nftables iptables iproute2 ]); users.groups.airvpn = { }; services.dbus.packages = [ suite ]; # replaces your activation script boot.kernelModules = [ "wireguard" ]; systemd.tmpfiles.rules = [ "d /lib 0755 root root -" "d /usr/local/sbin 0755 root root -" "L+ /lib/modules - - - - /run/booted-system/kernel-modules/lib/modules" ] ++ map (b: "L+ /usr/local/sbin/${b} - - - - /run/current-system/sw/bin/${b}") tools; # Keep your environment.etc entries for /etc/airvpn, using # source = "${suite}/share/airvpn/<file>" and mode = "0600". # Keep your systemd.services definitions, but drop the Environment=PATH line. } A few notes: The symlinks go into /usr/local/sbin, which Bluetit searches and NixOS does not manage, and systemd-tmpfiles recreates them at every boot, always pointing to the current generation. Remove the manual ones you created in /bin. /lib/modules points to the booted system, so it always matches the running kernel (uname -r), including after a kernel update until you reboot. autoPatchelfHook links the binaries against Nix store libraries at build time, so nix-ld is no longer needed for the Suite. Please use nftables for the network lock (networklock nftables, or networklockpersist nftables in bluetit.rc). Your log shows that the nftables lock initialized correctly, while the iptables restore failed. If Bluetit still reports "Command not found" (your log showed two of them before the network filter step), add the missing tool names to the tools list above. Running "journalctl -u bluetit" should show which feature failed. Cuckoo is only needed for per-application traffic splitting, so we suggest leaving it out for now. It must run setuid root, which is not possible inside the Nix store: store paths are immutable, built by unprivileged users, and Nix strips setuid bits and ownership from every file it adds. That is why your chown and chmod u+s failed. The NixOS way is security.wrappers: at every activation, NixOS creates a small setuid wrapper in /run/wrappers/bin, outside the store, with the owner, group and permissions you choose, and the wrapper starts the real binary from the store with root privileges. This is the same mechanism NixOS uses for sudo and ping. The next Suite release changes Cuckoo's installation requirements (it will be executable only by members of the airvpn group), and we will try to post the matching security.wrappers configuration then. Please let us know how it goes. If it works for you, your module could become a useful reference for other NixOS users. Kind regards

Hello! We reluctantly have to announce gloomy news to you all: Spooky Halloween Deals are now available in AirVPN... Save up to 74% on AirVPN longer plans (*) (*) When compared to 1 month plan price Deal will expire on 2026-11-03 UTC Check all plans and discounts here: https://airvpn.org/plans If you're already our customer and you wish to jump aboard for a longer period with this un-boo-lievable deal, any additional plan will be added on top of already existing subscriptions and you will not lose any day. Every plan gives you all the features that made AirVPN a nightmare for snoopers and a scary service for competitors. Just check this frighteningly long list of terrific features if you dare: a clear mission without compromises https://airvpn.org/mission exclusive and comfortable remote inbound port forwarding system flexible, opt-in block lists against malware and other hostile entities. Pick predefined lists, add exceptions or additional blocks, define your own lists, or just use our totally neutral DNS by default improved API functions to let you control and configure VPN features and account settings WireGuard integration AmneziaWG support in Eddie Android edition, with traffic mimicry of real websites (QUIC) to defeat DPI-based VPN blocking. This year our traffic wears a costume too: with AmneziaWG on Eddie Android, your connection goes trick-or-treating dressed up as an ordinary website, and DPI won't recognise who's behind the mask. Security-hardened Eddie Desktop edition Strong infrastructure growth: about 25% more total capacity in one year. Our servers grew by a ghastly 25% this year: more bandwidth to haunt the Internet at full speed. IPv6 support, including IPv6 over IPv4 and IPv4 over IPv6 refined load balancing to squeeze every last bit per second from VPN servers free and open source software for Android, Linux, Mac and Windows offering advanced features easy "Configuration Generator" web interface for access through third party software guaranteed minimum bandwidth allocation GDPR compliance and very high privacy protection standards no log and/or inspection of clients' traffic effective traffic leaks prevention by AirVPN software Tor support via AirVPN software on Linux, Mac and Windows various cryptocurrencies accepted without any intermediary no obligation to use our free and open source software to enter AirVPN infrastructure. Interoperability is an AirVPN priority. perfectly clear and easy to read Privacy Notice and Terms https://airvpn.org/privacy No tricks, only treats! We witch you a spooktacular Halloween AirVPN Staff

Hello! A quick follow-up on the WireGuard session counter issue mentioned above. The cause has been identified and fixed, and the fix is currently being rolled out across our infrastructure. Servers that have already received the update are back to reporting accurate figures, and the remaining ones will follow shortly, so the connection counts shown in the server monitor and in the related statistics will match reality again in the very near future. As previously stated, actual connections and the service itself have never been affected, only the displayed counter was. Kind regards