MartinK

Please check firewall configuration, and also verify that ERAProxy is actually running and actively listening on port 2222 (netstat or other utilities).

Could you describe what are your expectations, i.e. how do to check whether it works? Asking because according to logs, AGENT is connecting every 30 seconds, which is quet often and it may be problem to even observe that AGENT actually connected immediately instead of regular interval.

Please follow documentation: https://help.eset.com/eavbe_linux/4/en-US/?ud_advanced_ra.html Also make sure you actually have installed BE variant (Business Edition) of this product, otherwise mentioned settings won't be available.

If I recall correctly, latest MirrorTool is actually no longer able to create ep6 mirror -> it was replaced with ep6.6 mirror which should be compatible with 6.6 and older 6.* products. Endpoints v6.5 are not able to update from ep6.6 mirror in your environment?

Is there any reason why you are explicitly using specific IP address in mirror tool command? It is possible that specific server is in maintenance or no longer available. I would recommend to use update.eset.com hostname, which will redirect you to working instance.

I would recommend to restart eraagent service on those machine to be sure. Also have you checked security product is actually running? Please check also "Remote Administrator" configuration of security product, it should be configured to connect to localhost:2225 (in case you have not changed default port 2222). In case it won't help, please enable full trace logging on those AGENTs and contact ESET support.

There seems to be problem with connection to http://repository.eset.com from machine that is hosting ERA server. Could you verify internet connectivity is working correctly? In case ERA is configured to use HTTP proxy, please verify it is working correctly. You can check access to repository by checking whether file http://repository.eset.com/v1/info.meta could be downloaded.

Is there any relevant error after failed installation? Most common issue when using network share is that permissions for LOCAL_SYSTEM account are required to access network share.

In case SERVER's certificate contains only IP address, AGENT not only need network access to SERVER, but it has to be configured to use IP address to connect to SERVER. This means that when installing AGENT, you have to explicitly specify that AGENT should be connecting to IP and port, where IP must match exactly, and the same is for hostname.

So you can actually create peer certificate, just creating installers fails? When installer is requested, current SERVER's certificate (as is in SERVER configuration) is fetched, and respective CA certificate that were used to sign this certificate will be searched in ERA -> and this seems to fail. CA certificate used to sign SERVER certificate currently in use is present in ERA? Is it actually available for current ERA user in terms of access permissions?

Could you specify version&platform of MirroTool you are using? Regarding this error, it's English translation is "Error copying file" which most probably means that downloaded mirror file cannot be placed in output directory. This might be caused for example by full disk, insufficient permissions, or maybe file that is supposed to be replaced is locked for changes by another process.

I would recommend to troubleshoot AGENT connection using steps described in documentation, I would start with status.html log, which should indicate connection problem. There are two most common issues in this scenario: PROXY certificate has to be signed for public hostname used by AGENTs. This means, that certificate used by PROXY must contain public hostname in it's Host field, or wildcard "*", which is not recommended, but would work. AGENT are connecting to wrong hostname. I guess this is the problem, as I am not sure whether hostnames from policy you mentioned are actually used. Cannot verify now, but I think hostname specified during installer creation (should be in advanced parameters in installer wizard) will actually override those specified in policy, and in case you have not modified it, default value will be used (= it will be most probably internal hostname of your ERA server, which is obviously not accessible from outside of network). Problem with wrong hostname will be visible in status.html log. Workaround is to use public hostname explicitly in installer, and once AGENT connects to ERA, it can be re-configred to use mutliple hostnames, i/e/ apply policy with list of servers, including private and public hostname. Just a note: ERA PROXY is used only by AGENT to connect to ERA SERVER. ERA Webconsole (web interface) won't be accessible from outside of network through PROXY machine, so port 443 can be blocked.

I will give you simple example where limiting AGENT certificate to specific hostname/IP address makes sense: Imagine you have critical server (S1) in your infrastructure managed by ERA, and attacker (someone with administrator privileges) is able to copy whole system, or at least whole AGENT configuration. Technically it would enable attacker to deploy it's own server (S2) and connect it to ERA. In case there would be specific DNS name / IP address specified in AGENT certificate, attacker won't be able to connect it's server to ERA without affecting network, which might be problem (for example in case attacker has access only to different subnet). Adding multiple values should be easy, for example following configuration: should tie ERA to it's IP address 192.168.0.128 and specific private and public hostname. Only AGENTs configured to connect to one of these 3 values (exactly) will be able to connect.

Using non-asterix host for AGENT certificate is not recommended because it may cause problems as you encountered, especially in environment where reverse-DNS resolving does not work, or results are not of expected value. What actually happens when AGENT connects: client's IP address is reverse-resolved. If there is no DNS entry, IP address is used. resolved client's hostname is compared with Host value in it's certificate, and it has to match in order to proceed with connections. where critical is first part, where IP address as resolved/seen by ERA might be completely different than is IP address of client machine, for example in case client is behind NAT, or it is connecting through internet/VPN. This is why using such certificate requires advanced knowledge of network, otherwise results might be confusing. That is why I would use such hardened certificate only in environment where IP/DNS names are static, for example such certificates could be used for AGENT installed on server machines. When creating ERA Server certificate, it is different -> hostname signed in certificate Host fields, and hostname where clients are connecting are both under ERA administrator's control, and it should be used to prevent possible man-in-the-midle attacks on Agent->Server communication.

Unfortunately from client logs, it is not clear why it is not able to connection. Connection is closed by ERA Server during SSL/TLS handshake. This might be caused by rejected client certificate - are you using default certificates, or have you created new AGENT certificates with specific hostname? I would recommend to check logs on ERA Server, as they might indicate why connection are rejected.