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 post
  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
  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
  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 f
  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 switche
  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 include
  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 sys
  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 co
  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 u
  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
  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
  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
  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 switchin
  20. Same endless headache here. Eset staff doesn't acknowledge the issue exists, and therefore there is nothing to fix. 😉 Very convenient!
  21. If you ask about "Firewall in Interactive Mode On/Off bug", its more complex than your basic case. I can't repeat your case, since I already have plenty of rules created in Interactive mode. In addition, I mostly use VPN when browsing the web due to local WiFi insecurity. And any VPN client uses its own virtual adapter, so the network adapter is changed, when switching VPN client on and off. - Suppose you have rules created for many different apps in Interactive mode, as well as Win 10 default activities like DNS traffic etc. - Eset Firewall is active. Disable VPN, browse the web. Laun
  22. This bug was reported for awhile. When its going to be fixed? Does Eset have a Bug Tracker accessible by users similar to Bugzilla?
  23. So it makes sense to upgrade to Win 10. One can read more about protected processes in Protecting Anti-Malware Services.
×
×
  • Create New...