Staff

Hello! Excellent. Thank you for your tests! Now you can also check with goldcrest --bluetit-status that now shows who activated the connection too. Kind regards

Hello! That's correct. Per-app "reverse" traffic splitting is supported out of the box. For any application requiring a GUI, compatibility is 100% on all desktop environments, according to the tests and reports so far. Compatibility with both X11 and Wayland has been achieved as well. Please make sure you have AirVPN Suite 2.0.0 beta 4, because it improves cuckoo and reverse traffic splitting dramatically, on top of important bug fixes and the addition of a precious airsu tool. Find on the README.md file all the detailed instructions (an executive summary here below) that describe step by step how to start an application whose traffic must flow outside the VPN tunnel Executive summary: 1. Enable Bluetit's traffic splitting by setting allowtrafficsplitting on on /etc/airvpn/bluetit.rc file (this file can be edited with any text editor with root privileges) 2. Re-start Bluetit. In a systemd based system, with root privileges: systemctl restart bluetit In a SysV-Init style based system: /etc/init.d/bluetit restart 3. Connect to a VPN server. 4. Open a terminal and prepare the environment by running airsu airsu script will set all the necessary environment variables and switch to account airvpn. NOTE: airsu requires bash (it will not run properly with dash) - we are confident that it is available on every Linux distribution. Usually it is also the default interpreter, but if it's not you can easily install it. 5. Start AnyDesk program with the following command, entered in the same terminal where you had just run airsu: cuckoo --run /path/and/name/of/AnyDesk Kind regards

Hello! We're very glad to announce that AirVPN Suite 2.0.0 beta 4 is available, featuring an urgent fix of the bug causing ERROR: Cannot start WireGuard connection. Client name and user name (system login name) not provided. when Bluetit was configured to connect at startup. Please check the original message of this thread for more details, the updated link to download the Suite, and (if you come from 1.3.0 or from 2.0.0 beta 1) please consider to spend a few minutes on the new user's manual readme.md (in the package) to learn the new features. Please test the new beta 4 version when you can and report back any glitch or bug you find, thank you very much! Kind regards

@Kaappi Hello! Please find the solution on ufw manual (see below for a quick rule). We want to warn you: you have forwarded only incoming UDP, while qBittorrent relies a lot on TCP. Please make sure to forward TCP too for the port you have been assigned. sudo ufw allow in on <tun interface name> from any to any port <your reserved port number> Kind regards

Hello! Problem solved. Kind regards

Hello! As already mentioned beta 2 can not work anymore with nft (unless you disable network lock, not a good workaround), we're sorry. We're working on a beta 4 to have a new beta version that's usable as soon as possible. Thank you for your tests as usual! Your error with beta 2 is different and is probably correct behavior, but never mind at the moment, it's not worth keeping on testing beta 2 version. Please focus if possible on the next beta 4, which is imminent and where these latest bugs will be addressed. Kind regards

Hello! Bug confirmed, under investigation. Thank you for your tests! Kind regards

Hello! We're very glad to announce that AirVPN Suite 2.0.0 beta 3 is available, featuring: improved bootstrap servers management improved DNS management airsu utility improvements updated to OpenVPN3-AirVPN library version 3.11 bug fixes. All the bugs currently found on beta 2 have been addressed. Special thanks to the community for the invaluable tests! Please check the original message of this thread for more details, the updated link to download the Suite, and (if you come from 1.3.0 or from 2.0.0 beta 1) please consider to spend a few minutes on the new user's manual readme.md (in the package) to learn the new features. Please test the new beta 3 version when you can and report back any glitch or bug you find, thank you very much! Kind regards

Hello! Please click server names to see more details about each server. High packet loss means that the server is suffering more than 30% packet loss on one or multiple IP addresses. Packet loss is computed to and from the VPN server, from and to other servers in the infrastructure. The mentioned servers were shown as not available and suffering high packet loss because they suffered high packet loss. In this case the packet loss was caused by a widespread flood on various servers which lasted a few hours and required null routing the attacked IP addresses. On every server issue history you can see the start time and duration of each issue. Kind regards

Solved. Kind regards

Hello! Maybe. For a quick check to discern whether the problem is caused by ufw please disable it completely with the command: sudo ufw disable You can later re-enable it with sudo ufw enable Kind regards

Hello! This is a case that differs from having two ice creams instead of one. First, you need to consider the evaluation order of the Windows Filtering Platform rules, because Network Lock and you will both modify the WFP. By experience we see that in some cases Windows users mixing Network Lock and own rules by interacting directly with the WFP end up breaking Network Lock and exposing their system either to overblocking or leaks. Anyway if you know what you're doing of course you can even define entirely your own Network Lock. Keep in mind that if Eddie re-writes the WFP after you have enforced your rules, you will have to assess the new set. Kind regards

Hello! Does this problem persist with the latest Eddie 2.24.6 stable version? If so, can you please send us a system report (provided that you can manage to get out of the "Checking environment" hiccup) generated after the problem took place? Please see here to do it: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! Yes, from your description everything is fine. If you run the AirVPN software Eddie, you can consider to let it set firewall rules to prevent traffic leaks outside the VPN tunnel by activating Network Lock feature. On Eddie's main window please click "Activate Network Lock" button before you start a connection. You may also tell Eddie to activate Network Lock by itself when it is started by checking "Activate Network Lock at start" in Eddie's "Preferences" > "General" window. Kind regards

Hello! Problem solved. The reason of the problem and why your method works perfectly can be inferred from GlueTun behavior described here: https://airvpn.org/forums/topic/63708-gluetun-port-forwarding-works-for-an-hour/?do=findComment&comment=239350 By changing port you force a new socket on the rebuilt tunnel. Re-starting qBittorrent from scratch or the whole container should fix the issue as well. Please note that you have an additional option for mitigation described in the linked thread that does not require the workaround you implemented, worth a try. Side note, please insert the proper port for qBittorrent on your compose file ports: section and if necessary set properly the FIREWALL_VPN_INPUT_PORTS variable. Ref. https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/firewall.md Kind regards

Hello! This depends on your desktop wallet configuration/behavior. Perhaps after a suspend the wallet gets encrypted and you need to enter the password to decrypt it (and therefore Eddie will be able to decrypt the configuration file). Different issue is when Eddie asks for root privileges. To bypass this security feature Eddie backend can start as a systemd service (only on systemd based systems) during the bootstrap. That's why when you start the GUI you should not be prompted for the password to gain root privileges: the backend already runs with root privileges. It should be clarified now whether the password you need to enter relates to the wallet password (in order to decrypt Eddie's configuration file) or to the authorization to gain root privileges. In particular, please note that if Eddie was already running before the suspension, then at resume Eddie should find the configuration file already decrypted, and Eddie's backend already runs with root privileges. The passwords could match (it depends on your configuration) but they are used for different purposes. Can you also tell us your Desktop Environment name and version? Kind regards

Hello! The characters you type for a password are generally not echoed on the terminal emulator for security reasons. You have to type the password (of the Mac account with which you opened the terminal emulator) "blindly", then press ENTER. If you typed the wrong password the system will warn you. Kind regards

Hello! This is a not infrequent situation with those containers that destroy the tunnel at each VPN re-connection. Please see here for a specific GlueTun case and an effective mitigation: https://airvpn.org/forums/topic/63708-gluetun-port-forwarding-works-for-an-hour/?do=findComment&comment=239350 In general, if there's no way to prevent tunnel destruction and rebuild, re-starting qBittorrent (or anyway the listening program) could be the only solution. Kind regards

Hello! We confirm it's the same problem, so you can apply the identical solution. Kind regards

Hello! A new 10 Gbit/s (full duplex) server is now available in Germany. Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Frankfurt, Germany, is available: Ashlesha. 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. Ashlesha 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 . Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! For the readers' comfort and to suggest troubleshooting ideas, we paste the answer by the support team to your ticket (with a few omissions for privacy reasons): Hello and thank you for your choice! This is what we see on the server you are currently connected to (xxx): <...> a.b.c.d is your VPN IPv4 address, so the port forwarding is active and properly configured. We have noticed that when we try to send a packet to your node, the attempted connection is actively reset by your system (TCP RST) on both ... and ... ports. As you can see from the nftables counters, packets are sent to your system. When this problem occurs you should verify your virtual environment to understand why the attempted connections are reset. It could be a firewall rule, but it could also be your kernel that's configured to reset attempted connections to non-existing ports. This last case would imply that the qBittorrent process is either not running or binding to a wrong interface, or maybe stuck to a previous socket because the VPN connection dropped and was re-established. When it happens, if the container destroys the tun and re-creates it, then qBittorrent needs to be restarted. This is a known issue for example in GlueTun: https://github.com/qdm12/gluetun/issues/1407 The above would also explain why you experience the problem 1-2 times per week, which could be a disconnection event frequency. Kind regards

Hello! It is possible that we are interpreting the problem incorrectly. However, by editing the /etc/hosts file you should be able to resolve the issue. The next beta 3 is expected to be out in a few days. Kind regards

Hello! The unpacking will restore the old files with the wrong ownership, so the problem will likely re-appear when you re-install. The problem is still the same, but for another file: E 2025.01.29 21:21:14 - WireGuard > Error: Executable '/Applications/Eddie.app/Contents/MacOS/wg' not allowed: Not owned by root; Please change ownership of this file too and any other file in case of additional errors of the same type: sudo chown root /Applications/Eddie.app/Contents/MacOS/wg sudo chown root /Applications/Eddie.app/Contents/MacOS/wireguard-go Kind regards

Hello! Perhaps nothing wrong, this looks like a Bluetit bug which causes a critical error to the latest nft version (so it went unnoticed with the previous nft versions). If this is the problem we suspect, then it has been fixed and the new, imminent beta 3 will include the patch. As soon as Suite 2.0.0 beta 3 is out please test it and let us know whether it solves the problem. If you need urgently to run AirVPN Suite 2.0.0 beta 2, you should be able to fix the issue by editing your /etc/hosts file (root privileges required) and adding the following line: 82.196.3.205 bootme.org Thank you very much for your tests! Kind regards