Eddie ver. 2.16.3 gets stuck at “Checking route IPv6” when Network Lock is active

[conormullins3 1]

I've just installed Eddie 2.16.3 on a new Windows 10 system.

 

When Network Lock is active, I can't seem to get Eddie to connect to any of the servers because it gets stuck at "Checking route IPv6" and the connection keeps timing out. I have put exceptions in both Malwarebytes and Windows Firewall for all components used by Eddie including the OpenVPN Daemon but it still refuses to connect when Network Lock has been activated. It works fine otherwise, but it is annoying since Network Lock is a useful feature for preventing DNS leaks.

 

I have attached a log file to see if anyone can help me figure out what's causing the problem. Bizarrely this problem is not present in earlier builds of Eddie such as 2.14.5, which I don't want to use for security reasons.

 

I am using Windows 10 Home, Version 1803, OS build 17134.345.

 

I hope this information is sufficient to help resolve the issue.

Eddie_20181011_131408.txt

[tsuda_keisuke 0]

Just posting to add that I am experiencing the same problem as OP.

 

Running Eddie version 2.16.3. With Network Lock active, I can't connect to any server; I keep getting timeouts. With Network Lock disabled I have no problem connecting.

 

Windows Home 10, Version 10.0.17134, Build 17134

[angIoNethaYb 0]

I have the same issue on Windows 10 Pro (build 17134), with Eddie 2.16.3.

 

The issue only occurs if IPv6 is enabled AND network lock is enabled AND network lock is set to the default "Windows Filtering Platform".

For the time being, I have set network lock to "Windows Firewall (Not recommended)", and now I can successfully connect to servers.

 

EDIT: Ahh, ignore above... It only worked 2 or 3 times, I can no longer connect with network lock and IPv6 enabled at the same time.

[KenAV 5]

I have the same issue.  Sequence of events/tests:

- Decided to finally use "Network Lock"
- Result was endless loop of "Checking IPV6 Routing" -> "Disconnecting" -> "Connecting"
- Read Forum suggestion to Block IPV6 altogether.
- That worked, but then utorrent just sat there doing nothing
- Disconnected and disabled Network Lock and then reconnected and utorrent worked fine
- Allow lan/private has always been checked.
- Restored IPV6 settings to normal (default) and still works fine IF "Network Lock" is not engaged.
- Eddie Version 2.16.3 on Windows Vista.

Otherwise, everything works great.  Using UDP on port 443 on entry-IP 3 (tls-script) avoids the ISP throttling I consistently see on many other protocol/port combinations,  I just had a torrent download peak at 80% of the maximum unprotected speed, using those settings - with another PC on the same LAN on AirVPN showing a stream as well.  So, great performance if you get every set just right.

 

UPDATE: This morning I had the same endless loop of "Checking IPV6 Routing" -> "Disconnecting" -> "Connecting" with Network Lock OFF.  So, I again changed to IPV4 only in Network Settings and everything is fine again.  I understand the eventual need for IPV6 for the address space, and that businesses are changing first - but is there currently any compelling need for home users to have support for IPV6?

 

==> In my home LAN, I have my devices set to use static IPV4 addresses (which is needed for two minor applications that I use in my home network).  I'm wondering if this is preventing IPV6 from working correctly?

 

2nd UPDATE: I discovered that on my PC that solely runs utorrent, if the AirVPN server disconnectes and reconnects, then in-between, individual utorrent connections will then all connect to the unprotected Internet connection, and when AirVPN reconnects, it doesn't affect the utorrent connections, which are now connected to the unprotected Internet connection.  So, Network Lock is a must for torrent program use.

 

So, I closed utorrent, and set Eddie to IPV4 Only, and turned Network Lock back on, and this time, everything worked fine.  I wonder if the problem is on the server end?  An intermittent problem?  Something just fixed?

 

Also, as a newbie, I cannot post more today, so I also wanted to mention that Anonymity Check now says "VPN fingerprint     MTU 1397".   Is this a result of tls-script ?  (wild guess)

Edited ... by KenAV
Update

[PortlyNinja 17]

Did you  solve this issue. I  am having the sameissue, and intermittently. Then it works with network lock enabled.if you sussed it, letnus knkw how..

[Auro 1]

Using Linux Mint 18.3 Sylvia 64-bit and have same problem, same with network lock enabled. 

 

[YesGem 2]

Yeah same here, I have 3 pc's running, all three of them run on Win10 64, all three have the same settings in Eddie, yet one pc isn't able to connect when the Network Lock is on and the other pc's are able to connect with Network Lock turned on (after a few tries).

[7YKaLx0kUfa 0]

If it helps anyone the same happened to me on a fresh Win10 OS install. I eventually found a fix, by following this which gives a link to a Microsoft KB article on how to a regkey which disables IPV6 at the OS level.  After that and rebooting, then OpenVPN properly skipped IPV6 and things work as expected