Jump to content
Not connected, Your IP: 44.210.240.31
conormullins3

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

Recommended Posts

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
Posted ... (edited)

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

Share this post


Link to post

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..

Share this post


Link to post

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

 

Share this post


Link to post

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).

Share this post


Link to post

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

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...