Endpoint Security can't connect to Push Notification Service

[etosolini 1]

On 12/10/2021 at 7:40 AM, Marcos said:

To sum it up, the issue may be caused by 2 things:

1, If you use Apache http proxy on Linux - the configuration of the http proxy is incorrect. Please refer to the post above how to fix it. Apache HTTP proxy for Windows is not affected.

2, If you don't use Apache http proxy - the issue is caused by a bug in Endpoint v9 which checks for EPNS connectivity even if checking for license changes via EPNS is disabled, ie. when the interval check is set to "Limited". Solution: change it to Automatic. If you need to have it set to Limited for whatever reason, there will be a fix via an automatic module update within a couple of days. Please use "Automatic" at least temporarily until the new Direct cloud communication module is available.

Option 2, license interval check set to automatic seems to solve de problem.

[badmotorfinger 0]

Is there going to be an official fix? i dont know how to modify that config file.. i have the VA..

 

thanks..

[Marcos 5,070]

1 hour ago, badmotorfinger said:

Is there going to be an official fix? i dont know how to modify that config file.. i have the VA..

If you are referring to the license check time interval, this will be solved in future versions of Endpoint. A workaround will be delivered by an automatic module update soon. However, we recommend keeping the interval set to "automatic" instead of "limited" unless you have a good reason to change it.

As for HTTP proxy on Linux, we expect the help files and KBs to be updated with instructions soon.

[badmotorfinger 0]

13 minutes ago, Marcos said:

If you are referring to the license check time interval, this will be solved in future versions of Endpoint. A workaround will be delivered by an automatic module update soon. However, we recommend keeping the interval set to "automatic" instead of "limited" unless you have a good reason to change it.

As for HTTP proxy on Linux, we expect the help files and KBs to be updated with instructions soon.

Hello Marcos, i have it in automatic.. 

Edited December 14, 2021 by badmotorfinger

[badmotorfinger 0]

For testing puropuse i updated my workstation to 9.0.2032.2 and the error appeared, not in 8.0 versions or lower.

I have over 90 workstations connected to Eset Protect so turning off proxy polixy is not an option.
ESET Management Agent 9.0.1141.0, ESET PROTECT (Server), ver. 9.0 (9.0.2144.0) in VA.

[Marcos 5,070]

21 minutes ago, badmotorfinger said:

Hello Marcos, i have it in automatic..

Then re-configure Apache http proxy as follows:

1, Either disable the module reqtimeout_module
2, Or disable limits, ie. by creating a new file reqtimeout.conf in /etc/httpd/conf.d/ and setting "RequestReadTimeout header=0 body=0". Include the file in the configuration, ie. add "IncludeOptional conf.d/reqtimeout.conf" to /etc/httpd/conf/httpd.conf.

[Peter Randziak 1,130]

Hello guys,

LiveGrid communication module 1123.1 is available on pre-release update channel.

If you do not use the proxy try to switch to pre-release updates, confirm that LiveGrid communication module bas been upgraded to version 1123.1 and let us know if it resolved your issue, even if you have  License Interval Check set to limited.

Peter

[BradAtkins 4]

8 hours ago, Peter Randziak said:

Hello guys,

LiveGrid communication module 1123.1 is available on pre-release update channel.

If you do not use the proxy try to switch to pre-release updates, confirm that LiveGrid communication module bas been upgraded to version 1123.1 and let us know if it resolved your issue, even if you have  License Interval Check set to limited.

Peter

That works for me.

Thanks!

[badmotorfinger 0]

Well i thought is was working fine after the LiveGrid communication module 1123.1 update and clean reboot but the problem persists

 

 

[Marcos 5,070]

2 hours ago, badmotorfinger said:

>Didn't work for me 

You wrote that you had Endpoint configured to connect through http proxy.

Please refer to the Troubleshooting section at https://help.eset.com/protect_deploy_va/90/en-US/enable_apache_http_proxy.html:

If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:

1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf

2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf

3.Type this setting into the file:
RequestReadTimeout header=0 body=0

4.Save the changes a close the file:
CTRL+X > type Y > press Enter

5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf

6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf

7.Save the changes a close the file:
CTRL+X > type Y > press Enter

8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

 

[ElieB 0]

Hi,

I believe that the last update of eset would do the job. But that change nothing to me. Do we have a date for the official release of the solution with update of eset? 

(Already test to put in automatics or not, change nothing)

[Marcos 5,070]

2 hours ago, ElieB said:

I believe that the last update of eset would do the job. But that change nothing to me. Do we have a date for the official release of the solution with update of eset?

Couldn't it be that Endpoint is connecting via Apache http proxy to the Internet? If so, you will probably need to configure it as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html:

1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf

2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf

3.Type this setting into the file:
RequestReadTimeout header=0 body=0

4.Save the changes a close the file:
CTRL+X > type Y > press Enter

5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf

6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf

7.Save the changes a close the file:
CTRL+X > type Y > press Enter

8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

[PCS70 0]

19 hours ago, Marcos said:

You wrote that you had Endpoint configured to connect through http proxy.

Please refer to the Troubleshooting section at https://help.eset.com/protect_deploy_va/90/en-US/enable_apache_http_proxy.html:

If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:

Just like to add that the push notification error doesn't show in EPM Web Console at all, but at the client AV application only.

You can have all clients show in perfect state in Web Console, but locally their AV application reports this error.

And in regard to using EPM VA the notification only signals on internal clients that are using an incomplete or incorrect configured proxy after (auto-)upgrade of EPM VA to 9 version.

I can remember I had disabled proxy use for a while already, as VA disk was getting too full, but after the automatic upgrade of VA it seems to be enabled again. Also here I would prefer the upgrade attention instead of just auto upgrading the appliance. This would go against your own advise in help center of preferably deploying new VM to replace old one, although I like the in-place VA upgrade functionality through component upgrade or later in the help menu.

That link for (correct) configuration of the new apache proxy (although exists since version 7 if I remember correctly) will be useful to solve the problem for EPM VA internally connected clients. Thank you.

Or just deploy a new policy that will disable the use of EPM VA internal proxy server again.

Edited December 21, 2021 by PCS70

[veehexx 1]

Is this still an active issue, as we're seeing the problem and not got some of the updates (still in pre-release channel?) that have been mentioned.

I've updated to v9.0.2032.6 EES yesterday with the intention to deploy company wide and i'm seeing the same issue.

we use linux Eset Protect VM (iirc the eset provided VA), no http proxy (clients can freely connect direct to internet) but do cache updates, licencing interval is 'automatic'. Direct Cloud comm module is still 1122.2 (4/nov/2021).

 admittedly, i havent done any of the cfg file changes mentioned in this thread as they all appear to be "try this and see", most seemed not applicable to our environment.

telneting to epns.eset.net:8883 appears to work (blank screen, but no failure to connect), pings fail. if i've understood the connectivity correctly, 8883 is preferred, 443 is fallback so worst case is we should see 443 fallback and EPNS should never fail for us, and it has no effect on connectivity to our onprem Eset Protect VM; EPNS is globally available provided by eset.

[Marcos 5,070]

10 minutes ago, veehexx said:

we use linux Eset Protect VM (iirc the eset provided VA), no http proxy (clients can freely connect direct to internet) but do cache updates, licencing interval is 'automatic'. Direct Cloud comm module is still 1122.2 (4/nov/2021).

Did you configure Apache HTTP proxy as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html ?

Troubleshooting

If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:

1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf

2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf

3.Type this setting into the file:
RequestReadTimeout header=0 body=0

4.Save the changes a close the file:
CTRL+X > type Y > press Enter

5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf

6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf

7.Save the changes a close the file:
CTRL+X > type Y > press Enter

8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

[PCS70 0]

1 hour ago, veehexx said:

Is this still an active issue, as we're seeing the problem and not got some of the updates (still in pre-release channel?) that have been mentioned.

I've updated to v9.0.2032.6 EES yesterday with the intention to deploy company wide and i'm seeing the same issue.

we use linux Eset Protect VM (iirc the eset provided VA), no http proxy (clients can freely connect direct to internet) but do cache updates, licencing interval is 'automatic'. Direct Cloud comm module is still 1122.2 (4/nov/2021).

 admittedly, i havent done any of the cfg file changes mentioned in this thread as they all appear to be "try this and see", most seemed not applicable to our environment.

telneting to epns.eset.net:8883 appears to work (blank screen, but no failure to connect), pings fail. if i've understood the connectivity correctly, 8883 is preferred, 443 is fallback so worst case is we should see 443 fallback and EPNS should never fail for us, and it has no effect on connectivity to our onprem Eset Protect VM; EPNS is globally available provided by eset.

Even if you don't use the provided EPM proxy server on the clients, the offered fix or work around needs to be applied on the EPM VM in order to get rid of the notices at the client side.

They still refer here to Push Notification Error on the Web Console, while the notice strictly is shown on the AV client side and not even registered in the EPM web console, but yet is to be solved by adjusting the proxy config on the EPM VM.

The proxy solution on the EPM VM is also used to cache and prepare all-in-one installer packages and for AV definition updates for all internally connected (LAN) clients. While having proxy on the ESET Protect Management VM enabled through policies on containers you can still configure (certain or all) external clients to not use the EPM proxy, but externally they will fallback to ESET's servers anyway as they are not connected through local network to EPM proxy (except while VPN connected to company network) as these ports should stay closed for direct access through the internet at all times.

Edited January 7, 2022 by PCS70

[PCS70 0]

This might help too for correctly configuring the proxy on ESET EPM VM, especially if you upgraded from older versions to newer versions using the web console. The proxy replaces the old mirror update solution and so after upgrade or when enabled it requires some additional configuration too.

Maybe @Marcos can confirm this kb still applicable to correct proxy configuration in EPM 9 VA?

[KB7848] Write a ProxyMatch expression for configuration of Apache HTTP Proxy with ESET PROTECT

[veehexx 1]

1 hour ago, Marcos said:

Did you configure Apache HTTP proxy as per https://help.eset.com/protect_deploy_va/90/en-US/?enable_apache_http_proxy.html ?

Troubleshooting

If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:

1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf

2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf

3.Type this setting into the file:
RequestReadTimeout header=0 body=0

4.Save the changes a close the file:
CTRL+X > type Y > press Enter

5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf

6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf

7.Save the changes a close the file:
CTRL+X > type Y > press Enter

8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

 

50 minutes ago, PCS70 said:

Even if you don't use the provided EPM proxy server on the clients, the offered fix or work around needs to be applied on the EPM VM in order to get rid of the notices at the client side.
 

 

Thats the bit i didnt understand - we dont use Apache HTTP Proxy, so the Troubleshooting steps i figured were not applicable.

Turns out they are applicable and it's (so far!) fixed it for us; clients are staying 100% ok and all green.

[BradAtkins 4]

5 hours ago, veehexx said:

Is this still an active issue, as we're seeing the problem and not got some of the updates (still in pre-release channel?) that have been mentioned.

It looks like Direct Cloud communication module 1123.2 is still in pre-release.  Will that be moved to the regular update channel any time soon?

[Marcos 5,070]

2 hours ago, BradAtkins said:

It looks like Direct Cloud communication module 1123.2 is still in pre-release.  Will that be moved to the regular update channel any time soon?

I assume so. The module has been on pre-release only for 2 days so far.

[PCS70 0]

On 1/7/2022 at 2:52 PM, veehexx said:

Thats the bit i didnt understand - we dont use Apache HTTP Proxy, so the Troubleshooting steps i figured were not applicable.

Turns out they are applicable and it's (so far!) fixed it for us; clients are staying 100% ok and all green.

Indeed it's confusing too. as the message is only shown at the client side AV and is not visible in the web console of EPM.

They did update some troubleshooting sections on their help sections, so probably this fix is official now, although I can not find it there now anymore.

It didn't hurt any functionality though, but was annoying for users. Glad you got it solved too.

[Tim Brown 0]

On 12/20/2021 at 7:39 PM, Marcos said:

You wrote that you had Endpoint configured to connect through http proxy.

Please refer to the Troubleshooting section at https://help.eset.com/protect_deploy_va/90/en-US/enable_apache_http_proxy.html:

If you get the EPNS service servers are not accessible Web Console error, follow these steps to disable the connection timeout limits:

1.Create a configuration file reqtimeout.conf:
sudo touch /etc/httpd/conf.d/reqtimeout.conf

2.Open the file in a text editor:
nano /etc/httpd/conf.d/reqtimeout.conf

3.Type this setting into the file:
RequestReadTimeout header=0 body=0

4.Save the changes a close the file:
CTRL+X > type Y > press Enter

5.Open the httpd.conf file:
nano /etc/httpd/conf/httpd.conf

6.Add the following line at the end:
IncludeOptional conf.d/reqtimeout.conf

7.Save the changes a close the file:
CTRL+X > type Y > press Enter

8.Restart the Apache HTTP Proxy service:
systemctl restart httpd

 

This fixed the problem for us, and thanks for giving precise instructions for those of us who are less linuxy.

We had the virtual appliance which had been running fine since we put it in under v8 and had been updated several times to bring it to current, so were a bit caught out that additional config would be needed for V9.

[GlennC 0]

 

config files are already in place, worked for a few months but got a report issue is back?

anyone experiencing the same issue? thanks