9 replies to this topic

[Xwb2M9yPbL]

TLDR: Network lock via the Windows Firewall is completely broken in Eddie 2.14.5.

 

The following is based on a fresh Windows 7 Professional SP1 install (Vmware VM), Eddie 2.14.

5 is at stock settings except for Network Lock being changed from "Automatic" to "Windows Firewall (Not Recommended)".

1. Upon enabling Network Lock, the following Outbound firewall rules are created:
2. The "Eddie - Out - Allow IPs" rule (the one highlighted) allows ALL outgoing connections !?
3. Indeed, no traffic is blocked when the VPN is not connected, thus breaking Network Lock

Enabling verbose logging shows the rule being created as follows:

 

 

How on earth did this get through testing? I mean, I'm smiling, but I am very f***ing furious...

 

This really shakes the confidence that i had in AirVPN as a professional and technically competent VPN provider.

[go558a83nk]

hmmm.  I'm guessing it got through testing because people use automatic (WFP) not firewall and you apparently didn't help in testing.

[Staff]

Hello!

 

Thank you for the report. Please keep Network Lock at "Automatic" setting or "Windows Filtering Platform" while we investigate with maximum priority.

 

Kind regards

[Staff]

Hello!

 

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

 

Kind regards

[go558a83nk]

Hello!

 

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 and its release was anyway due for today. 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)".

 

Kind regards

 

 

 

 

https://airvpn.org/topic/28327-airvpn-dropping-connection-and-leaving-vulnerable/#entry74816

 

another user, most likely using "automatic", reporting network lock not working??

[Xwb2M9yPbL]

Hello!

 

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

 

Kind regards

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?

1. Is the (recommended) WFP protection only active while Eddie is running?
2. 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.

[DarkSpace-Harbinger]

Hello!

 

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

 

Kind regards

@staff, the issue is bigger than this. It appears to be affecting WFP/Automatic as well.

 

What i don't know is how far the leaks go beyond command prompt.

 

Torrent applications that always connect directly to IP's are likely compromised.

 

EDIT: Pings in command prompt will go through if allowed in Network Lock. Nothing to worry about!

[Xwb2M9yPbL]

Hello!

 

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

 

Kind regards

 

 

@staff, the issue is bigger than this. It appears to be affecting WFP/Automatic as well.

 

What i don't know is how far the leaks go beyond command prompt.

 

Torrent applications that always connect directly to IP's are likely compromised.

 

 

Have you tried this with anything other than ping? Per default, pings are alowed by Network Lock (they are pretty much the only thing it allows), but any other type of traffic should be blocked.

[go558a83nk]

It's easy to test if the above result using WFP is a bug by just disallowing pings in the settings right?

[DarkSpace-Harbinger]

It's easy to test if the above result using WFP is a bug by just disallowing pings in the settings right?

 

Your correct, i was being stupid.

 

I've tested it to make sure. I'll correct the other post.