Linux: AirVPN Suite 2.0.0 preview available

[Staff 9764]

Hello!

We're very glad to inform you that AirVPN Suite version 2.0.0 alpha 1 is now available. UPDATE 2023-11-24: version 2.0.0 alpha 2 is now available.

AirVPN Suite 2.0.0 alpha 2 introduces AirVPN's exclusive per app traffic splitting system as well as some bug fixes, revised code in order to pave the way towards the final and stable release, WireGuard support, and the latest OpenVPN3-AirVPN 3.9 library. Please see the respective changelogs for a complete list of preliminary changes for each component of the suite. If you feel adventurous and you wish to test this preview version, please feel free to report any glitch, bug and problem in this very thread.

 

The 2.0.0 alpha 2 Suite includes:

• Bluetit: lightweight, ultra-fast D-Bus controlled system daemon providing full connectivity and integration to AirVPN servers, or generic OpenVPN and WireGuard servers. Bluetit can also enforce Network Lock and/or connect the system to AirVPN during the bootstrap
• Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN and WireGuard servers
• Hummingbird: lightweight and standalone binary for generic OpenVPN server connections
• Cuckoo: traffic split manager, granting full access and functionality to AirVPN's traffic split infrastructure

WARNING: this is alpha software in its development stage, it is provided "as is" and with no implicit or explicit warrant it will work properly and as expected or planned. Because of the development stage, the software may have bugs which may also cause critical and unstable conditions. This software is used at the whole risk of the user and it is strongly advised not to use it in production or critical systems or environments. Please note that features and functionalities of this alpha/development version may be changed or removed in future releases.

WireGuard support
 

WireGuard support is now available in Bluetit. OpenVPN or WireGuard selection is controlled by Bluetit run control file option airvpntype or by Goldcrest option -f  (short for --air-vpn-type). Possible values: openvpn, wireguard. Default: openvpn. The option is documented in the 1.3.0 manual as well. Currently Hummingbird does not support WireGuard, please rely on Bluetit and Goldcrest.

Bluetit run control file (/etc/airvpn/bluetit.rc) option:

airvpntype: (string) VPN type to be used for AirVPN connections. Possible values: wireguard, openvpn. Default: openvpn

Goldcrest option:

--air-vpn-type, -f : VPN type for AirVPN connection <wireguard|openvpn>

 

AirVPN's VPN traffic splitting

AirVPN Suite version 2.0.0 introduces traffic splitting by using a dedicated network namespace, therefore completely separating the VPN traffic from unencrypted and "out of the tunnel" traffic. The VPN traffic is carried out in the default (main) namespace, ensuring all system data and traffic to be encrypted and tunneled into the VPN by default. No clear and unencrypted data are allowed to pass through the default namespace.
Any optional unencrypted data or clear network traffic must be explicitly requested by an authorized user with the right to run cuckoo, the AirVPN traffic split manager tool.

AirVPN's traffic splitting is enabled and controlled by Bluetit and by means of run control directives. The system has been created in order to minimize any tedious or extensive configuration, even to the minimal point of telling Bluetit to enable traffic splitting with no other setting.

In order to enable and control AirVPN's traffic splitting, the below new run control directives for /etc/airvpn/bluetit.rc have been introduced:

• allowtrafficsplitting: (on/off) enable or disable traffic splitting (unencrypted and out of the tunnel traffic) Default: off
• trafficsplitnamespace: (string) name of Linux network namespace dedicated to traffic splitting. Default: aircuckoo
• trafficsplitinterface: (string) name of the physical network interface to be used for traffic splitting. All the unencrypted and out of the tunnel data will pass through the specified network device/interface. In case this directive is not used and unspecified, Bluetit will automatically use the main network interface of the system and connected to the default gateway. Default: unspecified
• trafficsplitnamespaceinterface: (string) name of the virtual network interface to be associated to the Linux network namespace dedicated to traffic splitting. Default: ckveth0
• trafficsplitipv4: (IPv4 address|auto) IPv4 address of the virtual network interface used for traffic splitting. In case it is set to 'auto', Bluetit will try to automatically assign an unused IPv4 address belonging to the system's host sub-network (/24) Default: auto
• trafficsplitipv6: (IPv6 address|auto) IPv6 address of the virtual network interface used for traffic splitting. In case it is set to 'auto', Bluetit will try to automatically assign an unused IPv6 address belonging to the system's host sub-network (/64) Default: auto
• trafficsplitfirewall: (on/off) enable or disable the firewall in Linux network namespace dedicated to traffic splitting. The firewall is set up with a minimal rule set for a very basic security model. Default: off

AirVPN's traffic splitting is designed in order to minimize any further configuration from the system administrator. To actually enable traffic splitting, it is just needed to set "allowtrafficsplitting" directive to "on" and Bluetit will configure the traffic split namespace with the default options as explained above. When needed, the system administrator can finely tune the traffic splitting service by using the above directives. At this early alpha stage, it is advised not to change the network namespace name but leave it to its default value "aircuckoo" to let cuckoo tool properly work.

 

Power and limitations

 

The adopted solution offers a remarkable security bonus in terms of isolation. For example, it gets rid of the dangerous DNS "leaks in" typical of cgroups based traffic splitting solutions. However, the dedicated namespace needs an exclusive IP address. If the system is behind a NAT (connected to a home router for example) this is not a problem, but if the system is not behind any NAT, i.e. it is assigned directly a public IP address, you will need another public IP address for the network namespace dedicated to traffic splitting. You will need to manually set the other public IP address on the trafficsplitipv4 or trafficsplitipv6 directive as the guessing abilities of Bluetit may work only within a private subnet. Please keep this limitation in mind especially if you want to run the Suite with per app traffic splitting on a dedicated or virtual server in some datacenter, as they are most of the times NOT behind any NAT.

 

Introducing Cuckoo, the AirVPN traffic splitting manager tool

Traffic splitting is implemented in AirVPN Suite by using a separate and independent network namespace, directly communicating with the system's default gateway through a virtual interface associated to a physical network interface available in the system. This ensures a true separation of traffic between tunneled and encrypted VPN data from the unencrypted and clear data to be channeled out of the VPN tunnel. The unencrypted traffic will never pass through the default namespace - which is under the VPN control - including, and most importantly, DNS requests.

To generate unencrypted and out of the tunnel traffic, any software having this need must be run inside the traffic split namespace. In order to do so, AirVPN Suite 2.0.0 introduces a new tool meant to be specifically used for this purpose: Cuckoo.
The tool can be used by users belonging to the airvpn group only. It cannot be used by root or any user belonging to the root group.

Additionally, in order to fully use the cuckoo tool, the user must also have special capabilities enabled, notably CAP_SYS_ADMIN, CAP_NET_ADMIN and CAP_NET_RAW. The installation script will set these capabilities to the "airvpn" user only. In case you need to let other users of the airvpn group use the cuckoo tool, you can simply duplicate the corresponding line in /etc/security/capability.conf and adapt it to your needs.
Note that in many distributions all of the above will not be necessary but keep it in mind if you find some issue and please feel free to report it.
At this current alpha stage cuckoo supports "aircuckoo" namespace only, that is the default namespace configured by Bluetit.

This preliminary alpha version does not provide any option and it is meant to simply run an application inside the traffic split namespace only.
The usage is straightforward:

cuckoo program [program options]

 

The traffic split namespace uses its own routing, network channels and DNS. It will not interfere or communicate in any way with the default namespace where the VPN is running and using its own encrypted tunnel. As for DNS, the traffic split namespace will use default system DNS settings.

Programs started with cuckoo are regular Linux processes and, as such, can be managed (that is stopped, interrupted, paused, terminated and killed) by using the usual process control tools. The programs started by cuckoo are assigned to the user who started cuckoo.

As a final note, in order to work properly, the following permissions must be granted to cuckoo and they are always checked at each run.

• Owner: root

• Group: airvpn

• Permissions: -rwsr-xr-x (owner can read, write, execute and setuid; group can read and execute, others can read and execute)

Note on Web Browsers

 

Firefox and Chromium will not be able to resolve names in the aircuckoo namespace, not even when you run a unique instance of them inside the network namespace itself, in some Ubuntu systems. We are investigating this behavior. Brave, Opera and Konqueror are not affected by this problem, but please consider that due to how browser instances are tied to each other, you might get unexpected behavior if you run the same browser in both namespaces from the same user.
For example, if the browser has been started in the default namespace while there is an active AirVPN connection, the traffic will flow to the connected AirVPN server and from the associated VPN IP address from any future apparent instance launched by the same user, and vice-versa. The second instance may detect the first, delegate the task to it and exit, so you will have a new window but not another instance.
In order to circumvent the issue, at this stage you may tale care to run programs in the aircuckoo namespace via cuckoo only from airvpn account, and programs whose traffic must be tunneled from your ordinary account. In other words, to add security, do not add your ordinary account to the airvpn group if you plan to use traffic splitting, so your ordinary account will not be able to run cuckoo by accident.
 

Download AirVPN Suite 2.0.0 alpha 2:

https://eddie.website/repository/AirVPN-Suite/2.0-alpha2/AirVPN-Suite-x86_64-2.0.0-alpha-2.tar.gz

$ sha512sum AirVPN-Suite-x86_64-2.0.0-alpha-2.tar.gz 
c70f7b553d5489e02233a3e326c175c047c085dac7d4f36289ffc07e0bf0d86c98df4c49f4258d3d83b4fde96c81efbccc394f326260a1ac80d2f7892b825b79  AirVPN-Suite-x86_64-2.0.0-alpha-2.tar.gz

 

Kind regards & Datalove
AirVPN Staff

[jonjon91 0]

Hi. I'm trying to get up and running but I am having some trouble. please assist.

I have installed the package, the installer created the airvpn user and group, I then ran cuckoo [program] from the airvpn user. I get the following error message 

Cuckoo - AirVPN Traffic Split Manager 2.0.0 alpha 1 - 15 Sep 2023

ERROR: Cannot open network namespace 'aircuckoo': No such file or directory

 

[Staff 9764]

11 hours ago, jonjon91 said:

Hi. I'm trying to get up and running but I am having some trouble. please assist.

I have installed the package, the installer created the airvpn user and group, I then ran cuckoo [program] from the airvpn user. I get the following error message 

Cuckoo - AirVPN Traffic Split Manager 2.0.0 alpha 1 - 15 Sep 2023

ERROR: Cannot open network namespace 'aircuckoo': No such file or directory

Hello and thank you for your tests!

Can you please make sure that you have the following directive in /etc/airvpn/bluetit.rc

allowtrafficsplitting on

If this is missing you will get that error message. We will make that error message more explicative during the alpha stage. Please let us know whether the problem is caused by the missing directive or not.

Kind regards
 

[fsy 27]

On 9/15/2023 at 12:00 PM, Staff said:

Note on DNS and Gecko or Chromium Based Web Browsers

Not that I am into traffic splitting, not at all, but just to test the new Suite I think I would resolve the problem by having split Firefox environments: different datadir, profiles etc. Before I try, do you think it can work? I guess it might be overkill, if someone found a smoother solution let me know...
 

[jonjon91 0]

9 hours ago, Staff said:

Can you please make sure that you have the following directive in /etc/airvpn/bluetit.rc

allowtrafficsplitting on

Yes I have this setting and I am still receiving the same error.

I was also dealing with an issue that airvpn changed the /etc/resolv.config file. I had to delete the file contents and add my DNS to the nameserver to regain internet access 

 

[Staff 9764]

11 hours ago, jonjon91 said:

Yes I have this setting and I am still receiving the same error.
 

Hello!

Thanks. Thus, it must be a different issue or maybe a bug. Can you tell us your distribution name and version? Can you also please send us the complete Bluetit log? You can see it via journalctl if you are in a systemd based distribution. The following command:

sudo journalctl | grep bluetit > bluetit.log

will store the whole log in bluetit.log file.
 

11 hours ago, jonjon91 said:

I was also dealing with an issue that airvpn changed the /etc/resolv.config file. I had to delete the file contents and add my DNS to the nameserver to regain internet access 

When this other problem occurs, please send us a Bluetit log again as well as the content of the /etc/airvpn directory:

sudo ls -l /etc/airvpn

Kind regards

 

[Staff 9764]

On 9/19/2023 at 1:40 PM, fsy said:

Not that I am into traffic splitting, not at all, but just to test the new Suite I think I would resolve the problem by having split Firefox environments: different datadir, profiles etc. Before I try, do you think it can work? I guess it might be overkill, if someone found a smoother solution let me know...
 

Hello!

Unfortunately it will not work. We are investigating different issues caused by web browsers. Please check the original announcement, we have changed a part to reflect the matter, we paste it here for readers' comfort and in order to outline the issue:
 

Note on Web Browsers

Firefox and Chromium will not be able to resolve names in the aircuckoo namespace, not even when you run a unique instance of them inside the network namespace itself, in some Ubuntu systems. We are investigating this behavior. Brave, Opera and Konqueror are not affected by this problem, but please consider that due to how browser instances are tied to each other, you might get unexpected behavior if you run the same browser in both namespaces from the same user.
For example, if the browser has been started in the default namespace while there is an active AirVPN connection, the traffic will flow to the connected AirVPN server and from the associated VPN IP address from any future apparent instance launched by the same user, and vice-versa. The second instance may detect the first, delegate the task to it and exit, so you will have a new window but not another instance.
In order to circumvent the issue, at this stage you may tale care to run programs in the aircuckoo namespace via cuckoo only from airvpn account, and programs whose traffic must be tunneled from your ordinary account. In other words, to add security, do not add your ordinary account to the airvpn group if you plan to use traffic splitting, so your ordinary account will not be able to run cuckoo by accident.
 
Kind regards
 

[revsplus 7]

Glad to see this preview. Questions: shall we see a port to FreeBSD of the whole Suite? Can we expect app based traffic splitting on Windows?

[ARandomGuy 0]

On 9/15/2023 at 12:00 PM, Staff said:

if the browser has been started in the default namespace while there is an active AirVPN connection, the traffic will flow to the connected AirVPN server and from the associated VPN IP address from any future iapparent instance, and vice-versa. The second instance may detect the first, delegate the task to it and exit, so you will have a new window but not another instance.

Is it just me or is it a severe problem? I mean, if cuckoo just forces an app to run in a specific network namespace with no other process isolation whatsoever then not only browsers but also any program checking whether another instance of itself is already running in order to share resources or opt for delegations will cause all sort of troubles to the unaware user. Was the first instance launched in the root namespace or in the cuckoo namespace? Was another instance running because it started at boot? How the user is supposed to remember and track all the instances and know which programs check for another instance of themselves when starting?

Waiting for developers answers and hoping that, if I'm correct, this unhappy preview is just a bump in the road, after all it's only alpha 1.

[Staff 9764]

9 hours ago, ARandomGuy said:

Is it just me or is it a severe problem? I mean, if cuckoo just forces an app to run in a specific network namespace with no other process isolation whatsoever then not only browsers but also any program checking whether another instance of itself is already running in order to share resources or opt for delegations will cause all sort of troubles to the unaware user. Was the first instance launched in the root namespace or in the cuckoo namespace? Was another instance running because it started at boot? How the user is supposed to remember and track all the instances and know which programs check for another instance of themselves when starting?

Waiting for developers answers and hoping that, if I'm correct, this unhappy preview is just a bump in the road, after all it's only alpha 1.

Hello and thank you for your tests!

Of course, as you say, this is an early preview, an alpha 1, so we can and we will improve the software. With the understanding the the highest security level is reached only by renouncing to traffic splitting or by splitting traffic only through boosted virtualization via a proper hypervisor, our solution aims at offering a fair balance between a very light implementation and a safe environment. If we pushed on virtualization too much, then the user might as well use directly pushed solutions of non-Linux third-party components and software suites, such as VirtualBox or Docker. It's not in our vision to burden the AirVPN Suite at those levels, as the Suite is thought to remain the most lightweight piece of software we release.

In the current default setup, you have a minimum of two separate login users in any Linux box: airvpn and your usual user. By default, only airvpn can run cuckoo. If you consider not to add your current user to the airvpn group, you can safely rely on the fact that the types of processes you mention launched by your current user will never be affected by processes started by airvpn user and vice-versa. In this way it's almost impossible to cause a confusion by distraction and, for example, using a browser outside the tunnel while you think that it's inside.

It's also obvious that a decent concentration level is always required, but that's required even with full virtualization, because no security model can save you from the distraction to assume wrongly that a specific VM is connected to the VPN while in reality it is not. So nothing new, traffic splitting was, is and will be requiring some attention, no matter how you achieve it. Stay tuned for the alpha 2, we are working on it.

Kind regards
 

[Staff 9764]

On 9/21/2023 at 11:45 AM, revsplus said:

Glad to see this preview. Questions: shall we see a port to FreeBSD of the whole Suite? Can we expect app based traffic splitting on Windows?

Hello!

We're terribly sorry, the port to FreeBSD is currently frozen. We will re-consider it anyway in the future, but only after the Suite 2 stable version for Linux is released. As far as it pertains to Windows, we will leave the answer to the Eddie Windows edition developer.

Kind regards
 

[Stalinium 44]

13 hours ago, ARandomGuy said:

Is it just me or is it a severe problem? I mean, if cuckoo just forces an app to run in a specific network namespace with no other process isolation whatsoever then not only browsers but also any program checking whether another instance of itself is already running in order to share resources or opt for delegations will cause all sort of troubles to the unaware user.

It is indeed a severe problem and I don't see a way how this could be fixed. If you chose to separate the IPC/storage namespaces too then you'd need to take full control over application settings and how it's launched to ensure separation.
The main vector here are default protocol handlers. Click an http:// link in any other program and your default browser will start in the default namespace, not that other one. What else can you do, intercept all program launches? Linux doesn't have the same concept of matching an ".exe name" as on Windows.
Edit: I just saw that Staff replied. The per-user separation is a reasonable decision here.
= = =

On 9/20/2023 at 6:25 PM, Staff said:

Firefox and Chromium will not be able to resolve names in the aircuckoo namespace, not even when you run a unique instance of them inside the network namespace itself, in some Ubuntu systems.

I have a similar issue using a custom namespaced setup with Wireguard but in a different way. Firefoxes' DNS lookups inside the namespace will work until the computer goes to sleep. After waking up Firefox will be unable to resolve any hosts until Fx is restarted. I have not tried loading websites per IP, maybe Firefox actually loses all connectivity in this case. Arch Linux.
Just a guess, did you put a per-namespace resolv.conf file where it belongs? Somewhere around mans/arch wiki or systemd text there was a proposal of a standard to have per network namespace resolver configuration. Maybe Firefox when it doesn't run DoH looks at the wrong resolv.conf and tries to contact the local DNS resolver from another namespace.

[Staff 9764]

16 hours ago, Stalinium said:

I have a similar issue using a custom namespaced setup with Wireguard but in a different way. Firefoxes' DNS lookups inside the namespace will work until the computer goes to sleep. After waking up Firefox will be unable to resolve any hosts until Fx is restarted. I have not tried loading websites per IP, maybe Firefox actually loses all connectivity in this case. Arch Linux.
Just a guess, did you put a per-namespace resolv.conf file where it belongs? Somewhere around mans/arch wiki or systemd text there was a proposal of a standard to have per network namespace resolver configuration. Maybe Firefox when it doesn't run DoH looks at the wrong resolv.conf and tries to contact the local DNS resolver from another namespace.

Hello!

Yes, of course, we take care of both resolv.conf and nsswitch.conf inside the aircuckoo namespace (/etc/netns/aircuckoo/nsswitch.conf) in order to

1. prevent the feared and dangerous "DNS leaks inside then tunnel" which affect other traffic splitting implementations based on cgroups and
2. cover various distributions, including systems where systemd-resolved runs.

In our "reversed" traffic splitting implementation, the aircuckoo namespace apps must query the system DNS.
Per network namespace resolver configuration seems an established feature, or do you mean something else with the proposal you mention? Or do you imply that systemd-resolved may cause additional problems we have not taken into account?

For your specific problem, we have no immediate suggestion unfortunately, we would just recommend that you check (for example with Wireshark) what happens to Firefox packets after the system woke up. We're also unsure whether this article may help you, probably not but we link it anyway just in case:
https://philipdeljanov.com/posts/2019/05/31/dns-leaks-with-network-namespaces/

Feel free to keep us posted, and we'll do the same, as the different outcome with / behavior of Firefox in different distributions is under investigation and we need to clarify the issue carefully.

Kind regards
 

[fsy 27]

@Staff

At the moment I found a solution I like. I enter desktop environments both with airvpn and my normal account at the same time and then switch between the environments. Switching is quite fast on Linux and it helps me focus on which is which. It resolves a problem I met which I did not look into much, maybe you like to hear it. The airvpn account apparently does not get properly configured by the installer or maybe I made some error during installation, because airvpn account via cuckoo can't run any de based application on the desktop of someone else. [virtualized Fedora 38 here].
 

[Stalinium 44]

8 hours ago, Staff said:

Yes, of course, we take care of both resolv.conf and nsswitch.conf inside the aircuckoo namespace (/etc/netns/aircuckoo/nsswitch.conf) in order to

Hey I found what I was thinking of, man ip-netns:

Quote

DESCRIPTION
      A network namespace is logically another copy of the network stack, with its own routes, firewall rules, and network devices.

      By default a process inherits its network namespace from its parent. Initially all the processes share the same default network namespace from the init process.

      By convention a named network namespace is an object at /var/run/netns/NAME that can be opened. The file descriptor resulting from opening /var/run/netns/NAME
      refers to the specified network namespace. Holding that file descriptor open keeps the network namespace alive. The file descriptor can be used with the
      setns(2) system call to change the network namespace associated with a task.

HERE: For applications that are aware of network namespaces, the convention is to look for global network configuration files first in /etc/netns/NAME/ then in /etc/.
      For example, if you want a different version of /etc/resolv.conf for a network namespace used to isolate your vpn you would name it /etc/netns/myvpn/re‐
      solv.conf.

 

This is what you already do, nice. However for systemd-resolved I did not find a single mention of network namespaces (i.e. this convention) in their manual. God knows what it does or does not do.

Looking further I found https://github.com/systemd/systemd/issues/17155 - "portable: default profile /etc/resolv.conf bind mount can break in the container namespace." maybe that's similar to my case even though I don't use systemd-resolved (but rebinding happens; I'm not worried about DNS going through main namespace since I use dnscrypt there anyway - my ISP interferes with DNS). Yeah, I really should check Wireshark. For others reading, what's funny is Wireshark not supporting network namespaces yet. You must launch it in the appropriate net ns with enough permissions or Wireshark will not see the other interfaces.

Now an unrelated but good link with explanation of some systemd service options, here the user manually created a service with Wireguard-style netns: https://github.com/systemd/systemd/issues/28694
Here again a lengthy discussion of starting systemd services in a network namespace: https://github.com/systemd/systemd/issues/2741

[ARandomGuy 0]

@Stalinium
@Staff
@fsy

Thank you all, keeping separate accounts in their respective DEs is just great. OT: any plan to see the same per app traffic splitting mode in Eddie for Linux?
Keep up the good work!

[TooLittleTime 0]

@Staff

I have been using Bluetit on Debian 11 for more than a year now, and have ran into an issue with SSD activity.

It seems that Bluetit is causing noticeable read/write activity on the SSD.  This completely goes away if I use wireguard, or openvpn that is not running on Bluetit.  Version of Bluetit also doesn't seem to matter, as the same issue persists after updates.  Since the PC stays online 24/7, it is now causing significant wear on SSD. 

Is this a known issue?  If not, any suggestions on how to get around this?

[Staff 9764]

@TooLittleTime

Hello and thank you for your tests!

We are unable to reproduce the issue at the moment, can you please tell us whether you see the same when you run Hummingbird (with Bluetit not running at all)?

Kind regards
 

[Staff 9764]

Hello!

We're glad to inform you that AirVPN Suite 2.0.0 alpha 2 is now available.

 

NEW:

• WireGuard support by Bluetit and Goldcrest
• minor bug fixes

The announcement message has been updated accordingly. Thank you for your tests! Please report bugs or any malfunction here.

Kind regards
 

[Quallian 24]

Great, it works, and I see dramatic performance increase with WIreGuard and lower CPU load on a level playing field with OpenVPN (same server etc.). It's totally consistent with the wg client for Linux with kernel module. Not my case but out of information what happens if the module is unavailable?

[Staff 9764]

15 hours ago, Quallian said:

Great, it works, and I see dramatic performance increase with WIreGuard and lower CPU load on a level playing field with OpenVPN (same server etc.). It's totally consistent with the wg client for Linux with kernel module. Not my case but out of information what happens if the module is unavailable?

Hello!

Thank you for your tests!
If the WireGuard kernel module is missing, the Suite will not work in WireGuard mode.

Kind regards
 

[irxhnfdptv 1]

Cuckoo - AirVPN Traffic Splitting Manager 2.0.0 alpha 1 - 24 November 2023

ERROR: Cannot open network namespace 'aircuckoo': No such file or directory

$ sudo ls -l /etc/airvpn
total 168
-rw-rw---- 1 root root 138622 Jan 12 10:02 airvpn-manifest.xml
-rw-r----- 1 root root      5 Jan 12 10:02 bluetit.lock
-rw-rw---- 1 root root   3496 Jan 12 09:54 bluetit.rc
-rw-rw---- 1 root root   1445 Jan 12 09:41 connection_priority.txt
-rw-rw---- 1 root root     48 Jan 12 09:41 connection_sequence.csv
-rw-rw---- 1 root root    103 Jan 12 09:41 continent_names.csv
-rw-rw---- 1 root root   1743 Jan 12 09:41 country_continent.csv
-rw-rw---- 1 root root   3737 Jan 12 09:41 country_names.csv
-rw-rw---- 1 root root    225 Jan 12 09:41 nsswitch.conf

getting the same error as above. here's what i changed in bluetit.rc:
airvpntype wireguard
allowtrafficsplitting on
trafficsplitnamespace aircuckoo

distro: debian 12 stable amd64

bluetit.log

 

edit: i think it's because i didn't set my airvpn username and password 😅 now bluetit starts to connect

Edited ... by irxhnfdptv

[irxhnfdptv 1]

now i connects, but immediately disconnects and it endlessly tries to reconnect, see the logfilereconnect.log

Edited ... by irxhnfdptv

[Staff 9764]

@irxhnfdptv

Hello!

WireGuard can't connect. Might it be blocked in your network? If you try a connection with the native WireGuard client for Linux, is it successful? You can generate a profile for WireGuard on our Configuration Generator available in your AirVPN account "Client Area". By testing the WireGuard client directly you may let us discern whether the problem is Bluetit-specific or not.

Kind regards
 

[irxhnfdptv 1]

16 minutes ago, Staff said:

@irxhnfdptv

Hello!

WireGuard can't connect. Might it be blocked in your network? If you try a connection with the native WireGuard client for Linux, is it successful? You can generate a profile for WireGuard on our Configuration Generator available in your AirVPN account "Client Area". By testing the WireGuard client directly you may let us discern whether the problem is Bluetit-specific or not.

Kind regards
 

hello. yea it works natively if i use "wg-quick up wg0" Edited ... by irxhnfdptv