Staff

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

@Greyzy Hello! The SSL connect error is fatal. It could be caused by some packet filtering tool blocking specific connections (please check) or some incompatibility with Windows 7. Please consider to upgrade to a more modern system, if possible. WireGuard availability in Eddie starts from version 2.21.2: if you're running an older version, WireGuard is not supported by Eddie. Also, maybe the support is missing in your Windows 7 and even if you run a more modern Eddie version it will be unable to offer WireGuard connections. Please consider, if possible, to upgrade to a more modern system. If for some sinister reason you are stuck with Windows 7 and want to try WireGuard but Eddie can't run it, you can consider the native software, which is still Windows 7 compatible for now. Instructions are available here: https://airvpn.org/windows/wireguard/gui/ Kind regards

Hello! Goldcrest looks for a configuration file named "off" and does not find it. This is due to Goldcrest's parser, as this particular usage is not permitted. Goldcrest, in the current command line example you gave us, needs a configuration file as a mandatory option (for example air-connect) is missing. So it finds off and considers it the name of the configuration file and not the argument of the network-lock option. We will consider to address the issue both on the program and the manual to provide more informative notes and proper error message. Back to your problem, if you have persistent Network Lock enabled in Bluetit you can't disable it through Goldcrest: by design, some Bluetit settings can not be overridden by Goldcrest commands for security reasons (more info on the user's manual). If a system administrator needs to disable persistent network lock, root must terminate Bluetit. Just before exiting, Bluetit "disables Network Lock", i.e. it restores previous system settings and firewall rules. DNS settings are a different, potential reason of the issue: please check your system DNS after you have terminated Bluetit and make sure that publicly reachable nameservers are set. Kind regards

Hello! WireGuard can't assign addresses dynamically so each address is linked to a single key. With multiple keys you will have multiple addresses. Please generate different keys in your AirVPN account "Client Area" > "Devices" pane and use each key for a unique connection. Instructions are available here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! The correct FQDN for the various servers is <server name>.airservers.org. However it resolves into IP address 1 only. Each VPN server has 4 entry-IP addresses for various connection modes, but we do not offer domain names for each IP address. For example entry-IP address 1 accepts OpenVPN in TLS Auth mode (for backward compatibility with old OpenVPN versions) and WireGuard, entry-IP address 3 accepts OpenVPN in TLS Crypt mode and WireGuard, and so on. For every detail you can check the "Specs" page "Protocols and entry-IP addresses of each VPN server" section: https://airvpn.org/specs You can use the API to get all the entry IP addresses of all the servers. API instructions and an API navigator are available in your AirVPN account "Client Area" > "API" panel. To make an example based on your request, let's say that you need to know all the info about Teegarden. A first raw search can be performed through the API and filtered accordingly, please see below. The first example shows everything the API can say about Teegarden, the second example prints the THIRD entry IPv4 and IPv6 addresses. Kind regards $ curl -s "https://airvpn.org/api/status/" | grep -A17 -i teegarden "public_name": "Teegarden", "country_name": "United States", "country_code": "us", "location": "Los Angeles", "continent": "America", "bw": 637, "bw_max": 2000, "users": 102, "currentload": 31, "ip_v4_in1": "37.120.132.90", "ip_v4_in2": "37.120.132.92", "ip_v4_in3": "37.120.132.93", "ip_v4_in4": "37.120.132.94", "ip_v6_in1": "2a0d:5600:8:3e:b389:fbfa:508a:1eca", "ip_v6_in2": "2a0d:5600:8:3e:604e:24d0:570c:230f", "ip_v6_in3": "2a0d:5600:8:3e:eceb:3b20:e697:db07", "ip_v6_in4": "2a0d:5600:8:3e:878b:13a8:3b47:98ed", "health": "ok" $ curl -s "https://airvpn.org/api/status/" | grep -A18 -i teegarden | grep in3 | awk -F '"' '{print $4}' 37.120.132.93 2a0d:5600:8:3e:eceb:3b20:e697:db07

Hello! Please try the following procedure: run Eddie on Eddie's main window uncheck "Remember me" log your account out log your account in (you'll need to re-enter your AirVPN credentials) try again a connection See also https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?do=findComment&comment=231319 Kind regards

Hello! We are investigating the problem. Kind regards

Hello! We're glad to inform you that it is back online now. Kind regards

@valkyrie89 Hello! Inbound remote port forwarding is a feature divorced from the VPN p-t-p communication protocol, it all relies on NAT configuration through packet mangling, so you can use it both with OpenVPN and WireGuard. Kind regards

Hello! Can you please test Eddie 2.24.2 beta and check whether the problem persists or gets resolved? Please see here to download the latest beta version: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

@8zXUsOoeym Hello! The problem has been solved, at least according to our tests. Can you please check now? Kind regards