Staff

Hello! Please see here for an explanation and a solution. https://airvpn.org/forums/topic/67862-random-connections-to-different-cities-with-a-specific-city-vpn/?do=findComment&comment=245613 Please make sure you read GlueTun's documentation, including the part related to AirVPN integration: https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md Kind regards

Hello! Eddie should allow the execution of binaries when they are not owned by root, only if they pass the checksum verification. If they don't, only files owned by root will be run with root privileges. The files packaged with Eddie should pass the checksum verification. Why it does not happen is a matter of an ongoing investigation by the developers. With that said, the system refusal to change ownership even to the superuser is probably caused by a terminal that's not allowed to have full disk access, according to System Integrity Protection. You should grant Terminal program full disk access in the following way: Make sure that Terminal is not running. Open System Preferences > Security & Privacy from the Apple menu.. Click the padlock icon at one corner of the window and enter your administrator password to make changes. Go to the Privacy tab. Click the [+] button at the bottom of the list on the right. Navigate to Terminal program location in the Applications folder ([...]/Applications/Utilities/Terminal). Add Terminal to the list and make sure that its checkbox is ticked. Then, open the terminal and try again to change ownership of the relevant files sudo chown root <full path and name of the file> You will need to change ownership of both wg and wireguard-go files. Kind regards

Hello! Since the firewall is enabled the FIREWALL_VPN_INPUT_PORTS environment variable must be set to the proper ports (in case of multiple ports, separate their values with a comma ",") in any Docker container where appropriate. The firewall blocks any unsolicited incoming packet to any port whose value is not contained in the mentioned variable. We meant to test without any container, without any virtual environment. The initial post clearly states that the tests "were all run with the containers open, restarted, ports tested at every turn, active listening for connections", so we assumed that they were run in some Docker container. Sorry for having assumed specifically GlueTun, anyway the suggestion remains valid (FIREWALL_VPN_INPUT_PORTS is a Docker environment variable). According to your needs any virtualization seems unnecessary indeed. Kind regards

@Y7h-2dfrgrtAA-3 Hello! Thank you very much for the head up. A cable related problem, not detected by Quintex monitoring system, has been expeditiously solved and the machines are alive and kicking now. Kind regards

Hello! OK. However you need to set the rules after (and every time) Eddie has enforced the Network Lock, because previous rules will be overwritten each time Eddie enables Network Lock. You also need to bind the listening software to the physical network interface. Maybe a more practical solution is running AirVPN Suite 2.0.0 beta version and run the listening software outside the VPN tunnel. For this purpose just enable Bluetit's traffic splitting, connect via Bluetit, and finally run the listening software through cuckoo (an utility included in the Suite). You can keep using Network Lock even with this setup: Network Lock will prevent leaks from anything except the program(s) whose traffic must go outside the VPN tunnel. https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/ In this way the listening software remains reachable from outside the VPN tunnel as long as Bluetit is not shut down and port forwarding on the router is properly set. Kind regards

@Loadstone Hello! What is the value of the FIREWALL_VPN_INPUT_PORTS GlueTun environment variable? Does the problem persist or disappear if you operate directly on your host, without virtual environments? Kind regards

Hello! (Solved by disabling the route and DNS check). Kind regards

Hello! You need to generate, download and use new profiles when you renew, revoke or create client keys in the "Devices" panel, or trivially when you want a new connection mode or destination. In any other case, including remote port forwarding and DNS block list modifications, you do not need to generate new profiles Kind regards

Hello! For the readers' comfort, we paste here the solution, that you confirmed as working, suggested by the support team on your ticket Kind regards ===== Hello and thank you for your choice! Thank you for your great feedback. GlueTun supports AirVPN and bypasses the endpoint specified in the WireGuard profile, hence the problem you experience occurs. Therefore, you should make use of its environment variables to make sure that it connects always to the same server: SERVER_NAMES: Comma separated list of server names Example: SERVER_NAMES=Angetenar or always to the same city (but potentially to different servers if that city offers multiple servers): SERVER_CITIES: Comma separated list of cities Example: SERVER_CITIES=Toronto You can add the above in the compose file. Please check the documentation here: https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md Kind regards AirVPN Support Team

Hello! Thank you for your great feedback. If you enable Eddie's "Network Lock" with default settings, Eddie will set firewall rules that allow any incoming and unsolicited packet from (and only from) the VPN tunnel. No need to modify your nft rules in this case. Do you have a different purpose which requires a modification to this behavior? Kind regards

Hello! Please run Eddie, enable Network Lock, connect to a VPN server, disconnect from that VPN server, disable Network Lock and then send us: a system report generated by Eddie https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ the output of "sudo nft list ruleset" the output of "sudo iptables-save" the output of "sudo ufw status" the output of "cat /etc/resolv.conf" In general, since Mint packet filtering platform is based on nftables, you should keep ufw disabled (the default setting in Mint 21.x) to avoid various clashes caused by translations forced by the hybrid usage of iptables-legacy (ufw works only with iptables, not with nftables) and nft. Kind regards

Hello! We have noticed that you are connected successfully, did the problem solve by itself or did you need to modify something? Kind regards

@VagueCow Hello! We could not manage to reproduce the problem on our Linux Mint 22.1 testing machine. We run Eddie 2.24.6 installed from the deb package. The DE of the machine is Cinnamon. The system has been installed with all default settings. Can you please give us more details and also publish a system report generated by Eddie after the problem has occurred? Does anybody else on Mint 22.1 reproduce the problem? The "no route to host" error message by OpenVPN makes us think of a specific network related problem, not a problem affecting Eddie or Mint, unless maybe you run some tool at kernel level capable to block specific application traffic such as OpenSnitch? Please see here: Kind regards

@dornhoeschen Hello! Understood. The packet loss occurs outside our network as you already noticed. Those two IP addresses are inside M247's Frankfurt pool (check with "whois", in most other databases the addresses are missing). M247 incidentally is also one of our providers but not with that IP address range. Therefore, unfortunately, there is nothing we or you can do to address the problem directly. It's also curious that our M247 servers (spread in several EU countries and in the USA) communicate with Mesarthim, and vice-versa, with 0% packet loss. We could warn our Mesarthim provider but we're not sure they can do anything as apparently they do not interconnect directly with M247 and after the packets transited through M247 infr. no problem appears; maybe it's M247 that should review the matter. We will ponder over the matter to see what to do. Kind regards

Hello! For general information, with the AirVPN Suite 2 you can work with namespaces and split traffic even if you have a system not based on systemd (SysV-like init and systemd based systems are both supported). You don't need to run a process as a service. Also note that systemd services/units are not daemons, for clarity. You don't even need to modify or setup anything in your system. Just keep in mind that you have a "reverse" traffic splitting, i.e. Bluetit prepares a namespace whose traffic flows outside the VPN tunnel, while it tunnels to the VPN the traffic of everything running on the default namespace. You can start any application inside the new namespace (out of the VPN tunnel) simply by typing cuckoo --run application Kind regards

@dornhoeschen Hello! Since February the 7th the problem has never re-occurred, the dc should have sorted it out. Strange that you still experience packet loss, but it should not be caused by Mesarthim: could you post an mtr report if possible? mtr -n -c 25 -w mesarthim.airservers.org Kind regards

Hello! Solution found by the user: Kind regards

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

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

Hello! This is expected. More details on why it can't work later on this message. 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 (**). 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: 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. 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

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

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

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

Hello! 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