Prioritize client IP ranges

(imported topic written by atlauren)

We often have situations where a client (usually a laptop) is visible with IP addresses as “multiple results”. This generally happens when they’re on our fixed network, and also have a wireless card, or are using a VPN. In these cases, actions can take a remarkably long time to complete.

Is there a way to set TEM to prioritize certain IP ranges? For example ,if an endpoint is on 10.x.x.x and 192.168.x.x, respond on 10.x.x.x.



(imported comment written by jgstew)

This is likely due to the client being registered with a relay on one of the IPs, but that IP being behind a NAT or otherwise unable to receive the UDP packets from the relay.

If NAT is involved, one option is to put a Relay behind the NAT and port forward the BES port to the relay. This will allow clients behind the NAT to get the UDP packets.

Another option is to enable command polling on clients like laptops that are likely to be in this situation.

These mobile clients may also work better if the relay selection interval was more aggressive, but I am uncertain.

(imported comment written by mcalvi91)

This is also prevalent in any multi-homed/multi-carded device. ideally the IP address property would contain the IP address used to communicate with the TEM server/relay vs containing the multiple IP addresses.

(imported comment written by jgstew)

I do think the IP address inspector should return all of the IPs of the machine like it does. You can see all of them by hovering over the “multiple results” in the console, or by viewing the computer summary.

It would be useful if there was another property which would return the client’s IP that is registered with it’s current relay, but I’m not really sure what you would do with this information, other than debugging this issue.

As for multi-homed/multi-NIC devices, if more than one can reach a relay, it should not matter which one is chosen, unless there is a NAT or other issues blocking the UDP traffic. If you want only one to work with a relay, then only one should be able to reach a relay. This is an issue in the case of wireless devices, but in those cases a relay behind the NAT or command polling should help.

I don’t know if relay selection takes into account the ability to receive UDP return traffic, but if it could, that would be helpful, then if it could run Relay selection whenever the network state changes, like a new network connected, that would also help.