IP Address Reported by McAfee Agent to ePO

[ecardanha]

Hello,

  Currently the IP I see reported in by the Agent is captured from the Registery and passed up to the ePO  which will show only Private IPs if it is off the internal network.  Is there a way in newer releases to see what the actual public IP is from where the device is checking in?  Would like to know when devices are off network what the real IP incase a device is lost.

I had asked the question once before but that was in 2015 hoping the answer is different now.

   Thanks,

      Evan

[cdinet]

The agent can't report what any router or ISP nats that to.  We report what the OS tells us is the IP.

[ecardanha]

So since the client checks in on HTTPS port 443 is there no way for the ePO to show the real nat'd IP of where that request came from for that client?  Instead of showing only what the client captures from a registry entry.

   Evan

[cdinet]

No, the agent has no visibility into that.  The properties are local to the system and even Windows has no knowledge of what that natted IP address would be.  It is something occurring beyond the system itself.

[m33rk0]

Hello Everyone, I have a similar case.

Customer Windows 10 workstations connected to company resources via VPN and reporting to my ePO server are showing private IPs instead of VPN ones.

Here's a excerpt from ipconfig from one of the affected hosts:

Ethernet adapter Local Area Connection* 12:

Connection-specific DNS Suffix . : *******.com
Link-local IPv6 Address . . . . . : fe80::686c:dea8:b8e2:1dd9%22
IPv4 Address. . . . . . . . . . . : 10.100.64.174
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : *****.com

Wireless LAN adapter Local Area Connection* 9:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Local Area Connection* 10:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Ethernet adapter Ethernet 2:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . : modem
IPv6 Address. . . . . . . . . . . : 2001:8003:5c6d:4b00:c8cc:8e91:8276:1da0
Temporary IPv6 Address. . . . . . : 2001:8003:5c6d:4b00:7c68:f355:6e94:84fd
Link-local IPv6 Address . . . . . : fe80::c8cc:8e91:8276:1da0%18
IPv4 Address. . . . . . . . . . . : 192.168.0.38
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1

What I see in ePO is the 192.168.0.38 address instead of 10.100.64.174 which is the VPN one, and my customer would like it the other way around.

Could someone possibly explain to me how this could be achieved? Is this related to a Windows 10 setting perhaps? I presume the Agent has no mechanism that would enable it to 'choose' the IP that it is supposed to report, and what I see in epo is what the Agent 'gets' from the OS (Win 10).

I've asked one of the users to pull up PowerShell and run get-netipinterface so I could see the InterfaceMetric values for all the network interfaces. It turned out that even though the VPN adapter (Local Area Connection* 12) had the lowest value, it still made no difference, and the Agent (5.6.6) was reporting 192.168.0.38 from the Wi-Fi adapter which had a higher value.

I would appreciate your insight.

[cdinet]

No, currently we are dependent on api calls (not registry) for what the OS returns as the first bound IP address.  Please refer to the following KB.

https://kc.mcafee.com/corporate/index?page=content&id=KB53169

[Pavelek_g]

An API call will provide you a list of NICs and values bind to the NICs, so what is the determinant you use to chose the "first" reported NIC?

[cdinet]

We do not choose, the OS reports the bound nic to the agent.  We rely solely on the OS to report that.

[m33rk0]

Thank you for your replies. I do wonder how the OS decides which NIC to report. I presume there is a value on which it depends, and initially I thought it might be the InterfaceMetric.

I've attached a PNG screenshot from an affected machine's PowerShell. I asked the user to run get-netipinterface. As you can see, even though the Local Area 12 connection (VPN connection) has the lowest interface metric (20), it isn't its IP that is reported to the Agent but rather the IP assigned to the Wi-Fi adapter (InterfaceMetric 50). Based on this, I think it must be another value that is in play here.

I've checked https://kc.mcafee.com/corporate/index?page=content&id=KB53169 but I'm still none the wiser.

[cdinet]

Per the KB, we have no control over what IP the os reports to us as primary nic.  

Solution

Customers are requested to work with Microsoft to force the computer to report the NIC with the external IP address first.

If you require a change to product functionality, submit a new product idea at:

https://community.mcafee.com/t5/Enterprise-Product-Ideas/idb-p/business-ideas