Staff

Hello! The infrastructure is upgrading to OpenVPN 2.7 with DCO (Data Channel Offload) support. However, this upgrade doesn't break compatibility with OpenVPN 2.4 and higher versions, and you're running OpenVPN 2.5. Try to upgrade to OpenVPN 2.6 or 2.7 just in case and check whether the problem gets resolved. Also test WireGuard, which has not been modified (the kernel module gets upgraded with the kernel upgrade of course). To see the list of upgraded servers, you can go to your AirVPN account "Client Area", enter the "Config Generator", turn on the "Advanced" switch, and select "2.6 DCO" in the "OpenVPN profile" combo box. The CG will show only the servers running OpenVPN 2.7 and DCO module. Kind regards

@robertoohoho Hello! You have set either a Master Password or system key wallet password protection to encrypt Eddie's configuration file. If you can't remember the password, you have no choice but to delete Eddie's configuration file while Eddie is not running. At the next run Eddie will create a new configuration file with default settings and no password-led encryption. To delete Eddie's configuration file on macOS, from a terminal opened by the same account that installed Eddie: rm ~/.config/eddie/* Kind regards

Version 2.26.2 (Thu, 09 Jul 2026 11:19:55 +0000) [fix] [linux] Fix elevated startup on distros without systemctl (e.g. Devuan/sysvinit) [fix] [all] Emit disable-dco in generated OpenVPN config when startup options are incompatible with data channel offload [fix] [windows] Harden elevated named pipe against pipe-name squatting (FIRST_PIPE_INSTANCE, single instance) [change] [all] Misc fixes and general cleanup

Hello! Black list enabled: all traffic inside the VPN tunnel except the traffic of the black listed applications which goes outside the tunnel. White list enabled: all traffic outside the VPN tunnel except the traffic of the white listed applications which goes inside the tunnel. When you define a whitelist with a single app for per-app traffic splitting purposes, only that app traffic will be tunneled. The system process traffic will not be tunneled, and any other non-white listed app traffic will not be tunneled. So the behavior you observe seems just fine, but please feel free to elaborate if we misunderstood. Kind regards

@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