Leaderboard

@after_lunch Hello! Thank you for the complete report, it shows what is happening. Your Wi-Fi adapter gets its DNS servers from your router: 194.168.4.100 and 194.168.8.100, which are your ISP's resolvers. Eddie 2.26.2 sets the AirVPN DNS (10.128.0.1) only on its own adapter, and in some circumstances its DNS leak protection fails to block queries sent to the resolvers of the other adapters. This is a known bug of 2.26.2, and your report matches it: Network Lock is active and the log says "DNS leak protection with packet filtering enabled", yet Windows still reaches your ISP's resolvers. You can solve it in one of two ways: 1. Stay on 2.26.2 and apply a workaround: open Eddie's Preferences > DNS, enable "Force all network interfaces for DNS", save, then disconnect and reconnect. OR 2. Upgrade to Eddie 2.27.2 beta, which contains the fix: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Then repeat the test on ipleak.net while connected: only AirVPN DNS servers should be listed. If your ISP's resolvers still appear after the workaround, please switch to 2.27.2, and if they persist there too, post a new system report. About hiding long text: the forum does not convert spoiler tags typed by hand. Use the Spoiler button in the editor toolbar and paste the text inside the box that appears, or simply attach the report as a .txt file. Kind regards

Hello! Please ignore our previous message in this thread: it was meant for another topic. Deleted. This error is caused by a bug of Eddie 2.26.2 (and earlier) on macOS. To check the application's integrity, Eddie stores a small file in the system folder /Library/PrivilegedHelperTools. On Macs where that folder does not exist yet, because no other application has created it, the file cannot be saved and Eddie refuses to start with exactly this message. The bug is fixed in Eddie 2.27.2 beta. Please download it from here: https://airvpn.org/forums/topic/81340-eddie-desktop-edition-227-beta-released/ Select the right package for your Mac (Apple Silicon or Intel), quit Eddie, copy the new Eddie into your Applications folder replacing the old one, then open it from Applications. Your settings are kept. If the error still appears with 2.27.2, please post the complete message: this version also prints the reason of the failure in parentheses, which tells us what is going wrong. Kind regards

Hi, wow, thank you very much for the incredibly fast and detailed response! CASE CLOSED. That clears things up completely. I will use 10.128.0.1 as the DNS server and DNAT target for my WireGuard setup from now on. Also, thank you for acknowledging that the current Specs page is somewhat misleading regarding 10.4.0.1 and WireGuard. Looking forward to the updated documentation. I also appreciate the additional explanation regarding DNS leak prevention and making sure DNS traffic cannot fall back to WAN. My OPNsense rules are already designed around that principle. Overall very happy with the support and I'll happily renew for another three years when the Cyber Deal becomes available again. 🙂 Cheers!

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