itman

I would say "hell would freeze over" first before Eset ever adds full wildcard support to either the firewall or HIPS. It has been a feature requested for years by multiple Eset users and "panned" by Eset with statements like "it will most likely be added in an upcoming future release," etc..

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.

Forget the DNS suffix bit. From what I see in this posting: https://www.reddit.com/r/Windscribe/comments/9o0bx6/windscribe_tries_to_route_rfc1918_lan_traffic_to/ based on the ipconfig /all display, no DNS suffix exists for the VPN connection. Using ipconfig each time you switch WindScribe off/on, check the shown IPv4 address for the WindScribe VPN connection. If it remains the same, add that IP address to Eset's VPN network connection for WindScribe local IP address field and see if that makes a difference.

To begin with, files the begin with "\\?\ are not virtual files. This is how Windows reference files locate in the C:\Windows\WinSxS directory. You can try specifying that path but it will still be an effort in futility since the file names for Win Store apps and the like are constantly changing. And its not just Win Store apps that have constantly changing names. Win system apps including Windows Defender do likewise. One reason Eset included the specification in Network Protection to allow Win firewall inbound apps was to accommodate this activity. And many of the above apps do auto updating of the Win firewall to accommodate this. I have previously mentioned about Eset also using the Win firewall outbound rules likewise to accommodate this activity. It appears that this is something that the Eset firewall in its present Interactive mode isn't capable of handling.

This subject has come up many times in the past. The Eset firewall doesn't support wildcard notation for executables. If one insists on using Interactive mode, one will be getting an alert whenever the app .exe changes path name; real or virtual.

My ISP is AT&T. The below TCPView local address screenshot shows "attlocal.net" appended to my assigned internal PC name. Eset's Network Protection primary ID method for my Ethernet adapter is the same DNS suffix: What my PC name.attlocal.net in TCPView converts to is the local IP address assigned by the router via DHCP for my PC; e.g. 192.168.1.xxx.

Eset's network connection detection is very much conditioned upon IP address connection. Like I posted previously, see if there is a DNS suffix that the Windscribe VPN uses. An IP connection monitor like SysInternals TCPView: https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview should show that suffix when the VPN connection is active. Most likely the connection established for the WindScribe .exe. Then assign that suffix to the Eset VPN connection and see if that helps.

I strongly suspect this is the source of Eset ekrn.exe excessive activity you are observing. As @peteyt posted, his Eset VPN connection is not be deleted and recreated each time the VPN is stopped and started, As you posted previously if the network adapter connection VPN mini-port filter is likewise being deleted and added at each VPN stop/start event, this most certainly would be the cause. Perhaps the Wi-Fi Internet main network connection is the source of the VPN adapter connection being deleted from Eset? @peteyt is your main Internet connection Ethernet or Wi-Fi?

The only other thing I can think of is your VPN adapter connection is not properly set up in Eset firewall Known networks section. There should be two network connections shown there; one for your non-VPN adapter connection and one for the VPN connection, The VPN connection Network Identification data should show a network adapter type of "Virtual adapter (VPN, tunnel, ...)". Also there probably needs to be other identifying info specific which can only be DNS suffix as I see it. If the VPN network connection doesn't exist, you will need to set up one manually.

Also if you presently don't have a firewall rule to allow all inbound and outbound traffic, all protocols, all ports for the VPN executable, I would create one and move to the top of the existing firewall rule set. This in theory at least should allow all VPN traffic regards of IP address changes or the like.

Save yourself some time and stop looking. There is no option in the Eset GUI for 12.2.30 in regards to enabling AML. That won't exist until ver. 13. The scenario here is the same prior to when advanced behavior blocking was implemented. That is the feature in the form of the module being present is fully functional as far as I am aware of.

Does the behavior you're complaining about occur if the firewall is set to default Automatic mode?

It's there on my pre-released EIS ver. 12.2.30 installation: Detection Engine: 20128P (20191004) Rapid Response module: 15010P (20191004) Update module: 1018.1 (20190709) Antivirus and antispyware scanner module: 1555 (20190911) Advanced heuristics module: 1194 (20190918) Archive support module: 1292 (20190911) Cleaner module: 1200 (20190916) Anti-Stealth support module: 1155 (20190918) Firewall module: 1391.1 (20190912) ESET SysInspector module: 1275 (20181220) Translation support module: 1763 (20190916) HIPS support module: 1373 (20190916) Internet protection module: 1380 (20190920) Web content filter module: 1071 (20190605) Advanced antispam module: 7827 (20191002) Database module: 1110 (20190827) Configuration module (33): 1788 (20190719) LiveGrid communication module: 1054 (20190724) Specialized cleaner module: 1013 (20190627) Banking & payment protection module: 1160 (20190918) Rootkit detection and cleaning module: 1019 (20170825) Network protection module: 1682P (20190801) Router vulnerability scanner module: 1063 (20190724) Script scanner module: 1055 (20190924) Connected Home Network module: 1031.1 (20190621) Cryptographic protocol support module: 1040 (20190913) Databases for advanced antispam module: 3582P (20191004) Deep behavioral inspection support module: 1082 (20190716) Advanced Machine Learning module: 1034 (20190919)

https://forum.eset.com/topic/19083-eset-firewall-bug/

The "big enhancement" in ver. 13 is advanced machine learning. Just enable Eset pre-release updating in your current Eset ver. and you will receive the AML module.

OP is now "ranting" about Eset lack of VPN support in another thread. As @Marcos stated in that thread, Eset doesn't guarantee VPN compatibility. My take is Eset and assumed other AV vendors make reasonable "accommodations" in their software for VPN use. This would include the assumption VPN use is the norm; starts at boot time and disables at system shutdown time. Repeatedly turning VPN off/on during system up time would be one event I suspect AV's across the board might not anticipate and would respond to accordingly.

Post a screen shot of the Eset Detection log file or post individually event entries showing what malware Eset has detected. Eset can't clean a file containing malware if its an OS system or like critical file since it could bork your PC operation.

As far as I am aware of, you are the first to report this issue on ver. 12.2.30 which fixed the problem for most. Did you upgrade to 12.2.30 via Eset in-GUI upgrade? Or download full ver. and install on top of Eset prior ver. or from scratch after uninstalling the prior Eset ver.? Did the Eset firewall turn on after clicking on the "Turn on" tab in Windows Security Center? After doing this, open Control Panel -> Windows Defender Firewall and verify it states Eset is managing the Windows Defender Firewall. Reboot the PC and see if the issue still persists. Also WSC shows both Eset and MBAM real-time protection enabled. MBAM real-time protection might be the conflict here. Suggest you turn off MBAM real-time protection and only use it as an on-demand second opinion scanner.

All I can say is try another AV and see how it performs in this on/off VPN scenario. I saw one VPN provider recommend that their executable should be excluded from the AV's real-time scanning. Something I would never recommend but "each to their own."

If WinScribe is using a network adapter mini-port filter driver and uninstall/reinstalling it every time the VPN is turned off/on, I could see how Eset might go "bonkers" with that type of activity. Turning off WinScribe via its "firewall" option should not result in the mini-port filter driver being removed.

Here's something you can check out. Open the Eset GUI and open Tools -> Scheduled Scans. See if a scheduled Eset scan; e.g. startup scan, has a time that syncs with your disabling/enabling the VPN. Why this would be so, I have no clue. But it would explain the high CPU usage from ekrn.exe. Also a 50% CPU usage by ekrn.exe for a short duration of a few minutes is not considered excessive CPU usage in my book. Especially on a multi-core CPU.

Sure you never installed security software along the lines of MalwareBytes Anti-malware, etc.?

Windscribe VPN doesn't use a "killswitch" per se but rather what they refer to as a firewall for a Network Lock: https://windscribe.com/faq Assuming you are using the "Manual" mode to in essence turn the VPN off/on, it is this feature that in all likehood is causing the high processing activity by Eset. Based on everything I have observed in regards to Eset Network Protection features including the firewall, it is fine under normal VPN use. That is you enable the VPN at boot time and you leave it on.

What VPN are you using? As far as most VPN's go, Eset would just be firewall monitoring all inbound traffic from the VPN executable. Switching the VPN on/off in a short period multiple times might cause Eset to be constantly reestablishing a new network connection for the VPN. Eset might also consider such activity as potentially malicious and will switch to full protection mode resulting in the increased Eset kernel CPU activity you are observing. @Marcos will most likely require a process monitor log that has recorded all activity from time VPN is switched off till it is switched on. Also logging should be performed after previous VPN on/off cycling has caused high Eset kernel activity. Also rather than turning the VPN on/off is there a way to pause the VPN from monitoring network traffic?

Be as descriptive as possible in your postings. None on the forum are "mind readers." Appears you are referring to one of the most recent STOP ransomware variants. As such, this is not "new" malware: https://malwaretips.com/blogs/remove-nesa/ As noted in the malwaretips.com article, there is presently no decrypter available for this STOP ransomware variant. Are you stating that Eset failed to detect this variant?