Staff

Hello! Please try to set WireGuard interface MTU to 1280 bytes. GlueTun's default is 1400 bytes which could be too large for your network. A too large MTU will cause major performance hit or even disconnections.. MTU size can be set through the WIREGUARD_MTU environment variable. "You can bind mount an ini Wireguard configuration file to /gluetun/wireguard/wg0.conf. " https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/wireguard.md Another performance improvement can be obtained by configuring correctly the container in order to allow the torrent software to receive the incoming packets. Note that in your compose file you did not map the proper port in the ports: section and you did not define properly the FIREWALL_VPN_INPUT_PORTS environment variable, which should be set according to the port you remotely forwarded on your AirVPN account port panel. EDIT: after a few minutes we published this message we noticed that your torrent software became reachable, so the above setting modifications are probably unnecessary. Kind regards

@partypat Hello! Can you please upgrade to AirVPN Suite 2.0.0 beta 4 and check whether the problem gets resolved or not? https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/ Kind regards

Hello! Can you please check whether Eddie starts minimized and its tray icon is somewhere in the system tray? Please make sure you can see hidden icons too by clicking the "up" arrow on the system tray. Eddie may start minimized if it configured to do so. Its tray icon is a tiny cloud in a circle. By double-clicking it, Eddie main window should pop-up. You can tell Eddie not to start minimized by unchecking "Start minimized" in "Preferences" > "General" window. Kind regards

Hello! From your description you're just fine and there are no leaks. The suspicious connection stats are updated only every other minute or so, therefore they are not decisive. Just to stay on the safe side even more, you can consider to force Docker containers' traffic through the Gluetun container's network thus preventing any possible traffic leak outside the VPN tunnel: https://tcpip.wtf/en/force-docker-containers-vpn-gluetun.htm Kind regards

@misamarumaru Hello! Your setup is not infrequent to achieve "double hop" and increase the anonymity layer robustness in case one of the VPN servers is secretly or even illegally wiretapped and another one is not. The price to pay, as you noticed, is a performance hit. This setup is not "optimal" for the mentioned purpose because all the hops belong to the same entity. When a much more robust privacy or anonymity layer is needed, and one is fine with a remarkable performance decrease, a more effective multi-hopping is with the Tor network, even without previous double hop. Kind regards

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