SSL VPN and User identification

[dagibbs]

Hi.

When a user is logged on to the SSL VPN through my Palo Alto firewalls, the user dientification seems to be - well, flakey.

Sometimes it identifies, most of the time it doesn't.

I have "Enable User Identification" ticked on the VPN zone, yet I am seeing traffic into the network through the VPN which doesn;t identify the source user - yet the user is plainly identifiable by viewing the current users logged on to the VPN.

Interestingly, when the user initially logged on to the VPN this morning, every packet was identified for about the first hour and 20 minutes, ten the identification became interrmittent and only occurs every few packets.

Does anyone know if this is some inherent timer, or is there something I can tweak to get this working all the time?

Thanks.

[odaos]

Hello,

I am not aware of any timer issues?  What software version are you currently running on your pan-agent and how many do you have?

Try resetting your pan-agent connection to your PAN device and see if that helps.

[dagibbs]

odaos wrote:
Hello,
I am not aware of any timer issues?  What software version are you currently running on your pan-agent and how many do you have? 
Try resetting your pan-agent connection to your PAN device and see if that helps.

The box is running 3.1.6 software, and the VPN client is 1.2.0. Agent version is 3.1.2, all of which are the latest available as far as I can tell (well, there was a beta version of PanOS 4 which popped up in te software list the other day, but I definitely did NOT install it, and it's gone now).

I've removed/re-added the user agent connection - but haven't had a long-term VPN user logon since, so I have to wait until one of my more common "work from home" users logs back in. I have only one agent running in my domain, and it's only looking at about 4 domain controllers, so load should not be an issue.

Cheers

[kpatten]

Is there any mechanism for user identification over SSL VPN that utilizes the credentials provided by the user to make the VPN connection?

[dagibbs]

kpatten wrote:
Is there any mechanism for user identification over SSL VPN that utilizes the credentials provided by the user to make the VPN connection?

I don't know - I would have thought that would be the logical way of doing user dientification on the VPN link, but I'm not sure if it works that way or not.

Maybe someone from Palo Alto can clarify for us?

[kbrazil]

Yes, the SSL VPN login will populate the traffic, threat, url, etc. logs with User-ID information.

Cheers,

Kelly

[dagibbs]

kbrazil wrote:
Yes, the SSL VPN login will populate the traffic, threat, url, etc. logs with User-ID information.
Cheers,
Kelly

Yeah, except it doesn't always- not for long-duration VPN connections (see original question in this thread).

The VPN users originally appear in the "from user" ID field - but if they stay logged on for a long enough period of time (seems to be about 80-90 minutes) the "from user' field becomes blank.

doesn't really matter - I've worked around it for now - but it's a minor annoyance.

[kbrazil]

I would file a Support case as this does not seem to be expected behavior.

Cheers,

Kelly

[daniel_varela]

Hi,

I get this behaviour and I suspect that the problem is from whose users that open vpn ssl sessions from same public IP. Normally, Palo Alto device recognises the last user login from that IP (at the begining recognises several users but only for 20 minutes).

I don't know if Palo Alto has a way to map this users....maybe throught a session cookie?

[kbrazil]

The User-ID is being tied to the internal assigned IP address, so I'm not sure that the external IP address is the issue.  I suspect it may be a timing issue or conflict with the User-ID agent or Captive Portal logic.

Cheers,

Kelly

[daniel_varela]

This happens not only with user-id or captive portal, it happens with local

users too. How can the PA map the whole session? If all the connections

uses the same public IP there is a problem, how can keep the information of

all users? It uses port number? Some kind of cookie? We've checked all

types of timeout and we didn't find anything.

Cheers,

Daniel