Incorrect Username when using Captive Portal # set session processing-cpu dp0???

[kalyanram.piratla]

Greetings,

For a quick background; using PA-500 running version 5.0.1 with the User-ID agent installed for domain users as a stand alone agent on the Domain Controller and captive portal setup for AD users using wireless devices.

I have Captive Portal configured with NTLM redirect setup.  It was all working good with users authenticating and users being identified as abc/user_name.  For the past 2 weeks, I am seeing a problem with users being identified by Captive Portal, thereby hitting the explicit deny.

1. When I do a >show user ip-user-mapping ip x.x.x.x, the user name on the Palo Alto comes up as abc.local/user_name instead of abc/user_name after authenticating using Captive Portal and is not associated to any group.

2.  When I clear the user cache and re-login via Captive Portal, the user-ip to mapping is correct i.e abc/user_name, but in around 10mins, it changes to abc.local/user_name, thereby hitting the explicit deny.

3.  Another strange observation is, the wireless device upon connecting to SSID and browsing through to the internet, I get blocked straight away with no Captive Portal page popping up, but after 10mins when I retry to browse to the internet (without disconnecting from the SSID), bingo I have the Captive Portal page.  I authenticate and the mapping works perfectly fine and remains constant.

Any thoughts on what and why this behaviour?

After searching the knowledge base, I read an article "Sessions Showing Wrong Username when using Captive Portal" documented on the 19th of July 2012.  It stated that

"When doing NTLM authentication via Captive Portal, not every session is correctly authenticated and there seems to be irregular User/IP mappings in the logs.  And this behaviour was when the main dataplane process (dp0) goes our of sync with the other dataplanes. The workaround suggested was to force all traffic to be processed by the dp0 dataplane by issuing the command via CLI; # set session processing-cpu dp0.

For my surprise, I could not find this command on the CLI in either config or normal mode on either version 4.1.x or version 5.x.x.  Can someone please let me know if this command is  available and in which mode do I apply it?

If this command is not available or changed etc etc.., can I please ask someone from PAN to update the document.  It will be very much appreciated

Many Thanks

Kind Regards,

Kalyan

[kalyanram.piratla]

And yes, completely forgot to ask:

1. Is it a bug on v5.0.1?  Could not find any relevant information in the release notes nor on the critical issues document.

2. Will upgrading it to v5.0.2 fix the problem?  But I am a bit skeptical on upgrading to 5.0.2 as the bug regarding management plane hitting 100% is not I want.

Regards,

[SCoupland]

Hi Kal,

Long time since I've heard your voice on my phone! I take it this issue is the same thing that you called us about today? It sounds like there is a disconnect between which domain name should be applied to the user. Is this in transparent or redirect? What server profile is being used for the captive portal authentication? Can you provide an example of both user-IP mappings from when it's working and when it's not? What does the authd.log show?

Regarding point 3 I'm not sure, that's something new to me. What kind of device are you browsing with? There has been some odd issues noticed by one of our customers with IOS devices.

The article you are referencing is only for devices with multiple dataplanes, the PA-5000 series.

If the device has support through us then please log a case with us and we can take a look at it.

Regards,

SeanC

[kalyanram.piratla]

Hey Sean,

It has indeed been a very long time and provided I get a chance to get hold of you.  You guys are virtually hard to get off

Coming back to this issue, it might be very much a case of a disconnect between the domains.  I upgraded to 5.0.2 (risking the high data plane spike bug) but it seems that it has fixed the captive portal issue.  Not sure if it was the upgrade or the device required a reboot.

And I was very much inclined towards thinking the command must be for the higher spec boxes; but never mind.

Regards,

Kalyan

[amansour]

CP Works fine for me on 5.0.2 I changed dp0 for other suggestions with this release and even the debugging crashed the device. We really should stop recommending it, reboot fixed it but debugging the dataplane for a packet capture on dp0 is a great way to down the box.

[BobW]

Just a heads up that our CP was  working perfect until 5.0.2.  After 5.0.2 it would choke on occasion, probably because the CPU usage bug.  Point being if the CP seems slow, times out etc. on 5.0.2, it may be the CPU bug on the mgmt plane.  Also, just ordered the ram upgrade for the PA-500 which is supposed to make the management plane snappier...should be here today.

Bob

[amansour]

Thanks is it fixed in 5.0.3? Do you mean the RAM ugprade?

[BobW]

The management plane issue is supposed to be fixed in 5.0.3 and the captive portal works better without the management plane CPU bug (i.e. 5.0.0 or 5.0.1).  The RAM upgrade is supposed to make a pretty significant difference on the management plane speeds as well (something like $375 or so):

https://live.paloaltonetworks.com/docs/DOC-4600

hope that helps....now if we could get our hands on 5.0.3...

Bob

[amansour]

I hear it's out next week.

[kalyanram.piratla · Accepted solution]

The reboot then seems to have fixed the issue for me for the time being.