Firewall "Error: nonexistent zone"

[zamar27 5]

For the test, I manually added some IPs to various default Eset Zones. Then I tried to add any of default Zones to any Firewall rule.  The above error persists for *any* default zone in *any* rule despite the zone being populated with some extra real IPs. But if I create a new zone, it can be added OK to rules, which accept Zones.

I wonder if Eset periodically needs remnants cleanup and reinstall, since regular program updates possibly leave conflicting settings in Registry or config files. I'm always shocked by some programmers culture to leave garbage everywhere at uninstall, like its their own system, and not the user's.

Edited May 7, 2019 by zamar27

[itman 1,659]

Getting back to the VM issue, was Eset installed on both the host and the VM? Also there might be a licensing issue here in that a separate license or seat of multi-device license might be required for both the host and VM. I could not find an Eset knowledgebase article for Eset Home versions but I assume the below applies to them:

Quote

What are the best practices for ESET endpoint/server solutions installed on a virtual client?

Version 6 ESET endpoint/server solutions are optimized for operation in virtualized environments and do not require any customization to function correctly on a virtual client. In applications where ESET products are installed on both a physical host and virtual machine, some files may be scanned twice, however this should not result in a noticeable impact on system performance.

To avoid overuse of resources in a virtualized environment, we recommend that you install ESET products on virtual client computers in small derivations. Installing ESET on all virtual clients at once will result in a large number of initial scans, which can affect performance on the host computer.

See the resources available below to make sure that your virtual machine satisfies the minimum system requirements for ERA and ESET endpoint/server solutions.

• View system requirements for ESET Remote Administrator 6.x
   
• View system requirements for ESET Endpoint Security and ESET Endpoint Antivirus
   
• View system requirements for ESET Endpoint Security and ESET Endpoint Antivirus for Mac OS X

https://support.eset.com/kb3674/?locale=en_US&viewlocale=en_US

 

 

Edited May 7, 2019 by itman

[jimmerthy 0]

I have sufficient licenses. The VM has its own license, as does the host.

There is a laptop (Win10) on the network that's also showing the exact same issue that I'm seeing on the VM (Win81) so this isn't a VM thing.

I created a new Win81 VM and installed ESET Smart Security 30 day trial and everything seemed to work correctly when I added new rules constrained to Trusted zone, so it does appear that in the lifetime of these problematic ESET installations, something has broken its detection of connections or its database of connections.

One possibility comes to mind ihat it could be the result of some over-zealous Windows hardening (group policy changes, windows service disables). It'd be interesting if someone from ESET could say what intrinsic Windows services it relies upon and whether this reported issue could potentially be caused by something that's been disabled or misconfigured in the OS.

Like zamar27, I just tried creating a new zone (e.g. with the IP range of my DHCP pool at home) and then changing the broken 'Trusted Zone' assignment of one of the firewall rules to use the newly created zone. This assignment worked correctly in that the chosen zone shows up correctly without reporting 'Error: nonexistent zone' as it does for Trusted Zone.

As I said before and zamar27 reports, it appears that the firewall is operating much closer to correctly than to incorrectly. Unknown process outgoing connections are met with the expected pop-up dialog and incoming connections are being blocked as I would expect for the couple of tests I performed.
Evidence that something reasonable is actualy being computed for the 'Trusted zone' is borne from going to "Setup > Network Protection > Connected networks > Network adapters" and then looking at the 'Trusted zone' column. In my case, on machines that exhibit the problem, this column entry reports a correct-looking subnet.

I agree this is probably better raised as a direct support enquiry to ESET, which I will do and I'll reference this thread.

 

Edited May 7, 2019 by jimmerthy

[itman 1,659]

48 minutes ago, jimmerthy said:

It'd be interesting if someone from ESET could say what intrinsic Windows services it relies upon and whether this reported issue could potentially be caused by something that's been disabled or misconfigured in the OS.

This article should explain what Win services are used by both Eset firewall and IDS processing: https://support.eset.com/kb2906/ .

Enabling/disabling noted services will cause the Eset firewall rules to be correspondingly modified to reflect the change.

[zamar27 5]

Since Trusted zone is computed correctly in Eset Network Adapters window, this seems to be rather broken config file or Registry key issue likely caused by numerous Eset updates, or possibly relevant Reg cleanups.

[jimmerthy 0]

I have made some progress with further understanding this problem by using the Setup > 'Import/Export settings' (to XML) feature.

• Export settings from a freshly installed ESET Smart Security and search for 'stZones' using something like Notepad++.
• Five zones are defined in the .xml that follows this string. These correspond to the default zones visible in Advanced Setup > Network Protection > Firewall > Advanced > Zones.
• Each zone in the .xml has a 'zonedID' which is a GUID.
• Through experiment (WinMerge / Beyond Compare useful diff tools), my conclusion is that these default zones should have special reserved GUIDs.
  • Trusted Zone 'ffffffff-ffff-ffff-ffff-ffff80000000'
  • The other default zones (I'm not sure which is which) 'ffffffff-ffff-ffff-ffff-ffffa0000000', 'ffffffff-ffff-ffff-ffff-ffffa1000000', 'ffffffff-ffff-ffff-ffff-ffffc0000000', 'ffffffff-ffff-ffff-ffff-ffffd0000000'
• On installations of ESET Smart Security exhibiting the problem (Error: nonexistent zone), the GUIDs for these built in zones have all been changed to random GUIDs.
• Performing a very careful find and replace of these zoneID GUIDs in the exported .xml to restore their special reserved values, followed by an .xml import, appears to restore proper functionality. 'Error: nonexistent zone' disappears and the 'DNS Servers' and 'Local addresses' zones once again show IP address information.

I've fixed a couple of these broken installations now using this approach. I would caution anyone considering doing this that it's probably very easy to screw up the XML with unknown consequences, possibly compromising protection etc.

I would hope that if ESET reads this then they're one step closer to reproducing it for themselves. I imagine it would be quite easy for them to roll out an update that detects these incorrect GUIDs, fixes them silently and restore normal functionality.