HELP: Clients going 'under the radar' when CP is switched on...

Reply
L3 Networker

HELP: Clients going 'under the radar' when CP is switched on...

We find that an increasingly number of students never get the captive portal auth dialog popping up once we switch on CP (when we are having a test or exam) for their subnet.  The dialog pops up as expected for most of the students, but there are always a significant bunch that somehow never get the chance to authenticate, hence the FW classifies them as 'uknown users' and let them pass by our restrictive traffic rules.

 

All computers are non-domain and from we started using PA-500 8 years ago this setup worked without any problem.  Now we are using a VM-100 (currently on the latest v8).  It seems that the number of non-authenticated clients augments little by little, but the problem don't seem to affect the same users each time we switch on CP.

 

The user computers may have been in hibernation from before CP was switched on and / or they may have any browser open at the moment we switch on CP.  However I thought that any http or https request issued after CP had been switched on would trigger the CP auth dialog to pop up, but apparently this is not the case.

 

I have also tried issuing a 'clear session all filter from <class-zone>' but that does not help either.

 

I am at a loss where to start tracking down this.  Please pop in with tips or info on what mechanisms are triggered both on the fw and on the client computers when CP is switched on and where / what to test for in this case...

 

It seems to me that something like this would be nice: 

while unknown/unauthenticated users exist when CP is active then kick up the CP auth dialog for each of them

:-)

 

Thanks in advance for help on this :-) 

Tags (2)
Community Team Member

Re: HELP: Clients going 'under the radar' when CP is switched on...

Hi @LCMember4427 ,

 

I think the goal is to clear the IP user mapping ... not the sessions.

 

The following commands can be used to clear the mapping:

> clear user-cache-mp ip <IP-address>  //user-cache-mp   (Clear management plane user cache)

> clear user-cache ip <IP-address>  //user-cache      (Clear dataplane user cache)

 

I hope this helps !

-Kiwi.

Highlighted
L3 Networker

Re: HELP: Clients going 'under the radar' when CP is switched on...

Thanks but we can take an example from this morning.  We had no user mappings except a few teachers at the moment I switched on CP.  Immediately when the students arrived the user mapping list was filled up.  Now when I checked in traffic monitoring for IP adresses that went under the radar and did a show user ip-user-mapping on it, its user was <unknown>.  For users that had received the CP auth dialog their IP address was correctly mapped to their user.

 

Most of the students have a test now so I expect that I can't issue a clear user cache now?

 

Are any of those user mapping caches persistent?  When are they cleared (I assume we don't need to do a manual clear cache frequently..?)

 

 

L3 Networker

Re: HELP: Clients going 'under the radar' when CP is switched on...

 

I think the goal is to clear the IP user mapping ... not the sessions.

The following commands can be used to clear the mapping:

 

Does this mean that we have to do this manually once in a while to avoid problems like this...?

Does this mean that the user mapping is a persistent list? 

 

Sorry for asking but I just need to know how this actually works and what actually triggers the CP auth dialog to fire...

 

regards Tor

L5 Sessionator

Re: HELP: Clients going 'under the radar' when CP is switched on...

Hey @LCMember4427 

 

If you're mentioning that the users are coming up as unknown, it means that they don't have any mapping tied to them as you mention. Hence, clearing user-to-ip mappings shouldn't make any difference.

 

I'd like to comment on two points you raised:

 

However I thought that any http or https request issued after CP had been switched on would trigger the CP auth dialog to pop up, but apparently this is not the case.

 

This is actually incorrect (as you sort of alluded to) - the firewall can only serve a captive portal session on HTTP sessions. This is expected behaviour and essentially the purpose of SSL was to stop against man-in-the-middle attacks, which essentially you can consider a captive portal to be one. 

The only way the firewall will be able to serve captive portal sessions over SSL is if the firewall is doing SSL decryption. But since you mentioned these machines aren't domain joined - that option really isn't feasible.

 

You mention that this was working eight years ago - I simply believe this to be because the number of SSL sites has increased since then - resulting in an increasingly less amount of opportunity for the captive portal to be triggered. Likely 8 years ago, the home pages of the machines were set to a site that was listening on HTTP -so when the machine booted up and tried contacting that site the firewall could do its captive portal.

 

Other than decryption, you might want to look at deploying GlobalProtect as a method of obtaining user mappings for these machines.

 

Cheers,

Luke.

 

 

L3 Networker

Re: HELP: Clients going 'under the radar' when CP is switched on...

Aaaaaahhhh.  Now THAT makes sense. I just wonder why my consultants didn't tell me that a long time ago...

 

Ok I understand that GP would be the way to go then.

 

Does it exist a white paper or something which explains the settings to be done in a GP scenario like that?

 

Can I have it switched off in normal production and only activate it on days with exams / tests?

 

If yes, does it exist an elegant way to tell them 'Please use your GP client today'...  ?

 

This was revolutionary news.  I really need to rethink my options now....

 

But thanks a LOT for explaining this.  Now it all makes sense :-)

L5 Sessionator

Re: HELP: Clients going 'under the radar' when CP is switched on...

Hey @LCMember4427 

 

Glad I could provide some insight for you!

 

Now you're asking the real questions... GlobalProtect doesn't really have an "On-Off" switch... but thinking about it, if you're going to be using GlobalProtect internally, the traffic won't be tunnelled so why would you want to turn it off?

One option I can think of on the top of my head is have the connect method by default set to On-Demand User Login (a user can disconnect or connect at will) but then during exam times the connect method is Always-On, so as soon as the PC boots up it will make the connection attempt.

 

"If yes, does it exist an elegant way to tell them 'Please use your GP client today'...  ?" apologies to disappoint on this one. But I don't think so. I'll leave that question in the air for someone else in the community to answer though.

 

"Does it exist a white paper or something which explains the settings to be done in a GP scenario like that?"

 

You'll want to go for an 'Internal Gateway' deployment

 

https://docs.paloaltonetworks.com/globalprotect/8-0/globalprotect-admin/globalprotect-gateways/globa...

 

https://docs.paloaltonetworks.com/globalprotect/8-1/globalprotect-admin/globalprotect-quick-configs/...

 

Cheers,

Luke.

 

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 Live Community as a whole!

The Live Community thanks you for your participation!