Jump to content

How to configure agent policy to connect inside and outside the network


ShaneDT
 Share

Recommended Posts

So I've figured out how to get computers outside the network to connect back to the ERA server over the Internet successfully, but how do I configure policy to connect to the ERA server over the LAN while inside the network, and over the Internet when outside the network?

 

To enable connection from the Internet, I've created a new 'Remote Administrator Agent - http proxy usage' policy, adding the WAN IP address of the network in the 'Servers to connect to' list, and disable 'Use proxy server', all settings with the force flag enabled. Also with the relevant port forwarding on the firewall.

 

I assumed it would just be a matter of adding the LAN IP address of the ERA server and port number (2222) to the 'Servers to connect to' list, but this didn't work.

 

Do I need to re-enable 'Use proxy server' for the internal LAN connection?

 

Thanks.

 

 

Link to comment
Share on other sites

Thanks jraley for your reply, but that's not what I was asking. Yes I already have that configured for updates.

 

What I'm asking about is to enable connection from the agent back to the server, ie for status reporting.

Link to comment
Share on other sites

Anyone?

 

I now have a situation where I have nearly 20 notebooks that won't talk to the ERA server. I've removed this policy so now only the default policy applies, but I still can't get these clients to report back tot he server. I've tried redeploying the agent, which reports success for the task, but still no response back from the client. I've tried running an agent uninstall task, which is just sitting with status 'planned'. I set the trigger for asap but I don't know if the task is getting to the client as the agent isn't communicating.

 

Am I going to have to go and uninstall the client manually on every notebook and start again?

 

This has got to be the most complicated antivirus software IN THE WORLD!
 

Edited by ShaneDT
Link to comment
Share on other sites

  • ESET Staff

Anyone?

 

I now have a situation where I have nearly 20 notebooks that won't talk to the ERA server. I've removed this policy so now only the default policy applies, but I still can't get these clients to report back tot he server. I've tried redeploying the agent, which reports success for the task, but still no response back from the client. I've tried running an agent uninstall task, which is just sitting with status 'planned'. I set the trigger for asap but I don't know if the task is getting to the client as the agent isn't communicating.

 

Am I going to have to go and uninstall the client manually on every notebook and start again?

 

This has got to be the most complicated antivirus software IN THE WORLD!

 

 

In case AGENT is not connection, it won't be able to receive task, nor configuration policy.

ERA does not uses HTTP proxy to communicate with SERVER (port 2222) -> for this purpose, ERA Proxy component was supposed to be used- or maybe port redirection.

In order to specify steps for "repairing" AGENT you will have to provide more information, but If I understood you correctly, they are not connecting only because SERVER is not available for them from outside of network. If this is the case, connecting notebooks to internal network should enable them to connect and receive task/configuration policies.

Link to comment
Share on other sites

No, the computers are not reporting as connected from either inside or outside the network.

 

I don't understand what you mean by "ERA does not uses HTTP proxy to communicate with SERVER (port 2222) -> for this purpose, ERA Proxy component was supposed to be used".

 

When configuring policy to enable connection from outside the network, I've specified the WAN IP address and standard port 2222 in the 'Servers to connect to' list, and disabled 'Use proxy server', and this seems to have worked fine in other deployments.

 

But in this deployment I also added the internal server IP address including port 2222 expecting it would connect to one or the other.

 

So now that the agent is installed and not reporting back to the server, what can I do? As above, I was able to create a new task to install the agent on one of the computers where the agent was already installed, and this task reported success. The ERA server can still see the computers on the internal network obviously. Surely there must be some way I can send the updated policy to the clients if they're on the same LAN?

Link to comment
Share on other sites

I have other PC's and servers on the internal network that I deployed the agent to from the ERA server exactly the same as I deployed to the notebooks, only difference is they didn't have the 'inside/outside' modified 'Remote Administration Agent - HTTP Proxy Usage' policy applied, and these are reporting back to the server as expected.

 

But I cannot get the notebooks to report back to the server, either inside the network on the local LAN, or from outside the network.

Link to comment
Share on other sites

  • ESET Staff

You can create policy for ESET Remote Administrator Agent and in section Connection -> Servers to connect to list both internal IP and also external IP. Agents will be trying to connect to them in specified order, in case internal network connection will fail, it will try alternative.

 

Regarding your connection issues, we will need more precise error description, i.e. C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html from one of notebooks. My guess is that either there is network issue, or SERVER's certificate is not prepared for this scenario (maybe AGENTs are configured to IP/hostname that is not signed in SERVER's certificate?).

Link to comment
Share on other sites

You can create policy for ESET Remote Administrator Agent and in section Connection -> Servers to connect to list both internal IP and also external IP. Agents will be trying to connect to them in specified order, in case internal network connection will fail, it will try alternative.

 

This is exactly what I did and what I would have expected to happen. I've specified both the WAN and LAN IP of the server, both with port 2222.

 

Regarding your connection issues, we will need more precise error description, i.e. C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html from one of notebooks. My guess is that either there is network issue, or SERVER's certificate is not prepared for this scenario (maybe AGENTs are configured to IP/hostname that is not signed in SERVER's certificate?).

 

This might be a clue to the problem. I've just used the default Agent certificate created during ERA installation. Does the default certificate only have the server hostname? Not the servers LAN IP address? TBH I don't remember modifying the default Agent certificate with another deployment where I've configured the agent policy for external only connections. I configured the policy for this deployment exactly the same, just with the addition of the servers LAN IP address.

Edited by ShaneDT
Link to comment
Share on other sites

  • ESET Staff

Default AGENT certificate is most probably created for all hosts (using wildcard *) -> this means AGENT can connect from everywhere. You can actually see it in Admin section -> Certificates -> Peer certificates, it is column named "Host".

 

More problematic is SERVER's certificate. There will be probably list of signed hostnames/IP address, and AGENT can use only one of those. To get mentioned list, go to SERVER's configuration -> Connection and you should see there description of currently used certificate.  Search for something like Subject Alternative names (DNS:<hostname>) possibly containing hostnames or IP addresses of your SERVER resolved during setup.

Link to comment
Share on other sites

When you configure the server task in ERA to deploy the agent, you need to select a certificate. I've selected the default Agent certificate (as I have with other deployments).

 

With other deployments I've not modified any default certificates, or created any certificates. I've only used the default certificates created during ERA install. And haven't had a problem. My own ERA server is hosted on Azure with all client computers except of course the server itself reporting back via the Internet connecting to the WAN IP of my Azure service.

Link to comment
Share on other sites

  • ESET Staff

When you configure the server task in ERA to deploy the agent, you need to select a certificate. I've selected the default Agent certificate (as I have with other deployments).

 

With other deployments I've not modified any default certificates, or created any certificates. I've only used the default certificates created during ERA install. And haven't had a problem. My own ERA server is hosted on Azure with all client computers except of course the server itself reporting back via the Internet connecting to the WAN IP of my Azure service.

 

When AGENT connects to SERVER, both sides are verifying remote peer. In case you used default agent certificate, SERVER will have no problem verifying it. Problem is that AGENT also verifies SERVER's certificate, and this is most probably problem. But to be sure, please check previously mentioned status.html. It will print exactly where problem is and in case it will be certificate-related, we will know how exactly should look new certificate.

Link to comment
Share on other sites

No worries, will check that tomorrow. All notebooks have gone home for the day.

 

So back to one of my questions above. With the notebooks on the same subnet/LAN as the ERA server, and with the 'offending' policy now removed, is there a way to update the agent on the notebooks from the server so they start communicating again. I have PC's and servers in other static groups that are communicating correctly, with the only difference being this 'inside/outside' agent policy applied to the notebooks static group when the agent was deployed.

Edited by ShaneDT
Link to comment
Share on other sites

  • ESET Staff

No worries, will check that tomorrow. All notebooks have gone home for the day.

 

So back to one of my questions above. With the notebooks on the same subnet/LAN as the ERA server, and with the 'offending' policy now removed, is there a way to update the agent on the notebooks from the server so they start communicating again. I have PC's and servers in other static groups that are communicating correctly, with the only difference being this 'inside/outside' agent policy applied to the notebooks static group when the agent was deployed.

 

In case it won't be possible to repair connection to SERVER, only possibility will be repairing AGENT, which can be achieved:

  • manually directly on target machine
  • using GPO or other automated method for software deploying
  • using Remote Installation from SERVER

but in case it is certificate problem on SERVER side, it will be possible to repair it - this can be checked also in SERVER's trace log -> you should see "Error" line for each failed connection attempt - identified by IP address (this may be IP address of your NAT/Gateway from outside network).

Link to comment
Share on other sites

  • ESET Staff

Where is the servers trace log located? path and filename

 

C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs\trace.log

Link to comment
Share on other sites

OK so I figured out what happened, little bit embarrassing actually lol.

 

I had exported policies for EFS, EES and the Agent from my hosted Azure system to import on customer ERA servers to save a bit of time on setup. Well of course I changed the servers in the Agent policy but I must have forgot to change the certificate (though tbh I thought I had). So the notebooks were trying to connect using the certificate from my hosted Azure ERA server, not the customers on prem ERA server.

 

Manually uninstalling the agent, then re installing using the EraAgentInstaller.bat from the customers server resolved the issue.

 

Is there a way to create an uninstall script for the agent, that includes the uninstall password?

Edited by ShaneDT
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...