Walled garden and redirect

The allow-list that lets the portal load before the guest is authenticated.

Hosts that must be reachable before login

A "walled garden" is the set of destinations a guest's device can reach before they've logged in — normally, a controller blocks everything until authentication succeeds, but the login page itself (and whatever it needs to render) has to be an exception, or the guest can never reach it to log in at all. This allow-list lives on the controller or router itself (RouterOS calls it exactly that; other vendors call it a pre-auth whitelist or similar), not in Kiwire — there's no Kiwire admin page for it, because the traffic it governs never reaches Kiwire until it's already been let through.

At minimum, the walled garden needs:

• The Kiwire portal domain — the host guests are redirected to, so the login page's HTML, CSS, JS, images and fonts can all load. Blocking any one of these still shows a page, just a broken-looking one.
• Fonts and any third-party assets the portal template actually uses — Kiwire's own onboarding checklist calls out fonts.googleapis.com and fonts.gstatic.com specifically (the default template loads Google Fonts), and notes that a template using other external images or scripts needs those hosts added too. A portal using reCAPTCHA needs www.google.com and recaptcha.google.com.

RADIUS does not belong on this list. The walled garden only governs what the guest's browser can reach before login; RADIUS (UDP 1812/1813) runs between the controller and Kiwire, and disconnects (CoA, port 3799 by default) run from Kiwire to the controller. Those paths need to be open in any firewall between the two, but a controller that can't reach Kiwire's RADIUS shows a login page that always fails, however the walled garden is set.

Social sign-in and the walled garden

If a zone's login methods include social sign-in, the guest's browser needs to reach the identity provider before they're authenticated — that's the entire point of social login. Kiwire routes this through its own social sign-in gateway domains (socialgate.synchroweb.com / socialgate.kiwire.net), which the portal's Content-Security-Policy already allows as a frame source; the walled garden on the controller needs to allow the same domains (and, depending on the provider, the identity provider's own domains directly) for the sign-in popup or redirect to complete. A payment step in the portal (Razorpay, seen in the same CSP allowance) has the same requirement if a guest can pay before or instead of logging in.

HTTPS redirect and captive-portal detection

Kiwire's own URL is always HTTPS in production (the platform address is an https:// host) — there's no HTTP fallback to configure on the Kiwire side. What the controller does with a guest's outgoing HTTP vs HTTPS request before login is entirely the controller's own behavior: most vendors intercept plain HTTP requests and redirect them to the portal, while HTTPS requests to sites the guest already had open generally cannot be intercepted without a certificate warning, so they're normally left alone pre-auth. This is also what makes operating-system captive-portal detection work at all — iOS, Android and Windows each probe a known HTTP URL shortly after joining a network, and if the controller's redirect intercepts that probe, the OS pops up its own captive-portal browser automatically instead of waiting for the guest to open a page themselves. Kiwire doesn't implement or need to know about these probe URLs — that handshake happens entirely between the guest's OS and the controller, before the request ever reaches Kiwire.

Testing it

The most direct check is opening the Kiwire portal URL from a normal, non-guest internet connection: if it loads correctly there but not on the guest network, the problem is the walled garden (or the redirect), not Kiwire itself. On the guest network, opening the browser's developer tools (Network tab) while loading the portal will show any blocked asset requests in red — those exact hosts are what's missing from the walled garden. Portals › Troubleshoot › Controller Test in Kiwire is the other half of this check: it shows exactly what the controller actually sent, which tells you whether the redirect reached Kiwire at all, separately from whether the page then rendered correctly.