Switching on/off VPN causes lengthy ESET checks

[zamar27 5]

I use VPN often for security reasons when browsing, but some sites and activities require VPN switched off to access. When I switch VPN on or off, Eset starts heavy CPU and HDD activity for 3-4 min each time. Its unclear what causes this Eset disturbance but repeated every time regardless of VPN protocol used, and its near impossible to do other tasks on the PC during it. I tried to put VPN exe files exempt, but it didn't change anything. What can trigger such Eset activity, and how to avoid or mitigate it? Its suppose to learn from previous checks, why it doesn't? One can check it by switching *any* VPN on and off, so it may require no logs from the user.

[itman 1,746]

1 hour ago, zamar27 said:

Eset starts heavy CPU and HDD activity for 3-4 min each time.

Post a screen shot of ekrn.exe CPU utilization using Process Explorer or Win Task Manager when this occurs.

 

[zamar27 5]

How this screenshot can help? 😉

 

Edited October 3, 2019 by zamar27

[itman 1,746]

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?

[zamar27 5]

I use periodically various VPN vendors. The above pic is after Windscribe VPN is switched off. It goes for 3 min like this, you can try it yourself while a web browser is open with a few active tabs, as they offer 10GB free. I never frequently switch VPN on/off, may be once in 2-4 hours. However, the above pattern always the same each time VPN is switched on or off, meaning VPN connection is disabled (or paused if you will) and the PC switches to open Ethernet or WiFi. I realize that methods to change network adapters might differ for various VPN clients, meaning Pause may work in a different way.

Exiting (closing) or starting the VPN client doesn't produce much effect with Eset, only switching connections, including changing used VPN servers from the dropdown client list. I noticed that the shorter the switch cycle, the shorter the Eset activity cycle. I.e. If VPN is switched 2nd time off 2 min after previous On/Off, Eset CPU raise is shorter compare to VPN switched off after some web browsing for 1 hour. It looks like a short term Eset "learning", but the learned result is not kept after awhile.

Edited October 3, 2019 by zamar27

[itman 1,746]

Windscribe VPN doesn't use a "killswitch" per se but rather what they refer to as a firewall for a Network Lock:

Quote

What are the firewall modes?

Choose the mode that suits you best.

• Automatic (Default) - Firewall will be enabled when you connect, and disabled when you disconnect from a location. It will remain on if your connection suddenly drops. You should leave it in this mode unless you know what you're doing.
• Manual - You can toggle the firewall on or off whenever you want.
• Always On - Firewall is always on, and cannot be disabled unless you change this setting. You will not have any Internet access when you're disconnected from Windscribe.

 

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.

Edited October 3, 2019 by itman

[zamar27 5]

5 hours ago, itman said:

 

@Marcos will most likely require a process monitor log

I reported Eset bugs related to VPN use in the past, and Marcos never shown any interest in investigating and fixing these bugs, and neither required any logs whatsoever. Further, when contacting Eset support, they put every effort to deflect such requests, switching to licensing issues instead of saying "Thank you for reporting. Will investigate it right away"!!! Further, they spend tons of time trying to find out where one got her license rather than concentrating paid by consumers efforts on fixing these bugs. And finally they do refuse to fix obvious bugs, as if the reported bug is not an issue for every other Eset paying customer, but the single user license is paramount issue, even when she has a fully legit license.

Edited October 3, 2019 by zamar27

[zamar27 5]

1 hour ago, itman said:

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. 

No, its not. Switching Windscribe firewall switch on and off produces no notable or lengthy effect on Eset activity. Switching Windscribe VPN on or off does, i.e. changing Windows network adapters, or resetting currently used adapter (i.e. changing VPN server IP).

Its not "fine" like you say, its very annoying frequent customer time stealing Eset bug or lack of proper learning code. And I don't know many folks who use VPN all the time regardless of activity. VPN traffic paid quota is often limited, so no need to use VPN for example while watching multi-episode subscribed Netflix TV shows.

Edited October 3, 2019 by zamar27

[itman 1,746]

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.

[zamar27 5]

 

2 hours ago, itman said:

50% CPU usage by ekrn.exe for a short duration of a few minutes is not considered excessive CPU usage in my book.

Are you kidding? Its not startup scan, happens every time one switches network adapters by VPN on/off. There is no new data to check several mins, for that time one can check a huge newly downloaded software installation package. The proper code is just missing to enable Eset learning for the common task of changing Windows network adapters by switching VPN tunnel on/off.

Edited October 3, 2019 by zamar27

[SRT 1]

I use a VPN no problem at all. Just not Winscribe.

Stopped using Winscribe, I do not trust them, plus don't like their stupid little immature  remarks like when uninstalling, or any changes.

Stupid me bought a life-time license from them. 

[zamar27 5]

10 minutes ago, SRT said:

I use a VPN no problem at all. Just not Winscribe.

What VPN service? What protocol? What do you mean under "no problem"?

What Windows network adapter (name) is used while traffic goes through VPN server? Does it change when VPN is switched off? Do you observe any Eset activity at that time?

Edited October 3, 2019 by zamar27

[itman 1,746]

5 minutes ago, zamar27 said:

What Windows network adapter (name) is used while traffic goes through VPN server? Does it change when VPN is switched off? Do you observe any Eset activity at that time?

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.

[zamar27 5]

3 hours ago, itman said:

 uninstall/reinstalling it every time the VPN is turned off/on

I didn't say anything like that. Turning off VPN firewall is NOT equivalent switching VPN traffic off, it only allows for some direct traffic outside VPN tunnel, while the tunnel is active, and its hard to control what goes through the tunnel. For example, by switching VPN Firewall off, one can then use direct connection for a VoIP app, if it allows to choose a network adapter. I was talking about switching VPN tunnel completely on or off (which results in changing network adapter).

Also, changing network adapter IP like its done when choosing a different VPN server is not equivalent to uninstalling the adapter. Try yourself to change your network adapter IP. Your comments show lack of attention. More important is, Eset team does nothing to address multiple various VPN related user concerns.

Edited October 4, 2019 by zamar27

[itman 1,746]

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."

Edited October 3, 2019 by itman

[peteyt 396]

I believe I have windscribe installed but rarely use it but cant remember any issues. Will try tonight to see if I can see your issue. I presume you are on the latest eset version? Also is this with pre-release updates enabled

[itman 1,746]

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.

 

Edited October 4, 2019 by itman

[zamar27 5]

24 minutes ago, peteyt said:

Also is this with pre-release updates enabled

No, because there are usually no fixes in ongoing Eset versions related to improved VPN support, only unclear claims of "no guarantees" never supplemented by any effort to resolve reported multiple times bugs. This seems to be an obsolete marketing policy, making it look like consumers don't use and neither need any VPN support of GUI features in Eset, so its only for commercial customers.

 

11 minutes ago, itman said:

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.

If true this is wrong and obsolete assumption, given variety of tasks performed by users on PC, overwhelming popularity of VPN services among consumers, and traffic quota limitations of VPN consumer subscription plans.

Edited October 4, 2019 by zamar27

[peteyt 396]

1 hour ago, zamar27 said:

No, because there are usually no fixes in ongoing Eset versions related to improved VPN support, only unclear claims of "no guarantees" never supplemented by any effort to resolve reported multiple times bugs. This seems to be an obsolete marketing policy, making it look like consumers don't use and neither need any VPN support of GUI features in Eset, so its only for commercial customers.

 

If true this is wrong and obsolete assumption, given variety of tasks performed by users on PC, overwhelming popularity of VPN services among consumers, and traffic quota limitations of VPN consumer subscription plans.

Firstly what I believe Itman was stating was the fact that if someone kept turning a vpn on and off multiple times eset might look at this suspiciously - not the enabling/disabling but the fact it was happening multiple times.

I have just loaded Windscribe connected and then disconnected and noticed no massive change with eset and my system didn't crawl - and using windscribe a few times in the last few months I have never noticed what you described. While it probably won't help - make sure you are using the latest version of eset with pre-releases enabled - sometimes things are fixed that were causing multiple issues but people don't update and don't realise - it could be that eset didn't even realise the thing they fixed was also causing other issues. 

[zamar27 5]

2 hours ago, peteyt said:

I have just loaded Windscribe connected and then disconnected and noticed no massive change with eset and my system didn't crawl

I don't switch it on and off endlessly, may be once in 2-4 hours.

Enable Eset Firewall Interactive Mode (not sure if relevant, but this is my case), switch on Windscribe IKEv2 VPN, open Chrome in Win 10 with multiple tabs, work with it. Then disable Windscribe VPN. Watch lengthy Eset activity. Now enable Windscribe VPN again. Watch lengthy Eset activity again. Wait 30 min, then repeat to watch the same.

If you just started Windows and then switched Windscribe on/off, Eset activity will be much less, since there's no network action at that time from the system and other packages.

Edited October 4, 2019 by zamar27

[itman 1,746]

25 minutes ago, zamar27 said:

Enable Eset Firewall Interactive Mode

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

[BaldNerd 3]

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

[peteyt 396]

49 minutes ago, itman said:

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

I should add I use automatic right now which might be why I haven't had any issues

[itman 1,746]

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.

[zamar27 5]

Thank you guys. Tried everything suggested above, and it didn't work. In Firewall Automatic mode duration of Eset activity at changing network adapters (switching VPN on/off) seems a bit shorter. A peace of Eset code needs to be added to "learn" such network adapter or its IP changes as "normal" when triggered by manual VPN status or server change. Some related controls must be added to Eset GUI. That missing code can't be substituted by good forum advice. 😏

Edited October 5, 2019 by zamar27