Staff

@Dunmer1E700 Thank you! Understood. This a conceptual error in cuckoo which exits if it does not find any graphic environment, for example when launched from a pure TTY. cuckoo will be modified accordingly to allow correct usage even in cases like yours. It's not a trivial matter but we should be able to deliver the patch already in RC 2. About airsu, it can work only from a terminal emulator run by X or some Wayland compositor, and this is correct. You won't need airsu to run Caddy via cuckoo if Caddy does not need any graphic environment. Thank you again, your report has been instrumental to make us realize of this conceptual error. Stay tuned for Release Candidate 2. Kind regards

Hello! We don't understand, if you don't have any graphic environment for the user connecting via SSH how can you manage to run an application that needs it, with or without Bluetit and Cuckoo? Can you clarify the system setup to let us focus on the issue? Thanks in advance! Kind regards

Hello! The unlimited traffic has nothing to do with slowing or not slowing down servers. The bandwidth allocation per connection slot as well as the amount of simultaneous connections inside the tunnel originated by each slot are crucial factors in this case and both those variables have been addressed in AirVPN ever since a decade ago. There's no need to limit the traffic in a given time frame for the purpose you mention; in fact, it would be ineffective. Kind regards

Hello! It could be related to environment variables. Please run airsu first to prepare the environment and swich to airvpn user. airsu is a Suite tool that prepares the user environment for the X.Org or Wayland based ecosystem. Feel free to keep us posted. Kind regards

Hello! If, and only if, you connect directly the router to AirVPN servers and share the AirVPN traffic with device(s) behind the router, please see here: https://docs.gl-inet.com/router/en/3/tutorials/firewall/#port-forwards From the documentation it is not totally clear whether the "WireGuard" external zone for port forwarding applies also when the router runs WireGuard in "client mode": it should work fine since a WireGuard interface does not have a fixed role as client or server, it can act as both. Thus, chances are that the port forwarding documented for WireGuard in "server mode" will work identically in "client mode". For any problem please contact their customer support and if possible report back here. Kind regards

@James8795 Hello! Can you please publish the complete container's log taken after the problem has occurred? As a first "blind" attempt to resolve the situation, please test again with a WireGuard interface MTU set to 1280 bytes. Set the WIREGUARD_MTU environment variable to 1280 in the environment: section: environment: - VPN_SERVICE_PROVIDER=airvpn - VPN_TYPE=wireguard - HEALTH_VPN_DURATION_INITIAL=120s - WIREGUARD_MTU=1280 ... Kind regards

Hello! Passepartout can be run to connect to AirVPN servers by importing a WireGuard or OpenVPN profile generated by AirVPN's Configuration Generator. Kind regards

@Dunmer1E700 Hello! You can consider AirVPN Suite 2.0.0 RC 1 and have Caddy traffic (and if necessary any other application you wish) flow outside the VPN tunnel, since Bluetit 2.0.0 supports per app reverse traffic splitting. In this way only Caddy traffic will flow outside the VPN tunnel. Please see here: https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available Inside the package you will find the updated README.md which is a thorough user's manual. Release Candidate 1 has reached a very remarkable stability and reliability according to long and thorough internal and public testing. Release Candidate 2 is due to be out during the next week and the stable release will follow shortly. Please note that the namespace which Caddy (and any "outside the tunnel" process) lives in will have a different private IP address (consider this when you forward port 443 from the router). Kind regards

Hello! Starting from version 2.3, firewalld by default owns exclusively nftables tables generated by itself, thus preventing Eddie, Bluetit and Hummingbird Network Lock related operations. If you want to have Network Lock enabled and firewalld running at the same time, then you must configure firewalld by setting the following option: NftablesTableOwner=no in firewalld's configuration file, usually /etc/firewalld/firewalld.conf . After you have edited the configuration file with any text editor with root privileges, reload firewalld configuration or restart firewalld, and only then (re)start Bluetit, Hummingbird or Eddie. Additional insights: https://discussion.fedoraproject.org/t/firewalld-add-flags-owner-persist-in-fedora-42/148835 https://forums.rockylinux.org/t/rocky-9-5-breaks-netfilter/16551 Kind regards

Hello! GlueTun offers a remarkable integration with AirVPN and in general will not consider the configuration file to determine the end point. Instead, it will evaluate specific environment variables, please see here: https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md#optional-environment-variables Even if you set SERVER_REGIONS=Europe or something similar, a new end point will be determined only upon disconnection or container restart. Under no circumstance a connection will be intentionally and suddenly broken and then re-established to a different server without the operator's intervention. Remember that the mentioned environment variables will be correctly evaluated when the VPN_SERVICE_PROVIDER variable is set to airvpn: VPN_SERVICE_PROVIDER=airvpn Kind regards

Hello! Please try various WireGuard's interface MTU, starting from 1280 bytes and slowly increasing it, and check whether you have a specific value which improves the upload speed. GlueTun's environment variable setting WireGuard interface MTU is WIREGUARD_MTU. You can set it in the compose file environment: section. Remember to re-start the container each time you change the setting. Example: environment: - UID=1000 - GID=10 - TZ=Europe/Copenhagen - WIREGUARD_MTU=1280 Although you are probably in the EU, where such behavior would be illegal except when forced by congestion or exceptional causes, please note that some ISPs could cap UDP in upload even on symmetric lines (we mention UDP because WireGuard works over UDP). Please check the "traffic management" policy of your ISP, just in case. Kind regards

Hello! According to reports found on the web, Tunnelblick warns that IPv6 DNS server is not being used when the "disable ipv6" checkbox is ticked. The warning can be incorrect because it is thrown even though the IPv6 tunnel is functioning correctly and DNS queries to the provided IPv6 DNS server address work fine, can you verify? If DNS6 does not work, the problem can be related to the peculiar macOS management of IPv6 tunneling over IPv4, please see here: https://gist.github.com/smammy/3247b5114d717d12b68c201000ab163d Both Eddie and Hummingbird for macOS were rewritten in 2022/2023 to properly "convince" macOS to do IPv6 DNS lookups when your only IPv6 address is via a VPN or tunnel of some sort. We're not sure about Tunnelblick, when we tested in 2022 it could not do it. Kind regards

Hello! This happened in the past indeed, but it was an error promptly resolved by Bell, although intermittent problems with Cloudflare have been reported again throughout the recent past years by Bell users. You should contact Bell just in case some error again prevents reaching 1.1.1.1 and other Cloudflare DNS (assuming that the block does not come from Cloudflare of course). In the meantime do not use 1.1.1.1 for the healthcheck. https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md or for the server data updater. Kind regards

Hello! Different reasons come to mind (MITM packet injection, very noisy line, MTU related problem, bugs in the system or router stack when UDP traffic flow is high). Please: set WireGuard interface MTU to 1280 bytes in Eddie's "Preferences" > "WireGuard" window; if you connect via WiFi try to get a stronger signal and verify whether it's necessary to change channel; if you connect via Ethernet, test a replacement cable; make sure that your router firmware and your network interface driver are both up to date. Kind regards

Hello! Thanks for the thorough report. During the current tests with your own connection, we could verify that the port re-direction on the server is correct. On the other hand, your tcpdump output is quite clear. Therefore this could be a rare bug which does not always occur. Or you might have changed the "local" field of the port (in your AirVPN account port panel) while your connection was active. In this specific case the system can not change "on the fly" the pre-routing rules and requires a disconnection and re-connection. Please let us know whether the problem re-appears and/or persists even after a disconnection / re-connection. Kind regards