Set the session too short and guests curse your WiFi every hour. Set it too long and last month's visitor is still silently signed in. The timers are a hospitality decision wearing a technical costume — here is how to make it deliberately.
Every captive portal session is governed by two different clocks, and confusing them causes most timeout complaints. The session timeout is a hard ceiling: however active the guest is, the login dies when it expires. The idle timeout is a silence detector: stop using the network for that long and the session ends early. Untangle's Captive Portal exposes these session controls in the app settings. Bandwidth is a separate story, told honestly in the last section: the portal itself does not shape traffic at all.
Ask how long a guest legitimately stays, then give a little more. A coffee visit is one to two hours; a hotel stay is the length of the booking; a training day is the working day. Sessions that run for days feel generous and quietly destroy the point of the portal: the log can no longer say who was here today, and a device sold or lost keeps its access.
When in doubt, err shorter and say so on the page. A guest who re-accepts terms at lunch is mildly inconvenienced; a stranger riding a forgotten month-long session is a policy failure.
Idle means the device sent nothing — not that the human left. Phones in pockets go quiet; laptops asleep go quiet; a guest reading a long article is quiet. Ten minutes is harsh, a few hours is pointless. Tens of minutes is the working range for most guest networks: long enough to survive a coffee refill, short enough that a departed guest's session closes itself the same visit.
Remember what re-login costs in each mode: one OK press in acknowledgement mode, a password hunt in account mode. The stricter your login, the gentler your idle timeout should be.
Now the honest part. Signing in through Captive Portal gives a guest the same pipe as everyone else; the app has no speed dial. On Untangle, traffic shaping and quotas live in the separate Bandwidth Control app — per-user and per-device quotas, penalty boxes for heavy users, priority for the traffic that matters. It is a different app with its own licensing, and bolting it on is a deliberate purchase, not a portal setting you missed.
Before buying anything, check whether you even have a bandwidth problem: most guest complaints that sound like abuse are one guest on a weak access point. The Reports app will show you who actually eats the pipe, by user, once the portal is naming them.
Sign in, browse, and watch the session in the console — the full video walks the whole lifecycle.
▶️ Watch Full VideoAlmost always the idle timeout meeting a quiet device, or the hard session ceiling arriving mid-visit. Phones that sleep aggressively look idle to the firewall even in a guest's hand. Raise the idle value first, keep the session ceiling where your policy wants it, and print both numbers on the portal page so the behaviour is expected, not mysterious.
The clean way is an account with its own expectations managed by staff, or — for a fixed device that truly never logs in — the client pass list, accepting that the exemption is permanent and must be audited. Bending global timers for one person punishes every other guest for one exception.
Yes. Captive Portal authenticates; it does not shape. Per-user quotas and penalties are the Bandwidth Control app's job, a separate app on the same firewall. Decide from Reports data whether you need it — many small networks discover their problem was coverage, not greed.