Fragmented Sentinel

Thank you for taking the time to review the paper in this much detail. This is exactly the kind of technical criticism I was hoping the publication would generate, and I agree that several parts of v1.0 need to be either narrowed, clarified, or supported with stronger evidence. On the firewall point, you are correct. The failure I observed was in my own persistent nftables configuration used alongside wg-quick; it was not a failure of Eddie or Network Lock. I did clarify that later in the paper, but I agree that it should have been made explicit much earlier, including in the abstract and in the section describing the initial failure. I will correct that in the next revision and make the distinction much more prominent. I also agree with the IPv6 criticism. The successful IPv6 request through airvpn demonstrated working IPv6 connectivity through the VPN, but the direct-interface result of Network is unreachable does not prove that nftables blocked an otherwise viable IPv6 path. The correct conclusion from the existing evidence is that no IPv6 escape was observed in that VMware environment. I plan to add a proper control with a known-working non-VPN IPv6 path so that firewall enforcement can be tested independently of IPv6 availability. The reboot/startup point is also well taken. What I demonstrated was that the expected firewall and WireGuard state existed after reboot and that nftables was ordered before network-pre.target. That is evidence of persistence and service ordering, but not proof that no traffic escaped during the entire shutdown/startup transition. I plan to repeat this with a packet capture taken outside the VM, covering the full reboot, so that any traffic leaving the guest before the VPN becomes available can be observed directly. On DNS, I agree that my wording needs to be more precise. WireGuard itself is not negotiating DNS settings. In this configuration the DNS values are present in the wg-quick profile and are applied locally through the resolver integration. I already have evidence in the boot logs showing wg-quick invoking resolvconf, and I will document exactly how that results in the AirVPN resolver addresses and the ~. route-only domain being associated with the tunnel. I will also make it clear that ~. is part of the resolver-selection logic rather than an unconditional guarantee on its own. The packet captures remain the stronger evidence for the individual DNS queries that were tested. I strongly agree with the reproducibility point. Version 1.0 describes the experiment and includes representative commands, but it does not provide enough underlying material for someone else to independently inspect or reproduce the work. I plan to add a sanitized artifact set to the GitHub repository containing the original and repaired nftables configurations, a sanitized WireGuard profile, software versions, routing tables, resolver state, relevant systemd dependency information, infrastructure lookups, and packet captures where practical. I will also separate ARIN registration, BGP origin, reverse DNS, geolocation, and the AirVPN DNS identity more carefully rather than treating them as interchangeable evidence of infrastructure or physical placement. I also agree with the point about the no-logging conclusion. The absence of a published independent audit should be described as an evidence gap, not as evidence that logging occurs. Likewise, published source code, provider statements, historical reports, and audits all provide different kinds of evidence and should not be treated as equivalent. An audit would itself only establish findings within its defined scope and period, not provide a permanent guarantee. I intend to leave v1.0 intact as the original published record and incorporate these corrections, additional controls, and reproducibility artifacts into a v1.1 release. That way the revision history remains transparent rather than silently changing the original publication. Thank you again for the detailed review. The central goal of the project was to separate what I could directly observe from what I was assuming, and your feedback has identified several places where that distinction can be made substantially stronger.

I recently watched NetworkChuck’s video discussing what a VPN actually hides and, in particular, the idea that using a VPN shifts trust from the ISP to the VPN provider. I use AirVPN, so rather than treating that as a theoretical discussion, I decided to test my own setup and document what I could actually verify. The result turned into a fairly extensive lab exercise and eventually a short technical paper. My test environment was an Ubuntu VM using a manually configured AirVPN WireGuard connection rather than Eddie. I inspected Linux policy routing, captured traffic on both the physical and WireGuard interfaces, tested DNS behaviour, deliberately attempted IPv4 and IPv6 bypasses, forced applications to use the physical interface, tested hard-coded external DNS, stopped the VPN to test failure behaviour, and finally rebooted the VM to verify firewall ordering and persistence. One of the most useful findings actually had nothing to do with an AirVPN failure. My own custom nftables kill switch was broken. I had created a persistent nftables ruleset, but it used interface references that required the airvpn interface to exist when the firewall loaded. At boot, nftables started before WireGuard created that interface, so the firewall service failed. When I stopped WireGuard during testing, the VM silently fell back to its normal VMware NAT route and regained direct Internet access. That was a good reminder that having a security configuration present is not the same as demonstrating that it is operating. I corrected the ruleset to allow it to load before the WireGuard interface exists and then repeated the testing. After the repair, I tested: - IPv4 and IPv6 default routing through AirVPN - DNS visibility inside and outside the WireGuard tunnel - direct queries to the VMware/local DNS resolver - hard-coded DNS to 1.1.1.1 - applications explicitly binding to the physical interface - forced IPv4 and IPv6 escape attempts - WireGuard-down behaviour - reboot persistence - nftables/WireGuard boot ordering The hardened configuration failed closed as intended. The packet captures were particularly interesting. On the AirVPN interface I could plainly see normal DNS queries going to AirVPN’s internal resolver. On the VM’s physical interface, the same activity appeared only as encrypted UDP traffic to the AirVPN WireGuard endpoint. I could not see the individual DNS queries or direct connections to the websites being accessed. A hard-coded query to 1.1.1.1 also behaved as expected: it bypassed AirVPN’s DNS resolver, but did not bypass AirVPN itself. The DNS request still travelled through the WireGuard tunnel. I also queried the AirVPN resolver using CHAOS-class DNS records. version.bind returned "AirVPN DNS" and id.server identified the resolver as: unurgunite.airservers.org The server/network data pointed to the New York Unurgunite infrastructure on tzulo / AS11878. Using Akamai’s whoami.ds.akahelp.net resolver diagnostic, the recursive DNS egress appeared from the same IPv6 /64 as the VPN’s public IPv6 egress, although it was a different address. The response did not include an EDNS Client Subnet value. I also confirmed that the IPv4 WireGuard entry address and the public IPv4 exit address were different. The conclusion I came away with is slightly more precise than simply saying a VPN “hides metadata.” From the local/ISP side, AirVPN successfully hid substantial destination-related metadata. The ISP-side observer could still see the AirVPN endpoint, packet timing, sizes, traffic direction, volume and session duration, but could not directly see the individual DNS queries and destination connections carried inside WireGuard. That brings the investigation back to the trust question. Once traffic reaches the VPN endpoint, AirVPN is necessarily in a privileged network position. HTTPS still protects the application content end-to-end, but the VPN infrastructure is technically positioned to observe destination IPs, AirVPN DNS queries, timing and traffic volume. AirVPN states that it does not retain identifying traffic logs or inspect customer traffic, and a number of the architectural behaviours I could observe were consistent with a privacy-focused design. What I cannot verify externally is the production server-side logging configuration itself. That is the largest remaining evidence gap I identified: I could not find a published independent no-logs/infrastructure audit comparable to those some other VPN providers have commissioned. I would be particularly interested in clarification from AirVPN staff or anyone familiar with the infrastructure on a few points: 1. Does the resolver identified as unurgunite.airservers.org run directly on the same physical VPN host, or is the 10.128.0.1 service presented locally while recursion is handled elsewhere? 2. For the current tzulo New York servers, is the bare-metal hardware AirVPN-owned/colocated, rented dedicated hardware, or another arrangement? 3. Is an independent infrastructure/no-logging audit something AirVPN has considered or plans to pursue? 4. Is my interpretation of the separate entry/exit addressing and DNS architecture accurate, or is there anything important I have misunderstood? I’ve published the complete methodology, evidence, limitations and conclusions here: Paper / DOI: https://doi.org/10.5281/zenodo.22986653 GitHub: https://github.com/Fragmented-Sentinel/what-a-vpn-actually-hides The work is independent and is not affiliated with or sponsored by AirVPN, NetworkChuck, tzulo, or any other organization mentioned in the paper. I’d genuinely welcome technical corrections. The purpose of the exercise was not to prove that AirVPN is “good” or “bad,” but to separate what I could actually verify from what still depends on provider claims and trust.