Jump to content

Recommended Posts

Posted (edited)
7 hours ago, Stormin Ben said:

Attached screenshots show the two firewalls currently in use -as you ca nsee neither would have ben blocking 53535 traffic (the specific rule on the Vigor was a later addition)

I believe the issue might be your NetBIOS block rule.

Ekrn.exe filters traffic through UDP port 138 locally. Just what the hell it is doing is beyond me and have never been able to fully figure it out. However, I also believe DNS UDP port 53 is involved which would imply this activity is related to TLS/SSL protocol filtering.

@Marcos, can you confirm the above?

 

Edited by itman
Posted (edited)

There is another topic with the same issue

We're experiencing the same issues since upgrade to 8.1. It's random as far as the users; some are remote users in another office or working from home, and some are here at our main office. Sometimes they resolve the issue on their own after a short period, some after a few days, but I have a couple of others that are still showing errors after about a week.

Edited by LesRMed
Posted
On 7/19/2021 at 2:20 PM, itman said:

I believe the issue might be your NetBIOS block rule.

Ekrn.exe filters traffic through UDP port 138 locally. Just what the hell it is doing is beyond me and have never been able to fully figure it out. However, I also believe DNS UDP port 53 is involved which would imply this activity is related to TLS/SSL protocol filtering.

@Marcos, can you confirm the above?

 

The DNS rule only applies to external queries

ESET needs port 53 to local DNS server enabling as I understand it

  • Administrators
Posted

The only problem we are aware of is that the program may not be able to connect to LiveGrid servers in case the machine roams between networks with a direct Internet connection and networks with connection through a proxy server. This was addressed in the latest LiveGrid communication module 1111.2 which has been on the pre-release update channel since yesterday.

Posted

From ESET Support :

You should wait for update or use in the policy the "Update from beta version"

 

 

FRENCH SCREENSHOT

image.thumb.png.6a7a74c59b0b390c52cfc6dadaf404d3.png

  • Administrators
Posted

The pre-release update channel is not a beta channel. I'll ask colleagues responsible for translation to check it out and amend incorrect translations.

Basically you wrote the same what I explained in my post above.

Posted

Hi, just to clarify then for my situation - no proxy and unfiltered internet access - has this issue been recognised and we're just waiting for an update?

Thanks,

  • Administrators
Posted

Does the issue persist with the LiveGrid communication module 1111.2 which you have probably already received?

Posted

I haven't received 1111.2 yet, still on 1111 from 27/05/20201

 

Thanks

  • Administrators
Posted
8 minutes ago, mrlsmithiii said:

I am no longer getting notifications but the problem persist.

First of all, I would recommend posting in the appropriate forum for retail products since this forum is intended for Endpoint which works differently in certain aspects than the retail products.

If you get the notification shortly after a reboot, continue as follows:
- enable advanced logging under Help and support -> Technical support
- reboot the machine
- avoid running applications that generate network traffic
- wait until the notification appears
- disable logging
- collect logs with ESET Log Collector and provide the generated archive.

Posted
1 hour ago, Marcos said:

First of all, I would recommend posting in the appropriate forum for retail products since this forum is intended for Endpoint which works differently in certain aspects than the retail products.

If you get the notification shortly after a reboot, continue as follows:
- enable advanced logging under Help and support -> Technical support
- reboot the machine
- avoid running applications that generate network traffic
- wait until the notification appears
- disable logging
- collect logs with ESET Log Collector and provide the generated archive.

Sorry I did not realize I was in the wrong forum. I am new to the ESET forums and started by searching for the problem I was having. I found this thread and contributed. I do see now that this forum is for IT professionals who support business users. 

  • Administrators
Posted
14 minutes ago, mrlsmithiii said:

I do see now that this forum is for IT professionals who support business users. 

No problem :) We have separate subforums dedicated to particular products rather than subforums for IT professionals and novices. While all products are alike, there are differences also in internal behavior and therefore it's a good practice to post in the appropriate product subforum.

  • 2 weeks later...
Posted

We are running into this problem as well with multiple random endpoints.  From my testing, rebooting the endpoint seems to resolve the issue at least temporality, but then the problem can re-occur on the same endpoint days later.

  • Administrators
Posted
22 minutes ago, steingat said:

We are running into this problem as well with multiple random endpoints.  From my testing, rebooting the endpoint seems to resolve the issue at least temporality, but then the problem can re-occur on the same endpoint days later.

Please keep advanced antispam logging enabled under Tools -> Diagnostics in the advanced setup and disable logging only after the issue has occurred, then collect ELC logs.

Is that machine permanently connected to the Internet through the same network? Does it connect directly or through a proxy server?

Posted

Hello Marcos,

This is happening on multiple endpoints with multiple ISPs.  However, our users do jump on/off a VPN connection on a regular basis, and at least today, 7 end points were affected, 4 were connected to a VPN connection at the time of the error, one was on wifi and a ethernet connection at the same time, 2 were directly connected to the internet via a network cable and not on a VPN/Proxy.

 

We have Proxy auto detection turned off on all of our endpoints so these endpoints should not be using a proxy.

 

I will attempt to gather the requested logs from at least one endpoint.

Posted

I have similarly "Eset livegrid cannot be reached." EP 8.1 and Eset Endpoint Security 8.1.2031.0

This happens on random computers with the same policies and Firewall settings. We use eset proxy on squid.
As we have noticed, livegrid does not go through the proxy, but directly.
Firewall rules pass port 53535 TCP/UDP o
n required IP (support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall) - Reputation database (ESET LiveGrid), Web control/Parental Control, Antispam module.

 

  • Administrators
Posted
19 minutes ago, SZP IT said:

This happens on random computers with the same policies and Firewall settings. We use eset proxy on squid.
As we have noticed, livegrid does not go through the proxy, but directly.

Please carry on as follows:
- enable advanced antispam logging in the adv. setup -> tools -> diagnostics
- after the issue has occurred, disable logging
- collect logs with ESET Log Collector and upload the generated archive here.

Posted

Add myself to the list of people with this same issue. We also rolled out 8.1 to our users over the last couple months or so and get the "ESET LiveGrid servers cannot be reached" randomly on computers all over our network. Every day when I log into the ESET Protect console, there usually are 1 or 2 computers in the warning list with that alert, if I check awhile later the alert has cleared magically, all on it's own with no changes or intervention on our part. We have confirmed that all required ports are open in the firewall and can see the traffic leaving our network through the appropriate rules. We have redundant ISP connections and detailed alerting and can confirm we have not had any interruption in internet service to trigger the alert. Since the issue appears to be very random, it is somewhat difficult to enable logging and hope it does it again.

I have two computers right now with the issue, one the end user just emailed me a screenshot of the issue. One computer is a desktop that does not move or travel between networks, no VPN and we do not use a Proxy server. The other is a mobile device that does roam between the network and other internet sources with VPN.

I believe ESET needs to be taking a closer look at this as there are a lot of people reporting this issue. For as long as we have been running 8.0 I can only remember a few instances of ever seeing this error and usually there was a reason for it. Now I have seen it hundreds of times in the last few weeks.

I will see about enable the advanced logging on some machines and see if get lucky and reproduce the issue and get some logs.

  • Administrators
Posted

For those who use the Apache http proxy on Linux, in case of issues check httpd.conf and make sure that it contains

AllowCONNECT 443 563 2222 8883 53535

The directive is updated only on Windows if you use the All-in-One ESET PROTECT installer to upgrade all components. On Linux it must be updated manually:

image.png

Posted

Marcos, Sent you a PM with the logs collected from one of the problematic endpoints

Posted
On 8/6/2021 at 10:16 AM, Marcos said:

For those who use the Apache http proxy on Linux, in case of issues check httpd.conf and make sure that it contains

AllowCONNECT 443 563 2222 8883 53535

The directive is updated only on Windows if you use the All-in-One ESET PROTECT installer to upgrade all components. On Linux it must be updated manually:

image.png

Marcos - You mentioned that this was for the Apache http proxy on Linux, but I checked our Windows installation of ESET Protect where we do run the Apache http proxy and can see that port 53535 is not in the AllowCONNECT list. I have suspicion this is due to the fact that we are on ESET Protect 8.0 and have not upgraded to 8.1 yet due to the Domain Login issue. Do I need to add 53535?

Secondly, if port 53535 was missing from AllowCONNECT wouldn't that cause ESET Live Grid to not connect at all instead of the intermittent issue a lot of us are reporting?

image.png.4c6fd046b30fc050965136b4fe69fdc3.png

Posted
On 8/6/2021 at 12:16 PM, Marcos said:

For those who use the Apache http proxy on Linux, in case of issues check httpd.conf and make sure that it contains

AllowCONNECT 443 563 2222 8883 53535

The directive is updated only on Windows if you use the All-in-One ESET PROTECT installer to upgrade all components. On Linux it must be updated manually:

image.png

assuming we need to open a port on the firewall too?

sudo iptables -A INPUT -p tcp --dport 53535 -j ACCEPT

  • Administrators
Posted
On 8/16/2021 at 10:24 PM, swb371 said:

assuming we need to open a port on the firewall too?

sudo iptables -A INPUT -p tcp --dport 53535 -j ACCEPT

If the proxy is behind a firewall then yes, it must be able to communicate with ESET's servers on UDP and TCP port 53535. If clients connect through a proxy, they don't need to have TCP/UDP communication on port 53535 allowed on the firewall.

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...