Staff

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

@Fragmented Sentinel Hello! Thank you for publishing your investigation and explaining the limits of what client-side testing can establish. We agree with the distinction between observing traffic on the client and verifying what happens to data on a provider's servers. Having reviewed version 1.0, we would like to suggest a few clarifications to help readers understand exactly what was tested and what the results establish. 1. Identify the firewall that failed The setup uses wg-quick with a separate persistent nftables ruleset. The reported boot failure concerns that local ruleset; the experiment does not demonstrate a failure of Eddie or Network Lock. Section 10 makes this distinction, but it would help to state it in the abstract and Section 3 as well. For example: "The test VM's custom persistent nftables firewall failed to load at boot." If the origin of those rules is known, please identify it. The comparison with RTINGS should specify the client version, operating system and startup conditions involved. A result from this custom Linux configuration can't confirm or refute the behavior of a different client setup. 2. Separate IPv6 connectivity from IPv6 firewall enforcement The successful IPv6 request through the tunnel demonstrates IPv6 connectivity through AirVPN in the tested configuration. However, "Network unreachable" on the direct-interface test could also mean that the VM had no usable non-VPN IPv6 route. Without a baseline demonstrating a working alternative IPv6 path, the supported conclusion is that no IPv6 escape was observed in this environment. Establishing that the firewall blocked an otherwise viable connection requires that additional control. The VMware NAT configuration is relevant here and should be documented. 3. Distinguish reboot persistence from protection throughout startup Finding the expected rules and service state after reboot supports persistence. It does not, by itself, establish that no traffic escaped during shutdown or startup. The systemd directives also need to be considered together with the complete unit dependencies. network-pre.target is passive and must be pulled into the transaction; the network-management service must participate in the ordering. Ordering alone does not make successful firewall loading a prerequisite for networking. https://systemd.io/NETWORK_ONLINE/ A capture from outside the rebooting VM, covering the whole transition, would provide stronger evidence. This is a limitation of the published evidence, not a finding that the repaired configuration leaks. 4. Identify how DNS settings were applied WireGuard itself does not negotiate or push DNS settings. In a wg-quick setup, those settings are applied locally through the profile and through supporting tools or hooks. Please specify the mechanism that configured systemd-resolved, including the ~. routing domain. https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8 The ~. domain is also not an unconditional guarantee of exclusive DNS routing through one link: the complete resolver configuration matters. This does not invalidate the capture results for the queries you tested. Ordinary DNS carried inside the encrypted tunnel is not, merely because it is ordinary DNS, a DNS leak. 5. Make the experiment reproducible The reviewed deposit provides the paper and representative commands, but not the underlying artifacts. Sanitized original and repaired firewall rules, the WireGuard profile, software versions, routing and resolver state, service dependencies, and capture records would make independent checking much easier. Capture duration and dropped-packet statistics are useful too. For the infrastructure identification, please include the relevant public-address lookup records. Address registration, BGP origin and a DNS identity string are different kinds of evidence; none alone establishes physical placement. 6. Keep the no-logging conclusion within its evidential scope We agree that these tests cannot establish server-side non-retention, and that the absence of a published audit does not demonstrate logging. Provider statements, published source code, historical reports and operational audits should be assessed separately. Source availability does not prove what is deployed. Historical claims need supporting records. An audit has a defined scope and period rather than establishing a permanent guarantee. The central observation remains useful: after the local firewall was repaired, the reported tests found that the examined configuration carried the tested traffic through the VPN. These clarifications would make the attribution more precise and help others reproduce and extend your work. Kind regards