Staff

Hello! The idea is correct, but you must omit --interface option for the previously explained reasons. However this is a necessary but not sufficient condition to prevent traffic leaks. Binding qBittorrent to the VPN interface is a perfect solution. Our software Network Lock feature is another one. You may apply both settings for additional safety. Please note that some qBittorrent versions could handle only IPv6 or only IPv4 traffic, but we think that qBittorrent devs resolved this limitation recently. Kind regards

Hello! Well, the problem seems different though... the OP should be able to enjoy IPv6 over an IPv4 tunnel with the published configuration file. @nicoco First of all, there is an error in how you use curl. You must not specify the VPN interface: the interface must manage an IPv4 tunnel. IPv6 must be wrapped over it. If you bind curl to the VPN interface, you bypass the routing table and you prevent the system from picking the correct source IPv6 address. You don't see this problem with curl -4 --interface <VPN interface> probably because there is no ambiguity in selecting IPv4 source address when curl binds to the VPN interface, in spite of the routing table bypass (i.e. lucky case). Just omit this option and you should be fine (alternative: follow @Tech Jedi Alex solution, you will have an IPv6 tunnel over which you can tunnel IPv4 too and the problem could be "specular" with v4 when you use curl). Side note: the option --interface is not supported in Windows. If the problem persists: are you sure that your curl -6 tests are directed toward an IPv6 HTTP supporting service? Try https://ipv6.google.com for a cross-check, and ping6 too. If the problem still persists, please make sure that IPv6 support is enabled on your system and your network interfaces. Kind regards

Hello! Well, not totally true thanks to SIMD, especially AVX and AVX-512. AVX is commonly available on CPUs since 2011, while AVX-512 came out around 2016. By the way: WireGuard already saturates our servers (2.6 Gbit/s per client on the server, recently...) so the physical limit of our lines is reached before kernel performance becomes a problem. We would also like to see how the new DCO beats properly configured WireGuard on real life usage, not from a paper written by the same DCO developer. But anyway DCO changed incarnations and compatibilities many times. Having followed each iteration at the beginning, we wasted a significant amount of time and this situation had to be ended. No more, thank you... we are inclined to use the NEW DCO only when we have our infrastructure running on a mainline kernel that includes the module (in other words, starting from Debian 14, which is due to be released in 2027). On the other hand we also acknowledge the decision of important competitors to drop OpenVPN completely in the recent past. It's a delicate matter that we must take into consideration. Additionally, OpenVPN keeps a relevant superiority over WireGuard with some important features: DHCP enabled, ability to connect over SSH and TLS additional tunnels, and over socks and http proxies. But we do not need DCO for such strategic options (which by themselves hit performance heavily) so its adoption is not compelling. Our customers' choice is clear: OpenVPN usage dropped from 80% to 23% in just a year and a half. Note that just two weeks ago we had 24%, now it's 23%, the decline is fast. So what? DCO is not a replacement for blocks circumvention and does not feature AmneziaWG abilities, including CPS, handshake and payload packets padding, junk packets. We see DCO as a WireGuard competitor, but not at all as an AmneziaWG alternative, which in turn is aimed at lower performance for better blocks circumvention. Kind regards

Hello! We're not ignoring it, did you read the update on the first message of this thread? Kind regards

Hello! Note: we asked for the Bluetit log and you never sent it. In this case it's no more necessary because there is no problem at all, but in the future you should reply to requests, otherwise you prevent us from supporting you properly. This is expected and correct. air-server option requires a server name, not a list. If you want to define a list of servers you need air-server-white-list option, which expects a list of server names separated by a comma. When you define a white list of server, leave air-server commented out and do not specify it in the command line. The software will pick the "best" server among the white listed ones. As a peculiar case, when you invoke Goldcrest you can still specify --air-server <server name> just in case you want a connection to a specific server included in the white list. However, you can not force a server that's not in the white list. Nothing in /etc/airvpn/bluetit.rc must contradict goldcrest.rc as Bluetit directives and policy, that can be enforced only by root, take precedence. Kind regards

RTFM

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