We confirm the bug, it has been inserted starting from 2.14.
Needles to say that we will review with determination our internal method of testing and testing personnel. Unfortunately not even the whole community caught this issue, since version 2.14 has been in public beta testing starting from the end of January 2018 and nobody saw this, probably because this Network Lock method is clearly reported as not recommended.
Version 2.15.2 (which had been planned to be released as stable) will contain the fix. It will be released in a very reasonable time. In the meantime, Windows users should simply leave Network Lock at its default setting, or revert back to "Automatic" or "Windows Filtering Platform" if they changed the Network Lock method to "Windows Firewall (not recommended)".
First of all thanks a lot for the quick and clear response to this issue, it goes a long way towards restoring my confidence in this service . In retrospect i can see how this could have been missed by testers, as it is unlikely for users to select an option marked as Not Recommended. Adding an explicit smoke test for this issue in the future would probably be the best way to go.
On a related note, could you please clarify a couple of points regarding network lock?
- Is the (recommended) WFP protection only active while Eddie is running?
- If yes, would Eddie work if network access is blocked (via the windows firewall) for everything except the .exe files in the Eddie install folder?
I understand that Windows Firewall-based protection is generally not recommended since any application can modify its configuration (nice one Microsoft...), but it would be nice to have a second layer of protection in case the connection drops and Eddie crashes.