What is a Captive Portal?

A captive portal is a webpage to which a user’s web traffic is redirected – to require authentication, display an informational, justification, or PIN-override message – before network or internet access is granted or denied. It is a standard action in URL-filtering policy enforcement.

Key takeaways

• Redirects users to a webpage before granting or denying access.
• Core actions are ask, block, justify, override, and inform pages.
• Enforced as part of a URL-filtering profile on NGFW devices.
• Recommended fallback for non-domain-joined and BYOD devices.
• Pages can use platform defaults or a fully custom upload instead.

On this page: Why it matters · How it works · Types · Captive Portal & Versa · FAQ

Why is a captive portal important?

Not every device on a network can be trusted the same way. A domain-joined laptop can be identified passively through login events, but a contractor’s phone or a fresh BYOD device has no such trail. A captive portal solves this by interrupting the request itself: instead of silently allowing or blocking a page, it hands the user a page that asks first.

That interruption does real policy work. It lets an organization allow a borderline site only after a logged, auditable justification. It lets administrators block a category with a clear explanation instead of a silent failure that generates help-desk tickets. And it gives an override PIN holder a controlled way past a block without loosening policy for everyone else. For BYOD and non-domain-joined devices that cannot run passive identity agents, it is often the only practical enforcement point available.

What is a captive portal?

A captive portal is configured as an action inside a URL-filtering profile: when a session matches a URL category or reputation rule, the device redirects the browser’s request to a portal page instead of the requested site. That page can be a platform default or a fully custom upload – a .zip archive containing an index.htm file with its own HTML, CSS, and images, optionally carrying session variables such as the requested URL.

Redirection over HTTPS depends on SSL decryption, since the device must decrypt the session to substitute the portal response, and can optionally bypass further decryption once the action completes. To avoid re-prompting on every request, the device caches the decision – keyed to the source IP address, MAC address, or both – for a configurable expiration window.

Types of captive portal actions

Captive portal actions differ in what they ask the user to do. Ask presents an information page with Cancel and Continue buttons. Block denies the page outright and logs the attempt, with no way to continue. Justify requires the user to type a reason before continuing, and that text is logged for audit purposes. Override prompts for a 4-to-6-digit PIN; only a valid PIN admits the user, and every attempt is logged. Inform simply displays a message and lets the user continue after acknowledging it. Custom Redirection hands the session off entirely to an external web server, passing along details such as the requested URL for that server to handle.

Captive Portal & Versa

VOS devices enforce captive portal as part of URL filtering and URL filtering on the NGFW: a URL-filtering profile’s category or reputation action map can point at a predefined or custom captive portal action, applied wherever that profile is attached to a security access policy rule. Administrators configure captive portal under Configure > Settings > Captive Portal, choosing a default VOS page per action or uploading a branded custom page, and can attach a CA certificate so the portal serves over SSL.

Deployments needing per-routing-instance enforcement can define service endpoints with dedicated HTTP and HTTPS ports (44990 and 44991 by default). Global settings control how long a redirect decision is cached – 30 minutes by default – and whether the cache key is the source IP address, MAC address, or both.

Frequently asked questions

What actions can a captive portal take?

The core actions are Ask, Block, Justify, Override, and Inform, plus Custom Redirection to an external server. Each maps to a different user experience, from a simple acknowledgment to a PIN-gated override, and each can generate a log entry in Versa Analytics.

Does a captive portal require SSL decryption?

Yes, for HTTPS traffic. Without SSL decryption enabled, an HTTPS session either passes through unmodified (for the Inform action) or is reset (for Block, Ask, Justify, or Override), because the device cannot substitute the portal page inside an encrypted session it cannot read.

Can a captive portal page be customized?

Yes. Administrators can edit the message on a default page, or upload a fully custom page as a .zip archive containing an index.htm file with its own HTML, CSS, images, and logo, replacing the platform’s default look entirely with branded content.

What is the override PIN used for?

The Override action prompts the user for a 4-to-6-digit PIN before granting access to a blocked category. It is intended for supervised exceptions – someone who knows the PIN can grant temporary access without changing the underlying policy for other users.

How long does a captive portal decision stay cached?

By default, 30 minutes. Once a user answers the portal for a URL category, the device caches that decision against the source IP, MAC address, or both, so the same user isn’t re-prompted on every request until the cache entry expires.

More on captive portals

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about captive portals, these are worth looking at next.