cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

So I cannot believe we are the first company to be trying to achieve this.

 

Instead of going the expensive route of migrating our entire McAfee offering to ENS or building a new cloud-based EPO, we are trying to manage a new Azure-based customer using our existing internal on-prem EPO server.

 

I have installed the McAfee Agent on the endpoint, and after updating Firewalls etc, have got the endpoint to successfully appear within the EPO. However if I then try to push the VSE client or anything like this to the endpoint it fails.

 

The difficulty I can see is that we are using a NAT to access the Azure VMs, as their address range overlaps slightly with an existing customer. The agent reports the IP configured within the VM - 10.200.x.x however its NAT address is 10.199.x.x - is there anything that can be done to make this work nice and simply? I believe if I could force EPO to try and communicate on 10.199.x.x it would all just work.

 

Thanks in advance!

1 Solution

Accepted Solutions

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

So I've actually got this working with some assistance from my networks colleagues. We now have push commands working from the EPO back across to the agents in Azure, so my 'Run Client Task Now' is working to push VSE to the VMs in Azure. Agent Wake Up also works which every McAfee document I come across says won't work..

 

We added another NAT just for the EPO back to the VMs in Azure that would push the commands via the route we wanted it to go rather than via the IP reporting in by the agent. With a little extra playing on the firewalls, this has worked perfectly, client commands, agent wakeups etc all work as normal now.

5 Replies
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

How are you attempting to deploy the products - with run client task now, or scheduled tasks?  If run client task now, that will not work over nat, just as wakeup calls do not work over nat.  Refer to KB58818.

A scheduled deployment task should resolve the issue if all the required ports (kb66797) are open and the agent is successfully communicating

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

Ah, this is the article I missed during my searches! Perfect, I've configure dmy policies and assigned and scheduled tasks to the relevant group, should see this all working after lunch today Smiley Happy

 

Much appreciated!

McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 6

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

Glad to assist!

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

So I've actually got this working with some assistance from my networks colleagues. We now have push commands working from the EPO back across to the agents in Azure, so my 'Run Client Task Now' is working to push VSE to the VMs in Azure. Agent Wake Up also works which every McAfee document I come across says won't work..

 

We added another NAT just for the EPO back to the VMs in Azure that would push the commands via the route we wanted it to go rather than via the IP reporting in by the agent. With a little extra playing on the firewalls, this has worked perfectly, client commands, agent wakeups etc all work as normal now.

McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 6

Re: Using On-Premis EPO on internal network to manage endpoints in Azure (using a NAT).

Jump to solution

Sweet, great job!