Staff

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

Hello! This is expected. It is also unavoidable: consider that inside the VPN server packets originated by your node when it is a source pass through public entry-IP address -> virtual network -> exit-IP address -> final destination. When your node is a destination from external source, packets reaching the exit-IP address are forwarded to the virtual network, encrypted and sent to your VPN IP address So, if your VPN IP address is both source and destination and the packet should simultaneously get out of and enter the exit-IP address etc., what happens? You create a network loop because there's no self-routing logic for your packet between entry -> VPN -> exit -> exit again -> VPN and finally entry addresses, and the packet is lost. The VPN is not designed as a loopback device, so to speak. Use your system loopback interface to have the system communicate with itself as a simultaneous source and destination. This is a different issue and this behavior is explicitly blocked in the infrastructure for security reasons. It is a valuable VPN feature (allowing sharing resources, sharing the same network) in virtual networks where all the nodes are known and trusted, but it is dangerous in a public VPN service or in general where nodes can not be trusted by each other. The only shared resource in the VPN is the DNS server. No node can reach another node inside the VPN itself. Kind regards