X-Forwarded-For - get real IP for UEM world map

Can UEM be used for masked ip's monitoring and provide geographic specific latencies

I have tried to perform a UEM health check to verify whether the UEM dynaTrace cookies are being filtered out (dtCookie, dtPC, dtLatc). During our WebEx session there was a general outage of the customer's application which prevented us from accessing the application URL. Once the URL is reachable again, another UEM heal check will be attempted again.
Regarding the proxy server visits: At this point in time we know that certain end-users access the application through proxy servers (see screenshot proxy_visits.jpg). It has been mentioned that the high amount of US users are in fact also accessing the application from outside of the US

• One solution would be to map the known proxy servers to an exact location in dynaTrace (dynaTrace server => Geographical Locations), if the exact locations of the proxy servers are known. The disadvantage of that is that we would have an aggregate as well.
• Another option would be that the customer adjusts his proxy server settings. The question is whether the proxy servers can be configured in that way, that the real IP address is being passed through as well. There are currently two entries in the X-Forwarded-For (XFF) header attribute, whereas dT would expect only one entry. Therefore I was told that dT would have problems in processing the XFF attribute for UEM. I am also not sure whether the XFF attribute contains the "real" IP address. Is there any other attribute which contains the "real" IP address and which we could use for UEM?

Hi Tomislav,
is it possible that for some reason our cookis are filtered out (dtCookie, dtPC, dtLatc) for the missing user actions.
If so this would be an explanation why you see server side PP but no user action (and so no visits).

Best, Herwig

That is a good question about why there are two IP addresses in the X-Forwarded-For (XFF) field. From my understanding the left XFF value should be the original IP, and all subsequent XFF values should be proxy entries? During today's remote session dT only offered me to drill down to user action Purepaths (starting from the visits dashlet) and not to Purepaths, where I would see the XFF header field. What the customer also mentioned is that in the North America they have an unexpectedly high amount of visit counts, whereas in Asia the visit count is rather low. Maybe the reason for that is because end-users are using a VPN from Asia (connecting to the US) and then using the application?

From an older local session file, the following attached screenshot shows how I can drill down to the IP address in the Request Header visits_ip_drill_down.jpg

Another more important question: in UEM we currently have missing entries / visits. Are these missing entries also reflected "everywhere else" in dT? (meaning in the server-side Purepaths). As far as I understand, UEM is considered separately in dT and therefore other parts in dT should provide a complete picture. Is that correct? (e.g. dashlets for Web Requests, Transaction Flow, hotspots)

After yesterday's change, the first customer feedback today is that there is no improvement. The expected dots in the world map are still missing. In the System Profile, I have checked the "User Experience" settings and they seem to be fine. In the "Visits by Location" dashlet, there are proxy entries (see attached screenshot proxy_visits_by_location.jpg ). What could be the reason?

Hi Tomislav,

Pushing the X-Fowarded-For attribute to the top of the list in the Geographical Locations dialog did not resolve this issue for you?

Rick