Eset Firewall - Resume From Standby Issues

[itman 1,659]

I have had this issue ever since I have had Eset SS installed. That is originally in ver. 8 running on Win 7 x64 and continuing in ver. 9 and Win 10 AU x64. I couldn't get a complete "grip on it" in ver. 8 but with the improved ver. 9 diagnostics, I have been able to nail it down.

 

Upon resume from standby, the Eset firewall is alerting on inbound UDP traffic, to port 53, to my third party DNS server - only primary IPv4 one - from my PC IP address, any port, originating from svchost.exe DHCP service. If you think about this for a minute, appears the Eset firewall is not initializing fast enough and when it does, it borks whatever is in process from the Win firewall. In this case, it appears to be svchost.exe DHCP activity. Again svchost.exe DHCP is only for ports 67/68 and 546/547.

 

Edited September 29, 2016 by itman

[itman 1,659]

Interesting.

 

I did some testing. I first reverted back to using my router's DNS server instead of using third party IPv4 & 6 DNS servers via network adapter settings. Now upon resume from standby, the firewall's default "allow all connections within the computer" rule will allow outbound DNS i.e. port 53 request(multiple) from my PC to the router's DNS server. This same address also happens to be the one for the DHCP server. So I assume the activity being allowed for svchost.exe is for DHCP and not DNS. I can't tell for sure since Eset's firewall logger does not record what service is being used. In any case, at least the activity is somewhat legit outbound activity and not "convoluted" as was occurring previously. 

 

Note the following. I believe the "bug" in the firewall processing is that Eset considers any IP listed in the DNS Servers zone to be a valid local connection. Obviously, third party DNS server IP addresses are not "local connections." Then there is the question why that default firewall exists in the first place in ver. 9. In ver. 8, it existed in the IDS section which is where it should belong in my opinion.

 

Finally, there is still a timing issue with firewall initialization upon resume from standby since the "allow all connections within the computer" rule should only be allowing local host activity.

Edited October 1, 2016 by itman

[itman 1,659]

Finally got this one figured out and it is not an Eset firewall issue.

Today mysteriously the local scope i.e. fec0::/16 addresses showed up again in the firewall DNS zone; namely fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3. This lead me to re-examining IPv6 DNS local scope processing.

First, again I am using a 2Wire/Pace IPv4 router/gateway with AT&T hacked firmware to allow for IPv6 address resolution via 6to4RD tunneling. Appears AT&T also set up a IPv6 local scope DNS server although use of local scope IPv6 was deprecated years ago. So I dug into the old IEFT specification here: https://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-06

 

Basically IPv6 local scope DNS actually uses IPv6 DHCP to resolve to a remote ISP DNS server address. This explains those DHCP requests I originally posted above. I further muddied up the works by attempting to connect to third party IPv6 DNS servers which somehow did work but as I now have observed with a huge browser rendering impact. 

 

-EDIT-

 

I guess I should also explain what the problem was as given in this IEFT excerpt:

 

   This example will show how DHCPv6 and well known site local unicast
   addresses cooperate to enable the internal nodes to access DNS.

   The customer router CPE is configured on its internal interface with
   one of the reserved site local addresses and listen for DNS queries.
   It would act as a DNS forwarder, as in 5.2,  forwarding those queries
   to the DNS resolver pointed out by the ISP in the DHCPv6 exchange.

 

As observed, the first request is a IPv6 DHCP request that returns the address of my ISP's IPv6 DNS server. This address is stored in the router and is used to as the destination remote address for any subsequent local scope based IPv6 DNS requests. As such, it is not possible to effectively use third party IPv6 DNS servers since the router is not equipped to handle such addresses.

 

This router does have DHCPv6 server capability but it is not activated. To do so, I would have to pay for a static IP address.

Edited October 2, 2016 by itman