Jump to content
Not connected, Your IP: 34.207.82.217
Xwb2M9yPbL

PSA: Windows Firewall Network Lock is broken in 2.14.5

Recommended Posts

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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/?do=findComment&comment=74816

 

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

Share this post


Link to post

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.

Share this post


Link to post

 

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!

Share this post


Link to post

 

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.

 

rHEG3Tb.png

 

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.

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