IE8 and captive portal

[jasbeck]

Users are getting "can not display web page" in IE and "connection reset" message when using firefox when opening the browser up and captive portal is attempting to redirect them to the authentication page or the "block-continue" page. Has anyone noticed or seen this happen?

I notice it only when the WMI polling fails to correctly identifty the logged on user (if it fails our setup defaults to captive portal to id) OR if the PC is logged in with an account that would be unidentified and sent to captive portal anyways.

Has anyone ever seen this before? Traffic and URL logs do not show anything odd. They either show the attempt as a block-continue or they truly show nothing since the request is being intercepted.

Is it possible that the PA device is being overloaded so it's not serving the captive portal page and/or block-continue page?

Or is it something internal to IE8? Maybe compatabily mode for the block-continue page or captive portal pages presented to users??

[gswcowboy]

What PANOS are you currently running?

[jasbeck]

4.0.3

[gswcowboy]

Please run the following command on your PAN and provide the output.

> show counter global | match session_svc_cp

[jasbeck]

out from command is:

session_svc_cp                        2447        0 info      session   resource  Sessions allocated for captive-portal

Also ran a wireshark session and I see the PAN device actively resetting connections instead of presenting the captive portal page. After a random number of refreshes or hitting enter enough times it will eventually prompt with a captive portal page.

See screenshot lines 321 is the initial HTTP GET, 322 is the reset from the PAN. Line 328 is another HTTP GET (same URL) and 329 is the succesful captive portal presentation.

[gswcowboy]

Doesn't appear to be related to a bug I was thinking about. At this point, please call into Support for further diagnosis @jasbeck.

Regards,

Renato

[dept_tec_bcn]

Hello all,

We have a similar issue.

Our problem is that many WIFI users cannot get the Captive Portal web. If we try many times with luck the Captive Portal finally apears (sometimes in 10 minutes sometimes more than on hour later!!!!, sometimes no succeed), the strange thing is that the same user with the same computer can have the problem today and not tomorrow.

Once the computer succeds in connecting it can connect and disconnect without problems during the day. But perhaps tomorrow could or not find that problem. (We have the problem with all web browsers)

We are having this problem with lots of users, and because it randomly appears it is difficult to locate the real issue.

We have two 2020 PAN devices in HA Active/Passive in PANOS 4.0.3. The Captive Portal is in transparent mode.

Any Idea? We have checked all the net Wifi controller, Switchs, etc. All seems to be ok. Tomorrow i will try to configure redirect mode for Captive Portal but i have no many good feelings with that.

Thanks in advance for your help/support.

Albert

[jasbeck]

The issues we were seeing (captive portal failing to present a page and performing a reset on the connection - checked this via wireshark on an offending machine) were caused by a bug in 4.0.3 where captive portal will start failing after 24 hours. The fix was upgrading to 4.0.7.

Seems to be working fine after that.

[jasbeck]

An update on this:

upgrading to 4.0.7 did not fix anything.

I have been informed by tech support that all PAN devices have a hard cut off of 2500 concurrent connections for captive portal (i.e.: CP is presenting authentication page to users OR, more likely, an automated process using port 80 on workstation is attempting to run and being stopped and "presented" with CP).

So, now - my question is:  is there any way to see what is causing the captive portal connections?  What URL or traffic is being seen? The logs only show succesful flow of traffic, not attempts to port 80 that are stopped or presented an auth page by CP.

[rmonvon]

Hi...Captive Portal is initiated whenever the user is unknown & the HTTP traffic matches the Captive Portal rule. Let's say we have a single Captive Portal rule 'any any action=captive-portal'.  An HTTP request arrives from IP address 1.2.3.4 and there is no user associated with this IP.  This means IP 1.2.3.4 has user=unknown and is subject to Captive Portal.  The 'any any action=captive-portal' rule will match this HTTP request and the user is redirected to the Captive Portal page.

Once the user logins to Captive Portal, then his/her Captive Portal session will be released.  The user is now a known user and is not subject to Captive Portal until the credential expires.

Thanks.

[jasbeck]

Yup - that's my understanding of how it works.

So - my question once again: is there any way to see what is causing the captive portal connections?  The logs only show succesful flow of traffic, not attempts to port 80 that are stopped or presented an auth page by CP.

[rmonvon]

See if there is a captive-portal log & view it via the CLI.  You may need to contact Support if the log file is not generated.

admin@pa2050> tail follow yes mp-log captive_portal.log

Or issue a packet capture from the PA device.  Set the filters for dest ports: 6080 and 6082

6080       Captive Portal captive portal redirect

6082       Captive portal and captive portal redirect with certificate

Thanks.

[jasbeck]

Just an update on this:

Finally received a response regading this: It's not possible to see what destination IP (or URL) is causing captive portal to intercept. The GUI logs, nor any CLI log files, include this information. The captive potal log no longer exists in PAN 4.x.x, and the logs containing CP info do not contain the dest IP.

The only way we've been able to do it is to turn off captive portal and let all unidentified traffic pass from the CP rules to the security rules where they are blocked (unknown URL traffic is blocked in our environment). At that point we can check the logs. Unfortuantely, this process affects the production environment, so disabling CP for 5 to 10 minutes is the only viable option.