Staff

@moejoe Hello! Configuring DNS blocks through the app is currently not possible, we're sorry, but you can have different profiles by using the option to link specific DNS block settings to each key ("device"). Then you can easily switch between devices to switch DNS blocks, although a re-connection is required for each switch. Kind regards

For now, we ask you to ignore that message. It is caused by the fact that the current macOS UI is written in Xamarin, which does not support arm64 compilation. One of our goals is to release a new modern UI, natively compiled for arm64, before this restriction becomes a problem.

Version 2.26.1 (Sat, 04 Jul 2026 17:30:39 +0000) [fix] [linux] Fix nftables netlock ipv4 mangle OUTPUT chain priority typo [change] [linux] Store network lock rule backups in root-only state directory [fix] [all] Fix TOCTOU race [fix] [linux] Sanitize VPN DNS addresses written to /etc/resolv.conf [change] [all] Misc fixes and general cleanup [fix] [linux] Fixed connection on Arch (no SysV service command) [change] [all] Improved security of how the VPN configuration is handled by the privileged helper [fix] [all] Block OpenVPN directives that write files as root

Hello! Let's investigate it on a new thread. Kind regards

@taikeru Hello! We're glad to know that terminal=true solves the problem. fuzzel and rofi honor the Terminal=true field in .desktop files but they manage it according to their own settings. Please check. For stdout - but a future version can be tty-aware, stay tuned. Kind regards

@taikeru Hello! Thank you for your great feedback about the Suite software, much appreciated by the development guys too. Provided that the desktop user is in the airvpn group, the usage you mention should be possible with some caveat, as cuckoo needs a tty. Can you please add the following line to the .desktop file: terminal=true and test again? Kind regards

Hello! We are glad to announce that Eddie 2.26.0 beta has been released and is now available for public testing. This release is mostly about maintenance, security fixes, and compatibility work. It includes several security hardening changes, updates to OpenVPN 2.7.3 and WireGuard for Windows 1.0, improved OpenVPN driver handling on Windows, and a general cleanup of old or unused code paths. To test it: Go to the download page for your operating system. Click “Switch to EXPERIMENTAL”. Download and install Eddie 2.26.0 beta. Eddie 2.26.0 beta is available for Windows, Linux, and macOS. We are also continuing the larger work of modernizing Eddie Desktop, also with a new modern UI. We know that many requested features are still waiting, including dark mode, split tunneling, Amnezia support, and more. They are not forgotten. For this release, the focus was on fixes and updates that needed to reach users first. We expect this beta to move to stable soon. Thank you for testing, and as always for your support. Main changelog: Version 2.26.0 (Mon, 29 Jun 2026 14:29:16 +0000) [change] [all] Updated the app to .NET 10 [change] [all] Updated the legacy interface to .NET Framework 4.8.1 [change] [windows] Removed Windows 7 support [fix] [all] Cleaned WireGuard configuration generation by removing unsupported entries [change] [windows] Improved OpenVPN driver setup and adapter management on Windows [change] [windows] Removed outdated Windows driver options [change] [windows] Removed the old Windows Firewall Network Lock mode and migrated existing profiles. [change] [linux/macos/bsd] Removed unused filesystem protection handling from the elevated helper. [change] [all] Restricted elevated helper tool discovery to trusted application folders. [change] [all] Added limits to elevated helper replies to protect client memory use. [change] [all] Removed the Tor control cookie path option [fix] [all] Various security hardening fixes [fix] [windows] Fixed Windows elevated launches with long command lines [change] [windows] Improved Windows elevated argument handling to prevent extra arguments from being injected into helper tools [fix] [windows] Fixed Windows OpenVPN routing with TAP adapters [change] [windows] Updated WireGuard for Windows to version 1.0 [change] [all] Updated OpenVPN to 2.7.3 [fix] [linux] Fixed Linux AppImage cleanup. Credits GitHub #147 and #152. Thanks to ThienBienBlue. [fix] [linux] Fixed Network Lock detection on clean systems where optional nftables or iptables tools are not installed. [change] [all] Removed custom OpenVPN and Hummingbird executable path options. [change] [linux] Removed the Linux dependency on the system ICU library [change] [all] Misc fixes and general cleanup Kind regards & datalove AirVPN Staff

@Kiki09 Hello! You need to set FIREWALL_VPN_INPUT_PORTS environment variable, otherwise container's firewall blocks all incoming packets on the virtual network interface. Please check the manual https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md VPN_PORT_FORWARDING_LISTENING_PORTS has a quite different purpose. It sets up a redirection of incoming traffic from the VPN opened port to a custom localhost port of your choosing. As the GlueTun manual clearly warns, do not use this with torrent clients, or any other software that publicly announces its port, as that software would not be aware of the publicly visible port and would be announcing the private port instead (you can see more details of this explanation on our FAQ answer about p2p). Furthermore, it does not even instruct the firewall to allow incoming packets on the virtual network interface. Kind regards

@theradgrad Hello! The fact that the host is sending a RST strongly suggests the packet is making it through PF and reaching the TCP stack, where no matching listening socket exists for that specific destination IP and port. The port tester does not test UDP, only TCP. Please ascertain whether the listening program is really listening to all interfaces with: netstat -an -f inet Look specifically for something like 0.0.0.0:YYYYY or VPN_IP:YYYYY If instead it shows 127.0.0.1:YYYYY or LAN_IP:YYYYY then the kernel will immediately send RSTs for packets addressed to the VPN IP. Also, please send the output of the following commands: sudo sockstat -4 -l sudo netstat -rn Finally, a simultaneous packet capture while reproducing the issue: sudo tcpdump -ni tun0 tcp port YYYYY Kind regards

@theradgrad Hello! In reality your current error message is connection refused (111). It means in general that the packets were forwarded and reached the destination (your node), but it actively reset the connection via TCP RST. We have also checked in real time on the server you mention and packets are properly forwarded from the correct ports to your VPN IP address:port. Please make sure that tun0 is the correct interface name. If it is, the fact that the packets reach the OpenBSD host and it actively replies with a TCP RST suggests the kernel accepted the packet but decided there was no valid listening socket or the packet didn't belong to an existing connection. Please follow this checklist: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards

@0bacon Hello! Did the problem get resolved after hardware was repaired and you upgraded to AirVPN Suite 2.1.0? Kind regards

Hello! Thank you for your patience to reply to the numerous questions by the support team on your ticket. We re-publish the outcome here for Kubernetes users' and readers' comfort, and for future reference. Bluetit relies on filesystem-level operation to create the resolv.conf backup. In your setup, /etc/airvpn and /etc/resolv.conf are in different file systems. Therefore Linux kernel will return EXDEV ("cross-device link") error when Bluetit tries to move, via stdlib rename() method, /etc/resolv.conf into /etc/airvpn/ Possible work-around: Have /etc/airvpn and /etc/resolv.conf into the same file system, OR don't allow Bluetit to manage DNS by setting, inside bluetit.rc run control file, this directive: ignorednspush on and let the pod manage the DNS. You will not use anymore VPN DNS, but DNS queries will be tunneled anyway. You can still set your favorite DNS (even VPN DNS, if needed), but you have to set it manually. In a future Bluetit version we'll see how to improve Suite compatibility with Kubernetes (and possibly other environments). Kind regards

Hello! Since OpenVPN and WireGuard fail too, this is not an Eddie-specific problem. However, an Eddie system report could help us understand what goes wrong. Please see here to send a system report generated by Eddie: Kind regards

Hello! Of course. Eddie offers a GUI with a one-click connection button, but the case of firewalld is so special to be a very rare exception requiring manual intervention by the system administrator. We can't allow Eddie to manipulate your system in such a profound way. Note that Eddie will work anyway, but you can't use Network Lock to prevent leaks, because firewalld takes exclusive ownership of the firewall rules (Network Lock is based on firewall rules). And after all, do not underestimate yourself. The steps to fix the situation are very simple and "once and for all". Let's break the steps down: 1. Open a terminal (aka shell or Console or Konsole) from your Desktop Environment 2. Type the following command: sudo nano /etc/firewalld/firewalld.conf 3. You are now inside the "nano" editor, editing the firewalld configuration file with administrator (root) privileges. Move with the cursor arrow keys between the options and enter the following line: NftablesTableOwner=no make sure you press ENTER at the end of the line (so the line stays alone between all the other options, anywhere). 4. Save the file by pressing CTRL + O (keep CTRL pressed, and type O) 5. Exit the editor by pressing CTRL + X 6. Restart firewalld with the command (on the terminal): sudo systemctl restart firewalld Kind regards