Misusing Palo’s Captive Portal as a Guest Wi-Fi Welcome Page

I was faced with an interesting customer requirement: An existing guest Wi-Fi should be prefaced with a welcome page for accepting the terms and conditions. Since there was already a Palo Alto Networks firewall in place, could we perhaps use its captive portal directly for this purpose? It’s not about authenticating the users, but only for a single webpage with a simple check button that should appear once a month per device.

TL;DR: While we were able to redirect every device to a welcome page, we were not able to extend the lifetime of those sessions to longer than 24 hours. This might fit for short-term guest Wi-Fis, but is not appropriate for long-term connections aka BYOD. However, this is how we have done it:

First things first: This concept was not my idea but was listed here. Kudus to the unknown author there! My post is just a complete guide covering all the required steps.

I’m using a PA-440 with PAN-OS 11.2.0. PANW renamed the formerly “Captive Portal” to “Authentication Portal” a while ago. It is found at Device -> User Identification -> Authentication Portal Settings.

The Idea

A Palo Alto Networks Strata firewall is not meant to host guest Wi-Fis with captive portals. Neither for payment/vouchers nor for a simple welcome page. It is meant to authenticate internal users (rather than unknown guests) on a user-to-IP basis. That is: Once a user is authenticated with a certain IP, this mapping should NOT remain untouched, but should be refreshed or purged if not used anymore. This is in contrast to a guest Wi-Fi, where a single device, identified by its MAC rather than IP address, should be stored for a much longer time, though not active in between.

Anyway, here’s the idea:

The Realization

(Please note that I faced several problems with my dual-stack environment within those authentication portal tests. A single device is always active with both Internet Protocols which is unfortunately not merged into a single user. Since my customer is using legacy IP only anyway, I decided to disable IPv6 for this lab as well. Sorry for that. One problem after another. ;))

The configuration steps are as follows:

1. Enabling User Identification on the zone of the guest Wi-Fi
2. Interface Management Profile with “Response Pages” and “User-ID” enabled, added to the interface of the guest Wi-Fi
3. [not a firewall step:] DNS hostname for your interface along with an appropriate A record. In my case, it’s pa-home-gast.weberlab.de with a private RFC 1918 address.
4. [not a firewall step:] Generating and importing an X.509/TLS certificate (incl. private key!) for that just generated FQDN
5. TLS Service Profile (I’m completely ignoring the acronym “SSL” here since it’s obsolete for several decades now!) referencing the certificate
6. Local User “fake-guest” with “fake-guest-password” or the like ;)
7. Authentication Profile of type “Local Database” and one allow list statement listing the fake-guest user account
8. Authentication Portal:
   • Mode: Redirect
   • TLS Service Profile from step 5
   • Authentication Profile from step 7
   • Redirect Host: hostname from step 3
   • Timer: appropriate for your use case; however: the upper limit for this timer is 1440 minutes = 24 hours. :( I preferred to use 18 hours = 1080 minutes to have the timeout of the device during the night, assuming the user walked into the bar guest Wi-Fi during working hours.
9. [not a firewall step:] Download this HTML file and replace the 2x “guestuser” and 1x “guestpass” with your added user credentials. <- This is where this whole trick kicks in. :)
10. Response Page -> Captive Portal Comfort Page, importing the just edited HTML file
11. Authentication Policy, source: guest Wi-Fi (“Webergast” in my case), destination: Internet, http/https, Authentication Enforcement: default-web-form
12. Security Policies with source zone and source user of “fake-guest”

Phew! 😂

Here are my configuration screenshots as reference:

Checking of the hostname:

C:\Users\jweber2>nslookup pa-home-gast.weberlab.de
Server:  pi.hole
Address:  192.168.7.53

Nicht autorisierende Antwort:
Name:    pa-home-gast.weberlab.de
Address:  192.168.22.1

It’s Working!

Connecting to the Wi-Fi forces the user to view and click on this page:

The authentication log section lists these entries:

While on the CLI you can verify the guests as well:

weberjoh@pa-home> show user ip-user-mapping all

IP               Vsys       From    User         IdleTimeout(s) MaxTimeout(s)
---------------- ---------- ------- ------------ -------------- -------------
192.168.22.11    vsys1      CP      fake-guest   35982          64733
192.168.22.13    vsys1      CP      fake-guest   35987          64581
Total: 2 users

The traffic logs show the source user appropriately:

Conclusion

Yeah, well, to be honest, that’s a creative workaround and not a solid solution. 😂 The authentication portal is not meant to host a “click here” welcome page.

Otherwise, only the max value of the timer of one day spoiled our plans. With this current setup, the owner must accept the terms and conditions every single day – for every device! Obviously, this is unhandy for a guest Wi-Fi that is used for the private devices of the staff members.

Do any of you have other ideas or solutions? Keep them coming! After all, that’s what the comment function is for.

Soli Deo Gloria!

Photo by No Revisions on Unsplash.