zamar27

Switch Eset Firewall to Interactive Mode. As to making any updates or adding new features, I've an impression they decided to cut dev positions and projects in Firewall department, so the only thing I see Marcos posting is "we are not aware of any issues with Eset Firewall" - period. When you report bugs, they refuse to document them to support that answer. Existing documented bugs are not fixed for several years and counting - people pointed to it over and over on this forum, while Markos kept repeating "we are not aware" right in the same thread, as if he is unable to read previous posts.

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.

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.

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.

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.

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

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.

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

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.

One such issue was described in Eset Firewall Bugs and multiple similar threads, I now can't find in Archive because full user posts History is not preserved on this forum. Eset Firewall fails to restore settings in Interactive Mode after firewall is switched off while VPN is enabled, and then switched on while VPN tunnel is disabled, or vice versa. Another issue is described in Switching on/off VPN causes lengthy ESET checks. When VPN tunnel (Windscribe being a VPN package example) is switched on or off (in particular when internet browser is open with multiple tabs), it triggers the system to change Windows network adapter, and causes excessive and lengthy CPU and HDD activity by Eset each time (not by the system or browser), as there is no Learning mechanism in Eset for such VPN events. Same activity happens when a user changes VPN server from the same provider's list, as it triggers changing IP address of the Windows VPN network adapter.

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.

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.

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?

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.

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.