itman

What I will note is that it is virtually impossible via web search to find an authorized Eset reseller. A search for U.S sellers will point you to Eset U.S. web site in San Diego, CA.
I have always made it a point to purchase sealed box versions of whatever Eset product I was purchasing from whatever source in the U.S., and never had a licensing issue.

For some odd and unknown reason, the Eset firewall will often throw an alert about an insecure firewall rule in reference to the built-in equi rule. It usually occurs after an in-place Eset upgrade to a new version. You possibly answered one of those alerts as a block action which resulted in the rule being disabled.
What appears to be triggering this activity is Eset's Application Modification detection which is only applicable if the firewall is set to Interactive mode. Bottom line - this activity appears to be a long running bug in Eset firewall processing.

Don't you have direct contact info to Eset headquarters tech support in Slovakia? 

What I will note is that it is virtually impossible via web search to find an authorized Eset reseller. A search for U.S sellers will point you to Eset U.S. web site in San Diego, CA.
I have always made it a point to purchase sealed box versions of whatever Eset product I was purchasing from whatever source in the U.S., and never had a licensing issue.

Do you have any network shares mounted to your computer as a drive letter which are accessed through the VPN? If yes, you might consider turning off scanning of Network Drives in the Real-Time Protection settings. This feature is on by default, and in many scenarios can be helpful, but over a VPN it'd be devilishly slow and could account for the strange scanner behavior.
Robbie // The Bald Nerd

Nothing strange about it. The Eset off-line installer web site is always updated somewhat after the release hits the Eset update servers. Also the situation is identical to the current status, the ver. update is offered prior to an official announcement in the forum. More so currently in that it appears all the Eset support personnel at some conference this week.

Nothing strange about it. The Eset off-line installer web site is always updated somewhat after the release hits the Eset update servers. Also the situation is identical to the current status, the ver. update is offered prior to an official announcement in the forum. More so currently in that it appears all the Eset support personnel at some conference this week.

Note that email notifications is a sub-section of Notifications:

No because virtually all third party firewalls are part of integrated AV security suites these days. The only full-featured stand-alone firewall actively supported is Comodo's. The rest are old Win 7 versions with kludges applied to get them to function on later OS versions.

No because virtually all third party firewalls are part of integrated AV security suites these days. The only full-featured stand-alone firewall actively supported is Comodo's. The rest are old Win 7 versions with kludges applied to get them to function on later OS versions.

Elaborating, Eset switched the GUI to the Win Metro interface on vers. 9+. As such, all ver. 8 custom rules and the like will have to be re-entered from scratch. This does bring back painful memories ..........................

I believe that this article sums up nicely why pirated software should not be used: https://www.maketecheasier.com/dangers-of-using-pirated-software/ .
Also some security software does scan for pirated software. MalwareBytes is one of them. Also a number of the web sites that assist in free malware removal will refuse to provide help if they detect cracked software on a device.

Here's an analysis of what appears to be a later version: https://any.run/report/c77cf8ebd52d044362c7f5d1a8e3fc444488371985a8c0f2902420b93bc44001/2bdc9ed2-5ebe-42a9-beb4-f35fa778bd37#registry
In this case, the determination was suspicious.

The alerts still show in ver. 12.2.29. The only difference from prior Eset versions is they are now full screen alerts.
Using the wicar.org coin miner test, Eset will first throw a PUA alert. When one selects "Disconnect," the below screen shot alert is displayed:

I was going to post this might be a way to fix the issue. However, you would have to import settings from a prior export where the Eset GUI was properly configured. And of course, you will lose any GUI changes such as new rules created and the like that occurred subsequent to when the export was performed.

I am using 12.2.29. But there should be no change in regards to that section from 12.2.23.
Also your screen shot shows "Email notifications." In that slot should be "Notifications." So it appears to me there is something not right with your Eset GUI setup. Click on Email notifications and see if that brings up the screen @Marcos posted.

Personally, I believe something else is involved in these instances when Win 10 displays this Windows event notification.
The way it is supposed to work is at boot time, the following two events are logged in the Security Center event log:
The Windows Security Center Service was unable to load instances of FirewallProduct from datastore.
The Windows Security Center Service was unable to load instances of AntiVirusProduct from datastore.
Assumed is Eset is the cause of the above event log activity. However the Security Center is still in the process of initializing itself. As such, the Windows event notification should not appear. While this initialization activity is ongoing, Eset briefly allows Windows Defender to start and then terminates it. Security Center initialization completes with the result being Eset is registered as both the firewall and anti-virus provider.

VT update - Kaspersky and even MalwareBytes detects, but still not Eset ..............................

This is far from the first ransomware employing XOR techniques. Here are a few other examples:
https://www.rsa.com/en-us/blog/2017-05/how-ransomware-uses-tmp-files-and-the-temp-folder
https://www.cybereason.com/blog/the-sodinokibi-ransomware-attack
https://blog.malwarebytes.com/threat-analysis/2018/04/lockcrypt-ransomware/
So my guess is how it was deployed is new and this is why it wasn't detected by a number of solutions.
This is a perfect example of why everyone needs to backup their User files and keep them off-line; or the online backup location locked down access-wise.
Also another strong case for use of the anti-ransomware solutions like AppCheck or Checkpoint's solution. These use "bait" files to detect file modification and therefore are not dependant upon detecting ransomware behavior methods.

Of note is none of the Next Gen solutions on VT are detecting this. This would be a clear indication that behavior employed by this ransomware is new and their ML engines haven't been tuned to detect it.

More details on this ransomware is here: https://translate.google.ru/translate?hl=ru&tab=wT&sl=ru&tl=en&u=https%3A%2F%2Fid-ransomware.blogspot.com%2F2019%2F09%2Fgoransom-poc-ransomware.html
It is using XOR for encryption activities. Suspect this is why it is "flying under the radar" of security solutions monitoring for specific crypto API's.

This is far from the first ransomware employing XOR techniques. Here are a few other examples:
https://www.rsa.com/en-us/blog/2017-05/how-ransomware-uses-tmp-files-and-the-temp-folder
https://www.cybereason.com/blog/the-sodinokibi-ransomware-attack
https://blog.malwarebytes.com/threat-analysis/2018/04/lockcrypt-ransomware/
So my guess is how it was deployed is new and this is why it wasn't detected by a number of solutions.
This is a perfect example of why everyone needs to backup their User files and keep them off-line; or the online backup location locked down access-wise.
Also another strong case for use of the anti-ransomware solutions like AppCheck or Checkpoint's solution. These use "bait" files to detect file modification and therefore are not dependant upon detecting ransomware behavior methods.

No need for the ASR mitigation.
Assumed is WD's cloud sandbox has Controlled Folders enabled. Unknown process performing repeated file modification activities to same is enough to flag the unknown process. This is why MS had a sig. for it so quickly.

Of note is none of the Next Gen solutions on VT are detecting this. This would be a clear indication that behavior employed by this ransomware is new and their ML engines haven't been tuned to detect it.

More details on this ransomware is here: https://translate.google.ru/translate?hl=ru&tab=wT&sl=ru&tl=en&u=https%3A%2F%2Fid-ransomware.blogspot.com%2F2019%2F09%2Fgoransom-poc-ransomware.html
It is using XOR for encryption activities. Suspect this is why it is "flying under the radar" of security solutions monitoring for specific crypto API's.