j-gray 40 Posted December 10, 2019 Posted December 10, 2019 (edited) I'm getting the following repeatedly logged on the proxy server: [proxy:error] [pid 6596:tid 10020] [client x.x.x.x:52075] AH00898: Connect to remote machine blocked returned by epns.eset.com:8883 This specific remote server is constantly blocking these connection attempts. Any idea what's going on here and how to rectify this? Edited December 10, 2019 by j-gray Corrected title
Administrators Marcos 5,444 Posted December 11, 2019 Administrators Posted December 11, 2019 The ESET Push Notification Service works only if both clients and the ESMC server can access epns.eset.com directly on port 8883 or 443. Proxy servers do not forward MQTT protocol communication. https://help.eset.com/esmc_admin/70/en-US/epns.html
j-gray 40 Posted December 11, 2019 Author Posted December 11, 2019 @Marcos Thanks for the reply. We are not blocking this traffic on our networks at the client or server. Based on the error messages, it appears that the remote server (epns.eset.com) is blocking/rejecting the communication. Or is the error indicating that the epns server cannot connect to our client? I'm also confused, as the documentation indicates these calls are triggered by a Web Console user. I am the only Web Console user and have not triggered these ever (intentionally, at least). Could you please clarify how to resolve this issue? Ideally we would not want this outbound traffic to ESET. Thanks again.
j-gray 40 Posted December 12, 2019 Author Posted December 12, 2019 If nobody is triggering these, why are they occurring so frequently? Is it possible to disable this?
Administrators Marcos 5,444 Posted December 12, 2019 Administrators Posted December 12, 2019 Didn't you send a wake-up call from ESMC ?
j-gray 40 Posted December 12, 2019 Author Posted December 12, 2019 3 minutes ago, Marcos said: Didn't you send a wake-up call from ESMC ? No. I'm the only console user and I never use this feature. The logs show multiple entries per minute from a number of different clients. There are 429 entries in today's log file, alone. There's no reason it should be doing this that I know of.
ESET Staff MartinK 384 Posted December 13, 2019 ESET Staff Posted December 13, 2019 Connections to epns.eset.com are made by every ESMC 7.0+ components (Server + Agent) regardless of wake-up functionality use. Components will be trying to establish persistent connections regularly, with slightly increasing interval between attempts. That is why after startup of AGENTs it might be more often than later during the day.
j-gray 40 Posted December 13, 2019 Author Posted December 13, 2019 From both Windows and OS X clients, nmap results show both ports open (epns.eset.com:8883 and epns.eset.com:443). So I have no idea why the connection is being blocked. Any thoughts? That said, we'd prefer to minimize outbound traffic, particularly given we don't require that functionality. Is there a way to disable this outbound traffic within the product? Thank you.
j-gray 40 Posted December 18, 2019 Author Posted December 18, 2019 On 12/13/2019 at 4:12 AM, MartinK said: Connections to epns.eset.com are made by every ESMC 7.0+ components (Server + Agent) regardless of wake-up functionality use. Components will be trying to establish persistent connections regularly, with slightly increasing interval between attempts. That is why after startup of AGENTs it might be more often than later during the day. Are there any options if we do not want these frequent/persistent outbound connections?
ESET Staff MartinK 384 Posted December 18, 2019 ESET Staff Posted December 18, 2019 2 minutes ago, j-gray said: Are there any options if we do not want these frequent/persistent outbound connections? Unfortunately not, this functionality is enabled by detail and cannot be disabled. My best guess for failure is failure during SSL handshake, which ESMC Agent versions are actually used? I guess they are not 7.1?
j-gray 40 Posted December 18, 2019 Author Posted December 18, 2019 13 minutes ago, MartinK said: Unfortunately not, this functionality is enabled by detail and cannot be disabled. My best guess for failure is failure during SSL handshake, which ESMC Agent versions are actually used? I guess they are not 7.1? I just picked a random one from within the error logs. It is an OS X client running ESET Endpoint Antivirus 6.8.400.0 with ESET Management Agent 7.1.840.0 (latest). Another random client with the same errors is also OS X, running agent 7.1.840.0 (latest) but older av version 6.7.900.0 A third random client in the error logs is a Windows client with ESET Management Agent 7.1.717.0 (latest) running ESET Endpoint Antivirus 7.1.2053.0. So far, the random clients showing the connection error to epns.eset.com are all running the latest agent.
ESET Staff MartinK 384 Posted December 18, 2019 ESET Staff Posted December 18, 2019 In case you are using ESET Apache HTTP proxy, it is probable that connections to port 8883 are blocked but it is not clear whether this is the issue. Could you verify configuration of: AllowCONNECT 443 563 2222 in httpd.conf? It is possible that enabling this port 8883 will helps AGENT to connect successfully. In case direct connection to EPNS servers is not possible, multiple alternatives, including port variants (443,8883) are tried to ensure that connection is made even when configuration is not possible. j-gray 1
j-gray 40 Posted December 19, 2019 Author Posted December 19, 2019 19 hours ago, MartinK said: In case you are using ESET Apache HTTP proxy, it is probable that connections to port 8883 are blocked but it is not clear whether this is the issue. Could you verify configuration of: AllowCONNECT 443 563 2222 in httpd.conf? It is possible that enabling this port 8883 will helps AGENT to connect successfully. In case direct connection to EPNS servers is not possible, multiple alternatives, including port variants (443,8883) are tried to ensure that connection is made even when configuration is not possible. It looks like adding port 8883 to the httpd.conf file resolved the connection issue. Thanks for that tip.
ESET Staff MartinK 384 Posted December 19, 2019 ESET Staff Posted December 19, 2019 5 hours ago, j-gray said: It looks like adding port 8883 to the httpd.conf file resolved the connection issue. Thanks for that tip. Thanks for letting us know, it might indicate problem in order of connection attempts -> I guess port 443 should be preferred as it has much higher probability to bypass proxies and firewall on path to ESET infrastructure.
Recommended Posts