Switching on/off VPN causes lengthy ESET checks

[itman 1,659]

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.

Edited October 5, 2019 by itman

[zamar27 5]

All exist and marked Public. The VPN Connection and Adapter are quickly auto removed from Eset list when VPN is off, and auto added again when its on. It doesn't look like Eset Firewall causes lengthy Eset activity at VPN on/off, but likely some other Eset module, possibly caused by Registry and System file changes at VPN on/off. However, switching Eset System Protection off doesn't alter this pattern, and an open internet browser remains blocked part of the time when it occurs,  i.e. text entry fields and tabs become inaccessible. 

Edited October 5, 2019 by zamar27

[peteyt 393]

54 minutes ago, zamar27 said:

All exist and marked Public. The VPN Connection and Adapter are quickly auto removed from Eset list when VPN is off, and auto added again when its on. It doesn't look like Eset Firewall causes lengthy Eset activity at VPN on/off, but likely some other Eset module, possibly caused by Registry and System file changes at VPN on/off. However, switching Eset System Protection off doesn't alter this pattern, and an open internet browser remains blocked part of the time when it occurs,  i.e. text entry fields and tabs become inaccessible. 

Weird I have a vpn connection in my network bit even when windscribe isn't on. Although not sure if mine is public or home.

[zamar27 5]

I use WiFi  to connect to internet and LAN shared with other people. That's why all my connections are set Public, as the LAN is not strictly safe. Since the WiFi adapter is involved with VPN on and off switching, it may differ what occurs in re-establishing connection since the PC needs to re-connect again directly to WiFi network rather then through extra virtual VPN adapter, and might cause varying Eset pattern compare to physical Ethernet adapter?

Broadly speaking, any VPN connection IS public, otherwise one would invite VPN company staff into your extended "LAN tunnel", which includes the VPN company server instead of your internet provider's server. I tried to switch both connections to Private, no difference in Eset pattern.

Not sure what you mean by "bit even", not necessarily "packet even", which you can easily see the difference with Wireshark btw VPN on and off. 😉

Edited October 5, 2019 by zamar27

[itman 1,659]

2 hours ago, zamar27 said:

The VPN Connection and Adapter are quickly auto removed from Eset list when VPN is off, and auto added again when its on.

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?

[zamar27 5]

16 hours ago, itman said:

I strongly suspect this is the source of Eset ekrn.exe excessive activity you are observing.

I doubt so. You assume that Eset Connected Networks page reflects more, than it really does - it merely shows the "network connection #" status (active=show or inactive=hide). I've several inactive Connections, and none of them is shown on that Eset page, despite all listed in Eset Firewall Advanced Settings.

When VPN is switched off, Windscribe IKEv2 Virtual Network Adapter is NOT deleted. It just marked Disconnected in Windows Control Panel - Network Connections, and WiFi Adapter Properties change to Internet Access. Respectively, Eset hides the VPN connection. 

When VPN is switched on again, Windscribe IKEv2 adapter in Windows CP changes to Connected IKEv2, and WiFi adapter changes to No Internet Access. So basically the PC external IP changes, nothing else. Respectively, Eset unhides the connection again. Its done very quickly in a split sec in contrast with Eset remains agitated for very long each time. More interesting, HDD activity is high at that time on pair with Eset, though nothing is downloaded. Looking at Resource Monitor, system updates some of its big hidden files, logs, and Registry after VPN on/off switch.

The truth is, you were correct from the start suggesting to present Process Monitor log. The problem is, no-one is interested to see it, as you already well understood from Marcos' comments. They're claiming to be forever unaware of any VPN issues, while aggressively refusing to document and fix them even if one devotes 10 pages on this forum to a single issue, as was done in the past. Its clearly absurd Eset company doesn't have a public Bug Report Tracker, while their Support refuses privately to accept VPN related bug reports giving fake arguments instead. As a result, the entire paying Eset community suffers from never documented and fixed bugs.

Edited October 6, 2019 by zamar27

[peteyt 393]

1 hour ago, itman said:

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?

Yeah I don't connect wirelessly - Use a powerline adapter to get my internet to my pc

[zamar27 5]

I want to selectively switch off Eset components one by one to see which one is suffering from Learning disability in this case. My question is, does switching off Eset components have immediate effect (options in Context menu are usually immediately effective), or it would require to sign off / on to Windows or reboot to observe changes in Eset behavior after switching off its components like HIPS etc?

Would you also suggest a good sequence of such tests?

Without relogin or reboot the PC (meaning likely some Eset component functions remain active despite switched off), I found the following:

a) pausing Eset Firewall in Context menu does NOT alter high resource load by Eset at VPN on/off;
b) pausing Eset Protection and Firewall in Context menu does NOT alter this behavior;
c) switching off Eset protection, Firewall, and HIPS with reboot does NOT alter this behavior.

Eset CPU load is especially prominent and lengthy, when a web browser like Chrome with multiple tabs is open at VPN on/off. Why is that?

----------------------------------------------------------------------------

And now I found what causes Eset CPU load. Windscribe at switching VPN on closes all previously open web sockets, and reopens them under a new VPN IP. This is expected behavior to ensure traffic security, it would be unreasonable to disable it, this is namely what users want from a VPN service. The more web sockets are open (multiple browser tabs) the more sockets are reset. Eset EKRN.exe also has web sockets open with Eset servers, and they are also reset at VPN on/off. This is were the missing Eset Learning code would come handy - an obvious Eset deficiency, primarily caused by the fact they refuse to document and fix any bugs related to VPN consumer use, claiming instead there are NONE.

Yet another question is, why Eset keeps bumping CPU when all its active services are switched off, like Firewall, protection, and HIPS? What Eset service is still causing this mis-behavior? Can it be switched off manually as well, or some VPN exception added to it?

So I tested that option: deselected "Force close existing TCP sockets" in Windscribe Preferences. As expected, Eset high CPU load vanished, but not entirely, yet become a lot shorter cycle at VPN on/off. However, switching this option off contradicts prime VPN privacy purpose, and in real life no user would do that simply because some AV has never fixed or acknowledged by staff deficiencies.

Another issue is Eset compatibility with various VPN clients. If some other clients don't have this obviously required feature, and as a result don't re-assign the sockets to a new IP, Eset users would claim better compatibility with these clients like "no issues!!!". But such compatibility is simply the result of VPN client not doing its expected job, its not Eset accomplishment, but rather a serious VPN security gap. So Eset should account for such option even if its missing in some less secure VPN clients.

Edited October 6, 2019 by zamar27

[itman 1,659]

2 hours ago, zamar27 said:

So I tested that option: deselected "Force close existing TCP sockets" in Windscribe Preferences. As expected, Eset high CPU load vanished, but not entirely, yet become a lot shorter cycle at VPN on/off. However, switching this option off contradicts prime VPN privacy purpose, and in real life no user would do that simply because some AV has never fixed or acknowledged by staff deficiencies.

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.

Edited October 6, 2019 by itman

[zamar27 5]

TCPView in Win 10 doesn't seem to list DNS suffixes for any connection at all. 

ipconf /all shows no Primary DNS Suffix for PC, and no Connection-specific DNS Suffix for Windscribe IKEv2 WAN MiniPort, but there's one for WiFi adapter.

In Eset Network Connection  Properties Windscribe connection is identified by specific WINS and DHCP IP addresses, while regular WiFi adapter connection is identified by DNS suffix, adapter type, SSID and security type.

Why do you think that adding a DNS suffix to VPN connection would change Eset behavior? I can add such suffix in the WAN Miniport IPv4 Advanced TCP/IP Settings. VPN uses its own DNS servers if its relevant. This doc might help: VPN name resolution.

Edited October 6, 2019 by zamar27

[itman 1,659]

2 hours ago, zamar27 said:

TCPView in Win 10 doesn't seem to list DNS suffixes for any connection at all. 

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.

[zamar27 5]

I'll try to add DNS suffix to VPN adapter and Eset Network window, and see if it helps. Right now VPN adapter and most svchost processes just use computer name without suffix, except for WiFi adapter some suffix exists. Eset uses other criteria to ID the VPN adapter, its not a problem to ID it, but closing and re-opening sockets triggers lengthy CPU bump, as Eset is not trained to understand what's going on despite it should be as this is normal behavior at VPN on/off, if VPN client is designed for max privacy and security.

Also keep in mind, same VPN adapter DNS suffix will correspond to variety of VPN server IP addresses, since VPN servers are often changed by user from client dropdown menu depending on the website visited. Some websites allow only access to certain things from their home country, or block access from certain countries. So in this scenario, NRPT may play some role, and generally the suffix might be irrelevant to VPN adapter work.

Edited October 7, 2019 by zamar27

[itman 1,659]

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.

Edited October 7, 2019 by itman