Eddie not working on . Mac OS 10.14 (Checking IPV4 failed)

[TehGSpot 0]

Basically this is where the problems start... 


. 2021.09.30 11:03:45 - Flushing DNS
. 2021.09.30 11:03:45 - Flush DNS via dscacheutil
. 2021.09.30 11:03:45 - Flush DNS via nDNSResponder
I 2021.09.30 11:03:47 - Checking route IPv4
. 2021.09.30 11:03:47 - Fetch url error:Peer certificate cannot be authenticated with given CA certificates
. 2021.09.30 11:03:47 - Checking route (2° try)
. 2021.09.30 11:03:48 - Fetch url error:Peer certificate cannot be authenticated with given CA certificates
. 2021.09.30 11:03:48 - Checking route (3° try)
. 2021.09.30 11:03:50 - Fetch url error:Peer certificate cannot be authenticated with given CA certificates
E 2021.09.30 11:03:50 - Checking route IPv4 failed.
. 2021.09.30 11:03:50 - OpenVPN > Initialization Sequence Completed
! 2021.09.30 11:03:50 - Disconnecting


Just keeps looping.... 



OPEN VPN works fine on both protocols UDP TCP on my tablet and phone...  --- so the ISP is not the problem.. not working with Eddie on my Macs . 
 

[Staff 10014]

Hello and thank you for your choice!

Please make sure that you're running Eddie 2.19.7 or higher version (upgrade if necessary).

Then, please try the following settings:

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

Try again connections to various servers.

Explanation of the issue: consider that AirVPN uses mainly LetsEncrypt certificates. Then read here:
https://blog.germancoding.com/2021/04/16/lets-encrypt-and-expired-root-certificates/

Now, if you run a cURL version linked against OpenSSL 1.1.0 or older versions, or against LibreSSL older than 3.2.0, or GnuTLS older than 3.6.7, the validation chain will fail (and Eddie does use libcurl and curl). It's a TLS library bug. At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so .

Momentarily, the above quick fix will resolve the problem on Eddie. The initial checks become useless when you keep Network Lock enabled, so you don't have to worry about safety and security.

Kind regards
 

[TehGSpot 0]

thank you

Edited ... by TehGSpot

[jeromec 0]

Thanks @Staff for the reply and quickfix, but I do not understand "At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so ."
I really do not think it is viable to use expired certification routes for up-to-date-systems.

I hope I can re-enable "check DNS" in AirVPN soon on my Macs.
I understand you want to keep compatibility with older Android versions, but shouldn't you have a specific version or specific settings for older Android and not degrade security for more recent platforms?

[Staff 10014]

14 hours ago, jeromec said:

Thanks @Staff for the reply and quickfix, but I do not understand "At the moment we can not fix on our side: we would cut out all Android versions older than 7.1, and we don't want to do so ."

Hello!

Ignore that sentence, actually we fixed the issue on server side to maintain compatibility with bugged TLS libraries and at the same time old Android versions will not be affected.

 

Quote

I really do not think it is viable to use expired certification routes for up-to-date-systems.

That was never the case. The problem is caused by bugged TLS libraries in your system.
 

Quote

I hope I can re-enable "check DNS" in AirVPN soon on my Macs.

Yes, you can do it now!
 

Quote

I understand you want to keep compatibility with older Android versions, but shouldn't you have a specific version or specific settings for older Android and not degrade security for more recent platforms?

You understood exactly the opposite of what it really happened. Security degradation is on client side affecting those systems still running with obsolete TLS libraries affected by critical bugs. Although we now keep compatibility even with bugged TLS libraris, please consider to upgrade your system anyway. Bugged TLS libraries are (at least) OpenSSL 1.1.0 or older versions, LibreSSL older than 3.2.0 version, GnuTLS older than 3.6.7 version.

As you can see they are all obsolete versions which should not be used anymore.

Kind regards
 

[jeromec 0]

10 minutes ago, Staff said:

Hello!

Ignore that sentence, actually we fixed the issue on server side to maintain compatibility with bugged TLS libraries and at the same time old Android versions will not be affected.

 
That was never the case. The problem is caused by bugged TLS libraries in your system.
 
Yes, you can do it now!
 
You understood exactly the opposite of what it really happened. Security degradation is on client side affecting those systems still running with obsolete TLS libraries affected by critical bugs. Although we now keep compatibility even with bugged TLS libraris, please consider to upgrade your system anyway. Bugged TLS libraries are (at least) OpenSSL 1.1.0 or older versions, LibreSSL older than 3.2.0 version, GnuTLS older than 3.6.7 version.

As you can see they are all obsolete versions which should not be used anymore.

Kind regards
 

It works.
Thanks for the fix and the clarification.
Have a great day :-).