Staff

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

Hello! WireGuard on macOS still lacks a kernel module, so in an agnostic network you should not see a lot of gain from OpenVPN. However, it's also possible that your ISP shapes OpenVPN and not WireGuard, or shapes low ports but not high ports (if you connect WireGuard to port 51820 and OpenVPN to port 443, for example). Please make sure that the tunnel works properly by browsing to https://ipleak.net - when you open that page while the Mac is connected to the VPN, you must not see your "real", ISP-assigned public IP address anywhere. Do you also see performance boost compared to Eddie connecting over WireGuard? If so, MTU could come into play. The CG generates files with MTU set to 1320 bytes (*), Eddie 2.21.8 lets WireGuard pick the default value (1420 bytes, typically), while Eddie 2.24.x defaults to 1320 bytes but lets you configure various, different MTU size in bytes (1280, 1320, 1360, 1400, wg default). (*) You can change it by editing the configuration file with any text editor and changing the line "MTU = 1320". Kind regards

Hello! Yes, there are many upgrades underway throughout the infrastructure. On top of the usual, periodical system updates, we are adding an important new feature we will announce in the future (maybe as early as June, but don't take it for granted). Kind regards

@blank90 Hello! As @SurprisedItWorks wrote you may rely on https://ipleak.net, or you can also use the AirVPN API. Check your "Client Area" > "API" panel for instructions and commands through the API navigator. With a single fetch you can get all the data of all the servers, for example. Kind regards