Which ports are required to connect remote clients to ESET Protect server?

[Chris A 0]

I'm forwarding the following ports from the WAN to our ESET Protect server:

TCP: 80, 443, 3128, 2221, 2222, 2223, 8883

UDP: 88, 8883

I can easily browse the ESET Server from external networks, but remote agents are not connecting to the ESET server, and I'm not able to push out profile updates.

My live installer does use the FQDN for our server which is forwarded to the ESET Protect server and accessible from off-network.

Do I need to do something else in ESET Protect to make it possible to manage clients that aren't on the same network as the Protect server?

[Lio 0]

Hi Chris,

Are the endpoints in a domain? And which OS are they installed on?

Did you reboot one of them to see?

I had the same problem once

 

 

Edited April 20, 2021 by Lio

[MartinK 378]

Please proceed with standard connectivity troubleshooting (https://help.eset.com/protect_admin/80/en-US/fs_agent_connection_troubleshooting.html) which might helps in this case. There are multiple possibilities what could be wrong, from which most common in this case are:

• non-working DNS resolution in outside network
• misconfiguration of port redirection
• certificate not matching hostname/IP used for connection from outside network

where status.html log on one of failing devices might be enough to diagnose.

Also note, that for AGENTs connectivity, just port 2222 of your management server ha to be accessible from outside network and port 443 for accessing webconsole. I would recommend to consider blocking other ports, in case there is no reason to hold them open - it might block certain functionalities (i.e. port 2223 is used for "Server assisted" installations, but it also exposes API interface of ESET PROTECT). You also mention various other ports, that are not related to ESET PROTECT at all, for example UDP ports, or also TCP port 2221 - is there any reason why there were enabled? Maybe some obsolete article or documentation mentions it?

Edited April 20, 2021 by MartinK

[Chris A 0]

Thanks @MartinK for those details! When the initial NAT policy didn't work I started adding all of the ports I found on a diagram in case they were related.  I'll drop the other ones off as I don't want more open than necessary.

The certificate being used is currently invalid, if that is critical for connection from outside network then I'll absolutely change it.  I just thought since it is working for on-network machines I wouldn't need to get that working yet (we're still in implementation and only have a handful of test computers connected).

@Lio We aren't deploying over AD, although half our computers are AD joined (the other half are Macs that authenticate against Azure AD, but aren't officially "joined" to anything). The remote PC I'm testing is Azure AD joined and not local AD joined, and I have rebooted several times.

To be honest, I don't see anywhere that my server name is established, so I wonder if changing the certificate for the server will redirect things?  My policy already points them to the FQDN I am using, but the certificate is the generic "server" certificate without a proper FQDN.  If I swap certs, will I need to manually update each client or will the ones on-LAN get an update?  (not a huge deal either way since we only have a few computers so far)

[Lio 0]

@Chris A Did you check if your firewall is not blocking any communications?

you can check your listenning and connection established ports in Powershell

 

> Get-NetTCPConnection -LocalPort 57119

LocalAddress                        LocalPort RemoteAddress                       RemotePort State       AppliedSetting
------------                        --------- -------------                       ---------- -----       --------------
::                                  57119     ::                                  0          Bound
10.10.10.2                       57119     1.1.1.1                        2222       Established Internet

 

you can also check with 

> Get-NetTCPConnection -RemotePort 2222

or "netstat -an" to see everything

[MartinK 378]

On 4/20/2021 at 8:27 PM, Chris A said:

The certificate being used is currently invalid, if that is critical for connection from outside network then I'll absolutely change it.  I just thought since it is working for on-network machines I wouldn't need to get that working yet (we're still in implementation and only have a handful of test computers connected).

Could you please provide more details of what certificate and how is it invalid? I would expected that invalidity would cause all AGENTs to not connect, so maybe you meant different certificate, for example console certificate (the one you see in browser when accessing webconsole) - but hat one has no impact on AGENT-to-EP connectivity.
 

On 4/20/2021 at 8:27 PM, Chris A said:

To be honest, I don't see anywhere that my server name is established, so I wonder if changing the certificate for the server will redirect things?  My policy already points them to the FQDN I am using, but the certificate is the generic "server" certificate without a proper FQDN.  If I swap certs, will I need to manually update each client or will the ones on-LAN get an update?  (not a huge deal either way since we only have a few computers so far)

In this case, you are using certificate with wildcard "*", which is simpler as AGENTs will accept it regardless of hostname they are using for connections = it is less prone to configuration problem, but also less secure.
Regarding changes in certificates, in case AGENT are still able to connect to EP, there is still a way how to change all certificates in a way that AGENTs will be able to connect, even without local reconfiguration - but certain scenarios do require steps to be made in specific order to ensure connectivity is not lost. In this case, I would recommend to double check with documentation, I hope it describes various scenarios - it mostly depends on type of changes you require to make. For example re-generating just "peer" certificate, using original CA certificate is fairly safe. But changing also CA certificates might break "trust" between AGENTs and EP, resulting in connectivity issues, even to connectivity issues that won't be recoverable remotely.

[Chris A 0]

Because I don't understand the way certificates work in ESET, I was thinking I need to purchase a public valid certificate for the web interface.  For now, the webconsole always shows an invalid self-signed certificate, but it looks like the ESET Agent adds the ESET server's CA as a trusted CA (if I understand this correctly) so once the agent is successfully installed, future updates should work fine from off-network, and I can safely ignore the "invalid certificate" errors in my web browser.

Does that sound accurate to you?

Is it possible for me to install a public valid cert for the webconsole, or would that just introduce more problems than it causes?

[MartinK 378]

18 hours ago, Chris A said:

Because I don't understand the way certificates work in ESET, I was thinking I need to purchase a public valid certificate for the web interface.  For now, the webconsole always shows an invalid self-signed certificate, but it looks like the ESET Agent adds the ESET server's CA as a trusted CA (if I understand this correctly) so once the agent is successfully installed, future updates should work fine from off-network, and I can safely ignore the "invalid certificate" errors in my web browser.

Does that sound accurate to you?

Is it possible for me to install a public valid cert for the webconsole, or would that just introduce more problems than it causes?

Thanks for clarification. Now I can confirm that certificates used by AGENTs to communicate with EP are not related in any way with certificate used by console, and visible in web browser -> you can replace it anytime without impacting management of devices. When replacing console certificate, you just have to make sure Apache Tomcat configuration is correct, otherwise you might loose access to console...