A guest joins the company WiFi and reaches a short list of designated web services, nothing else. The confinement is enforced twice: the network lets the guest VLAN reach only Coelion, and Coelion resolves every request to one designated service and refuses everything else. An allowlist by construction, not a denylist filter.
Layer 1, the network, confines the guest VLAN to Coelion. Standard network engineering on the customer's own gear: an isolated guest VLAN with client isolation, a firewall that denies all egress by default and allows only the Coelion listener on TCP 443, and a guest DNS resolver that answers only the designated hostnames. Layer 2, Coelion, confines every request to one designated web service. Each service is a virtual host fronting one backend, internal or allowlisted-external. Coelion only knows its configured virtual hosts and has no arbitrary-destination behaviour. Every request runs through the per-request access check and produces one access-log line.
The VLAN stays internet-closed by default. One designated service can be a Coelion access portal: sign-in, voucher or terms acceptance. On success Coelion records the decision and signals the network controller, through a RADIUS Change-of-Authorization or a controller API call, to widen the device's egress policy. The internet traffic then flows directly through the firewall, never through Coelion.
Web only: a designated service that is not web-based cannot be fronted. The network layer is the customer's responsibility, not Coelion's. Coelion is not a captive-portal or NAC replacement. The internet-egress hand-off is an integration wired to the specific controller in use, not a built-in capability.