Staff

On 4/7/2024 at 2:16 PM, Alonzo said:

I'm trying to setup wireguard in a way that only applications i set to use the wg's interface will route its traffic through the VPN, with port forwarding enabled.

Hello!

This is currently possible on Android (with Eddie Android edition), Windows (with WireSock) and (only reversed, i.e. you can specify apps whose traffic must flow outside the tunnel) on Linux with the AirVPN Suite 2.0.0 beta version.

Kind regards
 

13 hours ago, GearForgeMC said:

Hello, I just paid for the VPN service 2 year plan and I can't seem to figure out how to get the activation code. can someone help? IDK if there is a wait period for card.

Hello!

There is no code, when the IPN (Instant Payment Notification) is received the plan gets activated in a matter of a couple of seconds. In your case PayPal is keeping the transaction on hold for internal investigation that usually takes 24-48 hours. After that, the money is either delivered to us or sent back to your account. If it is delivered to us, the system activates your account plan immediately after the IPN is received.

Kind regards
 

15 hours ago, King0777 said:

My problems are
- that I can’t connect in through the VPN forwarded port from a device on the same LAN.

Hello!

This is expected. More details on why it can't work later on this message.
 

15 hours ago, King0777 said:

- and I can’t connect in outside of the VPN (through a forwarded port set on my router) from a device outside of my LAN.

Expected too, due to the routing table and also the Network Lock if enabled.

If you need traffic leaks so that a listening program is reachable both on the "real" public IP address and on the VPN server exit-IP public address, you should disable Network Lock (or re-configure it accordingly), have a program listen to all interfaces, define (only when necessary) source based routing, and configure WireGuard NOT to route all traffic inside the tunnel (**).
 

15 hours ago, King0777 said:

When trying to connect from another device on the same LAN through the VPN forwarded port, the SYN packet opening the TCP connection is received through the Eddie interface, as expected.

This means that you tried to reach the listening program on the VPN interface IP address from inside the same LAN, or to the public VPN server IP address (or through the DDNS, same thing) - this is an error because then the physical reply is necessarily routed into the VPN tunnel (check your system's routing table (*) and you will immediately see why; or that WireGuard is tunneling the whole IP space (default behavior with Eddie Desktop edition). As you noted:
 

Quote

But the SYN,ACK response is sent back through my eth interface.

You must contact the service directly on the LAN and you have to make sure that WireGuard does not send everything inside the VPN tunnel (**), to avoid that the reply is routed in the VPN tunnel and becomes un-routable on the VPN server. The interpretation you give here is not totally correct.

It's true that the physical reply is routed finally through eth (just like anything else, because a virtual network sooner or later must rely on something physically existing), but the packets transiting there have been already encrypted and wrapped.

The final destination address is the original sender address through the VPN routing. The reply (the underlying payload of the traffic) then gets lost as expected because it must go to the same public IP address of your router, i.e. the same public IP address the VPN server sees your client connecting from, which is also the same public IP address the request to your listening service comes from, in the eyes of the VPN server.
 

15 hours ago, King0777 said:

That was working on Windows, it’s not working on linux.

This is very strange. Maybe you had a different setup in Windows? Anyway the correct behavior is the one you just described on Linux.

(*) Please note that if you have enabled multiple routing tables then source based routing may become strictly necessary to ensure that responses to packets received from an interface are always sent back from the same interface.  From your description this doesn't seem the case, but if it is, please keep it into consideration. You will also need that devices in the same LAN can route outgoing traffic to different public IP addresses to contact a listening service (through the VPN) of a machine in the same LAN. It doesn't make sense anyway, just pass through the LAN.

(**) The option to do so is currently not implemented in Eddie Desktop edition, but only in Eddie Android edition. It is planned anyway on an imminent AirVPN Suite for Linux release. Please see here for a thorough explanation and a possible solution:
https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?do=findComment&comment=217458

Kind regards
 

2 hours ago, King0777 said:

Come on, I must not be the only one to have that problem, where is the official documentation from AirVPN on how to do it???

Hello!

It's here:
https://airvpn.org/faq/port_forwarding/

We can already reach your sshd (and another service too) through the proper ports of the VPN servers you're connected to, so your setup seems already correct and working.

Side note: you have also defined a *.airdns.org name to reach your sshd. Note that when you change VPN server the record will be updated immediately by our authoritative DNS server, but the TTL is 1 hour, so when you change server you may need to wait for the propagation if you query a public DNS.

Kind regards
 

On 2/15/2025 at 4:13 PM, Staff said:

We will test on Mint 21.3 and 22.1 in the next days and let you know.

Hello!

@dhch

The more extended tests on Mint 21.3 allowed to detect the problem. When ufw is running, it sets a series of custom rules. If you then enable network lock with Bluetit in default configuration, Bluetit stores the rules through nft (correctly). However, the system translation from ufw/iptables rules to nft syntax goes horribly wrong. When Bluetit restores the previous firewall status, the restore fails because during the previous translations syntax errors were introduced in the file where the previous rules were saved. This is a well known / notorious issue since years ago, it's the translation problem we wrote about in our previous message.

After that, Bluetit even crashes (core dump you may have seen), so it will also fail to restore DNS system settings if a connection was performed during the session. This crash must be investigated of course: it is triggered by nft critical error (it exits with unknown error 256), so we should be able to avoid the crash, but the syntax errors caused by the system commands during the translations are unavoidable, they are system tools intrinsic. It is not in our scope to fix what's lost in translation; the problem can be avoided in other ways.

By not running ufw when you start Bluetit, you will also be able to avoid another problem we see in your log.

The solution is the one we recommended before: make sure that ufw is disabled when you start Bluetit, or force Bluetit's network lock to fall back to iptables. To disable ufw:

sudo ufw disable

Please let us know whether any problem still persists after you test Bluetit with ufw disabled.

Kind regards
 

1 hour ago, dhch said:

just to clarify, system is linux mint 21.3, not sure if the mentioned 2.21 is the same

Hello!

Sorry, our testing system is Mint 21.1 Xfce edition and, provided that you install bash, everything runs perfectly, including traffic splitting. We will test on Mint 21.3 and 22.1 in the next days and let you know. The log shows multiple critical problems that are not currently reproducible. We will update this thread in due time.

As far as it pertains to ufw, Bluetit does not disable anything, but Network Lock operates at nftables level in your system through the userspace utility nft, because Bluetit detects that both nftables and nft are working in your system. However, ufw is an iptables frontend, so it can not interact directly with nftables, it must do it through legacy translations. This hybridization is deprecated because it may cause very many problems (Bluetit tries to warn you with "WARNING: ufw is running on this system and may interfere with network filter and lock" as you may have seen).

ufw does not support nftables, which is the new network filtering subsystem of your distribution Linux kernel.

iptables compatibility is maintained through a complex set of translations. If you operate simultaneously with nft and ufw, bad things may (will) happen. When Bluetit restores the previous rules, it does so via nft. If ufw gets disabled at this stage, it's not Bluetit that disables it directly.

The above firewall problems are not user's direct responsibility, instead they look like the outcome of a suffering and maybe not well planned migration from iptables to nftables on Ubuntu and derivatives. Please note that in Mint 21.3, ufw is disabled by default, thus resolving the problem at its root.

Solution: consider to clean up the system to stay entirely on translations or entirely on nftables. If you want to go with nftables, just disable and/or uninstall ufw.

If you prefer to keep ufw then renounce to nft and rely exclusively on translations, and force Bluetit to go back to iptables translation. To do so, just change the networklockpersist setting into iptables (from the default automatic choice).

Kind regards


 

Hello!

From the log we see that Suite 1.3.0 can not run properly in your system, we're sorry. Can you also send us the complete Bluetit log of the Suite 2.0.0 beta 4? From our tests, with the exception of the utility airsu , our testing Linux Mint 21.1 machine can run Goldcrest and Bluetit just fine. The problem with airsu is already being investigated (EDIT: found the problem, fix on its way, workaround available), anyway you need it only in part (for traffic splitting, in order to prepare the env to run a GUI based app with traffic outside the VPN tunnel).

EDIT: tech note, the problem with airsu occurs because dash is forced to interpret airsu in spite of the she-bang #!/bin/bash - a more thorough investigation will be performed on this issue. A quick but dirty solution is linking /bin/sh to /usr/bin/bash (after bash package has been installed of course).

Important note: Mint 21.3 comes without bash pre-installed - please install bash package first, then install the Suite. This is necessary because the installer script has been written in bash.

sudo apt install bash

Kind regards
 

2 hours ago, colorman said:

But still error; 

Hello!
 

2 hours ago, colorman said:

2025-02-15 11:49:25 ERROR: Cannot start WireGuard connection. Client name and user name (system login name) not provided.

We managed to reproduce the bug by trying to launch Goldcrest by both airvpn (or users in the airvpn group) and root. We will address the problem in the next beta version. In the meantime (so you can continue testing) please do not use a configuration file for WireGuard connections. Run Hummingbird directly when you want to establish a WireGuard connection through a configuration file and run Goldcrest for AirVPN integration.

Thank you for your tests!

Kind regards
 

1 hour ago, dhch said:

the dns settings seem to be stuck somehow. when terminating goldcrest the content of /etc/resolv.conf still lists the nameserver set by the vpn client.

Hello!

AirVPN Suite 2.0.0 has improved Network Lock and DNS managements in general and also when systemd-resolved is in control. It also fixed many bugs. Currently the Suite 2.0.0 is at the beta stage, with public testing. Would you like to test it to check whether the problem gets resolved or not? If so, please see here:
https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/

If you opt testing 2.0.0 beta but the problem persists please send us the complete Bluetit log taken after the problem has occurred. From a terminal:

sudo journalctl | grep bluetit > bluetit.log

then send us the generated bluetit.log file. If you decide not to test the Suite 2.0.0 beta version, please send us anyway Bluetit 1.3.0 log (in the same way, as above).

Kind regards
 

On 12/2/2024 at 8:21 PM, Air4141841 said:

open vpn with the remote command actually reconnects to a different server when one goes down! 

On 12/2/2024 at 8:21 PM, Air4141841 said:

using wireguard in Opnsense 

Hello!

WireGuard userspace native utilities do not offer this feature. As a side note, WireGuard features IP addresses roaming and we're not sure whether the ability you require would be compatible with this important feature.

Kind regards
 

@dhch

Hello!
 

1 hour ago, dhch said:

Is it the network lock that stays active?

It may stay active, according to your preferences. Bluetit can operate with a persistent Network Lock if networklockpersist is set to on on your /etc/airvpn/bluetit.rc file, can you please check?

Kind regards
 

@webshammo

Hello!

Apparently the remotely forwarded inbound ports reserved for your AirVPN account are not published in your compose file ports: section so the behavior you observe would be expected. Please add them and also set the environment variable FIREWALL_VPN_INPUT_PORTS accordingly, if necessary.

Kind regards
 

1 hour ago, colorman said:

./install.sh: line 385: setcap: command not found

Hello!

setcap sets file capabilities and requires libcap. Please install libcap and libcap-progs packages, uninstall and re-install the Suite, test again and report back at your convenience.

Kind regards
 

1 hour ago, Kaappi said:

I wasn't sure whether or not wireguard supported TCP

Hello!

We're glad to know the the problem is resolved.
 

1 hour ago, Kaappi said:

I wasn't sure whether or not wireguard supported TCP

WireGuard doesn't support TCP as a VPN connection protocol, but this is unrelated. When a tunnel is established over UDP,  any transport layer protocol packets (TCP, UDP, RDP etc. etc.) get wrapped inside UDP.

Kind regards
 

32 minutes ago, 183aTr78f9o said:

Can confirm that

ERROR: Cannot start WireGuard connection. Client name and user name (system login name) not provided. 

bug is solved now after updating to beta 4.

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

 

On 2/11/2025 at 12:56 PM, Anf0rg said:

understand that AirVPN Suite 2.0 (or the latest version) supports per-app reverse traffic splitting through Bluetit and Cuckoo, which should allow me to exclude AnyDesk from the VPN tunnel. Could you please provide detailed instructions or a guide on how to configure this split tunneling feature to specifically exclude AnyDesk, including the necessary steps to identify and specify AnyDesk’s traffic using Bluetit and Cuckoo, either through command-line configuration or by editing the relevant configuration files?

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.

1. 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.
2. 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
 

10 hours ago, Starch7305 said:

After some research I identified the issue. DNS wasn't resetting properly. Problem solved!

Hello!

Problem solved.

Kind regards
 

2 hours ago, colorman said:

I'm back to beta 2, but can't get it to work anymore.

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
 

2 hours ago, 183aTr78f9o said:

ERROR: Cannot start WireGuard connection. Client name and user name (system login name) not provided.

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
 

On 2/8/2025 at 2:15 AM, kkkdaf83884 said:

I'm actually curious if more details are available anywhere else than here

Hello!

Please click server names to see more details about each server.
 

On 2/8/2025 at 7:49 AM, haiki said:

updates/notices about server issues.

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.
 

On 2/8/2025 at 2:08 AM, SDNT said:

Why are all the West coast servers showing up as N/A with packet loss in Eddie?

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
 

3 hours ago, Reconfirm5 said:

figured it out I needed to add a device, redo the config generator and assign it to that device.

Solved.

Kind regards
 

On 1/23/2025 at 4:21 PM, Tubular said:

Now, however, as of several months ago (?), with this current issue, I see that `ufw` does not go inactive when I enable Network Lock. Could that be part of the problem?

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