ESET LiveGrid servers cannot be reached and limited Direct Cloud errors after upgrade to v17.0.15

[rocketman1980 0]

Hello.

Long time user of Smart Security. I upgraded to 17.0.15 yesterday from 16.2.15, and ever since I've been getting regular notifications 'The ESET LiveGrid servers cannot be reached' and 'limited Direct Cloud'. After Eset updated automatically and I first got these errors, I uninstalled and clean installed using the Eset uninstaller. This made no difference. The computer, Windows 11 23H2, has no other firewall installed. The only other firewall that Eset is behind, is the one built-in to my Vodafone router. I disabled this, and this also made no difference. What has solved the issue is rolling Eset back to 16.2.15. Before I did, I created a log using the log collector. In effect, v17 has connection issues on a computer that v16 doesn't using the same hardware and identical configuration.

essp_logs.zip

[Marcos 5,107]

There is no difference between v16 and v17 in the communication with cloud servers. Please enable advanced direct cloud logging under Tools -> Diagnostics in the advanced setup. When the error occurs, collect logs with ESET Log Collector and upload them here.

[Corso 1]

Yes, i have same problem here. Getting annoying every now and then it just popsup and warning it can't reach these Eset "live Grids" message. It has been like this with earlier versions and it took some time before you fixed it. 

v16 don't have this bug so obviously there is something not working right with 17.

I did a clean install when installing v 17.0.5. I used your purge tool in fail safe mode and cleaned out all of v16 first. Installed with the setup.exe installer. I'm on regular channel. We shouldn't have to use "pre-release" for bugs like this.

Using Windows 10 Pro x64. 22H2 Eset Internet Security 17.0.5.

So how to fix it?

Edited November 26, 2023 by Corso

[itman 1,676]

Are either of you using a VPN?

[Corso 1]

No, i'm not using VPN. Internet works fine. Everything works fine, Just this message pop ups from time to time. Then after a minute or 2, then it vanish again and so on.

[rocketman1980 0]

No VPN here either. No issues after running v16 for 20 hours, and as soon as I update to v17, the connection issue pop-ups start appearing immediately!

[rocketman1980 0]

16 hours ago, Marcos said:

There is no difference between v16 and v17 in the communication with cloud servers. Please enable advanced direct cloud logging under Tools -> Diagnostics in the advanced setup. When the error occurs, collect logs with ESET Log Collector and upload them here.

Where is this setting? I cannot find it in v17?

[Chas4 8]

@Marcos Could this be similar to the Nod32 recent version 17 update where the license info did not get set right?

[rocketman1980 0]

16 hours ago, Marcos said:

There is no difference between v16 and v17 in the communication with cloud servers. Please enable advanced direct cloud logging under Tools -> Diagnostics in the advanced setup. When the error occurs, collect logs with ESET Log Collector and upload them here.

Logs attached as requested.

essp_logs.zip

[Marcos 5,107]

34 minutes ago, rocketman1980 said:

Logs attached as requested

26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 8.8.8.8@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [8.8.8.8]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_resolver>: Question [name: avcloud.e5.sk, type: A] Resolve failed
26.11.2023 ERROR [RESOLV] <dns_conn_cache>: Failed connect to FE80:0000:0000:0000:D635:1DFF:FEA5:4445@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [FE80:0000:0000:0000:D635:1DFF:FEA5:4445]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server 'FE80:0000:0000:0000:D635:1DFF:FEA5:4445' state unavailable (until: 1701017599; 180 sec)
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server '192.168.1.1' state unavailable (until: 1701017599; 180 sec)

Looks like a general network connectivity issue when the machine could not connect neither to your local DNS 192.168.1.1 nor to Google DNS 8.8.8.8.

If you can reproduce the error easily, you could enable also advanced network protection logging besides advanced direct cloud logging so that we can analyze the whole network communication shortly before the network outage occurs.

[Marcos 5,107]

52 minutes ago, Chas4 said:

@Marcos Could this be similar to the Nod32 recent version 17 update where the license info did not get set right?

Nope, the license keys were re-generated on the backend about 5 days ago and the issue manifested only by the subscription verification message in gui.

[rocketman1980 0]

20 minutes ago, Marcos said:

26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 8.8.8.8@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [8.8.8.8]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_resolver>: Question [name: avcloud.e5.sk, type: A] Resolve failed
26.11.2023 ERROR [RESOLV] <dns_conn_cache>: Failed connect to FE80:0000:0000:0000:D635:1DFF:FEA5:4445@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [FE80:0000:0000:0000:D635:1DFF:FEA5:4445]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server 'FE80:0000:0000:0000:D635:1DFF:FEA5:4445' state unavailable (until: 1701017599; 180 sec)
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server '192.168.1.1' state unavailable (until: 1701017599; 180 sec)

Looks like a general network connectivity issue when the machine could not connect neither to your local DNS 192.168.1.1 nor to Google DNS 8.8.8.8.

If you can reproduce the error easily, you could enable also advanced network protection logging besides advanced direct cloud logging so that we can analyze the whole network communication shortly before the network outage occurs.

Log attached. Still doesn't explain why this happening in v17 and not v16 on the same PC?

essp_logs.zip

[itman 1,676]

Another Eset ver. 17.0.15 user was having this same problem: https://forum.eset.com/topic/38859-limited-direct-cloud-connectivity-issue/#comment-176295 . He was also using a VPN and appears to have resolved the issue by excluding ekrn.exe and equi.exe from the VPN processing. Hence, my prior question in regards to VPN usage.

Edited November 26, 2023 by itman

[itman 1,676]

3 hours ago, Marcos said:

26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 8.8.8.8@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [8.8.8.8]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 ERROR [RESOLV] <dns_resolver>: Question [name: avcloud.e5.sk, type: A] Resolve failed
26.11.2023 ERROR [RESOLV] <dns_conn_cache>: Failed connect to FE80:0000:0000:0000:D635:1DFF:FEA5:4445@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [FE80:0000:0000:0000:D635:1DFF:FEA5:4445]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server 'FE80:0000:0000:0000:D635:1DFF:FEA5:4445' state unavailable (until: 1701017599; 180 sec)
26.11.2023 16:50 ERROR [RESOLV] <dns_conn_cache>: Failed connect to 192.168.1.1@53 (UDP) (error: 1)
26.11.2023 16:50 ERROR [RESOLV] <dns_nameserver>: [192.168.1.1]: Question [name: avcloud.e5.sk, type: A] UDP no connection
26.11.2023 16:50 DEBUG [RESOLV] <dns_resolver>: Name server '192.168.1.1' state unavailable (until: 1701017599; 180 sec)

There is another possible explanation here based on the above posted DNS log entries.

It appears that both DHCPv4 and DHCPv6 are being deployed to assign actual ISP DNS servers IP addresses from the router.

Some router/gateways; notably AT&T issued ones, are slow to respond to assignment of DNS server IP addresses and end up timing out prior to assignment being made.

One possibility here is ver. 17 is not waiting long enough for DNS server assignment to be made and defaulting to DNS resolution failure.

[itman 1,676]

Another thing that needs to be done is to perform a nslookup to Eset LiveGrid domain as shown in the below screen shot:

First, the DNS IP address resolution should be instantaneous.

Next, the Server address shown should correspond to a DNS domain name associated with your ISP or third party DNS provider; e.g. Cloudfare, if so assigned. Most important, the Address shown should be an IPv4 or IPv6 DNS address associated with your ISP or third party DNS provider. Finally, avcloud.e5.sk domain resolved IP address should be displayed.

If all the previous is not applicable, there is a problem with DNS processing on your device.

Edited November 27, 2023 by itman

[Shuntfield 0]

I am also getting this, I do not use a VPN, and it seems to have started since the recent install of 17.0.15.0 - it appears as a message saying Live Grid is not available and then clears of its own accord. 

I have AdGuard running as the DNS in my LAN and I have check that, and its not blocking any ESET services at all, indeed when its switched off it still does the same thing, I have also explicitly allowed *.eset.com within it, and there are no messages in the block list saying that it is blocking traffic to/from ESET.

I haven't tried any of my other computers with it yet, and I am not getting a similar error on my phone connected to the same network.

[itman 1,676]

16 minutes ago, Shuntfield said:

I have AdGuard running as the DNS in my LAN

Perform nslookup of avcloud.e5.sk as I posted previously.

[Lukáš Maršálek 0]

I have the same issue, since updating to 17.0.15.0, ESET Home reports one station like every ten minutes with this message. I got two devices at home, only one has this issue, it is laptop on wifi, second is  PC on cable, it doesnt have this issue. I dont have VPN on any device and nothing changed on my home network except updating Eset to latest version. Performed nlsookup on both stations. One that is without issues returns:

C:\WINDOWS\system32>nslookup avcloud.e5.sk
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    avcloud.e5.sk
Addresses:  91.228.165.43
          91.228.166.46

 

The one with Livegrid issues returns:

C:\WINDOWS\system32>nslookup avcloud.e5.sk
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    avcloud.e5.sk
Addresses:  91.228.165.44
          91.228.166.52

[rocketman1980 0]

2 hours ago, itman said:

Another thing that needs to be done is to perform a nslookup to Eset LiveGrid domain as shown in the below screen shot:

First, the DNS IP address resolution should be instantaneous.

Next, the Server address shown should correspond to a DNS domain name associated with your ISP or third party DNS provider; e.g. Cloudfare, if so assigned. Most important, the Address shown should be an IPv4 or IPv6 DNS address associated with your ISP or third party DNS provider. Finally, avcloud.e5.sk domain resolved IP address should be displayed.

If all the previous is not applicable, there is a problem with DNS processing on your device.

 

[itman 1,676]

First, all avcloud.e5.sk resolved IP addresses are correct.

The difference between my avcloud.e5.sk IP address resolution is I resolved to LiveGrid servers in the IP address 38.90.xxx.xx and domain h5-c0x.eset.com range. I am assuming this is a different Eset server.

Also note that for DNS server xxxx:xxxx:1dff:fea5:4445, local DNS Server name is unresolved. That is a problem. Since this appears to be a native IPv6 network, I assume the ISP is using 6rd tunneling, like mine is, to convert IPv6 addresses to IPv4 format. Upon receipt by ISP network assigned tunnel broker server, the IP address is converted back to an IPv6 format address and forwarded to its final destination. I can't begin to describe the nightmare I have had with Eset networking processing to get the 6rd tunneling to work correctly. Eset networking is totally clueless about this type of tunneling activity.

Edited November 28, 2023 by itman

[Lukáš Maršálek 0]

@itman it could be your case, that it is not resolving, but mine does and I got two devices at home, same Eset product, same version, one laptop, one desktop. Up until version 17, I got message about Live grid not available everytime laptop was awaken from sleep, since Eset is active sooner, than wifi reconnects. It was only time I was getting this message. But since version 17 I am getting this message like 2-3 times every hour. So it has to be something with wifi, when laptop reconnect to different band, which is not noticable when browsing, but probably detected by Eset? Like maybe it is more sensitive now? 

[itman 1,676]

26 minutes ago, Lukáš Maršálek said:

Up until version 17, I got message about Live grid not available everytime laptop was awaken from sleep, since Eset is active sooner, than wifi reconnects. It was only time I was getting this message.

Eset firewall issues with return from Win sleep mode is another issue that has never worked right on any Eset version I have used and I am on an Ethernet connection.

As best as I can determine, the Eset firewall doesn't initialize fast enough resulting in blocked outbound network traffic including blocked DNS traffic. I suspect a Wi-Fi connection only exacerbates the issue. 

I resolved it by creating a firewall rule specifying my assigned IPv4 device address as remote IP address and my assigned IPv4 assigned gateway/router address as the local IP address. You will have to ponder this one for a while.

Finally, I try to avoid Win sleep mode altogether and just shutdown my PC instead when not in use.

[xwolverine 0]

17.0.15.0 no vpn, ethernet connection, same issues with LiveGrid

[Marcos 5,107]

Please raise a support ticket so that it can be processed and tracked properly.

We'll need to get more information, such as:
1, The DNS servers used after connecting to VPN
2, A Wireshark  / advanced network protection pcap log with the communication captured on all network interfaces before and during a connection to VPN together with advanced direct cloud logs from the same time.
3, What VPN do you use? Does the problem persist even with some other VPN providers?
4, The exact time when you connected to the VPN and when you disconnected so that we can determine the corresponding records in logs.

[itman 1,676]

4 hours ago, Marcos said:

We'll need to get more information, such as:
1, The DNS servers used after connecting to VPN
3, What VPN do you use? Does the problem persist even with some other VPN providers?
4, The exact time when you connected to the VPN and when you disconnected so that we can determine the corresponding records in logs

The problem here has nothing to do with VPN usage. In fact, the only person who posted in the forum using a VPN resolved the issue: https://forum.eset.com/topic/38859-limited-direct-cloud-connectivity-issue/#comment-176295