ESET's FIREWALL on Windows version 10.1.2046 blocks network connections (e.g., DHCP acquisition)

[Kimiya Kitani 0]

The problem is not reproduced on the previous Windows version 10.0.2045.0.

Problem: A network connection is blocked when ESET Windows version 10.1.2046 is running on a terminal that is not connected to the network.

Workaround: Temporarily disabling ESET FIREWALL will allow network connections. Thereafter, the network connection will remain open even if ESET FIREWALL is enabled. However, if the network connection is turned off, the computer is started, and ESET is running, the network connection is blocked.

The problem occurs with both new installations and updates of Windows version 10.1.2046. Reproduced on multiple devices.

Downgrading to the previous Windows version 10.0.2045.0 does not reproduce the problem.

[mrac 5]

Hi. We have also problems with 10.1.2046 version, which blocks everything randomly.

Our issues:

1. WSL2 on Windows 11: blocked DNS requests from WSL. In Network access troubleshooting - blocked local application svchost.exe, Internet connection sharing.

2. Applications for security cameras on custom ports 10xxx, blocked on computer even with allow rules in Windows Firewall and "Also evaluate rules from Windows firewall" enabled.

3. Push installation of Veeam backup agents failed because of blocked ports 135, 137 (smb).

etc., etc...

It is possible to fix only by unblocking in "Network access troubleshooting". But it is not possible without admins, because we have password-protected user's interface of ESET.

"Used rule" is always empty.

It started since update from 10.0.2045 to 10.1.2046 on many computers.

We tried to enable pre-release updates for newer firewall module - doesn't help.

@Marcos How we can stop this nightmare without rollback to 10.0?

Edited July 27, 2023 by mrac

[ChrisM117 1]

10.2046 has broken our firewall configuration, we had it configured to only allow traffic on certain connected networks, the users can now access anything and everything without restrictions.  We have had to reinstall 10.2045 and block client updates as this is a major security issue for us.  what has changed in the firewall setup which is breaking how network profiles and trusted networks are handled??

[Marcos 5,078]

2 minutes ago, ChrisM117 said:

10.2046 has broken our firewall configuration, we had it configured to only allow traffic on certain connected networks, the users can now access anything and everything without restrictions.  We have had to reinstall 10.2045 and block client updates as this is a major security issue for us.  what has changed in the firewall setup which is breaking how network profiles and trusted networks are handled??

Do the Endpoint 10.1 clients have the firewall module 1438.2 installed which is required for the new firewall to work?

[FRiC 9]

For me, users are having issues printing to shared USB printers. Symptom is that the client machine shows the print job spooling for a long time but eventually (5-10 minutes) does print out. Workaround is to turn off printer spooling on the host machine. Not even sure if this is related to ESET 10.1 yet but we've had no other changes this week.

[ChrisM117 1]

Building a test system this morniing to diagnose the issue further.  Looks like the new firewall module added private and public zones to the network list which is likely the cause as they are not in the existing policy.  Will report back later this morning.

[Kimiya Kitani 0]

16 hours ago, Marcos said:

Do the Endpoint 10.1 clients have the firewall module 1438.2 installed which is required for the new firewall to work?

Yes.

As shown in the screenshot below, the Firewall module uses 1438.2.

 

[Kimiya Kitani 0]

Also, when waking up from sleep, the following dialog message “the network has been changed.” is displayed. The network is blocked and cannot be connected unless the firewall is temporarily disabled.

 

[ChrisM117 1]

OK, I have found the issue in our configuration.  Two new known network zones have been added, Privat eand Public.  Private is marked as public.  You have to go back through the Network profiles and include the se zones in any allow or block rules as required.  Otherwise you end up with the scenario we had.  We had a profile which blocked all traffic apart from vpn access on non trusted networks (we had added a set of trusted networks).  The new firewall zones allowed all traffic to pass apart from our vpn, so basically reversed the protection we had configured.  I think that any change to the firewall like this should come with a detailed warning that it will break your configuration.

[Kimiya Kitani 0]

I have not found a drastic solution at this time, but I have found a tentative workaround.

After updating to 10.1.2046 version, I checked the Firewall log and noticed that DHCP (69/udp -> 69/udp) is blocked. Then, looking at the default rules of firewall, I noticed the following permissions for inbound, but not for outbound. So I added a rule that grants permission to outbound, and the problem was solved.

Allow DHCP for svchost.exe
Local ports: 67, 68 /udp
SYSTEMROOT\system32\svchost.exe

Allow DHCP for service.exe
Local ports: 67, 68 /udp
Remote ports: 67, 68 /udp
SYSTEMROOT\system32\service.exe

Allow IPv6 DHCP for svchost.exe
IPv6 DHCP
Local ports: 546, 547
SYSTEMROOT\system32\svchost.exe
Remote pots: 546, 547

However, for the my device, after updating the firewall settings from the ESET server, the FIREWALL rules for the client devices disappeared, as shown in the forum below. Only the defaults are in place. This does not change after removing and reinserting ESET.
I also tried it on another terminal and it did not destroy the FIREWALL rules on that one, especially on the client. This is the part I am wondering why.

Firewall rules may no longer apply due to a change in settings in another policy that is not related to firewall settings

The ESET management system is using ESET PROTECT (Server), version 9.1 (9.1.1296.0), which is a bit old, so I am planning to change it to 10.0.15.2.

 

[Kimiya Kitani 0]

I have not updated the management system because it is still taking some time due to the circumstances of the outsourced management company yet.

At this time, we have applied for the beta release and set the version of the firewall module to 1439. However, there is no change in the situation.

Both the firewall rule and IP set in the ESET management server's policy settings are blank, and there is only the default rule on the ESET side in the case of version 10.1.2046.0. 

Uninstalling and reverting to one previous version will apply the policy and return to normal.

[Marcos 5,078]

Actually there is nothing like "beta release". The pre-release update channel contains latest modules that have passed pre-release tests and are provided to those who have opted for receiving new (tested) modules in the first round before they are served to all users.

Unfortunately it's not clear what version of the Configuration module you have. Is it the latest 2075.6? The version of the firewall module is irrelevant.

Quote

Both the firewall rule and IP set in the ESET management server's policy settings are blank

Couldn't it be that the firewall rules and zones were created years ago? Several years ago with v6 or so it could happen that the settings got damaged which started to manifest by blank rules and IP sets only recently and only if you have modified the policy. The solution is to re-create the affected policies from scratch.

[RObertWSA 0]

Any news in topic? We still have this nasty firewall bug and only way top fix it is manualy uninstall Eset on host, and when it get address from dhcp install version 10.0.

We need fix for this up!

[Marcos 5,078]

1 minute ago, RObertWSA said:

Any news in topic? We still have this nasty firewall bug and only way top fix it is manualy uninstall Eset on host, and when it get address from dhcp install version 10.0.

Yes, this was fixed between October 4 and October 9, depending on when you received the fixed module. Couldn't it be that you've been using policies with firewall settings for years without re-creating them from scratch?

[Kimiya Kitani 0]

Here is the report as of now.
I have not yet had time to try creating a new policy as presented by Marcos. At this stage, we have upgraded our ESET management server from 9.1 to 10.
ESET PROTECT (Server), version 10.0 (10.0.1129.0)
ESET PROTECT (Web Console), version 10.0 (10.0.133.0)

Then create and prepare the installer.

1. delete ESET and reboot
2. install ESET ( 10.1.2046 )
3. wait for the module to be updated
4. upgrade to 10.1.2050 was indicated.
Reboot the terminal

After doing this, Firewall related policies remained blank.

When I revert to 10.0.2045, the Firewall related policies come up as configured on the management server.

Now I am wondering if I need to re-create the policy once on the management server. However, I will be out of the country for a while, so I will try this after mid-September. 
 

[Marcos 5,078]

Removing the old policies with firewall settings and re-recreating them from scratch should fix the issue when a policy might have got corrupted years ago for some reason and this hadn't taken effect until recently due to conversion to new firewall settings with a particular Configuration Engine module installed.

[joloriquelme 1]

Hi,

After updating to .2046, we are having this issue with several clients computers (many companies).

This message appears repeteadly.

The user is working in the same network all day, same kind of connection (Wi-Fi), and the issue persists.

Also, there's no way to disable this alert.

[Marcos 5,078]

7 hours ago, joloriquelme said:

Hi,

After updating to .2046, we are having this issue with several clients computers (many companies).

This message appears repeteadly.

The user is working in the same network all day, same kind of connection (Wi-Fi), and the issue persists.

Also, there's no way to disable this alert.

There should be at least two profiles - public and private:

The notification can be disabled here:

[joloriquelme 1]

Thanks. Is there a way to disable this notification through a ESET Protect policy?

[Marcos 5,078]

Yes, it can be configured via a policy as well:

[joloriquelme 1]

On 8/25/2023 at 12:28 PM, Marcos said:

Yes, it can be configured via a policy as well:

But that option is for 7.0 versions and earlier?

[Marcos 5,078]

1 hour ago, joloriquelme said:

But that option is for 7.0 versions and earlier?

The label means Endpoint v7.0 and newer.

[RObertWSA 0]

On 8/23/2023 at 8:55 AM, Marcos said:

Yes, this was fixed between October 4 and October 9, depending on when you received the fixed module. Couldn't it be that you've been using policies with firewall settings for years without re-creating them from scratch?

We didn't re-create the policies, but there was no information from you anywhere about such a need before the update went live. Especially when we have automatic client updates set up. It's your fault for not testing and advising after the fact that we should create new policies. Even after creating new policies, I keep getting an error with dual firewall profiles.

[Marcos 5,078]

This information was provided here as a part of troubleshooting firewall issues. We have discovered only recently that policies could get corrupt years ago but that was not enough for the issue to manifest; you'd also had to edit such policy between June 21 and July 6.

Please check if re-creating policies with firewall settings resolves the issues.

[RObertWSA 0]

23 hours ago, Marcos said:

This information was provided here as a part of troubleshooting firewall issues. We have discovered only recently that policies could get corrupt years ago but that was not enough for the issue to manifest; you'd also had to edit such policy between June 21 and July 6.

Please check if re-creating policies with firewall settings resolves the issues.

After the first tests of Endpoint version 10.1.2050, the firewall works properly and even old firewall rules (which you think were causing problems) work correctly.