Traffic Logs show 2 different source users from same IP

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Traffic Logs show 2 different source users from same IP

L1 Bithead

We are using User Identification and have the user-id agent running on 2 different AD servers.  Also using global protect.  When looking at traffic logs I can filter on my GlobalProtect VPN IP, I can see the source user of my user account, and a source user of another account.  When looking user-id mappings, and look at my VPN IP, I only see my user account.  Any idea what would be causing this?image.pngimage.png


L7 Applicator

Hi @emarschang 

Did you really hit enter for the search query in the first screenshot?

As there are 2 hours between the logs in these screenshots it might be possible that the other user disconnected and global protect assigned then this IP to you. At least this is an explanation. If you provide some more logs like the global protect logs we might be able to find the actual reason.

Sorry for the confusion there on the timestamps.  Next time I catch this happening, ill will try to grab the relative logs/time stamps.

L1 Bithead

I finally was able to get some fresh screen shots.  I got a screen shots from the traffic log, user-id log, and url filter log.  I think we can take the global protect out of the equation.  This is happening to internal users as well.  In this example, end user tried to go to you tube, got a blocked page, but it showed his username as the manadmin user.  Not his user account. TrafficLogs-SourceUsers-SameIP.pngURLFilter-SourceUsers-SameIP.pngUserID-SameIPs.png

Cyber Elite
Cyber Elite


What is the timeout setting for your user-id settings? Also what are you using for user-id to perform the mapping, active directory logs, etc.?


We are using active directory logs.  We have the agents on two domain controllers.  Time out is set to 2700 seconds (45 Min.)

Hey @emarschang ,

This is very strange... Because by design User-ID cannot associate one IP address with more than one user:

- It can associate one username with multiple IP addresses, because it is common for user to connect to multiple machines (login to workstation and perform remote access to multiple server/hosts). So it make sense each machine to be associated with that user.

- But FW should never associate single IP with multiple users, instead it will replace the associated user with the latest once that is received from the user-id agent (agent or agent-less). I believe the reason for that is that User-ID purpose is to identify  where the user is physically connected from.

Probably better explained here -


That being said it shouldn't be really happening to have two users associated with one IP.

Looking more closely to your last three screenshots I still don't believe there is actual conflict, but rather "aggressive" IP reuse:

- Looking at you User-ID logs we can see that user "evanhoozer" was associated with that IP until 06:10, when new user ("manadmin") is associated with the same IP.

- Having that in mind checking your URL logs it make sense, because the bottom half of the logs are around 05:46 - at that time "evanhoozer" is associated with that IP (as we saw from user-id logs). The rest of the logs are from 06:15 onward - which are after the User-ID log (at 06:10) showing that "manadmin" is now associated with that IP.

- Moving to the traffic logs - All the logs from the picture have ended after 06:19 (again from user-id logs at that time manadmin is associated with that IP). From the picture we don't know when those sessions have started, but if they are show the "manadin" user, most likely they have started after 06:10 (first user-id log associating "manadmin" with that IP).

- Probably the more interesting logs from the picture are the two with "evanhoozer" user - looking at the Session End Reason field I notice that those are closed as "aged-out". Also noticed that this is decrypted traffic on port 443, this means it is TCP traffic (as far as I am aware PAN cannot decrypt QUICK over UDP). So TCP session that has aged-out, means that FW didn't saw FIN/FIN-ACK or RST from both source or dest and connection was not properly closed. By default TCP session timeout is 3600sec, which means FW will keep the session for one hour before closing it and creating end log entry... And combining all of these makes me very confident in my guess that the sessions for those traffic logs were opened some time before 06:10 - when the IP was still associated with "evanhoozer". If you open the log details (the magnifying glass on the left) you should see start and end timestamps. I can bet that for those two logs the start time is before 06:10


Looking at the provided screenshots, for me it doesn't like you have any actual problem, other than very aggressive reuse of IP addresses - it looks little strange why you have user-id log at 06:09:24 for "evanhoozer" and another at 06:10:33 for "manadmin" - this is one minute gap. Couple of reasons could explain this behavior.


But before going deeper, I would ask the following questions:

- Do you have actual problems for blocked traffic, because firewall was using wrong ip-to-user mapping?

- Does the two users in the example used by different people? Are those personal account?

- The one looks like privileged account, that could be used for remote access? Does "manadmin" being used for RDP connections? Does it has connected anyhow to the workstation where "evanhoozer" was login?

- I assume you use DHCP for the network that those users are connected - what is DHCP Lease time? Do you know if you are reaching the end of the pool? Or any other reason for more aggressive IP address reuse?



Thank you for the wealth of information.  After reading and checking out the link, it may be something very similar happening.  I am starting to guess, that there is a remote process logging into the devices that may be causing the second id mapping.  I am going to try the work around and add the privileged accounts to the exclude list.  Thank you again for the help.

  • 7 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!