Jump to content

Recommended Posts

Posted (edited)


Following on from this problem (which was never really resolved - apart from exporting and re-importing a modified eset configuration xml file, I had / have / exactly the same problems.

I also use the latest version of VMWare and had a virtual NAT VMWare adapter (VMware NAT8).

I think it got introduced (the problem) of Error: nonexistent zone appearing in new firewall rules - when I changed both my real network adapter and this virtual adapters IPV4 and IPV6's DNS details to AdAware's DNS Servers (they support both IPV4 and IPV6 DNS servers, so I changed those in both the real and virtual adapters IPV4 and IPV6 prefferences).

I also note that it appears to be a problem with the ESET software "populating" this "Add zone" dialog box properly (red box area). As seen below.zone.thumb.jpg.0998a814c6e4b345da4df0ad705b3f8a.jpg

The "Trusted zone" is the "top" or "default" options. So if I just click "OK" to add the "Trusted zone" to a firewall "Zones" rule area, I get the aforementioned problem I.E "Error: nonexistent zone". However, if I click on the drop down, in the "Add zone" dialog box, to select a different zone (for example the next zone down - "Addresses excluded from IDS" - not actually adding it in, but just changing the option) - THEN I go back and select "Trusted zone" again in the list of dropdown options, THEN the "Trusted zone" is added to the firewall rule correctly. (As shown in the demonstrated graphic above).

So essentually, if you just click "OK" thinking your adding "Trusted zone" (because thats what is shown in the dropdown) you get "Error: nonexistent zone".
If you change the option shown by selecting something else in the dropdown, but then go back to "Trusted zone" THEN click add, "Trusted zone" is added and shown in the firewall rule.

Very strange. No idea whats causing it (nonexistent zone), but it's definitely a bug in the software.

I've tried changing my IPV6 network card adapter options back to their "Obtain default DNS server" options (I'm retaining my IPV4 AdGuard DNS options), because I think changing my IPV6 parameters from default DNS to AdGuard IPV6 DNS is what caused to problem to start appearing. I've changed the IPV4 lots of time before without getting this problem, but I seem to recalled I also changed the IPV6 this last time as well (so I did something different and the problem started appearing).

(AdGuard DNS process / servers are shown here)
https://adguard.com/en/adguard-dns/overview.html

Edited by MoRbIdBoY
Posted (edited)
6 hours ago, MoRbIdBoY said:

So essentually, if you just click "OK" thinking your adding "Trusted zone" (because thats what is shown in the dropdown) you get "Error: nonexistent zone".
If you change the option shown by selecting something else in the dropdown, but then go back to "Trusted zone" THEN click add, "Trusted zone" is added and shown in the firewall rule.

Very strange. No idea whats causing it (nonexistent zone), but it's definitely a bug in the software.

I already reported this bug in forum. Appears it still is not fixed.

Thanks for the tip though. Will have to try that.

-EDIT- I didn't notice you left "Error: nonexistent zone" in place for the firewall rule.

Did you actually test that Eset is applying IP addresses listed in the Trusted Zone for this rule? I suspect the error specification zone might bork the entire firewall rule as far as Remote IP address detection.

My advice is just add the IP addresses manually to the Remote area of the firewall rule. That's what I do. Or alternatively, create a new zone; add the IP addresses to that zone; and specify the new zone in the firewall rule.

Edited by itman
Posted (edited)
6 hours ago, itman said:

I already reported this bug in forum. Appears it still is not fixed.

Thanks for the tip though. Will have to try that.

-EDIT- I didn't notice you left "Error: nonexistent zone" in place for the firewall rule.

Did you actually test that Eset is applying IP addresses listed in the Trusted Zone for this rule? I suspect the error specification might bork the entire firewall rule as far as Remote IP address detection.

I don't know if its applying them, but it certainly isn't showing them in the Zones. As you can see.

ZONES.thumb.jpg.56860383650e4619d9dcd55ae5f064a3.jpgMost worrying really, is the fact that I've removed EVERY single trace of ESET after uninstall, from Registry (searching for ESET in registry mechanic), ProgramData, Users, Common folders, etc. (there wasn't much left) - Then I did a complete network reset, using Windows Settings / Network and Internet / Network reset.

Reset my C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS file to:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#    127.0.0.1    localhost
#    ::        localhost


Even run a PowerShell script I converted to remove any remenant drivers (sometimes it leaves the ESET firewall helper - but not since a few versions back):
 

# Remove-ESET.ps1
#
# Remove all eset drivers from the driver store using PnPutil.exe

Param(
    [switch]$Yes,
    [switch]$Help
)

Function Show-Usage {
    Write-Host
    Write-Host "Usage: Remove-ESET.ps1 [-Yes] [-Help]"
    Write-Host
    Write-Host "Parameters:"
    Write-Host "    -Yes    Remove drivers instead of just showing what would get removed"
    Write-Host "    -Help   Display this help message"
    Write-Host
    Write-host "Disclaimer: USE AT YOUR OWN RISK."
    exit 1
}

$driverlist = Invoke-Command -ScriptBlock { & C:\Windows\System32\PnPutil.exe -e }

$tap_found = $false

if ($Help) {
    Show-Usage
}

foreach ($line in $driverlist) {
    if ($line.StartsWith("Published name")) {
        $published_name = $line.Replace(" ","").Split(":")[1]
    } elseif ($line.StartsWith("Driver package provider")) {
        if ($line.EndsWith("Eset spol s r. o.")) {
            $tap_found = $true
            if ($Yes) { & PnPutil.exe -d $published_name }
            else      { Write-Host "Would remove ${published_name}" }
        }
    }
}

if (! $tap_found) {
    Write-Host "No ESET drivers found from the driver store."
}


After I rebooted, the only thing left was my router wired Network Adaptor after it got re-installed from the reboot / network reset.

Then I ran:
ipconfig /flushdns
ipconfig /registerdns

I reinstalled ESET, fresh as a daisy. Tried to add a firewall rule, using "Trusted Zone" and got the nonexistent error straight away - and the Trusted Zone not populating (as seen above).

I'm only hoping that when you do add "Trusted Zone" to the firewall rules, it's having the sense to fall back to either "nothing" (don't allow) or local addresses (at least), so as not to compromise security.

Apart from re-installing windows (which is RIGHT out - lol), trusted zones appears to be completely stuffed. Only other thing I can try is exporting a fresh ESET configuration from a different (or even virtual) machine and try importing that.

Edited by MoRbIdBoY
Posted (edited)
13 minutes ago, MoRbIdBoY said:

I'm only hoping that when you do add "Trusted Zone" to the firewall rules, it's having the sense to fall back to either "nothing" (don't allow) or local addresses (at least), so as not to compromise security.

Note that the Trusted Zone is just a "shorthand" like feature so IP addresses don't have to entered each time.

Use of IP addresses listed in the Trusted Zone only are applicable if the Trusted Zone is specifically referenced in an existing Eset firewall rule. Many of Eset's default firewall rules do not use the Trusted Zone.

Finally, the Trusted Zone is automatically populated with local subnet addresses only if the Home/Office firewall profile is used. For the Public profile, nothing by default exists in the Trusted Zone.

Edited by itman
Posted (edited)

An additional way to add trusted IP addresses is at the network adapter level. My testing however has shown that adding IP addresses to the Trusted Zone is more encompassing as far as the Eset firewall goes:

Eset_Adapter.thumb.png.b8d1ae8b33f9ae01b3032f40ca588443.png

Edited by itman
Posted (edited)

I also just noticed your existing zones screen shot in regards to IP addresses shown in the DNS zone.

Of note is the same IP addresses being repeated multiple times. Maybe that has something to do with the fact that two network adapter connections are defined. But in that case, the DNS server IP addresses should only be repeated once which is clearly not the case.

Also I see an IPv6 DNS server addresses shown. The IPv6 DNS IP address shown, 2a00:5a60::ad1:ff, is associated with Merit Network in Russia. Is this your ISP which I highly doubt? The two IPv4 DNS addresses shown are for Adguard DNS servers which are also located in Russia. As far as using DNS servers located in Russia, I say "thanks, but no thanks" to that one.

-EDIT- Appears 2a00:5a60::ad1:ff is IPv6 DNS address for Adguard. My question is why is it associated with Merit Network which appears to be a Michigan based ISP provider?

Edited by itman
Posted

As far as accessing the security status of Adguard DNS servers, I suggest you run this test: https://www.grc.com/dns/dns.htm

Note that since this test is browser based if you are using FireFox with the default DoH setting enabled, this test will be against whatever DNS server set up in FireFox. By default, FireFox uses Cloudflare DNS servers for DoH.

Posted
On 1/23/2020 at 9:26 PM, itman said:

Finally, the Trusted Zone is automatically populated with local subnet addresses only if the Home/Office firewall profile is used. For the Public profile, nothing by default exists in the Trusted Zone.

So my physical network adaptor IS listed as a "Home" network and my VMWare virtual adaptors are listed a "Public" because I dont want or need them on my local network (just need them to be able to have internet access).

But... remember...

After removing EVERYTHING and doing a clear down (removing virtual adaptors using VMWare virtual network manager) resetting windows networking (flush DNS - everything!) - all I was left with was my physical adaptor (set as a Home network). I then installed ESET from fresh and got the nonexistent zone error and the trusted zones not populating (that was with my virgin media dns server - IP and DNS set to obtain automatically).

After that, I just set MY defaults back up (they clearly aren't causing the above problem). The reason the same DNS is listed multiple times is that I set the AdGuard DNS addresses up in the default two VMWare Virtual network adaptors as well as my physcial network adaptors.

I've undone this (set both the virtual adaptors back to obtain automatically), mainly because they'll be getting their IP lookups from the primary network adaptor anyway (so whats the point). They are the default VMnet1 (Host Only) and VMnet8 (NAT). So, the one that's host only won't even be able to contact the external DNS. Guess that's my "got to mess with it" OCD kicking in.

I'll check and see how many DNS are listed after I reboot with defaults back to normal. (See if it updates).

Additional trusted addresses I dont use. All those ESET settings are default. I set up my network adaptors though (in ESET Edit Network) as shown in your graphic. Windows doesn't let you set your physical network adaptor up on the "private" network while being able to set your virtual adaptors up as "public". ESET does, so I uncheck "use windows settings) and set the virtual adaptors up as using a "public" network (physical as "home"). I also remove identifying networks with DNS, using instead, IP address and gateway address.

The Trusted Zone option I use a lot, because I have the firewall set up as Interactive. There is quite a lot of software I set up as being able to only communicate in the local network (trusted zone) while denying internet or sometimes subnet access.

As for DNS servers (I think we are getting away from the point of the thread, but) - they scored as follows (think those ruskies get a hard time personally). They seem to score pretty well compared to Virgin Media's default DNS servers and they do a pretty decent job of blocking garbage. Adguard IP4 and IPV6 DNS servers are used.

https://adguard.com/en/adguard-dns/overview.html

AdGuard DNS Servers

45.32.184.119.vultr.com - Excellent,
78.141.223.194.vultr.com - Excellent.
141.101.64.* - (This class-C network has no associated domain name) - Moderate.
172.69.52.* - (This class-C network has no associated domain name) - Moderate.

Default Virgin Media (obtain automatically) DNS servers.

brad-dnscache-1b.server.virginmedia.net - Moderate.

Posted

Before I reply further, I realized that I really don't know what your Eset network issues are other than the previously reported bug in adding the Trusted Zone to an Eset firewall rule.

  • 2 weeks later...
Posted (edited)

Exactly the same as jimmerthy above, but I'm not going to gangbang his thread or write "same problem". Problem is.. it's a security risk. People sometimes add firewall rules like automatons, because it's a "routine thing". If this "none existent zone" problem happens (pops up) and ESET actually LETS you add it to a firewall rule do YOU know what implications that has on the rule or the software? Do you know if I've just given the entire world access to my local area network? Does anyone actually know what a none existent zone actually is? I don't.

Hardly trustworthy is it?

I'm used to Trusted Zone automatically being populated (by ESET) with "Trusted Zones" determined by my network configuration (or Connected Networks settings). Never had to populate Trusted Zones myself before. Never seen none existent zones before.

Clearly having VMWare 15.5.1 (which was recently updated - a pre-requisite / requirement of upgrading to Windows version 10 1909's HyperVisor- which may have caused this problem) causes some kind of conflict with ESET. It's only a 192.168.0.1/24 LAN with the "default" VMWare VMnet0, VMnet1 and VMnet8 network config. Hardly "socket" science is it (bum bum!).

Anyway, might be an idea just to close the thread, it's clearly one of "those" problems that's going to hang about like a bad fart.

Edited by MoRbIdBoY
Posted (edited)

Yep, just as I thought. Even when I fill in the Trusted Zone myself as follows:

image.thumb.png.8599fbb55248948f7b2d23476312c4df.png

When I physically add a rule to the firewall using "Error: nonexistent zone", thinking I've clicked on "Trusted Zone" (that's what the default option in the drop down list is telling me remember, I only see "Error: nonexistent zone" if I double check what ESET has just added to my firewall, then I get this as the actual firewall rule - and ESET lets me proceed and add it in without any kind of warning.

image.thumb.png.4b59e16d6fab2a332e5997efc7d97d22.png

So just to be clear - the second rule (in which I intended to let this application only communicate in the "Trusted Zone" - has automatically now become a rule which allows complete local and internet access. "Remote" column above should say "Trusted Zone" in the second entry, or at least "nonexistent zone".

As you can see above, I've filled in the Trusted Zone details myself, so there shouldn't even BE a nonexistent zone.

If THAT isn't a serious software bug that needs fixing yesterday I honestly don't know what qualifies to you guys. Personally, right now, I'm looking at alternative solutions for firewalls.

image.png.6726f863ec63f217384beb9637b95a64.png

1. This box isn't populating correctly.

2. ESET isn't warning me I'm mistakenly adding a zone which does not exist (AT ALL). It's actually making me think I'm adding Trusted Zone because that's what it says.

3. Trusted Zones isn't self populating (I've used ESET for about 15 years and I've NEVER ONCE had to populate Trusted Zones manually).

4. This is a completely fresh install of ESET. Everything was uninstalled prior to this error. Registry cleaned of EVER ESET entry (your cleaners used - PS, your uninstallers miss HKEY_CLASSES_ROOT\eComServer.EsetHC and HKEY_CLASSES_ROOT\eComServer.EsetHC.1) as well as any remnants from the driver store using PnPutil.exe. - ITS GONE.

5. End up accidentally adding a firewall rule which potentially allows full access to my network.

Just because I've gone VMWare 15.5.1 installed?

Edited by MoRbIdBoY
Posted (edited)
1 hour ago, MoRbIdBoY said:

1. This box isn't populating correctly.

2. ESET isn't warning me I'm mistakenly adding a zone which does not exist (AT ALL). It's actually making me think I'm adding Trusted Zone because that's what it says.

3. Trusted Zones isn't self populating (I've used ESET for about 15 years and I've NEVER ONCE had to populate Trusted Zones manually).

If you are using the Eset Public network adapter profile or you are using "Use Windows settings" profile and the Win firewall has been previously be set to use the Public profile, nothing will be populated in the Trusted Zone. This is by design.

Also since you are somewhat concerned about the "Error: nonexistent zone" bug, have your created a support ticket on the issue with your local support Eset provider?

Edited by itman
Posted (edited)

So, updated my VMWare as per guidelines prior to 1909 Windows update.
Uninstalled ESET (also as per general guidelines).
Did Windows Upgrade to 1909.
Reinstalled ESET,
Got all these problems.

I haven't marked anything as a public network. I believe windows firewall did that automatically just on the default VMWare NAT adaptor when I upgraded (which I believe is probably a good thing right? - I don't particularly want VM's to be able to access my LAN unless I need it, never thought about it before). So I just "stuck with it".

Never had anything this stupid in my life. How do I get it back to "self populating" then if it's "by design", it's not a design I particularly favour or understand. The whole POINT of antivirus and firewall software is to make this stuff easy, otherwise I may as well go clunking through Windows Firewall.

Design is OK as long as I can figure out W*F is going on.

(And I don't think good design lets people populate their firewalls with garbage that lets anything through it).

- I only say all this by the way, because it might be interesting to see if it clears up the non-existent zone problem. They both happened at the same time.

Edited by MoRbIdBoY
Posted (edited)

No, I haven't created a support ticket... at this stage, if I had a box, I'd throw the damn stuff out of the window. I'm about another 30 minutes trying to sort it out, then it's the studio manager getting his had in his wallet for some decent stuff.

- just one other question itman - and cheers for your support, i appreciate your help, version 8 used to work fantastic, can you still download it and get a/v updates through it?

Edited by MoRbIdBoY
Posted

Let's recap again.

You cannot use the Trusted Zone in either the Local or Remote sections of a user created firewall rule because of the bug. If you must do so, you will have to create a new Zone. Titled it "My Trusted zone" or whatever. Add whatever IP addresses you require to this created Zone. Then reference this created zone in your firewall rules.

The real question is why are you doing this in the first place if you don't want your VM to access your LAN?

Is the issue that you what one set of firewall rules to apply to the VM and another set of rules to apply to the LAN? If so, you need to create a new firewall profile for the VM, add your rules to that profile, and then assign this new profile to the VM network adapter. By default, Eset only uses one firewall profile - the global profile. In other words, only one set of rules is being used by all known network adapters.

  • Administrators
Posted

The bug should be fixed in the upcoming service release of v13.

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...