Staff

Hello!

Since WireGuard works, we can rule out that the problem is caused by a general block against UDP. Possible causes include a selective block by your ISP (UDP to certain ports, or OpenVPN in itself) or a local problem with OpenVPN and/or OpenVPN adapter

We see that you have a DCO adapter, probably installed by openvpn-connect: this adapter is incompatible with OpenVPN versions older than 2.6, like the one packaged with Eddie Windows edition and may be the source of the problem. Useful clues may come from a system report generated by Eddie:

Kind regards
 

On 1/26/2024 at 10:02 PM, ms2738 said:

limiting OpenVPN connections based on CPU usage would solve the problem?

Hello!

Server load is indeed, and it has always been, one of the variables which are taken into calculation to determine the server rating and therefore recommend a server over another. Furthermore we have other inner variables which are monitored and are indicative of a server overload. In extreme cases yes, a server may be even closed to new connections due to overload, nothing new here. Such events are quite rare.
 

4 hours ago, oassQ9w4cbl4AySZhhth%p36x said:

more insightful heuristics into how much OVPN opters are slowing thingsdown

Where does this assumption come from? There's no evidence that OpenVPN users are slowing down WireGuard users. The problem is mainly on the OpenVPN client side, as users running OpenVPN on agnostic networks and/or on devices not supporting AES-NI might be unable to reach the performance which they would enjoy with WireGuard.

Again, whether or not prioritizing WireGuard over OpenVPN on the client side through our software default settings is not a problem due to OpenVPN stealing CPU time to WireGuard on server side (as incorrectly understood by @ms2738 too, we see now), as all servers have plenty of CPU available time for WireGuard, but a problem of customer satisfaction (in our previous message we mentioned the pros and cons which make the choice non trivial).

Kind regards
 

@kbps
@rabbit

Hello!

As promised we monitored the UK servers but again we did not notice any anomaly. This is what we see in the worst conditions, during peak times, from a variety of datacenters in Europe (connection through WireGuard, OS Linux or FreeBSD) to the servers in UK:



More or less it's the same on all servers, during peak times. We see more than decent throughput and no significant asymmetry between upload and download.
Maybe it's a problem only with peering with some ISP. We publish this not to rule out the option to have another provider in the UK, but just to show that according to our tests and monitoring there is no capping or congestion on the M247 side.

@Atien

That's not surprising, because the NL servers lines go directly to AMS-IX, so the probability that any other server in Europe can seriously compete with them while having connections from a residential ISP is moderate.

Kind regards






 

15 hours ago, FlyawayRavage said:

Edit: It seems disabling the airwhitecountrylist option fixes this. I'm not seeing anything in the readme that suggests there's this sort of interaction between the country and server whitelist options. I assumed it would just select from the intersection set of the two restrictions. Admittedly I can't think of much of a use case for using both options, but it might be useful to document how the "quick" connection option works with respect to the whitelists. I may have also missed this in the readme or just misunderstood what these settings are described to do. 

Hello!

We will look into the issue together with the developer. Your case is peculiar as you enforce a white list of a single server, so it is equivalent to specify the connection to a single server directly and not to a country and not in quick mode. You can be right, the manual may document more thoroughly the interaction and/or the program could manage the situation differently. Something under this respect was planned anyway, please feel free to test next releases of the Suite 2 preview:

Kind regards
 

@ScarAtlas
@roklipni
@S.O.A.

Hello!

Please open a ticket and/or your own thread. The problem in this thread has been resolved so you might have a different problem. What's more, each one of you might have a different problem. Adding your messages in this way in a thread which already solved the original problem might probably lead you nowhere unfortunately.

Kind regards
 

11 hours ago, Radagast said:

1) is there any way to have this autoconnect on TV power-on?

Hello!

Unfortunately not. This option has been deliberately disabled by Google in Android TV systems (from version 9 if we're not mistaken). On some manufacturer's devices, apps can be launched during the bootstrap through a launcher/boot app running on high privileges but, as far as we know (we would be happy to be corrected if we're wrong), that's not possible with Sony Bravia.
 

11 hours ago, Radagast said:

2) I find that after enough passed time, if I return to check on it, it disconnects, or hangs; if disconnected, I can manually reconnect. If hung, invoking it makes it terminate (blank white screen); invoking it again launches it unconnected, so I manually reconnect.

The second behavior (hung -> blank screen -> restart without connection) sounds like a bad crash. Please send us (either here or in a ticket to the support team) the complete report. It will contain the logcat too, so it may provide us with valuable information to understand what happened. To send us the log and logcat:

• open the settings view
• tap the paper plane icon on the top
• note down or copy to the clibpoard the URL that the app will give you back
• send us or the support team the URL

Kind regards

 

3 hours ago, Sceptrum said:

What is the issue? Am I banned?

Hello!

Just for a definitive confirmation, your account is not banned and has no limitations whatsoever. It must be a local problem. In the following thread, two users with this problem found out that it was caused by BitDefender:
https://forums.openvpn.net/viewtopic.php?p=120189

Can you check, if you run BitDefender?

Kind regards
 

10 hours ago, wwhh79 said:

i’m having the same issue on macOS. i always quit eddie manually, but my denylist is never saved. 

Hello!

Yes, this problem was reported on 2.21.6, as the OP correctly specified. Do you still experience this problem on 2.21.8 and/or 2.23.2?

Kind regards
 

@Rmanso33

Hello!

Eddie "Network Lock" modifies firewall rules to prevent traffic leaks outside the VPN tunnel. The blocking rules are not permanent. Even if Eddie's exit is not clean, you can flush firewall rule or you can reboot the system to solve the problem. If Eddie was running with Network Lock on, then it was doing its job. An additional step to improve compatibility with any software is disabling Fast Startup on Windows:
https://www.windowscentral.com/how-disable-windows-10-fast-startup

If Eddie's exit is not clean, you will need to check DNS settings as well, because VPN DNS is not accessible from outside the VPN and it will remain set even after a reboot. You can fix by re-running Eddie and shutting down it properly, or you can operate manually:
https://www.windowscentral.com/how-change-your-pcs-dns-settings-windows-10

You're not forced to run Eddie to connect to AirVPN servers. In this page you can find various alternatives:
https://airvpn.org/windows/

Another software for Windows which recently has received a remarkably good feedback by AirVPN users (although it is not open source) is WireSock, please see here:
https://airvpn.org/forums/topic/57174-how-to-correctly-use-the-routes-tab-to-only-route-the-torrent-client-through-eddie/?do=findComment&comment=228744

Kind regards
 

@salvialight

Hello!

You need to install resolvconf. We're not sure it's available for your Ubuntu / Pi OS version in the official repositories though. Worth a try:

sudo apt update
sudo apt install resolvconf

wg-quick runs resolvconf to manage DNS properly.

Side note: please send text and not screenshots whenever possible (in your previous message you could just copy and paste the text in the terminal).

Kind regards
 

8 hours ago, salvialight said:

is this doable on pi OS? i'm totally  novice with this stuff. not sure when to input these commands. i have the airVPN wireguard conf file. i don't understand how/when to use the nmcli commands. i'm only doing this because the eddie GUI client just freezes upon launch no matter what i do (even on a fresh install of pi os)

Hello!

In this case you had better go directly with wg-quick and not nmcli.  https://airvpn.org/linux/wireguard/terminal/

Kind regards
 

5 hours ago, salvialight said:

anyway, i got rid of pi OS, installed ubuntu desktop 23.1, and eddie installed and works just fine. port forwarding worked, and no DNS leaks! i tried to figure out setting up wireguard on pi OS also, but that is a bit beyond my abilities lol

Hello!

Should you need to install WireGuard in the future on a Raspberry Pi OS, consider that it's a Ubuntu based system, so you can handle the matter just like you would do in Ubuntu. Proceed to install WireGuard components:

sudo apt install wireguard

WireGuard userspace utilities will be installed too, so you can then proceed with our instructions starting from step 2:
https://airvpn.org/linux/wireguard/terminal/

Kind regards
 

Hello!

Can you tell us the laptop Operating System name and version?

Kind regards
 

@AntairVPN

Hello!

Can you please switch to WireGuard and check whether the same problem occurs or not? In order to switch to WireGuard:

• from Eddie's main window please select "Preferences" > "Protocols"
• uncheck "Automatic"
• select any line with WireGuard. The line will be highlighted.
• click "Save" and re-start a connection to apply the change
• please make sure to test a few servers in different locations around your node

If the problem persists, disable the route check, just in case the failure is a false positive:

• from Eddie's main window select "Preferences" > "Advanced"
• uncheck "Check if the Air VPN tunnel works"
• click "Save"
• enable "Network Lock" from the main window
• from Eddie's main window select "Preferences" > "DNS"
• uncheck "Check Air VPN DNS"
• click "Save"
• test again

Kind regards

 

3 minutes ago, madrat said:

Any idea what local problems I might look into? The thing is, up until 2 weeks ago, there was never a problem. Not sure what might have changed.

Hello!

With the current information unfortunately we can't say what you should look into. Try to open a ticket and investigate together with the support team. Let them know your Operating System, the browser you run, the software you use to connect to VPN servers... probably they will ask you for even more info in an attempt to understand the cause of the problem.

Kind regards
 

23 minutes ago, madrat said:

Well, Nahn was working for the last few days, but once I started switching to other servers to test them and switched back to Nahn, now it doesn't work again. None of Pisces, Telescopium, Titiwan or Sham will connect to Yahoo at the moment. Now I'm back where I started! I will continue to test other servers. If I find one that works, I'll let you know.

Hello!

We have just tested Nahn, Pisces, Telescopium, Titawin and Sham. https://yahoo.com is perfectly reachable from all of them. The connections were performed via WireGuard and the VPN DNS (10.128.0.1) correctly resolves the name. No block of any kind has been detected. More and more it sounds like your own local problem, let's see the feedback from other users. Note that in the route checker, "301" is correct (although it is questionable that the checker displays it with a red token), as yahoo.com replies "moved permanently" to ca.yahoo.com (re-direction is fine).

Kind regards
 

@madrat

Hello!

Can you give us the name of those servers you can't access yahoo.com from?

Kind regards
 

@salvialight

Hello!

Please note that you resurrected an 8 years old thread. Many things have changed in the meantime.

The alleged problem heavily depends on the DNS management of the software you run to connect. In general, WireGuard, Eddie (the Air software client) and the AirVPN Suite for Linux do that, while OpenVPN does not. Note: if your system runs systemd-resolved only Eddie 2.23.1 and newer versions added full support with proper DNS management for every systemd-resolved working mode. For manual DNS setup purposes, since you mention Pi OS we guess that it's the latest Pi OS based on Ubuntu 22/23, so you can consult Ubuntu, or general Linux, and systemd-resolved guides on DNS settings.

Also note that only with the introduction of some new systemd-resolved "on link" working modes the "DNS leaks" plague entered the Linux world, while previously it was a Windows-only pest. Before systemd-resolved specific working modes were activated by default in various distributions, DNS leaks did not exist in Linux. it seems no accident that shady pestilence spreaders who infect Linux with endemic Windows plagues then end up hired by Microsoft.

Kind regards
 

Hello!

The following errors thrown by OpenVPN:
. 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065)
. 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065)
. 2024.01.28 17:17:24 - OpenVPN > write UDP: Unknown error (code=10065)

hint to something blocking UDP and/or OpenVPN packets. Please check any packet filtering and traffic management tools both on your system and router and make sure you remove any such block. Also test a connection over WireGuard to discern whether the block is against UDP or against OpenVPN specifically. To switch to WireGuard:

• from Eddie's main window please select "Preferences" > "Protocols"
• uncheck "Automatic"
• select any line with WireGuard. The line will be highlighted.
• click "Save" and re-start a connection to apply the change

Please make sure to test various servers in different locations.

Kind regards


 

Hello!

Is that the complete error message, no additional info? Can you tell us the Operating System and whether the configuration file pertains to OpenVPN or WireGuard? Which OpenVPN or WireGuard version do you run?

Kind regards
 

@air92186

Hello!

We fear that Gluetun's server list is hard coded here: https://raw.githubusercontent.com/qdm12/gluetun/master/internal/storage/servers.json
Saclateni is not included in that list, maybe the list must be updated manually?

To avoid hard coded lists a developer could parse the AirVPN manifest. How to download and how to parse the manifest must be seen on Eddie Android (Java) or AirVPN Suite (C++) source code, which is (in our opinion) very readable and well commented. A developer could also use the Bluetit daemon (developer's reference manual available here) for all the needed operations for a full integration with AirVPN (Bluetit exposes a D-Bus interface), although the integration requires that the target functions and/or classes are developed according to the AirVPN–SUITE classes marshaling mechanism (thoroughly documented anyway).

However, there is no official document describing the manifest format and the procedure to download it from the bootstrap servers, we're sorry. We might plan a fully documented API for third party developers so they don't need hard coded lists of servers and IP addresses, or we might document the manifest download procedure and its format... we'll think about it.

Kind regards
 

Hello!

Thank you very much, you are a long time customer!

Some Eddie Linux edition versions, including 2.21.8, have a bug which causes a race condition in some cases when the round trip times tests are performed. The bug was fixed in Eddie 2.22 and the whole round trip time checks procedure was significantly improved in 2.23. From your description, we suspect that your problem is caused by the mentioned bug. Please test Eddie 2.23.2 beta and check whether the problem gets solved. Please see here to download Eddie 2.23.2 beta version:
https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/

If you are already running Eddie 2.23.2 then the problem must have a different cause, let us know.

Kind regards
 

Hello!

Please renew your client certificate and key according to the following instructions:
https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/
 

Reason: we signed client certificates with SHA1 between 2010 and 2017. In 2017 we started to sign them with SHA512, but the update was not forced on customers in order to avoid sudden disconnections and potential compatibility problems. You're indeed a long time customer, thank you!

Nowadays OpenSSL 3 (the SSL library used by OpenVPN) considers SHA1 based signatures insecure. By renewing the certificate you will have a new certificate signed through SHA512. Please remember that you need to re-generate your configuration file(s) after you have renewed the certificate.

Kind regards
 

@julienth

Hello!

Eddie picks the DCO adapter which is already installed in the system, but this adapter is incompatible with the OpenVPN version (2.5.5) in your system that Eddie itself runs. You can solve quickly the problem in this way:
https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323

Alternatively you can install OpenVPN 2.6 (which supports DCO) and force Eddie to run OpenVPN 2.6. You can configure which OpenVPN binary Eddie must run in  Preferences > Advanced > OpenVPN custom path.

Kind regards
 

Hello!

Let's verify whether the route check failure is a false positive or not:

• from Eddie's main window select "Preferences" > "Advanced"
• uncheck "Check if the VPN tunnel works"
• click "Save"
• enable Network Lock from Eddie's main window
• select "Preferences" > "DNS"
• uncheck "Check Air VPN DNS"
• click "Save"
• test again connections with WireGuard and OpenVPN. This time the connection should be fine from the log, but you must verify manually that you can perform your normal Internet activity. Network Lock will prevent anyway any traffic leak and make the route check superfluous

Kind regards