Staff

@macuser2 Hello! Can you please test Eddie 2.24 beta version and check whether or not the problem persists? https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! Can you please try again and report back? Kind regards

Hello! Thank you very much for your tests! We're very pleased to receive confirmation that this version solves those problems. Network Lock does not survive, but it is re-enforced before any new socket can be created, so no leak occurs. This is exclusively up to systemd: apart from writing correctly the suspend and resume unit files there's nothing else we can do, we're afraid. Kind regards

Hello! We have found a problem with WireGuard in one USA server, Polis. Perhaps when you experienced the problem, us3.vpn.airdns.org resolved into Polis entry-IP address. We have resolved the problem on Polis. Can you please try again now? If you experience the problem please note the specific server and let us know. Kind regards

Hello! We're very glad to inform you that Hummingbird 2.0.0 beta 1 for macOS (Mojave or higher version required) is available. Different native versions for Intel and M1/M2 based Mac computers are available for maximum performance. UPDATE 2025-04-05: Hummingbird 2.0.0 beta 5 for macOS is available UPDATE 2025-04-16: Hummingbird 2.0.0 Release Candidate 1 for macOS is available UPDATE 2025-06-10: Hummingbird 2.0.0 Release Candidate 2 for macOS is available Hummingbird is free and open source released under GPLv3: https://gitlab.com/AirVPN/AirVPN-Suite Main features Lightweight and stand alone binary client supporting both OpenVPN and WireGuard No heavy framework required, no GUI Small RAM footprint Lightning fast Based on OpenVPN 3 library fork by AirVPN and WireGuard Robust leaks prevention through Network Lock based on pf Proper handling of DNS push by VPN servers New, more flexible Network Lock What's new linked against OpenVPN3-AirVPN 3.11 library all libraries and dependencies have been updated added complete WireGuard support by means of the official WireGuard tools provided by its developers. Installation of wg and wireguard-go binaries is currently required, as WireGuard library is not available on macOS. Please check the user's manual (README.md file included in the packages) WireGuard support section for comfortable, step by step instructions. new Network Lock related options offering more flexibility. Now you can accept or deny incoming, outgoing or both ICMP-echo packets, and independently you can permit or forbid IPv6 NDP, which is based on ICMPv6. The new options supported by Hummingbird (please check the readme file for additional details) are: --allow-ping --allow-ipv6ndp Apple ARM based systems version is now C++20 compliant (required by Sequoia) Important note for high speed line users Because of some architectural specifications and implementation in macOS Hummingbird may warn the user about shortage of buffer space, specifically when connected with the UDP. This condition is signaled by Hummingbird with the below messages in the log: UDP send exception: send: No buffer space available ERROR: NETWORK_SEND_ERROR The error is caused by the maximum network sockets size set in macOS, a value usually small and unsuited for modern high speed networks. The solution consists in increasing the maximum allowed size for socket buffers and, in case the problem persists, the number of mbuf clusters. The procedure is simple, please find out all the details in the manual. Open the README.md file with any viewer and consult the "Note on macOS and UDP" section. Download the software here: Apple silicon ARM based machines notarized package: https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-arm64-notarized-2.0.0-RC-2.zip https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-arm64-notarized-2.0.0-RC-2.zip.sha512 Apple silicon ARM based machines package: https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-arm64-2.0.0-RC-2.tar.gz https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-arm64-2.0.0-RC-2.tar.gz.sha512 Apple Intel based machines notarized package: https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-x86_64-notarized-2.0.0-RC-2.zip https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-x86_64-notarized-2.0.0-RC-2.zip.sha512 Apple Intel based machines package: https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-x86_64-2.0.0-RC-2.tar.gz https://eddie.website/repository/hummingbird/2.0-RC2/hummingbird-macos-x86_64-2.0.0-RC-2.tar.gz.sha512 Kind regards & datalove AirVPN Staff

Hello! We're glad to inform you that AirVPN Suite 2.0.0 Beta 1 is now available. What's new update of all libraries OpenVPN linked against OpenSSL 3 in every package (dynamically linked in non-legacy packages, statically linked (3.3.0) in legacy packages in order to operate on those systems still not offering OpenSSL 3) improved WireGuard support and management Goldcrest and Bluetit asynchronous connections and Network Lock suspend / resume service for Bluetit in systemd based systems rewritten network availability detection options autocompletion by pressing the TAB key on bash or zsh while entering a Goldcrest or Hummingbird command change of logic in the choice of servers in a specific country, no more using domain names (for additional safety against Tunnelcrack) ability to select whether Network Lock must allow or not communications within local network enhanced support to those IPv6-only networks, no more supporting IPv4 directly and working on IPv4->IPv6 address translation: Network Lock will now allow traffic to/from the translated addresses support for highly-hybridized systems running components causing a frequent mix up of nft and iptables rules (example: Fedora 39 and above) through Network Lock proper adjustments support for legacy 64 bit systems, both x86-64 and ARM (examples: Debian 11, Raspberry Pi OS 64 bit legacy) bug fixes The list of changes and new features is very long! Please check the various changelogs, available in the first post of this thread. Also check the new readme.md to test and use the new features. Kind regards & datalove AirVPN Staff

Hello! On the systems, of course! It is possible to disable it on the router too but that's ineffective in any case. If you don't control the router you just can't do it, as you correctly point out, but even if you control the router and then the rogue DHCP server is installed in your local network but it's a machine different from your router, it makes no difference that you disabled it on your own DHCP server (apart from the fact that if the attacker gains control of your router, he/she can re-enable all DHCP options). Kind regards

Hello! As reported in the very informative and well written article, provided that unfortunately the adversary has the ability to crack your local network and install inside it an evil DHCP server, an excellent mitigation is based on firewall rules exactly as they are enforced by AirVPN's Network Lock. Kill switches are ineffective as usual, nothing new here, but Network Lock greatly mitigates the problem. This mitigation is very hard to circumvent, as it would require traffic analysis first and more operations later (check "Problems with Firewall Rule Mitigations" in the article). Please note that traffic splitting MUST be avoided, otherwise firewall rules of Network Lock will have exceptions which can be in themselves a dangerous enlargement of the surface attack and that can be again exploited by TunnelVision. As a double protection, you may consider to disable DHCP option 121, an option which can be reported even as “Disable Classless Static Route”. Without DHCP option 121 the attack lacks its essential pre-requisite. Check the downsides, though. We will have the paper investigated by independent reviewers in the next days and if anything relevant on top of all of the above comes out we will publish it. Kind regards

Hello! Please try to switch to WireGuard and test again with various MTU (ranging from 1280 to 1420 bytes). The option in WireGuard's configuration file to change VPN interface MTU is MTU = n where n is in bytes. The directive must be entered in the [Interface] section. Kind regards

Hello! The cached data are from MaxMind and nothing goes back to MaxMind or third parties. MaxMind's privacy policy may apply to the MaxMind's data related to their IP addresses database and ipleak.net administrator's account used to retrieve info, not to users browsing ipleak.net. Kind regards

Hello! Please verify whether or not it's a false positive: disable DNS check in "Preferences" > "DNS" by unchecking "Check Air VPN DNS" click "Save" disable route check in "Preferences" > "Advanced" by unchecking "Check if the VPN tunnel works" click "Save" start again a connection with Network Lock enabled if the connection goes through verify the DNS servers your system queries on https://ipleak.net If no data pass through after the above modifications then the check failure was not a false positive and the tunnel did not work for real, therefore you must look into why the tunnel does not work (some options include ISP blocks against specific protocols, unintended firewall blocks either in your system or router). If everything works fine, then the check failure was a false positive, a rare but not impossible occurrence in Eddie Desktop edition. Kind regards

Hello! Please check DNS settings whole Eddie is not running: https://serverguy.com/kb/change-dns-server-settings-mac-os/ It's possible the Eddie failed to restore system DNS settings after a session was concluded. Set public DNS and test again. If you need a suggestion, we recommend Quad9 (9.9.9.9) and OpenNIC (195.10.195.195 and other, please see https://www.opennic.org ) for their commitment to privacy and neutrality. Kind regards

Hello! Apart from the obvious case of wrong answer, an endless CAPTCHA cycle can be caused by the browser changing transmitted details at each page load. Add-on aimed at preventing any type of fingerprinting will cause you enter such endless cycles, especially when in synergy with IP addresses not assigned to residential ISPs. Kind regards

Hello! We can't reproduce at the moment... Does this problem occur only with github.com? What performance do you get with downloads from other sources? And with an HTTP based speed test? Which server(s) do you connect to? Kind regards

Hello! The problem is Android-related and not VPN client related. However, Eddie has an option which will prevent this leak, "VPN Lock". Please note that this option will not allow Eddie to re-connect and/or re-configure the tunnel, which is the exact reason for which leaks are prevented. When Google solves this Android problem you can then disable "VPN lock" and rely again on Android built-in leaks prevention. Please note that "VPN Lock" is disabled by default, so you must activate it from the "Settings" > "VPN" view. We totally agree with Mullvad when they write, in the article you linked,"Depending on your threat model this might mean that you should avoid using Android altogether for anything sensitive". Remember also that an overwhelming amount of evidence suggests that iOS and Android were designed to be primarily profiling and surveillance devices, so it's an antimony to use such a device to enhance privacy or create a layer of anonymity. Kind regards

Hello! UDP seems blocked. Please check any packet filtering tool both on your system and router and make sure they don't block UDP. If the block is enforced by your ISP then you must use only TCP (or change ISP, of course). By the way please test WireGuard. WireGuard works in UDP only but it is possible that the UDP block is only toward some ports. To switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select the line with WireGuard, port 51820 (picking a high port, which is also WireGuard's official port, can reduce likelihood of blocks). The line will be highlighted click "Save" and test again connections to various servers Kind regards

Hello! The problem should be resolved and we have re-opened Turais. Please let us know in case you find any anomaly or malfunctioning. Kind regards

Hello! We will consider seriously the suggestion, thank you. Kind regards

Hello! We think WireGuard developers are correct, as you can't allow some traffic outside tunnel AND block all traffic outside the tunnel. Therefore that option correctly disappears. You can consider to block traffic leaks (except for the local network) with firewall rules. Kind regards

Hello! No worries, as loopback is directly connected. For the same reason "everything works" when you specify in AllowedIPs the whole IPv4 space with 0.0.0.0/0, which is the default settings in so many configurations. Kind regards

@Greyzy Hello! The solution is relatively simple when you use a subnet calculator: you must tell WireGuard that some subnet (in this case your local network) must NOT fall into the VPN tunnel through the AllowedIPs directive. The AllowedIPs directive in the WireGuard *.conf file lists the set of IP addresses that the local host should route to the remote peer through the WireGuard tunnel. By constructing from the global address space the complementary set of the range of your subnetwork you will solve the problem. Please read the following thread for more complete explanations and definite solution: https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?tab=comments#comment-217411 Kind regards

@lil_bedigas Hello! Network Lock is a set of firewall rules which is not persistent, so a reboot should have solved the problem. Maybe the problem is DNS related (DNS settings are in fact persisting throughout system restarts), please check DNS settings in your system. For a more specific support can you please tell us your Operating System name and version? It is strange that Eddie is unable to restore the previous settings when you re-run it and shut it down properly, but the issue happens sporadically and it will be investigated. Kind regards

Hello! Please check the following guide to use resolvectl instead of the command you don't have (probably it's no more necessary) and for a more comprehensive approach: https://www.linuxinsider.com/story/be-it-resolved-systemd-shall-serve-dns-177275.html To understand the several systemd-resolved working modes you can also consult the documentation here: https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html Kind regards

@torrenttorment Hello! So you have connectivity but the system can't resolve names. Something must have gone wrong when you configured OpenDNS, please check and re-configure according to your system setup. Note: if you're running systemd-resolved (if we're not mistaken Mint distributions come pre-configured with systemd-resolved running) please see also here if necessary: https://notes.enovision.net/linux/changing-dns-with-resolve Kind regards

@torrenttorment Hello! From your description we can't discern whether your system can't resolve names or doesn't have Internet connectivity at all. What happens for example with the following commands: ping -c4 google.com ping -c4 8.8.8.8 Feel free to send the whole output. Kind regards