Jump to content

j-gray

Members
  • Content Count

    300
  • Joined

  • Last visited

  • Days Won

    4

j-gray last won the day on May 31 2019

j-gray had the most liked content!

Profile Information

  • Location
    USA

Recent Profile Visitors

2,326 profile views
  1. It looks like adding port 8883 to the httpd.conf file resolved the connection issue. Thanks for that tip.
  2. 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.
  3. Are there any options if we do not want these frequent/persistent outbound connections?
  4. 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.
  5. 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.
  6. If nobody is triggering these, why are they occurring so frequently? Is it possible to disable this?
  7. @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.
  8. 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?
  9. Exactly. Though I view wake-up call more like wake-on-lan, requiring network broadcast, which is not a good practice across multiple subnets. I'm looking for a simple 'send policy' that doesn't require network broadcast. Even if it's a basic command I can run from the client (remotely).
  10. Description: Mechanism to force policy refresh on client(s) from ERA console. Detail: There doesn't appear to be a way (that I've found) to force a client to pull a new policy. We either have to wait for the policy refresh interval or create a new policy with a shorter refresh interval and apply it. It would be great to have a right-click option from the ERA console to force an immediate policy refresh.
  11. Description: Better method for detecting unmanaged clients Detail: RDS is not a practical solution in environments with multiple LANs, it can't be installed on OS X, and relies on outdated/unsupported software (WinPcap). A simple ping-sweep tool that works across multiple subnets and shows unmanaged clients, or better yet, a dynamic group that does the same so that an agent install task can be run when client joins the group. This would be awesome, especially for OS X where Group Policy automated install is not an option.
×
×
  • Create New...