Not connected, Your IP: 216.73.217.61
Online: 46587 users - 596790 Mbit/s total BW
.png.f3c947a2e9e68659251859004ed11f01.png){kind=avatar}
Staff
-
Content Count
11894 -
Joined
... -
Last visited
... -
Days Won
2180
Posts posted by Staff
-
-
On 3/27/2026 at 9:48 PM, 0bacon said:I don't close the terminal window. I enter goldcrest -O and it says that it is connected but I can't reach anything. I send kill command after I confirm that I have no connection. Ive given it at least 30 seconds before the kill command, maybe something is causing it to quit after a few seconds?
Hello!
So, the AirVPN Suite works fine as expected. The problem causing the traffic not flowing in the tunnel must lie elsewhere. First, let's determine whether the traffic is completely blocked is it is only apparently blocked. Try to resolve names and ping destinations without names resolution and let's examine the outcome. Examples:ping -c 4 8.8.8.8 dig google.comAlso, can you please test a connection over OpenVPN? Please set airvpntype openvpn on /etc/airvpn/bluetit.rc file, re-start Bluetit and test again a connection. If it fails too, switch to TCP by setting airproto tcp, re-start Bluetit and test again connections.
Kind regards
-
9 hours ago, The Fox said:1. When I reserve ports, they are available to me from any VPN server's exit IP address that I connect my VPN client to? Not sure how you work that magic if it's correct but it makes life very easy.
Hello!
Welcome aboard.
1. Yes, correct.
9 hours ago, The Fox said:2. Again with port 10001 forwarded and set to "all devices"... If I have two client devices (on the same LAN so same public IP address from here) connected to different VPN servers, Say Client A connected to Kornephorus and Client B to Capricornus: Client A will receive traffic forwarded from Kornephorus's port 10001 and Client B will receive traffic forwarded from Capricornus' 10001?
2. Yes, correct.
9 hours ago, The Fox said:3. If I want to connect multiple clients to the same VPN server, with multiple forwarded ports, then I either leave the port forwarding on "all devices" and let my client devices choose what to listen to, or I could opt to pass only a particular port to a particular device by selecting that in the port forwarding for each forwarded port? (the first option would not be so good I guess if there's a lot of incoming traffic, since it would be flooded to all devices on the VPN whether they listen to that port or not).
3. With a port linked to "All devices" this is not possible, because you create an unsupported case in forwarding rules, i.e. the same packet to a specific VPN server public IP address port should be forwarded to the port of multiple VPN IP addresses. This is not implemented and also poses a technical challenge in our infrastructure that's not trivial. To overcome this situation you must use unique key pair for each device and take care to link each port to a single device. Alternatively, a simpler solution is just connecting each device to a different VPN server (your 2nd scenario).
Kind regards
-
3 hours ago, nicoco said:If I omit --interface, then curl does not uses the wireguard tunnel, so my ISP-provided IPv6 is not hidden at all.
Hello!
In this case there's something wrong in setup. The configuration file is correct:
AllowedIPs = 0.0.0.0/0, ::/0
This line tells WireGuard to tunnel the entire IPv4 and IPv6 address space. Any leak is caused by wrong binding or bad routing table together with absence of "network lock" leaks prevention.
Use the AirVPN Suite to get rid of these problems, but it would be interesting to investigate further, if you don't mind. We could start by examining the routing table, the network interface settings and the firewall rule set during a connection, while the problem is occurring. Tracing IPv6 routes can provide valuable clues too.
QuoteQuoteBinding qBittorrent to the VPN interface is a perfect solution
This is what I do, and while it does hide my ISP-provided IPv4 perfectly, the situation is different for IPv6, where my ISP-provided IPv6 is leaked to the tracker and my peers.
This is a symptom hinting at a serious mis-configuration (or some previously un-detected qBittorrent bug, but it's unlikely as something so important would have been immediately noticed). Network Lock would prevent this situation but your case is very interesting and in our opinion deserves further investigation.
QuoteI think there is a confusion in your reply. My setup may be somewhat unusual because I do not want all traffic router through the wireguard interface. I only want certain software to specifically bind on this interface. For eg, web browsing, I'm fine not hiding my IP.
In this case your setup is plausibly the source of the problem. Traffic splitting on an application basis requires some care to avoid those very leaks that you are experiencing. Consider running the AirVPN Suite for a safe traffic splitting on an application basis.
AirVPN Suite resources: https://airvpn.org/forums/topic/79336-airvpn-suite-resources/
Kind regards
-
On 3/26/2026 at 4:33 PM, 0bacon said:I've only been working with ~/.goldcrest.rc.
On 3/13/2026 at 6:50 PM, 0bacon said:it tells me that it's reading run control directives from file /home/xxx/.config/goldcrest.rc
Hello!
Note the discrepancy. Goldcrest may read both ~/goldcrest.rc and ~/.config/goldcrest.rc, no problems, but be aware that you might have two different files.
On 3/26/2026 at 4:33 PM, 0bacon said:(I should also mention that in my firewalld.conf, I have NftablesTableOwner=no.)
Very well, this is essential to allow network lock to work properly.
Quoteit has something to do with the push dns rejected message, could you explain to me in simplest terms what that is?
That's fine, it means that Network Lock blocks the traffic to your system DNS. In this case it's not really true because the system DNS has the same gateway IP address, whose traffic will be allowed in any case (you can verify by pinging 192.168.1.1 for example).
About the log, we would like a clarification, we see that, multiple times, soon after a connection you order a disconnection, for example:
9:11:45 AM bluetit: Requested method "bluetit_status -> Bluetit is connected to VPN (WireGuard)"
9:11:45 AM bluetit: Requested method "stop_connection"
9:11:45 AM bluetit: Stopping WireGuard synchronous connection
Why do you order the disconnection immediately (or just a few seconds) after the connection was established? Note (just in case) that you're running goldcrest in synchronous mode, so if you destroy the window of goldcrest terminal emulator parent, it will receive a SIGTERM and in turn will require Bluetit to disconnect. So, is the disconnection ordered by you voluntarily? If so, is it because you see that no traffic flows?
As a side note, you have defined a white list of only one server. If this is intentional it's fine, but please test more, different servers, just in case there is a problem that's specific between you and Fang. You can define a white list of servers through a list of comma separated server names in the air-white-server-list option in your goldcrest.rc file.
Kind regards
-
Hello!
We're very glad to announce that Eddie Android edition 4.0.0 Release Candidate 1 is now available.
- New CPS QUIC database: now Eddie features a CPS database of more than 30 real web sites allowing accurate QUIC + HTTP/3 mimicry of real services through AmneziaWG. Each database entry is identified by a clear label for immediate selection in the app's settings. Eddie will take care to compile AmneziaWG In parameters accordingly: no need for manual input, which anyway remains an available option. This addition significantly bolsters Eddie's arsenal against blocks.
- New: IPv4 and IPv6 traffic can now be wrapped over an IPv6 tunnel with WireGuard and AmneziaWG too.
- Minor bug fixes
The original message of this thread has been updated accordingly. You will find on it the new download link and checksum, as well as detailed Amnezia description.
If you decide to test, please report at your convenience any bug and problem in this thread. If possible generate a report from the app in a matter of seconds: by tapping the paper plane icon on the Log view bar rightmost side you will generate a full system report which will include both log and logcat and have it sent to our servers. Then you just need to send us the link the app shows you (open a ticket if you prefer to do it in private).
Kind regards & datalove
AirVPN Staff -
8 hours ago, nicoco said:getting curl -6 --interface airvpn ip.network to yield airvpn's public IPv6 was the first step to verify that my setup is working correctly
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
-
On 3/25/2026 at 6:09 PM, Tech Jedi Alex said:Please refer to the FAQ. ch.vpn.airdns.org only resolves to v4. Use ch.ipv6.vpn.airdns.org for v6.
Hello!
Well, the problem seems different though... the OP should be able to enjoy IPv6 over an IPv4 tunnel with the published configuration file. UPDATE: Table = off in a WireGuard profile disables the automatic routing of traffic through the WireGuard interface, allowing the user to manage routing manually. Therefore it's up to the user to set the proper routes,
@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
-
1 hour ago, oassQ9w4cbl4AySZhhth%p36x said:thank you, yes i missed that update the forums do not notify when you modify the thread.
disappointing decision though. AES-NI support and using AES-GCM is better for computer to computer communication
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.
1 hour ago, oassQ9w4cbl4AySZhhth%p36x said:AmneziaWG is good but also most things do not support it. For most people they just want the best throughput for the lowest overhead which up until openvpn DCO was wireguard. now it is not.
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
-
7 hours ago, oassQ9w4cbl4AySZhhth%p36x said:https://netdevconf.info/0x16/papers/27/ovpn-dco.pdf
yep some pretty interesting results, praying @Staff stop ignoring it.
Hello!
We're not ignoring it, did you read the update on the first message of this thread?
Kind regards
-
17 hours ago, 0bacon said:hello, I'm giving this another try. I am working with the .goldcrest.rc to choose the air-server of my choice. I want to connect to chicago servers.
air-server Fang,Kruger,Meridiana,Praecipua,Sadalsuud,Sneden,Superbagoldcrest -O givesERROR: AirVPN Server "Fang,Kruger,Meridiana,Praecipua,Sadalsuud,Sneden,Superba" does not exist.
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
-
10 hours ago, zedik said:Are you saing that "goldcrest --disconnect" or "goldcrest --pause" plus "sudo systemctl stop bluetit" will give me Internet without VPN?
If confirmed I'll tray Suite again.
Q, "This is not true, and anyway it's not buggy" - so why I had to remove modified /etc/resolv.conf file?
Shouldn't uninstall do that?
Q, "Probably you have not understood the "issue" so far" - please elaborate! I love learning.
RTFM
-
9 hours ago, zedik said:Command: "sudo /sbin/bluetit stop" I found using AI (Ask in Brave browser) but don't remember the question.
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.
9 hours ago, zedik said:AirVPN Suite is not for me. I still don't know how properly end the goldcrest session with network lock off
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.
9 hours ago, zedik said:Correct me if I'm wrong but I think is design to run VPN all the time with traffic splitting.
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.
9 hours ago, zedik said:Anyway its buggy because uninstalling Suite leaves modified by it /etc/resolv.conf file and you end up with no Internet
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.
9 hours ago, zedik said:Shouldn't this be included in uninstall.sh file?
Of course not, for the same reasons.
Kind regards
-
33 minutes ago, zedik said:Is:→ sudo /sbin/bluetit stop - and found this "fanciful" information on Internet.
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?
33 minutes ago, zedik said:I don't have AirVPN Suite anymore (uninstalled) and want back my no VPN connection.
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.
33 minutes ago, zedik said:Just noticed airvpnSuite left changed /etc/resolv.conf file. How to restore original resolv.conf?
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
-
20 minutes ago, zedik said:I have killswitch as I mentioned earlier:
sudo ./wg-killswitch-nft.sh up wg0 sudo ./wg-killswitch-nft.sh down wg0I downloaded killswitch from: https://github.com/xtarlit/wg-killswitch-nft
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
-
53 minutes ago, zedik said:Suggested command:→ goldcrest --air-connect --air-country OC
gives me:→ ERROR: country 'oc' does not exist (NZ - the same)
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.
53 minutes ago, zedik said:I'll be using wg-quick.
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
-
3 hours ago, zedik said:However, I would like to know how to tell goldcrest to choose best server from Oceania as I am in Australia.
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 OCNote that "air-country" accepts continent codes too.
Kind regards
-
1 hour ago, kinsham said:The problem is that assigning matching ports in Soulseek doesn't take effect until it is restarted (or so it says) and then it assigns two new ports which then no longer match the port forwarding.
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
-
8 hours ago, zedik said:File bluetit.rc I linked is original from install (not modified).
Did I understand correctly — I should modify bluetit.rc file?
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 wireguardyou 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.
2 hours ago, zedik said:I just followed advice from internet but maybe AirVPN Suite doesn't need that.
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
-
-
@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
ANSWERED Configuring White listed servers and traffic splitting
in AirVPN Suite
Posted ...
Hello!
Bluetit is correctly forbidding connections to servers of the country you are in. Resolve it by setting forbidquickhomecountry off in /etc/airvpn/bluetit.rc (or build a white list of servers outside your home country). From the manual:
From your tests we see that the traffic doesn't flow in the WireGuard tunnel - it could be a block enforced your ISP, but make sure that you disable firewalld first just in case and test again:
sudo systemctl stop firewalldIf the problem persists let's check with OpenVPN. Try OpenVPN over UDP and over TCP.Kind regards