ANSWERED Eddie 2.10.3 network lock breaks LAN connectivity

[rainmakerraw 94]

Hi, 

 

Currently running Eddie 2.10.3 on a Windows 8.1 Pro x64 box. With network lock enabled my LAN network shares are not accessible. Going to 'Network' in explorer shows that file and printer sharing (and network discovery) are both turned off. They are impossible to re-enable, and trying to do so simply closes the dialogue but they remain turned off. 

 

All relevant services are running on the machine (SSDP discovery service, UPnP etc etc) and as soon as network lock is deactivated network discovery is automatically enabled again, LAN shares show up and everything works OK again.

 

In Preferences > Advanced > Network lock I have already checked the box to 'allow lan/private'. I also tried disabling network lock, de-selecting 'allow lan/private' and then re-enabling everything. Still no joy. The only solution for me to keep network shares available is to disabled network lock entirely. 

[Guest]

Having the same problem on Eddit 2.10.3 and windows 10. Something is wrong with the firewall rules. Checked client 2.9.2 and i still have the problem even though i am sure in the past i could enable network sharing. Weird.

[tranquivox69 27]

As such, I have an event setup to import firewall settings upon connection and another to restore standard settings when the connection closes. From time to time I update the two files, WinFirewallAir.wfw and WinFirewallOriginal.wfw, in case I add programs or exceptions to the firewall rules. This has the added advantage of stopping Eddie from making me add exceptions all the time, since those are not saved (or were not until 2.9.2, which I am using currently).

 

The two events I link the actions to are Session Start and Session End. Upon these two events I set up Eddie to issue, respectively, the two following commands:

 

Session Start

File name: netsh.exe

Arguments: advfirewall import "D:\WinFirewallAir.wfw"
Wait end of process: ON

Session End
File name: netsh.exe
Arguments: advfirewall import "D:\WinFirewallOriginal.wfw"
Wait end of process: OFF (it's clearly not as critical, for obvious reasons)

It's critical that the WinFirewallAir.wfw file contains the rules displayed in this picture (save for Chrome, that's there by mistake, unless you use it, of course), both for inbound and outbound settings. You can work on getting the right *.wfw files by using the import and export functions of Windows Firewall with Advanced Security, reachable through Advanced Settings in the standard Firewall panel in Windows.



All this on Windows 8.1 x64, updated with all security patches.

[tranquivox69 27]

Sorry to resurrect an old thread but I want to know if new versions of Eddie will take care of the above. To lose all LAN connectivity when connecting to AirVPN is unacceptable. I can go on using my solution but I wonder if I can be the only one with the same problem.

 

To say nothing of exceptions to the firewall that need to be saved each and everytime because Eddie resets them every time.

[OpenSourcerer 1435]

Sorry to resurrect an old thread but I want to know if new versions of Eddie will take care of the above. To lose all LAN connectivity when connecting to AirVPN is unacceptable. I can go on using my solution but I wonder if I can be the only one with the same problem.

 

To say nothing of exceptions to the firewall that need to be saved each and everytime because Eddie resets them every time.

 

One of the reworked features is the Network Lock done with Windows Filtering Platform. You can add your firewall rules without being afraid of Eddie resetting it. More info in the announcement.

[htpc 9]

as long as I used the eddie client, network-lock never really worked smoothly with bonjour services and network discovery on mac platforms. this was reported in several threads but never resolved. I don't know if it's just not possible technically, there is no will to do it or we users are all doing something fundamentally wrong. either way for the average or even non-coding power users this feature of the client just seems to be broken. btw, checking "allow lan connectivity boxes" and similar often suggested tips are not a solution to this, at least they never worked for me.

[Staff 9973]

as long as I used the eddie client, network-lock never really worked smoothly with bonjour services and network discovery on mac platforms. this was reported in several threads but never resolved.

 

 

On the contrary, it has been resolved, anyway it has always been a non-real problem. If you did not upgrade to Eddie 2.11.x beta just allow the IP addresses required by Bonjour in Eddie "Network Lock" window :

 

239.255.255.250

224.0.0.251

 

Not needed on Eddie 2.11.x that allows them by default if "Allow LAN" is ticked

 

Kind regards

[htpc 9]

hmm, I am upgraded actually. And while it seems that the new beta 2.11.x has improved things slightly I cannot confirm that network lock does not break local connectivity. For example as soon as I activate network lock on either OSX or Ubuntu machines discovery services for LIFX bulbs via LAN protocol fail. As soon as I disable network lock they work flawlessly. This is just one case I ran into today. I had other similar problems (and others here on the forums as well btw) that I couldn't recall right now.

 

There's a good chance that those things are by design and working the way they were supposed to, but for a non-expert user I'd say it's hard to accept the statement that network lock doesn't come with any limitations concerning local connectivity.

[Staff 9973]

hmm, I am upgraded actually. And while it seems that the new beta 2.11.x has improved things slightly I cannot confirm that network lock does not break local connectivity. For example as soon as I activate network lock on either OSX or Ubuntu machines discovery services for LIFX bulbs via LAN protocol fail. As soon as I disable network lock they work flawlessly. This is just one case I ran into today. I had other similar problems (and others here on the forums as well btw) that I couldn't recall right now.

 

There's a good chance that those things are by design and working the way they were supposed to, but for a non-expert user I'd say it's hard to accept the statement that network lock doesn't come with any limitations concerning local connectivity.

 

Just allow the IP addresses required by a particular protocol you need in Eddie. Also consider that sometimes the problem comes from the inability to resolve local names when local DNS is no more used (when you are in the VPN, your system queries the VPN DNS by default), so act accordingly.

 

Kind regards

[htpc 9]

OK, to be specific I ask you to help me with this LIFX problem I'm having. I want to use this module https://github.com/mclarkk/lifxlan to control my LIFX bulbs over the local network. As long as network lock is disabled everything works smoothly, but with network lock activated the bulbs will no longer be discovered by the scripts. I was trying to solve the problem with the developer directly and after investigating the IP table rules he wasn't able to pinpoint the exact problem. He suggested I might find better help here than with him. I'm not an expert and not sure I do perfectly understand the implications of the local DNS resolve topic you mentioned in your last post. What the developer was telling me is

 

"...that the lifxlan discovery protocol uses the LAN broadcast address 255.255.255.255 and doesn't rely on DHCP or DNS."

 

I'm not sure what other information I can provide to help people to help me :-)

[Staff 9973]

Hello htpc!

 

255.255.255.255 is already allowed by default (to let DHCP work). there must be something else needed by the protocol.

 

Kind regards

[htpc 9]

Hello htpc!

 

255.255.255.255 is already allowed by default (to let DHCP work). there must be something else needed by the protocol.

 

Kind regards

 

OK, but what else could there possibly be that is changed by network lock? I can replicate this on different machines as well as OSs (OSX and Ubuntu). I would try to investigate if I knew where to start and how. But unfortunately nobody seems to be having a clue.