Eset Not Monitoring IPv6 DNS Connections

[itman 1,728]

This is really getting aggravating. With all the past issues I have had with Eset not properly recognizing my IPv6 connections, this is the latest.

Ever since I have been on ver. 14.2.14, ekrn.exe is not monitoring my Win 10 IPv6 DNS connections when resuming from sleep mode after a prior Win 10 sign-off. It is also a "hit-or-miss" occurrence; sometimes ekrn.exe shows IPv6 DNS monitoring occurring; sometimes not. What works every time is if I open a command prompt window and enter "ipconfig /all" wallah, ekrn.exe immediately starts monitoring IPv6 DNS connections. 

[itman 1,728]

I am going to post some additional info. about this situation.

First is the below screen shot showing Eset firewall fully recognizes that IPv6 DNS servers exist on the local network:

However Eset Network Connections shows ekrn.exe is oblivious to the fact that a IPv6 connection exists. Further confirmed in TCPView network connection display:

Today upon resume from sleep after prior logon, I started Firefox and for a very brief instance, Eset created a ekrn.exe connection for IPv6 and then immediately dropped it. Again, only ipconfig /all gets ekrn.exe to permanently register that an IPv6 connection exists.

Note that I have LLMNR permanently disabled via Win 10 means. This caused no issues till recently and I can't fathom why Eset would be using it internally for IPv6 detection.

Edited August 19, 2021 by itman

[itman 1,728]

My latest test scenerio.

Performed Ipconfig /flushdns -> ipconfig /release6 -> ipconfig /renew6. At this point, a new IPv6 session established. Performed a bit of web surfing.

Signed off PC. Entered standby mode via Win 10 lock screen option. Waited a bit. Resumed from sleep mode.

At this point, ekrn.exe did recognize that IPv6 exists.

Problem is I have done this previously only to have this issue resurface.

[itman 1,728]

Well, that didn't last long. Upon next resume from sleep mode, back to old non-detection behavior.

Next test. Opening Win 10 network settings, also causes ekrn.exe to immediately recognize IPv6 DNS connection.

It really appears that Eset has an issue properly recognizing existing Win 10 network settings in regards to IPv6 upon resume from sleep mode.

[itman 1,728]

Found what is causing this. -EDIT- No, this didn't resolve the issue - see below posting.

It results when Win 10 Web Services Discovery service is disabled in Eset firewall settings. If disabled, all its associated inbound traffic is blocked. However, I am using the Public profile, so all inbound WSD traffic should be blocked anyway. Why Eset has a IPV6 DNS connection existence test using this service is beyond.

The reason I disabled WSD service in the first place is Eset's Public profile is not blocking inbound UDP traffic from other devices on my network to my PC.

Edited August 23, 2021 by itman

[itman 1,728]

Finally, I was able to get Eset not to drop IPv6 connection monitoring after resume from sleep mode. 

The issue traces to the Win 10 smart multi-homed name resolution feature:

Quote

Smart multi-homed name resolution is a DNS related feature that Microsoft introduced in Windows 8 and implemented in Windows 10 as well.

The feature is designed to speed up DNS resolution on a device running Windows 8 or newer by sending DNS requests across all available network adapters. Microsoft refined the feature in Windows 10 as it selects the information that is returned the fastest automatically.

https://www.ghacks.net/2017/08/14/turn-off-smart-multi-homed-name-resolution-in-windows/

Since I am running Win 10 Pro, I was able to disable this feature via Group Policy which is the only way it can be disabled. Note I have both LLMNR and NetBIOS disabled for security reasons:

Quote

Do the following to open the Group Policy Editor in Windows: Tap on the Windows-key on the keyboard, type gpedit.msc, and hit the Enter-key on the keyboard.

Go to Computer Configuration > Administrative Templates > Network > DNS Client > Turn off smart multi-homed name resolution.

Set the policy to enabled, to disable the smart multi-homed name resolution feature of the system.

If you enable this policy setting, the DNS client will not perform any optimizations. DNS queries will be issued across all networks first. LLMNR queries will be issued if the DNS queries fail, followed by NetBT queries if LLMNR queries fail.

Edited August 23, 2021 by itman

[itman 1,728]

I forgot to mention that Eset is still dropping ekrn.exe monitoring of IPv6 connections after resume from standby mode with Smart multi-homed name resolution disabled after Eset's initial connection monitor gyrations are completed. The difference now is the first IPv6 outbound traffic after this time reestablishes ekrn.exe IPv6 monitoring.

[itman 1,728]

On 8/23/2021 at 4:04 PM, itman said:

Smart multi-homed name resolution

Well, disabling Smart multi-homed name resolution lasted for a few hours and the prior dropping of IPv6 monitoring by ekrn.exe upon resume from sleep mode continued. So I reset everything back to initial settings; LLMNR and Smart multi-homed name resolution enabled.

First, note I use Eset Public firewall profile on a local Ethernet connection. As such, nothing local subnet-wise is trusted by the Eset firewall.

I then happened upon a great series of articles on the web in regards to IPv6 and LLMNR. The first thing noted by the author is LLMNR is N/A in Win 10 as long as Win 10 network discovery is disabled which it is by default. So my security concerns about LLMNR were unfounded. Then the author got into LLMNR IPv6 address assignment; namely ff02::1:3. In a second article, he referred to LLMNR IPv6 address assignment via global reference; namely ff00::/8. Whoa, I had seen that reference in an Eset firewall default rule; the rule for IGMP. Now I had previously disabled that Eset service since I did not do any external multi-casting activities. So I re-enable the IGMP service which in turn activated the Eset default firewall rule for IGMP. Again and very important is these default IGMP rules allow unrestricted inbound LLMNR activity via its ff00::/8 IP address specification. I rebooted and everything is back to normal Eset-wise.

Bottom line here is my ISP provided router does not have IPv6 circuitry to support a IPV6 DNS server. Rather the router assigns a pre-allocated IPv6 DNS server from its poll of reserved servers. All this is done via LLMNR IP addresses via the router at system startup time.

-EDIT- Well in spite of the above statements, resume from sleep mode after prior Win 10 sign-off still dropped ekrn.exe IPv6 connection monitoring. So I did a full Win 10 based network reset. After scheduled system shutdown and restart, I got an Eset new connection detected alert. Reviewing what Eset set up for that connection, it created an IPv6 DNS server entry for the local network IP address the router forwards its external DNS server DNS traffic to. Also my IPv6 gateway address was created in the gateway section. I then proceeded to add those two entries to my prior Eset created network connection. I then deleted the new network connection Eset created. Finally ..... now Eset is not dropping the ekrn.exe IPv6 monitoring upon resume from sleep mode.

I previously never had to be this specific when setting up an Eset firewall network connection. So Eset has modified something in regards to IPv6 DNS in this latest version. I also pity the poor Eset user that may have a router similar in configuration to mine and probably is oblivious to this activity occurring.

Edited August 25, 2021 by itman