Staff

Hello! With Bluetit's network lock active, this cannot work, but there is a different approach that is well worth trying. Why the pods become unreachable: Bluetit's network lock is a kill switch for the whole host. It sets the default policy of the FORWARD chain to drop and only accepts forwarded traffic coming from the VPN tunnel. Pods that don't use hostNetwork are reached through forwarding (LAN or ingress, then NAT to the pod address on the cni0/flannel interfaces), so their traffic is dropped, while hostNetwork pods use the host's own input/output path and keep working. The "allow private network" exception only covers input and output on the host, not forwarding, and when the lock is applied Bluetit replaces the whole firewall ruleset, k3s rules included. There is no Bluetit option to exempt container interfaces or forwarded traffic. The better approach is to turn it around: leave the host and k3s outside the VPN, and put only Firefox and BiglyBT inside it, in a dedicated network namespace whose only way out is a WireGuard interface. If the tunnel goes down, the applications in the namespace simply have no network, so you get a kill switch by design without touching the host firewall, and k3s, the Cloudflare tunnel and your LAN are not affected at all. Please note that this is a suggestion we believe is worth a try, but we have not tested it on a setup like yours, so treat it as a starting point and let us know what happens. 1. Generate a WireGuard configuration file with our Configuration Generator (Client Area > Config Generator, Linux, WireGuard, one specific server) and save it, for example, as /etc/wireguard/airvpn.conf. Take note of the Address, DNS and MTU lines in its [Interface] section. Stop Bluetit or at least disable its network lock. 2. Create the namespace and the tunnel, as root and in bash (the wg setconf line uses a bash feature that plain sh does not support). The WireGuard interface is created and configured in the main namespace, so its encrypted UDP traffic leaves through your normal connection, and then it is moved into the namespace: ip netns add vpn ip -n vpn link set lo up ip link add wg0 type wireguard wg setconf wg0 <(wg-quick strip /etc/wireguard/airvpn.conf) ip link set wg0 netns vpn ip -n vpn addr add <IPv4 Address from the file> dev wg0 ip -n vpn addr add <IPv6 Address from the file> dev wg0 ip -n vpn link set wg0 mtu <MTU from the file> up ip -n vpn route add default dev wg0 ip -n vpn -6 route add default dev wg0 mkdir -p /etc/netns/vpn echo "nameserver 10.128.0.1" > /etc/netns/vpn/resolv.conf Use the Address and DNS values from your own file if they differ. "ip netns exec" mounts /etc/netns/vpn/resolv.conf in place of /etc/resolv.conf, so programs in the namespace use our DNS through the tunnel. Please also check that the "hosts:" line in /etc/nsswitch.conf does not contain "resolve": that module asks systemd-resolved on the host directly and would bypass the namespace resolver. 3. Check that it works: ip netns exec vpn wg show ip netns exec vpn curl https://ipleak.net/json/ wg show should report a recent handshake and curl should show the AirVPN exit address. 4. Start the applications inside the namespace, as your normal user: sudo ip netns exec vpn sudo -u $USER env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY WAYLAND_DISPLAY=$WAYLAND_DISPLAY XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR firefox --no-remote -P vpn --no-remote and a separate profile (create "vpn" once with firefox -P) are important: otherwise, if Firefox is already running outside the namespace, the command just opens a new window of the existing instance, outside the VPN. The snap version of Firefox shipped with Ubuntu may not like being started this way; if it fails, the Mozilla .deb or tarball build should behave better. BiglyBT can be started the same way. If you use port forwarding, set the forwarded port from your Client Area as BiglyBT's incoming port: it reaches the namespace through the tunnel. To remove everything: ip netns del vpn (wg0 is deleted with it). The commands in step 2 can later go into a small script or systemd unit to run at boot. As an alternative for BiglyBT only, since you already run k3s: you can run it as a pod together with a VPN sidecar container such as Gluetun configured for AirVPN WireGuard, so that the pod can only reach the Internet through the tunnel. Firefox would still need the namespace approach above. Please let us know how it goes, especially if something in the steps above needs adjusting on your system. Kind regards

@183aTr78f9o Hello! Thank you for the very detailed report, and sorry for the long wait. Your analysis was right: the problem is that Bluetit assumes a standard filesystem layout (FHS), which NixOS doesn't provide. We checked the Suite source code and there are two specific causes: 1. Bluetit does not use PATH to find external tools (systemctl, nft, iptables, ip...). It only looks in a fixed list of directories: /bin, /usr/bin, /sbin, /usr/sbin, /usr/local/bin and /usr/local/sbin. That's why Environment=PATH=... had no effect and why your symlinks in /bin worked. 2. Before loading the WireGuard module, Bluetit requires /lib/modules/$(uname -r)/modules.builtin to exist, and it fails if the file is missing, even when the module is already loaded. On NixOS the modules live in /run/booted-system/kernel-modules/lib/modules, so you get "system 'modules.builtin' does not exist" and "cannot load wireguard system module". Until these assumptions are relaxed upstream (but for point 1, probably they will not be implemented for security reasons), you can work around both of them declaratively, without manual symlinks in /bin. Below is a reworked version of your module (Suite 2.1.0, x86_64). Please note that this reworked version has been generated through an LLM, verified by human, but we have not been able to test it in depth on a NixOS machine, so please treat it as a starting point: { config, lib, pkgs, ... }: let version = "2.1.0"; suite = pkgs.stdenv.mkDerivation { pname = "airvpn-suite"; inherit version; src = pkgs.fetchurl { url = "https://eddie.website/repository/AirVPN-Suite/${version}/AirVPN-Suite-x86_64-${version}.tar.gz"; hash = lib.fakeHash; # replace with the hash reported by the first build }; nativeBuildInputs = [ pkgs.autoPatchelfHook ]; # no need for nix-ld buildInputs = with pkgs; [ dbus openssl stdenv.cc.cc.lib zlib xz zstd ]; installPhase = '' install -Dm0755 bin/bluetit $out/sbin/bluetit for f in goldcrest hummingbird airsu; do install -Dm0755 bin/$f $out/bin/$f; done install -Dm0644 -t $out/share/airvpn etc/airvpn/* install -Dm0644 -t $out/share/dbus-1/system.d etc/dbus-1/system.d/* install -Dm0644 -t $out/share/zsh/site-functions etc/site-functions/* ''; }; # tools Bluetit looks up in the fixed directories tools = [ "systemctl" "resolvectl" "ip" "nft" "iptables" "iptables-save" "iptables-restore" "ip6tables" "ip6tables-save" "ip6tables-restore" ]; in { environment.systemPackages = [ suite ] ++ (with pkgs; [ nftables iptables iproute2 ]); users.groups.airvpn = { }; services.dbus.packages = [ suite ]; # replaces your activation script boot.kernelModules = [ "wireguard" ]; systemd.tmpfiles.rules = [ "d /lib 0755 root root -" "d /usr/local/sbin 0755 root root -" "L+ /lib/modules - - - - /run/booted-system/kernel-modules/lib/modules" ] ++ map (b: "L+ /usr/local/sbin/${b} - - - - /run/current-system/sw/bin/${b}") tools; # Keep your environment.etc entries for /etc/airvpn, using # source = "${suite}/share/airvpn/<file>" and mode = "0600". # Keep your systemd.services definitions, but drop the Environment=PATH line. } A few notes: The symlinks go into /usr/local/sbin, which Bluetit searches and NixOS does not manage, and systemd-tmpfiles recreates them at every boot, always pointing to the current generation. Remove the manual ones you created in /bin. /lib/modules points to the booted system, so it always matches the running kernel (uname -r), including after a kernel update until you reboot. autoPatchelfHook links the binaries against Nix store libraries at build time, so nix-ld is no longer needed for the Suite. Please use nftables for the network lock (networklock nftables, or networklockpersist nftables in bluetit.rc). Your log shows that the nftables lock initialized correctly, while the iptables restore failed. If Bluetit still reports "Command not found" (your log showed two of them before the network filter step), add the missing tool names to the tools list above. Running "journalctl -u bluetit" should show which feature failed. Cuckoo is only needed for per-application traffic splitting, so we suggest leaving it out for now. It must run setuid root, which is not possible inside the Nix store: store paths are immutable, built by unprivileged users, and Nix strips setuid bits and ownership from every file it adds. That is why your chown and chmod u+s failed. The NixOS way is security.wrappers: at every activation, NixOS creates a small setuid wrapper in /run/wrappers/bin, outside the store, with the owner, group and permissions you choose, and the wrapper starts the real binary from the store with root privileges. This is the same mechanism NixOS uses for sudo and ping. The next Suite release changes Cuckoo's installation requirements (it will be executable only by members of the airvpn group), and we will try to post the matching security.wrappers configuration then. Please let us know how it goes. If it works for you, your module could become a useful reference for other NixOS users. Kind regards

Hello! We reluctantly have to announce gloomy news to you all: Spooky Halloween Deals are now available in AirVPN... Save up to 74% on AirVPN longer plans (*) (*) When compared to 1 month plan price Deal will expire on 2026-11-03 UTC Check all plans and discounts here: https://airvpn.org/plans If you're already our customer and you wish to jump aboard for a longer period with this un-boo-lievable deal, any additional plan will be added on top of already existing subscriptions and you will not lose any day. Every plan gives you all the features that made AirVPN a nightmare for snoopers and a scary service for competitors. Just check this frighteningly long list of terrific features if you dare: a clear mission without compromises https://airvpn.org/mission exclusive and comfortable remote inbound port forwarding system flexible, opt-in block lists against malware and other hostile entities. Pick predefined lists, add exceptions or additional blocks, define your own lists, or just use our totally neutral DNS by default improved API functions to let you control and configure VPN features and account settings WireGuard integration AmneziaWG support in Eddie Android edition, with traffic mimicry of real websites (QUIC) to defeat DPI-based VPN blocking. This year our traffic wears a costume too: with AmneziaWG on Eddie Android, your connection goes trick-or-treating dressed up as an ordinary website, and DPI won't recognise who's behind the mask. Security-hardened Eddie Desktop edition Strong infrastructure growth: about 25% more total capacity in one year. Our servers grew by a ghastly 25% this year: more bandwidth to haunt the Internet at full speed. IPv6 support, including IPv6 over IPv4 and IPv4 over IPv6 refined load balancing to squeeze every last bit per second from VPN servers free and open source software for Android, Linux, Mac and Windows offering advanced features easy "Configuration Generator" web interface for access through third party software guaranteed minimum bandwidth allocation GDPR compliance and very high privacy protection standards no log and/or inspection of clients' traffic effective traffic leaks prevention by AirVPN software Tor support via AirVPN software on Linux, Mac and Windows various cryptocurrencies accepted without any intermediary no obligation to use our free and open source software to enter AirVPN infrastructure. Interoperability is an AirVPN priority. perfectly clear and easy to read Privacy Notice and Terms https://airvpn.org/privacy No tricks, only treats! We witch you a spooktacular Halloween AirVPN Staff

Hello! A quick follow-up on the WireGuard session counter issue mentioned above. The cause has been identified and fixed, and the fix is currently being rolled out across our infrastructure. Servers that have already received the update are back to reporting accurate figures, and the remaining ones will follow shortly, so the connection counts shown in the server monitor and in the related statistics will match reality again in the very near future. As previously stated, actual connections and the service itself have never been affected, only the displayed counter was. Kind regards

Thank you all for the valuable feedback. Following this thread, we have identified a bug, most likely introduced on October 7th-8th, which causes the WireGuard session counter on some servers to grow incorrectly over time. As a result, the number of connections currently shown in the server monitor is higher than the real one. The actual connections, and the service itself, are not affected. We are working on a fix and will update this thread as soon as it is in place. On a side note, this also means that our no-overselling commitment is honoured by an even wider margin than the one computed by @fsy Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in New York City, USA, is available: Hiisi. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Hiisi supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor , by clicking the server name. Direct link: https://airvpn.org/servers/Hiisi Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff Photo by John Dillenbeck (Public Domain)

Hello, You do not need to travel or do anything illegal to have a reason to use a VPN. In addition to the points already mentioned by pHxaq, there are some practical uses: Accept incoming connections behind CGNAT. If your ISP does not provide a publicly reachable IPv4 address, a VPN with port forwarding can make selected services reachable through its servers. This can help with self-hosting, game servers or peer-to-peer applications, including sharing Linux distributions. AirVPN provides this feature; not every VPN does. Any exposed service still needs appropriate authentication and security. Work around routing problems. A VPN changes the route your traffic takes. This can sometimes avoid poor ISP peering or a problematic path to a destination. It is not a guaranteed speed improvement and cannot fix congestion on your own access line. Protect more than browser traffic. A properly configured VPN can cover applications and system services as well as your browser, adding encryption between your device and the VPN server. HTTPS and other end-to-end encryption remain necessary: the VPN tunnel does not extend all the way to every destination. Reduce interference by the local network. For traffic carried inside the tunnel, the network operator or wiretapping entities have less ability to inspect and no possibility to alter application requests or DNS queries or traffic content (no possibility of injecting forged packets). This can be useful even without travelling. For your de-Googling goal, a VPN is a complementary tool: it does not stop a logged-in service from recognizing you, remove tracking cookies, or prevent browser fingerprinting. Choosing applications and services that collect less data remains important. You also shift trust from your ISP to the VPN provider, rather than eliminating the need for trust. Whether you need one depends on which benefits matter to you. Linux and privacy-conscious applications are useful choices, but they address quite different parts of the problem. More information: https://airvpn.org/faq/port_forwarding/ https://ssd.eff.org/module/vpn.html Kind regards

Hello! Yes. To select another server automatically, exclude the current server when starting a new connection. For example, if you are connected to Comae: goldcrest --disconnect goldcrest --air-connect --air-black-server-list Comae Wait for disconnection to complete before running the second command. Replace Comae with your current server’s name. --reconnect alone does not request a different server. Alternatively, after disconnecting, choose a replacement explicitly: goldcrest --air-connect --air-server SERVER_NAME Replace SERVER_NAME with the desired server name. IMPORTANT: your usual Goldcrest authentication and Bluetit’s server/country restrictions still apply. To make an exclusion persistent, add: air-black-server-list Comae to your Goldcrest configuration (~/.config/goldcrest.rc or ~/.goldcrest.rc, depending on your setup). If you configured a fixed air-server, change or remove it when you want automatic selection. Please read the user's manual: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/AirVPN-Suite/README.md#goldcrest-configuration Kind regards

Hello! We believe we have identified the main cause of the recurring Los Angeles connectivity issues and have deployed measures that may have resolved them. Our monitoring shows a clear improvement, but we would appreciate your help confirming the results in everyday use. Could you please test the Los Angeles servers again and let us know whether you still experience interruptions or traffic stalls? If an issue recurs, please include the server name and the approximate time with your time zone so that we can correlate it with our monitoring. Thank you in advance! Kind regards

Hello! Thank you for the additional details and for correcting the incident time to October 5 at 07:58 UTC. We found a matching IPv4 reachability alarm for Revati, so our investigation includes IPv4 as well as IPv6. Our capacity measurements rule out sustained server overload from “too many users” during the period reviewed. We checked all five Los Angeles servers over September 29 - October 6: Peak sampled total CPU utilization remained below 36% on every server. Memory utilization remained below 5.6%. Connection-tracking table occupancy remained below 61% of capacity. The highest traffic rate measured over approximately five-minute intervals was 6.1 Gbit/s in both directions (6.1 + 6.1 = 12.2), on 10 Gbit/s full-duplex interfaces. At the reported time, Revati's total CPU utilization was approximately 20–24%, and its connection-tracking table was about 30% full. These measurements show substantial capacity headroom. They do not, however, exclude very brief network events or issues affecting individual paths or queues. We are investigating the recurring connectivity interruptions internally and are evaluating involving the provider to help establish their cause. The cause has not yet been confirmed. As previously explained, a partial failure percentage across our monitoring probes can coincide with a complete interruption on a particular customer's path. We appreciate the reports you have provided. Kind regards

Hello! Thank you, that clarification helps. Since your tunnel endpoint is reached over IPv4, the recurring IPv6 pattern we mentioned does not explain your experience. We see ICMPv4 nearby packet-loss reports for the servers you named: Sarin at about 07:20 UTC and Revati at about 07:58 UTC. These are close to, but do not exactly match, the 07:35 UTC time you reported. They come from distributed monitoring probes, so they cannot confirm what happened on your particular route. Could you tell us which VPN protocol and client you use, and whether the VPN connection itself disconnected or stayed connected while traffic stopped? If available, please also share the connection log covering a few minutes around 07:35 UTC, with any keys or credentials removed. This should help us compare the event with the server and network records. Kind regards

Hello! We checked our infrastructure monitoring data and can confirm recurring connectivity issues, concentrated on our five Los Angeles servers, not on all West Coast servers though. The recorded issues predominantly affect IPv6. If your VPN tunnel is established over IPv6, it is indeed very likely that these incidents explain the temporary complete loss of connectivity you describe. The packet-loss percentage on the status page reflects results from multiple monitoring locations. A reading of around 30% does not mean that every connection loses 30% of its packets: connectivity from a particular network can fail completely while other paths remain available. Is your VPN tunnel established over IPv4 or IPv6? We mean the address used to connect to the VPN server, rather than whether you access IPv6 destinations inside the tunnel. Please also provide the affected server names and, if possible, an approximate incident time with your time zone, so we can correlate your experience with our monitoring. We apologize for the recurring IPv6 interruptions and we will open a request for investigation with the provider. Kind regards

Hello! For AirVPN WireGuard connections, the IPv4 gateway and DNS server address is 10.128.0.1. WireGuard uses a single IPv4 subnet, and this address remains the same regardless of which AirVPN server you connect to. Please keep 10.128.0.1 as your DNS DNAT target. 10.4.0.1 is an OpenVPN DNS address, and its availability through some WireGuard connections should not be relied upon. Your observation that it works through a German endpoint does not change the address to use with WireGuard. The reported difference alone does not establish a DNS outage on Dutch servers. You are also right about the documentation: our Specs page describes 10.4.0.1 as reachable from any virtual subnet without explicitly restricting that statement to OpenVPN. That wording is misleading for WireGuard users, and we apologize for the confusion. We will assess the situation and either clarify the Specs page or make 10.4.0.1 consistently reachable for DNS queries through WireGuard on all servers (not recommended anyway, see below). In any case, we recommend using the VPN gateway address as the DNS server address, as AirVPN supports this configuration, with both OpenVPN and WireGuard. We recommend using 10.128.0.1 for WireGuard DNS and ensuring that DNS traffic can only leave through the VPN tunnel. Route-injection attacks on hostile networks can otherwise divert DNS queries outside the tunnel, exposing the requested domain names and potentially enabling forged DNS replies. This class of attack can also affect WireGuard deployments, depending on the operating system’s routing and firewall configuration. For your OPNsense setup, redirect the selected clients’ DNS traffic, both UDP and TCP port 53, to 10.128.0.1, ensuring that the redirected traffic is routed through the WireGuard tunnel. Firewall rules should prevent those clients from falling back to WAN when the VPN is unavailable. Port 53 redirection alone does not control applications using DNS over HTTPS or DNS over TLS. Your interpretation of the successful dig @10.4.0.1 test with DNAT targeting 10.128.0.1 is correct: it does not demonstrate that 10.4.0.1 itself answered. Kind regards

@1234asdfghjkl Hello! Alruba is now up. We have not been informed about the exact problem it suffered but we see that it's up and working fine. Kind regards

@1234asdfghjkl Hello! The server is completely unreachable. Even IPMI and KVM power cycle don't work. We're waiting for datacenter technicians feedback. We will keep you posted. Kind regards

Hello, This is expected behavior: our server in Estonia is currently down, so the domain name temporarily resolves to IP addresses of AirVPN servers in other countries. This fallback allows users with configuration files for Estonia to continue connecting while the Estonian server is unavailable. Kind regards

Hello! The problem with IPv6 has been almost resolved through a switch replacement. However, a moderate packet loss on ICMPv6 traffic persist, up to 2.5% as far as we can see. Datacenter technicians are still investigating but according to our tests all the Swiss servers are perfectly usable with IPv6 too, currently: TCPv6 records negligible packet loss / re-transmission < 0.5% Kind regards

Hello! @MasieX We mean Developer options in your phone’s Android settings. On Samsung Galaxy devices, open Settings → About phone → Software information, tap Build number seven times and enter your PIN if prompted. Samsung’s instructions: https://www.samsung.com/uk/support/mobile-devices/how-do-i-turn-on-the-developer-options-menu-on-my-samsung-galaxy-device/ Then open Settings > Developer options > Select mock location app and select Eddie. @UncleAdolf Could you please check that Eddie is selected under “Select mock location app”? Enabling Developer options alone does not complete this step. Android documents this setting here: https://developer.android.com/studio/debug/dev-options#debugging If Eddie is already selected and the error persists, please provide your phone model, Android version, Eddie version and the exact error message, so we can investigate further. Kind regards

@ThirdGazometric Hello! Your log shows that you are running Bluetit 2.0.0. Please upgrade to AirVPN Suite 2.1.0: the Bluetit version included in this release substantially improves network availability detection, which is directly relevant to the startup behavior you describe. Downloads and installation instructions: https://airvpn.org/suite/ Also, if the options in your post are written exactly as they appear in /etc/airvpn/bluetit.rc, please correct their syntax. Do not use an equals sign between a directive and its argument. Use one or more spaces, or a tab, instead: airconnectatboot quick networklockpersist on After upgrading and correcting the configuration, reboot and check whether Bluetit establishes the VPN connection automatically. Verify that the new startup log reports version 2.1.0. Since you report that Internet access remains available outside the VPN, please do not assume Network Lock is protecting your traffic while Bluetit is stuck in this state. Avoid sensitive traffic until the VPN connection and Network Lock are confirmed active. If the problem persists, please tell us your Linux distribution and version and post the complete Bluetit log from the affected boot: sudo journalctl | grep bluetit Kind regards

@trainwreck666 Hello! Thank you for the report and for explaining which Eddie versions you have already tried. Since newer Eddie versions do not work on your current system, you could try Tunnelblick 3.5.26, which is listed for OS X 10.4-10.9 on the developers' official download page: https://tunnelblick.net/downloadsDeprecated.html Please note that the developers explicitly warn that this legacy version contains serious security vulnerabilities. This is a temporary compatibility option, not a secure long-term solution. We recommend moving to a maintained operating system and current VPN software when possible. To try it: 1. Fully quit Eddie and install Tunnelblick 3.5.26. If downloading fails in your old browser, download it on a newer computer and transfer the installer. 2. Sign in to https://airvpn.org/generator/ and enable Advanced mode. Select the OpenVPN 2.4 profile, choose an IPv4 connection and your preferred server, then download the configuration. 3. Import the configuration into Tunnelblick, select its OpenVPN 2.4 engine for that connection, and try connecting. This bypasses Eddie's server list. An empty list in an old Eddie version does not necessarily mean that a standalone OpenVPN client cannot connect. If the connection fails, please post the Tunnelblick connection log. Kind regards

Hello! Thank you for the detailed suggestion. The main reason for this design is privacy. Sharing public exit IP addresses among many customers is one of AirVPN's foundational privacy features, and we deliberately preserve that property for IPv6 as well. Assigning a unique public IPv6 address to each customer or tunnel would make that tunnel's traffic distinguishable by its source address. Websites and other observers able to see multiple connections could use that address to correlate activity belonging to the same tunnel, even without knowing the customer's real identity. With a shared exit address, the address alone does not provide that distinction between customers. Changing the address on each OpenVPN reconnect, or rotating it periodically through Eddie, would reduce the time window for this correlation. However, throughout each address lifetime it would still identify one tunnel rather than be shared by many customers. Rotation therefore does not preserve the same privacy property. We understand the appeal of globally routable tunnel addresses and the compatibility concerns you raise. However, the availability of IPv6 addresses does not resolve this privacy tradeoff: assigning an exclusive public address to each customer would remove a fundamental characteristic of our service. If you have a specific application or reproducible IPv6 issue with the current setup, please share the details so we can examine that separately. Kind regards

Hello! Yes, you can use your laptop on your university's Wi-Fi while your home PC remains connected, using the same AirVPN account. Your devices do not need to be on the same network or in the same location. Each account allows up to five simultaneous VPN connections, so your example would use two of those five slots. If both devices connect to the same VPN server, each must use a different device/key, which you can manage in Client Area > Devices. For details: https://airvpn.org/faq/multiple_connections/ Kind regards

Hello! Thank you for reporting this and sharing the workaround. The distinction you found between working IP connectivity and failing hostname resolution is useful. The explanation is consistent with a DNS configuration problem inside the namespace. 127.0.0.53 is systemd-resolved’s local DNS stub address. Since a network namespace has its own loopback interface, that address inside aircuckoo does not reach the resolver running in the main namespace. Unless a resolver is also listening inside aircuckoo, DNS requests sent there cannot succeed. See the systemd-resolved documentation. https://www.man7.org/linux/man-pages/man8/systemd-resolved.service.8.html Providing reachable DNS servers through /etc/netns/aircuckoo/resolv.conf is therefore a reasonable workaround for the reported symptoms. The namespace-specific configuration mechanism is documented in ip-netns https://www.man7.org/linux/man-pages/man8/ip-netns.8.html, and Cuckoo also applies the namespace’s configuration files when launching an application. Two clarifications: This does not establish that Network Lock caused the problem. Disabling networklockpersist would not make the main namespace’s loopback resolver accessible inside aircuckoo. There is no need to disable that protection to address this DNS issue. Also, the Suite 2.1.0 manual documents networklockpersist as off by default. Please do not assume the manual DNS override will survive namespace recreation. Bluetit manages this directory and can remove and regenerate its contents during the traffic-splitting lifecycle. Cuckoo intentionally runs applications outside the VPN. DNS requests made to Cloudflare or Google through this configuration also follow the non-VPN path; choosing those resolvers changes who receives the queries. To investigate why the stub address was selected, please share your distribution and Suite version, relevant traffic-splitting and Network Lock settings, and: readlink -f /etc/resolv.conf cat /etc/resolv.conf cat /etc/netns/aircuckoo/resolv.conf resolvectl status The Bluetit startup log, particularly the “Found system … DNS” entries, would also help. Please remove credentials and other sensitive information before posting. There is no need to undo the working workaround. Next Bluetit and Cuckoo versions will feature respectively a dedicated directive and option to set the DNS for the namespace. Kind regards

Hello! Any problem related to IPv4 seems resolved. IPv6 related problems persist. The warning on packet loss you can see on the servers monitor is caused by IPv6 related problems: intermittent but very frequent packet loss. These problems do not affect Athebyne, Dorado and Toliman. We are in touch with the dc engineers while investigating this problem. Kind regards

@19990909jp @alrosm@sbcglobal.net Hello! If you prefer to keep Windows 7 for now, you can still connect to AirVPN using OpenVPN 2.4.12 for Windows 7, independently of Eddie. The installer is available from the official OpenVPN archive: https://build.openvpn.net/downloads/releases/openvpn-install-2.4.12-I601-Win7.exe. Generate your configuration files using the AirVPN Configuration Generator, selecting compatibility with OpenVPN 2.4, then import the downloaded .ovpn files into OpenVPN GUI: https://airvpn.org/generator/. Please consider this a temporary workaround. OpenVPN 2.4.12 itself is no longer supported, as indicated here: https://community.openvpn.net/Pages/Supported versions. A long-term solution requires moving to a more modern, actively supported operating system, whether a supported Windows version, FreeBSD or a Linux distribution compatible with your hardware. Microsoft ended Windows 7 support in January 2020, and its Extended Security Updates programme ended in January 2023. Continuing to use Windows 7, especially for Internet access, exposes you to vulnerabilities that no longer receive fixes from Microsoft: https://learn.microsoft.com/en-us/lifecycle/products/windows-7 A VPN protects traffic through the VPN tunnel, but it cannot fix operating system vulnerabilities or protect your data from malware already running on your computer. Restoring the VPN connection does not eliminate these risks. Kind regards