Staff

Hello! Windows can be configured to set time zone automatically according to the presumed location of the device. One of the factors to determine the location is the geo-location of "your" public IP address, which may be correct or wrong. The feature was added in November 2022 and has been repeatedly reported as buggy or not working at all in Microsoft support forums. The configuration can be managed in Settings > Time & Language > Date & Time. Kind regards

Hello! Please open a ticket at your convenience for this request. Very glad to know it and thanks for the additional information. Kind regards

@ogvickmackie Hello! Please check this: https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?tab=comments#comment-231319 If the problem persists, please generate and send a system report: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@johannawellick Hello! We have seen from past reports that Radmin VPN causes the UDP block you are experiencing and which seems the reason of the problem. Can you please disable Radmin VPN and test again? We infer that you have that VPN active as the following interface is up: "Radmin VPN (Famatech Radmin VPN Ethernet Adapter)". Kind regards

Hello! That's defined on the Plex settings. In your specific case this is not relevant because you have the remote port *2866 forwarded to your VPN interface port 32400, so port *2866 never comes into play in your system and everything works. You don't need any modification. Kind regards

@johannawellick Hello! Can you please include a system report generated by Eddie just after a connection attempt failed? https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@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. WARNING: Please note that Hummingbird 2.0.0 beta version is in a development stage. Therefore, the software may have bugs potentially causing critical and unstable conditions. If you feel adventurous and you wish to be a beta tester, please do not hesitate to report any bug or glitch you find in this thread. 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 What's new linked against OpenVPN3-AirVPN 3.9 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. 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 M1/M2 based machines notarized package: https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-arm64-notarized-2.0.0-beta-1.zip.sha512 https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-arm64-notarized-2.0.0-beta-1.zip Apple M1/M2 based machines package: https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-arm64-2.0.0-beta-1.tar.gz https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-arm64-2.0.0-beta-1.tar.gz.sha512 Apple Intel based machines notarized package: https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-x86_64-notarized-2.0.0-beta-1.zip https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-x86_64-notarized-2.0.0-beta-1.zip.sha512 Apple Intel based machines package: https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-x86_64-2.0.0-beta-1.tar.gz https://eddie.website/repository/hummingbird/2.0-Beta1/hummingbird-macos-x86_64-2.0.0-beta-1.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