LiveGrid servers cannot be reached

[demonlight 0]

After the most recent ESET Internet Security update, I started receiving a popup and warning stating "The ESET LiveGrid servers cannot be reached.   This could be due to an outage or a problem with your network connection.  Allow access to ESET LiveGrid servers on firewall."   I did the test at this help page, ESET detected the file.    After a period of time, the LiveGrid message would go away.  Eventually it comes back.    This happen earlier this year after update but resolved itself.

Is this a known issue with this update?

[cyberhash 197]

If it is only happening intermittently then i would suspect that the problem may well be with your ISP connecting to the ESET servers , a routing problem that is outwith their/your control and generally gets resolved within a reasonable time. If there are any major issues with updates then there tends to be lots of posts with the same issue.

Using TRACERT within windows might show where the problem is stemming from.

 

[Stormin Ben 1]

On 6/23/2021 at 11:20 PM, cyberhash said:

If it is only happening intermittently then i would suspect that the problem may well be with your ISP connecting to the ESET servers , a routing problem that is outwith their/your control and generally gets resolved within a reasonable time. If there are any major issues with updates then there tends to be lots of posts with the same issue.

Using TRACERT within windows might show where the problem is stemming from.

 

We pushed out the 8.1 update to 200+ machines across 15 different customer sites
All sites are experiencing the same intermittent pop up which then resolves itself

I think it highly likely that all 9 different ISPs are all experiencing similar issues and that is all their fault.
The comon factor here is ESET
I'm wondering whether one of the LiveGrid servers is offline and it is this that is causing the pop up?

 

[JoeP 0]

1 hour ago, Stormin Ben said:

We pushed out the 8.1 update to 200+ machines across 15 different customer sites
All sites are experiencing the same intermittent pop up which then resolves itself

I think it highly likely that all 9 different ISPs are all experiencing similar issues and that is all their fault.
The comon factor here is ESET
I'm wondering whether one of the LiveGrid servers is offline and it is this that is causing the pop up?

 

We're also getting this intermittent message on a few client machines, and only since the 8.1 update.

[Stormin Ben 1]

Just ran a tracert to all of the LiveGrid servers mentioned above (see attached file)

Does anyone know what the timeout for connection is within the ESET client?
Most of the servers are 15 hops with 45ms per hop but the later ones are 20 hops all with 150ms times

ESETtrace1.txt

[Nightowl 206]

Check if you can make connections to these ports and IPs , see if your firewall is blocking connections to these

 

[Nightowl 206]

This is more active topic about it , but I believe you have been already there :

 

[Retiredbodyman 0]

Same issue, some computers. All my users are remote so I doubt it's all of their ISPs. I did test a couple of computers by making sure ports listed above were open and I ran a flushdns command. No change all morning.

[Marcos 5,290]

If switching to the pre-release update channel doesn't make any difference, carry out as follows:

- enable advanced logging under Help and support -> Technical support
- reboot the machine
- quit any network-aware applications that may generate network communication
- wait until a warning about limited LG connectivity pops up
- disable logging
- collect logs with ESET Log Collector. When done, upload the generated archive to a safe location and drop me a personal message with a download link.

[Marcos 5,290]

12 minutes ago, Retiredbodyman said:

Same issue, some computers. All my users are remote so I doubt it's all of their ISPs. I did test a couple of computers by making sure ports listed above were open and I ran a flushdns command. No change all morning.

Do these users have ESET Endpoint or a retail product EAV/EIS/ESSP installed? Do they always connect directly to the Internet or also though a proxy sometimes?

[Retiredbodyman 0]

eSet Endpoint no proxy. It's not always the same computers, some users do connect to VPN at times. It does not seem to matter whether on VPN or direct Internet. I'll see if I can capture logs on one.

[Pawel Dacka 0]

We have tha same problem after update to 8.1

Eset Endpoint.

Direct connection to the Internet.

[Marcos 5,290]

8 minutes ago, Pawel Dacka said:

We have tha same problem after update to 8.1

Eset Endpoint.

Direct connection to the Internet.

Please provide logs from a machine where the error is reported as per the instructions in my post above.

However, you have posted in a wrong forum; this one is intended for retail products ESET Internet Security and ESET Smart Security Premium. A topic for Endpoint where this issue is discussed is at https://forum.eset.com/topic/28979-eset-endpoint-v81-livegrid-connection-problem.

[DumitruSino 1]

Same problem here! After the update!

@ESET, please fix this.  

 

I think you've could easily prevent this, if you would've TEST THE UPDATE BEFORE RELEASE!

Poor testing! Please blame it on your PRODUCTION and TESTING TEAM, not on us clients! UNPROFESSIONAL!

[Marcos 5,290]

There is no problem with LiveGrid serves on ESET's end. Please provide logs created as follows to determine the root cause:
- enable advanced logging under Help and support -> Technical support
- reproduce the issue
- disable logging
- collect logs with ESET Log Collector and provide the generated archive.

Also we need to know:
- if endpoints are connected directly to the Internet or through a proxy
- if endpoints or proxy is behind a firewall
- what proxy server you use
- if the proxy has communication on TCP and UDP port 53535 allowed.

[DumitruSino 1]

@Marcos, if you've read the TOPIC, and if you've read what people mentioned. This issue popped up AFTER THE UPDATE!

 

So please dig in your update, and find the issue. You don't need our logs for that. 

Edited August 26, 2021 by DumitruSino

[Marcos 5,290]

26 minutes ago, DumitruSino said:

@Marcos, if you've read the TOPIC, and if you've read what people mentioned. This issue popped up AFTER THE UPDATE!

 

So please dig in your update, and find the issue. You don't need our logs for that. 

If you are referring to update to Endpoint 8.1, the reason is that the communication has changed and Endpoint must be able to communicate with ESET's servers on TCP and UDP port 53535 which was not the case before. This is not needed if Endpoint connects via an http proxy, however, the proxy must be configured properly and must have communication with ESET's servers allowed.

[Retiredbodyman 0]

I think a big change on our side (Corporate) is that most uses are now working from home. It does seem to clear up on it's own then happen to another user then clear up again. I have not made changes on many computers but it does seem intermittent.  Which on both sides make it very difficult to troubleshoot.

[itman 1,756]

I am also questioning if LiveGrid is functioning properly.

In reference to the cloudcar download from this website: https://support.eset.com/en/kb5552-enable-or-disable-eset-livegrid?ref=esf , Firefox blocks the download as malware. If I allow the download, it does so w/o a peep from Eset Internet Security.

-EDIT- It gets better. If I perform an Eset context scan on the downloaded cloudcar.exe file, Eset doesn't detect it.

Edited August 26, 2021 by itman

[Marcos 5,290]

Please carry on as follows:

- enable advanced logging under Help and support -> Technical support
- download CloudCar
- disable logging
- collect logs with ESET Log Collector and provide the generated archive.

[itman 1,756]

2 hours ago, Marcos said:

Please carry on as follows:

Log file attached.

eis_logs.zip

Edited August 26, 2021 by itman

[itman 1,756]

A few interesting Eset Filtered web sites log entries below in regards to posted AMTSO cloudcar test behavior. Appears from these entries, Eset "bows out" of the monitoring picture if the download is allowed via Firefox override:

Time;URL;Status;Detection;Application;User;IP address;Hash
8/26/2021 3:21:01 PM;https://mozilla.cloudflare-dns.com/dns-query;Allowed;;C:\Program Files\Mozilla Firefox\firefox.exe;xxx-PC\xxx;2606:4700::6810:f8f9;6E6C61A9F8A1D1C96B17E310A48AEAA49545C0EF

Time;URL;Status;Detection;Application;User;IP address;Hash
8/26/2021 3:21:02 PM;https://amtso.eicar.org/cloudcar.exe;Allowed;;C:\Program Files\Mozilla Firefox\firefox.exe;xx-PC\xxx;81.7.7.163;6E6C61A9F8A1D1C96B17E310A48AEAA49545C0EF

Time;URL;Status;Detection;Application;User;IP address;Hash
8/26/2021 3:21:04 PM;http://amtso.eicar.org;Allowed;;C:\Program Files\Mozilla Firefox\firefox.exe;xxx-PC\xxx;81.7.7.163;6E6C61A9F8A1D1C96B17E310A48AEAA49545C0EF

 

[Marcos 5,290]

Please try the following:
- in safe mode delete C:\ProgramData\ESET\ESET Security\local.db
- restart Windows in normal mode
- clear browser cache
- temporarily change logging verbosity to Diagnostic under Tools -> Log files in the adv. setup
- download CloudCar
- collect fresh ELC logs but also select Local cache db:

[itman 1,756]

2 hours ago, Marcos said:

Please try the following:
- in safe mode delete C:\ProgramData\ESET\ESET Security\local.db
- restart Windows in normal mode
- clear browser cache
- temporarily change logging verbosity to Diagnostic under Tools -> Log files in the adv. setup
- download CloudCar
- collect fresh ELC logs but also select Local cache db:

Log attached:

eis_logs.zip

[itman 1,756]

@Marcos, I believe I know the issue here in regards to the Eset allowed cloudcar.exe download and analyzing my Eset logs won't yield anything.

Refer to my prior posted Eset Filtered web site log entries. Note the first entry generated time-wise is Cloudflare IPv6 DNS related. The next entries chronologically and related to the AMTSO web site cloudcar.exe download, all show IPv4 addresses.

My ISP, AT&T, has pretty much transitioned to an all IPv6 network. It is handling IPv4 web site connections using 464XLAT: https://en.wikipedia.org/wiki/IPv6_transition_mechanism using NAT64/DNS64 on the router. What this means is IPv4 address are being converted to IPv6 addresses in transit and then reconverted to IPv4 address by the router.

I always assumed this was all being done on the WAN site of the router and would be N/A as far as any Windows network stack processing. However, based on this cloudcar.exe allowed download, this appears to be not the case. In any case, Eset "needs to take a hard look" at its ability to handle all IPv6 communication methods.

Edited August 27, 2021 by itman