Jump to content

zamar27

Members
  • Content Count

    112
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by zamar27

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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. 😉
  7. 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.
  8. 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. 😏
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. Consumer VPN use is widespread now. Eset 12 has many bugs related to VPN use, and the devs are negligent in fixing these bugs. In fact they're never fixed for years, and the impression is, Eset package is simply not tested by devs to be continuously used in consumer VPN environment. Eset also has no controls or interface features related to VPN use. Examples are regular excessive lengthy Eset CPU and HDD load when switching VPN on and off. Also Eset Firewall failure to restore settings in Interactive Mode after firewall is switched off while VPN is enabled, and then switched on while VPN is disabled, or vice versa. When reading Eset Help docs, the impression is Eset team purposely ignores the overwhelming trend on the consumer market during last years of using VPN, and devotes no technical or knowledge base articles to this very issue. Further, when contacting Eset support, they bring every fake reason to refuse investigating issues related to Eset failures to work properly in VPN environment. In Help docs, Eset writers make it look that VPN is only used and of interest to enterprise market, and consumers should not ask any questions, or report any bugs related to Eset consumer products systematically failing for years to work properly with VPN. Instead of saying "Thank you" for reporting never fixed bugs, Eset reps claim they can't find one's license, or its expired, or how it was obtained etc, trying to find a reason to refuse the bugs investigation. Meanwhile, reporting bugs is users free gift to Eset, and the bugs must be fixed to benefit all paying and testing product customers, regardless who reported them and under what conditions. Most large companies have Bug trackers where anyone can enter bugs, it does NOT require any license proof at all, because bug reports are free donations to the very rich Eset company, allowing it to get ever richer. On this forum, Eset reps also systematically ignore all user posts and threads related to VPN issues with Eset. This seems to be thick culture within Eset company of aggressively ignoring and denying existence of burgeoning consumer VPN market, thus making Eset less and less attractive to consumers despite cosmetic changes in slightly updated new product versions. I know my post will be deleted, ignored again, or attacked by Eset paid guns, who also attacked them in the past, while Eset has no intention to change this ill long obsolete culture of ignoring consumer VPN market.
  19. 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.
  20. Is it possible in the next ESS version to add "Remove Threat" or "Select Action" button to a last scan log of each scan type, even if a user did not select any action immediately after the scan was completed and instead rebooted the PC? In this scenario, if ESS removed a threat upon reboot, the Action button would no longer be visible against this threat in the log. If the treat file was later manually moved by a user to another folder, upon selecting an Action the user would get an Error "no file found". Also, a user should be able to select multiple threats from the log to choose a common action. Now there's a problem with manual threat removal. I scanned my PC yesterday, and got a long list of "potentially unwanted application - action selection postponed until scan completion" records in the Eset Smart Scan Log done with default settings (i.e. Default Cleaning Level - no auto removal of unwanted apps). BUT... there was no way upon scan completion to choose an unwanted app from the log and select an Action!!! In addition, probably due to ESS yesterday's module update, my PC went to sleep and failed to wake up properly, so I needed to reboot. Upon reboot I could access the last ESS log, BUT... there're again NO ways to select any action (like: Remove) in that Log window or any other window. Why then I did the 2-hour scan, if no ways to do any action after that?
×
×
  • Create New...