Registration Subnet relevance returns <error>

Usage and Config
1

I’m using the following relevance to return the subnet that the Endpoint is reporting from …

registration subnet address of client

on a number of systems the results returned are “< error >”. (The spaces were added so the < > characters would display in the forum editor)

This is only happening on a small subset of endpoints. Most are returning the desired values. I’m guessing something is wrong with these endpoint’s network configuration, but I can’t tell what it is.

Does anyone have any suggestions on where to start looking?

2

The information that is used by this inspector is the same information passed to the client on its registration commands so if you look in the client log at any of the relay selection commands (look for clientregister on a URL) you need to be seeing some AdapterInfo parameters formed like:

&AdapterInfo=-<mac address>_<subnet>%2f<ipaddress>_X

So you can probably see where the information is coming from. If your registration command doesn’t include that then the following relevance probably isn’t giving the right information:

(mac address of it as string, cidr string of it, address of it as string) of ipv4 interfaces whose ( up of it and exists mac address of it and length of mac address of it = 17 and exists cidr string of it and exists address of it ) of network
3

Could the agents having this issue be behind NAT’s? I believe the inspector returns the value that the parent relay returned to the agent when it registered. This is only returned by the parent relay when it sees the incoming socket’s IP address matches one of the IP addresses listed in the registration request.

4

Looking closer at the systems that are giving me the error, they seem to be laptops (Windows and Mac) AND for the most part they are using one of our DMZ relays.

I use the _BESClient_RelaySelect_FailoverRelay setting to configure laptop devices so they can still communicate from outside the network.

5

Its possible that the DMZ relays are behind a NAT type interface and as @AgentGuy pointed out, this type of information doesn’t flow well through these type of connections as one side thinks its one address and the other thinks its another.