Captive Portal Setup in Minutes

Plan the Guest Network First

A captive portal runs on your own network, for your own guests and users — it is not something you put on anyone else's connection. Before touching the firewall, decide which network the portal applies to: normally one dedicated guest network (its own interface or VLAN and its own SSID on your access points), kept separate from the staff and office LAN. The portal should capture guest devices only. Your office PCs, servers and printers must never end up behind a guest login page.

Install the Captive Portal App

Sign in to the Untangle firewall's admin interface and open the Apps view. Find the Captive Portal app, install it into the rack if it is not already there, and turn it on. Until capture rules exist, an installed portal captures nothing — the app by itself does not change anyone's browsing. Everything that decides behaviour comes in the next steps, and that order matters: app first, rules second, guests last.

Write the Capture Rules

Capture rules are the heart of the setup: they tell the firewall which traffic gets stopped and sent to the portal page. Write the rules so they match the guest network only — the guest interface or the guest address range your plan from Step 1 set aside. A client that matches a capture rule sees the login page before any internet access; a client that does not match browses normally. Start with the narrowest rule that covers your guests, then check the rule from a test device before widening anything.

Choose the Login Type

Next, decide what a guest has to do on the portal page. The Captive Portal app offers several authentication styles, from the lightest to the strictest: a simple capture page where the guest just accepts the terms of use, accounts from the firewall's own local directory, or sign-in backed by an external directory service such as RADIUS or Active Directory through the firewall's directory integration, with social sign-in options also available. Pick the lightest type that fits your place: a small cafe usually wants the terms page or a shared guest account, while an office guest network usually wants named accounts so access can be traced and withdrawn.

Whichever type you choose, guest credentials are issued by you or your staff and handed to guests directly. They are never published on a public web page or notice that anyone on the internet can read, and accounts for people who have left should be removed, not left active forever.

Add Passed Hosts

Passed hosts are the exceptions: addresses that clients are allowed to reach without logging in. Typical uses are the pages a guest genuinely needs before signing in — for example a payment or registration page your login flow depends on, or a specific service you deliberately keep open. Add only the hosts your setup actually needs, one at a time, and note why each one is there.

Test Like a Real Guest

Now test the way the video shows it — as a guest, not as the admin. Take a phone or laptop that has never signed in, join the guest network, and open a browser: the portal page should appear before any site loads. Complete the login exactly as a guest would, confirm normal browsing starts, and check that a passed host from Step 5 also opens without a login. Then reconnect and confirm the behaviour is the one you intended — some setups ask for a login every time, others remember a device for a set period; either is fine as long as it is the behaviour you chose, not an accident.

What "In Minutes" Really Means

The title's promise is honest for the setup shown: on a firewall that is already installed, one guest network, one login type and a short passed list genuinely is a few minutes of console work. It is not a guarantee for every network. Multiple guest networks or SSIDs, directory-backed sign-in that first needs the directory itself configured, a custom-branded portal page, and sites linked through VPNs all add real time. Plan the simple version first, prove it with the guest test in Step 6, and only then grow it.