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)