Staff

Hello! Thanks, now it's clear. It's a typical LLM hallucination. We strongly recommend you do not trust them: the free model for the casual consumer hallucinates so often in this regard that we have already documented disasters much more serious than the small incident you had. We also have to fix frequently threads and the support team claims that they have every day bizarre reports clearly caused by wrong assumptions based on LLM hallucinations. Please read the manual instead. There are typically two ways, one of them compliant to Unix and Linux conventions (sending a signal). Everything is documented on the manual. Stopping Goldcrest requires a second, either in synchronous or asynchronous mode. Note that stopping Goldcrest (the client) does not imply stopping Bluetit (the daemon), so if you stop Goldcrest and you have persistent network lock by Bluetit, you will not disable network lock (and rightly so!). Apparently all of your problems were born from an LLM hallucination. Just read the manual, it was written with care. When you can see what the Suite can do you may change your mind. You're wrong in the sense that by default Bluetit keeps traffic splitting disabled: it is opt-in. Read the manual and you'll see. Here we're talking about per-app reverse traffic splitting based on dedicated namespace, which is a safe way to split traffic on an app basis. In a desktop environment, both X.Org and Wayland are supported. This is not true, and anyway it's not buggy. Probably you have not understood the "issue" so far, never mind. If you read the manual you'll get the whole picture and you might even re-consider the software suite. If you don't, never mind and just keep going on: as usual AirVPN can be used normally without our software and we will never force proprietary software usage. Of course not, for the same reasons. Kind regards

Hello! Where exactly? We would like to fix it but no search engine can find it as far as we see. Can you give us a link? Please determine whether the problem is connectivity or only names resolution and report back at your convenience. Also answer to our previous questions to let us help you properly. Not a big deal. As you can read on the manual your case can be resolved immediately. It can be triggered by a "kill -9" command or analogous situations. How to recover network settings is described here. https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/README.md?ref_type=heads#recover-your-network-settings If you purged Bluetit, however, you may have destroyed the whole /etc/airvpn directory so you deleted the resolv.conf backup copy too that is kept protected there. Again, not a big deal. In this case just rebuild your resolv.conf file manually or via your DNS management tool (for example network-manager, systemd-resolved...). Kind regards

Hello! Yes, but you are using it improperly according to your first message. Note how you are exposed between the connection and the manual execution of the script (not to mention in case a failure occurs etc.). A good mitigation of the main problem would be integrating leaks prevention in WireGuard PostUp / PostDown events or just coding a whole script of your own that executes and checks for errors everything. In order to pick the "best" server in New Zealand, you can rely on nz3.vpn.airdns.org domain name. The Configuration Generator will also take care to put it in the profile end point line if you select "New Zealand" country or "Oceania" continent during the selection. NOTE: we did not examine the script, so we are not implying that it works or doesn't work. Kind regards

@zedik Hello! sudo bluetit stop is not a valid command to stop Bluetit. Can you tell us where you found this "fanciful" information? Please read the user's manual here to know how to stop Bluetit: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/README.md?ref_type=heads#controlling-bluetit-daemon If the problem persists after you have stopped Bluetit for real and after you have READ THE MANUAL please feel free to state your Linux distribution name and version and publish Bluetit's log to let us investigate. Kind regards

Hello! Sorry for the typo. Oceania continent code for Bluetit is OCE, not OC. Bluetit follows IOC continent code convention used by the International Olympic, since there is no ISO code for them. Or you could just specify the whole name, Oceania. NZ is recognized correctly though, so your report is incorrect in this regard. Just keep in mind that you don't have many features, such as integration or namespace management for safe traffic splitting, and above all be aware that you don't have a leaks prevention feature (network lock). If you deem it necessary take care to reproduce it. If you don't, please do not complain about traffic leaks. Kind regards

@mcducktits Hello! All the URLs you mention don't exist, where did you find them? Use the web site to find the correct ones, or start from here: https://airvpn.org/windows Also, where did you get the idea of this "ports tab"? There's no such thing in Eddie. Remote inbound port forwarding is managed through the web site and is also client-independent. Kind regards

Hello! We're glad to know that you managed to resolve the problem. For this new purpose tell Goldcrest to connect generically to Oceania (or New Zealand, since in OC we have servers only in NZ because of the infamous "anti-encryption" legal framework in Australia). Example: goldcrest --air-connect --air-country OC Note that "air-country" accepts continent codes too. Kind regards

Hello! This a wrong assumption. Soulseek clients (like Nicotine+) do not randomly change ports on their own if properly configured. Of course you need to re-start the software if you change listening ports. After the re-start, no new ports are assigned. If this happens something wrong is going on, for example the configuration was not saved, or you forgot to disable some random port selection option (from picking random ports to negotiating via UPnP etc.). As a side note, please remember to configure GlueTun environment variables properly, in particular environment: - FIREWALL_VPN_INPUT_PORTS=PORT1,PORT2 That's the environment variable telling the containers firewall to allow incoming packets on listed ports of the VPN adapter. Kind regards

Hello! From now on please feel free to keep using this thread to add CPS sequences capable to bypass blocks in your country or enforced by your ISP, as you already did. QUIC is currently king but feel free to add any other protocol signature to be entered in Eddie Android edition and AmneziaWG software profiles. Kind regards

@8b752fe00bfa513670da30ef68 Hello! Your web site is reachable from the Internet when your system is connected to any VPN server, therefore your setup is correct. For the readers: https://airvpn.org/faq/port_forwarding/ Essential checklist in case of issues: https://airvpn.org/forums/topic/66388-port-forwarding/?do=findComment&comment=243305 Kind regards

Hello! To resolve this error: 2026-03-19T11:07:01.296401+11:00 zedkomp bluetit: Requested method "set_options: air-vpn-type (f) -> <wireguard>" 2026-03-19T11:07:01.296633+11:00 zedkomp bluetit: ERROR: --air-vpn-type can be openvpn or wireguard you needed to change <wireguard> into wireguard where necessary, either in command line or goldcrest.rc file. Now that you have set the airvpntype option in bluetit.rc you may also omit completely the Goldcrest option air-vpn-type because you have set WireGuard connection type already in bluetit.rc. If you want to enable Network Lock or persistent Network Lock in the AirVPN Suite, do not add your own firewall rules in the same chains used by the Suite: they will be overwritten when Network Lock is enabled. Conversely, if you prefer to use your own rules, disable Network Lock completely on bluetit.rc file: networklockpersist off networklock off Kind regards

Hello! Please note that OpenVPN 2.6 and higher versions (i.e. the OpenVPN version you meet on the servers) will push in any case IPv6 gateway, routes etc. Yes, we need to consider whether disabling the now misleading option completely on the CG. Kind regards

@zedik Hello! The bluetit.rc file you sent us is not consistent with the log. The log mentions: 2026-03-15T12:01:09.447328+11:00 zedkomp bluetit: ERROR: networklockpersist in /etc/airvpn/bluetit.rc must be on, iptables, nftables, pf or off 2026-03-15T12:01:09.447395+11:00 zedkomp bluetit: ERROR: networklock in /etc/airvpn/bluetit.rc must be on, iptables, nftables, pf or off ... 2026-03-16T10:53:44.803779+11:00 zedkomp bluetit: ERROR in /etc/airvpn/bluetit.rc: invalid value "<wireguard>" for directive airvpntype (allowed values: openvpn, wireguard) but the rc file you linked has those directives commented out. Can you please check? About the initial error you pointed out, the cause is the same: 2026-03-19T11:07:01.296401+11:00 zedkomp bluetit: Requested method "set_options: air-vpn-type (f) -> <wireguard>" 2026-03-19T11:07:01.296633+11:00 zedkomp bluetit: ERROR: --air-vpn-type can be openvpn or wireguard Note the difference between <wireguard> (wrong) and wireguard (correct). Kind regards

Hello! We can't reproduce in any way. If you had entered some non visible character in your command line we wouldn't be able to see it (on this forum "code" section) and the parser would throw the error. Can you please re-type from scratch the whole command, just to rule out this potential issue? If the problem persists, can you also add the Bluetit log and the bluetit.rc file (wipe out username, password)? To generate the Bluetit log for example to a bluetit.log file: sudo journalctl | grep bluetit > bluetit.log Can you also verify the char encoding of your terminal (type the command locale and send us the whole output)? The correct line is: airvpntype wireguard The angular brackets in our convention include possible options or option argument, with the symbol "|" meaning "or". They are not part of the syntax of the option or option argument, instead they are mere placeholders, so you must omit them. Just like in a lot of GNU documentation and Unix man pages, to be clear. Kind regards

Hello! Available in "Settings" > "System" > "Application Filter Type" > select white or black list, then compile the list on the new "Select applications to be *listed" menu item that will appear. BLACK LIST enabled: all the traffic is tunneled except the traffic of the black listed app(s). WHITE LIST enabled: only white listed apps will have their traffic tunneled. Kind regards