MartinK

There has been only Apache HTTP Proxy component upgraded between these components: could you confirm this component is not upgrade when using all-in-one installer? Otherwise no other upgrades should be offered.

Unfortunately there is probably no proper solution for now, so I would recommend to file a support request or contact your ESET distributor/partner so that is it tracked. From technical standpoint, machine is shown as rogue in console when: MAC address or machine itself is detected in the network using RogueDetectoinSensor (passive detection of all present devices) MAC address of detected machine is not one of MAC addresses reported by ESET Management Agent, where only active interfaces are reported in this way, and this is the problem - when devices are switched to secondary interface, original one is no longer active = no longer reported, and thus considered as "unknown".

Yes, those settings are there to have possibility to use different proxy settings for AGENT-to-PROTECT communication, and all other communication, especially to the internet (= i.e. ESET servers), but generally it is for all HTTP/HTTPs traffic. Probably all communication has some sort of fallback mechanisms, which might explain why it works even when proxy is not configured correctly, just to prevent mistakes that would cut-off control of the network just because of wrong configuration. As I mentioned in previous comment, when AGENT is connecting to PROTECT, it validates remote certificate and check whether this certificate is supposed to be used by PROTECT Server or by AGENT - and in this case it seems that AGENT-type of certificate was used for PROTECT Server service - so my best guess is that wrong certificate was selected when PROTECT settings were modified in one of the steps. This whole check is actually security precaution, so that AGENT's certificate are not misused.

Difference between 8.1.13.0 and 8.1.13.1 is that later embeds newer version of HTTP Proxy and MirrorTool - in case you are not using those components, there will be no difference. In case you would like to upgrade to 8.1, feel free to download latest available all-in-one installer at the time and use it. Regarding failed on-product upgrade, it is hard to diagnose without proper data, so I would recommend to open support ticket in case issue persists, so that proper logs for analysis are collected.

Could you please double check that both ESET PROTECT WebConsole and ESET PROTECT Server are of the same and compatible version? This might be relevant in case it started to happen after upgrade attempt was made, which might have failed.

In case standard Apache HTTP proxy distributed with ESET PROTECT is used, TLS communication is used only when ESET Dynamic Threat Defense functionality is used in your environment, and even in this case it is used only for outgoing connections. But regardless of that, it might be possible to disable respective Apache modules or just remove problematic library, and caching should probably work - but I have not verified that nor it is tested scenario - but it should not be crucial for standard caching functionality. I would recommend it only in a way fast solution is required, even in case that vulnerabilities are most probably not affecting your environment.

Could you please double check that Apache Tomcat service is actually running on this machine? Also most common problems are: Apache Tomcat stopped working after Java upgrade or uninstallation -> to resolve this, tomcat configuration utility should be run and JAVA_HOME variable should be fixed to point to correct paths if this is the case. Some other service might have taken port 443 used by Apache Tomcat -> please check there are no other services, especially web servers, that might have done this. Verify there is enough free memory for Apache Tomcat to run - this might be relavant only for large environments.

So I will provide just short summary, what was most probably the easies solution to do: Install new EP Server, with new certificates generate automatically during deployment Interchange public certificate parts of CA certificates. I.e. export all CA certificates from old server and import them into new EP server, and vice versa = export CA certificates from new EP server and import them to old ESMC server. This will ensure, that both servers will trust AGENTs using both old and new AGENT certificate. Move (= export/import) policies from ESMC to EP server, especially those that has to be there to ensure full security, exclusions, etc. Just be aware that policie for AGENT should be migrated carefully, and those configuration certificates and hostnames for connectivity should be ideally skipped or adapted to new environment. Create new configuration for AGENTs in old ESMC, where you set new hostname of EP server, or ideally you can set both servers, as an alternative hostnames, where new server should be first one to be considered as an priority. Please double check that hostname of new EP server you enter into configuration is signed in EP's serverificate, especially in case certificate with wildcard "*" was not used. This can be verified in EP console, in "server settings". Assign such policy to testing device -> you should see it connecting to new EP server. Once migration is done, you could possibly re-configure AGENTs via policy to start using new certificate, which would enable you to get rid of original certificates after some time. And regarding your specific problem, there is an error "Agent to agent communication is not supported" which indicated that your EP server is probably using wrong certificate - any chance you changed certificate in "Server settings" of your newly deployed EP to a way that certificate supposed to be used only by AGENTs was used?

It depends on type of license you are using as of now. In order to managed devices, you will need license that has cloud-management included - it is possible you already have such license, but I would recommend to verify. Simplest check might be to open ESET Business Account with your current license and check whether you are offered creation of EP Cloud "instance" -> this is offered only for users with eligible licenses.

Just to let you know, we had an configuration issue which was fixed almost immediately, but it might have affected ESMC/EP instances as they are synchronizing in hour intervals.

As of now, only possibility is to re-configure management AGENTs on those devices to connect to new account. This can be achieved by running installation repair, i.e. by running installer created in the new account's console on devices currently managed by old accounts.

Just a note that this issue should be resolved with version deployed recently.

Could you please specify why would you do this? Mentioned update actions will list and offer execution of update on devices where AGENT is not on the latest version. Or problem might be specific of environment where online-based upgrade won't work? Also note, that AGENT will actually upgrade itself automatically after some time (there is a few weeks/random delay) so it might be easier, especially in case there are no new features introduced in AGENT that would require immediate upgrade.

I would recommend to contact ESET support for more detailed analysis - we are not aware of any issues with this protection as of now, so it might be some missconfiguration of misunderstanding. More detailed description of step taken will have to be described, as is policy configuration, it's use and possibly also what method for uninstallation is actually used.

Communication on port 2222 is using mutually authenticated (via certificates) TLS connection, so it should be fairly safe, at least until your certificates are leaked. We have seen also customers using proxy in between internet and ESMC server as an precaution, but that would possibly prevent only DoS type of attack which would be filtered on the proxy, as it serves just as an forwarder. Using your own VPN would definitely increase security, especially in terms you will have it under full control - this might be suitable solution especially in case you already employ use of VPN in your infrastructure. Also it might help you to fullfil security compliance, if it is enforced.