How to Configure Captive Portal

Printer Friendly Page


The attached document gives step-by-step instructions for configuring captive portal.  Four scenarios are covered:

  1. Web form login page- Transparent mode
  2. Web form login page - Redirect mode
  3. Client certificate
  4. NTLM authentication


  1. Starting with PAN-OS 5.0, the action previously named "captive-portal" is now "web-form." Only the name has changed. The web-form page prompts the unknown user for credentials.
  2. The action previously named "ntlm-auth" is now "browser-challenge.".Only the name has changed. The browser-challenge action authenticates users behind the scenes through the NTLM support in the browser (for example, IE and Firefox).

Note: The 'no-captive-portal' action remains unchanged. When the initial traffic is https, Captive Portal will not be presented because of encryption. For HTTPS traffic to have Captive Portal launched, enable decryption.
For more details reference the following link How to Implement and Test SSL Decryption


owner: tlozano


Are there any updated instructions for Pan ver 6?

Although I have Captive Portal working on my Palo Alto, I now have a situation where I need to create a Walled Garden, specifically for iOS devices. By default, iOS keeps "Auto-Login" ON, which causes a problem. iOS tries to get to one of a number of sites, and if it fails it reports the Captive Portal has failed and drops the connection. Turning off Auto-Login on iOS and then manually opening Safari solves this problem, however it requires the user know to do this. Otherwise we need to whitelist a number of hosts in a walled garden:


My question is: "How do I set up a walled garden?" Or do I just allow traffic before the web-form rule?

dgross: Where you able to figured the Captive Portal for iOS 8.1 devices? I'm having the same problem.  Where email is not being updated until the user logs in to the Captive Portal.

any updates to this? Other vendors have figured this issue out for iOS devices. Strange why Palo isn't keeping up or at least addressing it in this forum.


This been my fix as well, adding all of Apples domains.  You can go a bit further and include  /library/test/success.html

Couple more notes of interest:

  • I have seen dramatic differences in minor revisions on the IOS devices like:  fictional example: 7.1.1 might act differently than 7.1.2
  • Most users go to "" which default to https://.  They need to go so an unencrypted site.
  • If after trying to go to a site they still don't get the CP prompt, have them use an alternative browser.  Safari does work with the captive portal very well.  Firefox and Chrome work 100% of the time.


sad that Palo doesn't build this capability in ... once again... competition has addressed it.

I don't understand why I need a decryption for the https - traffic  accessing captive portal.

The only thing I want to do  is that the user is authenticated over the portal . The first site he called has to be redirected to the captive portal for signing in. Therefore I don't need to decrypt - normally !

For me it is unusable because the user are irritated when they gets the "Untrusted certificate error"   if I use a self signed CA



you can either use a certificate signed by your ActiveDirectory CA so the users trust the certificate, or have the users import the certificate into their root store


the reason decryption is needed, is because you cannot intercept a GET request in an encrypted session as this part is already encrypted and the browser will not accept a redirect that does not follow the rules of ssl encryption (the redirect needs to happen as a response to the GET request inside the ssl session)

My goodness! I'm dealing with a similar problem now for Chromebooks, and I just found this old article. I didn't have "email me" clicked at the bottom - I'm sorry! - I didn't know there were responses.


Since there are "new" responses only two weeks old - I did originally figure out the iOS problem. The short answer:


Under Policies > Captive Portal we created a new rule called Apple Captive Portal Asst. Source was our public and student wireless / any, and destination was untrust / and apple's IP block and for service-HTTP and service-HTTPS -> choose no-captive-portal. (Instead of web-form or browser challenge.)


That did allow iOS devices to whitelist around our CP without incident.


I'm now trying to do the same thing with Chromebooks, since they need to see Google to configure themselves. But Google doesn't have a single block of IP addresses - it uses a rapidly changing and dynamic group of addresses and I'm not having luck getting these devices to work the way the iOS devices did.


/*turning on email responses this time... ;) */

hi guys is it possible to set the captive portal page to HTTP only?

hi @toskie

yes, by only setting 'service_http' (eg TCP/80) in the captive portal policy