Jump to content

jimmerthy

Members
  • Posts

    12
  • Joined

  • Last visited

About jimmerthy

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    U.K.
  1. Thanks for ruling that out itman, I was about to start trying to mess around with the registry, so that's saved lots of wasted time. Anyway, I now have a very clear reason for why it's happening... If I use Microsoft Remote Desktop Connection to access the PC in question then I cannot 'create rule and remember permanently' - the UAC prompt is never shown. If I immediately then switch to using the PCs desktop console and repeat the exact same test, then it works. Same behaviour Win81 or Win10. I've only just noticed this on my Win81 machine (a VM) because I'd switched from administering it via RealVNC to RDP only this week, so that was an unhelpful coincidence. RealVNC emulates the desktop console. In the same way, the Win10 machine (laptop) also behaves fine if I use ESET on it locally. I'd switched to using RDP half way through the long job of setting it up, so I could work on it from another PC with better ergonomics. I hadn't made the connection that when I switched to RDP, ESET interactive firewall prompts stopped working properly. As a workaround I can use RealVNC for a bit, but it would be important for me for this to get fixed.
  2. I am suddenly being affected by this on two computers (Win10 1903 and Win 8.1, both x64). ESET Internet Security 12.1.34.0 The Win 10 computer installation is only hours old, I discovered this during its setup. To reproduce: Switch to Firewall Interactive mode Make an outgoing connection that triggers an ESET interactive firewall dialog Choose 'create rule and remember permanently' then click 'deny' or 'allow' (doesn't matter which for the test purpose) Observe no UAC prompt (normally you'd expected UAC prompt at this point) Observe that the ESET firewall interactive dialog closes Right click on tray icon > Log Files Switch to log type of 'events' Observe 'failed to create rule' event Repeating this with ProcMon collection, I get this suspicious correlation with the time of the ESET event log error... 12:35:53.0120436 ekrn.exe 2576 RegOpenKey HKLM\Software\ESET\ESET Security\CurrentVersion\Config\gui\UI_CONFIG\Notifications NAME NOT FOUND Desired Access: Read 12:35:53.0122737 ekrn.exe 2576 RegOpenKey HKLM\Software\ESET\ESET Security\CurrentVersion\Config\era\gui\UI_CONFIG\Notifications NAME NOT FOUND Desired Access: Read 12:35:53.0125818 ekrn.exe 2576 WriteFile C:\ProgramData\ESET\ESET Security\Logs\warnlog.dat SUCCESS Offset: 3,528, Length: 36, Priority: Normal Sure enough, the 'gui' reg key is missing on both problematic installations. On a Windows 7 installation running the same version of Internet Security, the regkey is present.
  3. I am seeing an empty dialog being displayed more and more recently (Internet Security, Win 8.1 x64, Interactive Firewall). I'm fairly convinced this is one of the interactive firewall pop-ups that has failed to render properly. Alt+F4 won't close it and the only fix is reboot or maybe log off-on again. Here's a screenshot... https://i.imgur.com/NJf7CZH.png I expect it's the same problem as this from 2013 with no obvious resolution... https://forum.eset.com/topic/1403-smart-security-7-pops-up-empty-window-that-can-not-be-closed/ UPDATE This issue is likely linked to interacting with a PC that runs ESET Smart Security via Microsoft Remote Desktop Connection.
  4. I have made some progress with further understanding this problem by using the Setup > 'Import/Export settings' (to XML) feature. Export settings from a freshly installed ESET Smart Security and search for 'stZones' using something like Notepad++. Five zones are defined in the .xml that follows this string. These correspond to the default zones visible in Advanced Setup > Network Protection > Firewall > Advanced > Zones. Each zone in the .xml has a 'zonedID' which is a GUID. Through experiment (WinMerge / Beyond Compare useful diff tools), my conclusion is that these default zones should have special reserved GUIDs. Trusted Zone 'ffffffff-ffff-ffff-ffff-ffff80000000' The other default zones (I'm not sure which is which) 'ffffffff-ffff-ffff-ffff-ffffa0000000', 'ffffffff-ffff-ffff-ffff-ffffa1000000', 'ffffffff-ffff-ffff-ffff-ffffc0000000', 'ffffffff-ffff-ffff-ffff-ffffd0000000' On installations of ESET Smart Security exhibiting the problem (Error: nonexistent zone), the GUIDs for these built in zones have all been changed to random GUIDs. Performing a very careful find and replace of these zoneID GUIDs in the exported .xml to restore their special reserved values, followed by an .xml import, appears to restore proper functionality. 'Error: nonexistent zone' disappears and the 'DNS Servers' and 'Local addresses' zones once again show IP address information. I've fixed a couple of these broken installations now using this approach. I would caution anyone considering doing this that it's probably very easy to screw up the XML with unknown consequences, possibly compromising protection etc. I would hope that if ESET reads this then they're one step closer to reproducing it for themselves. I imagine it would be quite easy for them to roll out an update that detects these incorrect GUIDs, fixes them silently and restore normal functionality.
  5. I have sufficient licenses. The VM has its own license, as does the host. There is a laptop (Win10) on the network that's also showing the exact same issue that I'm seeing on the VM (Win81) so this isn't a VM thing. I created a new Win81 VM and installed ESET Smart Security 30 day trial and everything seemed to work correctly when I added new rules constrained to Trusted zone, so it does appear that in the lifetime of these problematic ESET installations, something has broken its detection of connections or its database of connections. One possibility comes to mind ihat it could be the result of some over-zealous Windows hardening (group policy changes, windows service disables). It'd be interesting if someone from ESET could say what intrinsic Windows services it relies upon and whether this reported issue could potentially be caused by something that's been disabled or misconfigured in the OS. Like zamar27, I just tried creating a new zone (e.g. with the IP range of my DHCP pool at home) and then changing the broken 'Trusted Zone' assignment of one of the firewall rules to use the newly created zone. This assignment worked correctly in that the chosen zone shows up correctly without reporting 'Error: nonexistent zone' as it does for Trusted Zone. As I said before and zamar27 reports, it appears that the firewall is operating much closer to correctly than to incorrectly. Unknown process outgoing connections are met with the expected pop-up dialog and incoming connections are being blocked as I would expect for the couple of tests I performed. Evidence that something reasonable is actualy being computed for the 'Trusted zone' is borne from going to "Setup > Network Protection > Connected networks > Network adapters" and then looking at the 'Trusted zone' column. In my case, on machines that exhibit the problem, this column entry reports a correct-looking subnet. I agree this is probably better raised as a direct support enquiry to ESET, which I will do and I'll reference this thread.
  6. So yes I agree that the weird bit seems to be the lack of anything populated in 'DNS Servers' and 'Local addresses' in Advanced Setup > Firewall zones. On a machine affected by this problem, if I go to Setup > Network Protection > Connected networks > Network adapters, I can see that for the affected adaptor, Trusted Zone does have a sensible entry (192.168.1.0/24). Well, at least this matches what I see in the same dialog on a machine on the same network that's not affected by the problem.
  7. I've just checked this over more carefully as I now have a bit of time. 'Wired network 1' has been set with ESET 'protection type' 'Home or office network'. Windows' category for the network was set to 'public' (so in disagreement). I just flipped the Windows network to 'private' by setting Profiles\{GUID}\Category to '1' for the appropriate adaptor in Regedit and rebooted. It came back up as private as expected. I then changed the ESET 'protection type' to 'Use Windows setting' to hand control back to Windows so to speak. I was maybe hoping that would get rid of the 'Error: nonexistent zone' but it didn't.
  8. no, there's no domain controller, it's a home network. I'm not sure where 'localdomain' has come from actually. Its DHCP server is set to 192.168.254.254 but my home router is 192.168.1.1. Anyway, ESET > Home > Connected Home Monitor reports that 'Wired network 1' is the network that's in use. The machine is a VM and it's sometimes connected via VMware Workstation's NAT and sometimes via Bridged, I suspect the 192.168.254.254 network may be VMware's NAT virtual network router. I had come to assume that Window's network classification (public vs. private) sort of corresponded to ESET's (not Trusted Zone vs. Trusted Zone). I've often wondered whether I'd be in a less confusing world if I let ESET manage whether a network is 'Public' or 'Home or office network' (prompting user on each new connection) rather than relying on 'Inherit from network adaptor'. I can't find the reference now, but I'm under the impression that Windows native UX now makes it difficult (or at least unintuitive) to change to/from private & public (if for example it was set up wrong the first time).
  9. Thank you for all the replies. Here's a screenshot of the 'Known Networks' dialog.
  10. I run Internet Security with Interactive Mode firewall on several computers. When I apply "Trusted Zone" as a remote IP constraint in a firewall rule, it shows up as "Error: nonexistent zone" in the "Remote" column of the table of firewall rules. What's going on? Thanks
×
×
  • Create New...