Sign In: branded captive portal and guest Wi-Fi

Captive portal examples

One engine. Every brand on top.

Same engine, infinite looks. Logos, colors, fonts, redirects, and per-language strings, configured by the customer and deployed live in seconds.

SkiStar

Resort Wi-Fi on every device: branded sign-in, language picker, and terms.

Peab

Site Wi-Fi for construction crews, brand identity intact, deployed across projects.

Formula E

Race-weekend Wi-Fi across the global tour, branded once, deployed in every city.

Holiday Club Åre

Resort Wi-Fi with destination photography, branded once, deployed every season.

OKQ8 / Q8

Retail captive portal across hundreds of fuel stations. Same brand, every site.

Lantmännen

Visitor Wi-Fi across sites and silos, branded once, deployed at every location.

Svensk Elitfotboll

Matchday Wi-Fi for the league and its clubs, branded once, deployed across every arena.

Bilia

Showroom and workshop Wi-Fi: dark theme, light footprint, one brand across the chain.

Stockholms Stad

Responsive captive portal across phone, laptop, and tablet. One brand, every screen.

STIM

Office and event visitor Wi-Fi, branded around the organisation, not the network.

SkiStar

Resort Wi-Fi on every device: branded sign-in, language picker, and terms.

Peab

Site Wi-Fi for construction crews, brand identity intact, deployed across projects.

Formula E

Race-weekend Wi-Fi across the global tour, branded once, deployed in every city.

Holiday Club Åre

Resort Wi-Fi with destination photography, branded once, deployed every season.

OKQ8 / Q8

Retail captive portal across hundreds of fuel stations. Same brand, every site.

Lantmännen

Visitor Wi-Fi across sites and silos, branded once, deployed at every location.

Svensk Elitfotboll

Matchday Wi-Fi for the league and its clubs, branded once, deployed across every arena.

Bilia

Showroom and workshop Wi-Fi: dark theme, light footprint, one brand across the chain.

Stockholms Stad

Responsive captive portal across phone, laptop, and tablet. One brand, every screen.

STIM

Office and event visitor Wi-Fi, branded around the organisation, not the network.

Plug & play integration

Three ways to deploy. Zero new infrastructure.

Sign In drops onto the network you already have: Cisco Meraki cloud, Cisco routers as Service Gateway, or Cisco SD-WAN with local internet breakout. Same captive portal, same admin, same self-service.

Cloud-to-cloud

Cisco Meraki Networks

Plug & play integration with your Meraki network. No appliances, no RADIUS server to run, nothing installed at the site. Point the guest SSID at Sign In in the Meraki Dashboard and the captive portal is live.

Truly cloud-to-cloud, no extra hardware required
Works with every Meraki MR access point
Branded captive portal on the existing SSID
Per-network policy delegated through Sign In

See how it connects

Cisco Catalyst routers, the Service Gateway lineup

Routed integration

Cisco Service Gateway

Deploy Sign In on any Cisco router acting as a Service Gateway. Built-in DHCP and DNS make it fully self-sufficient: smooth, reliable, and hassle-free deployment from day one.

Runs on Cisco ISR and Catalyst 8000 routers (IOS-XE)
Built-in DHCP and DNS, no separate services to wire up
Encrypted FlexVPN tunnel back to the cloud service
Hot-standby and load-balanced redundancy options

See how it connects

Local breakout

Cisco SD-WAN (Viptela)

For multi-site estates that need local internet breakout. Provision Sign In through vManage templates and let each site go straight to the internet: secure, scalable, and centrally managed.

vManage templates for repeatable deployments
Local internet breakout per site for low-latency guest traffic
Centralized telemetry across every Service Gateway
Same Sign In experience, distributed by design

See the Service Gateway sketch

How it connects

Two paths into your network. Watch how each one connects.

Choose Service Gateway or Meraki, then the angle: how the integration is built, how one guest gets from the SSID to the internet, and how it grows from one site to many. Cisco SD-WAN sites run the Service Gateway integration, provisioned through vManage, so that tab covers them too.

Service Gateway Integration step by step

Service Gateway is a Cisco router that routes your network to the cloud. Its configuration is generated from a framework in Administration Portal. Portal, DHCP and DNS come from the cloud, while internet traffic breaks out locally.

Step 1 of 8 Starting point A guest network on any WLAN vendor, guests with their own devices, and an internet connection. None of it is replaced.
Step 2 of 8 Create the Sign-In Context In Administration Portal, the Sign-In Context is the instance of Sign In for this network. The wizard asks for a name, the SSID name, a default redirect, Production or Demo, and the network integration: Service Gateway (Routed Integration). The context gets its own captive portal URL.
Step 3 of 8 Register the Service Gateway A Cisco IOS-XE router (ISR 1100 or 4400 with the Security and AppX licenses, or Catalyst 8100 to 8500 with DNA Essentials or Routing Advantage, on a supported IOS-XE release) is placed between the guest network and the internet. It can sit behind your firewall. With NAT in the path, NAT-T goes on at both ends. Under Service Integration you add it with its Router ID and public IP, and pick the IPsec remote peer it will connect to.
Step 4 of 8 Generate the configuration from a framework A Service Gateway Framework is a router-configuration template your partner maintains in the MSP Portal. Select it in the gateway detail view: the platform fills in the reserved variables (platform address, IKEv2 pre-shared key, tunnel interface IP, BGP AS numbers, context and router ID) and you set the custom ones (WAN and LAN interfaces, DNS). The result is a complete IOS-XE configuration for this router, ready to load onto it.
Step 5 of 8 FlexVPN tunnel to the cloud With the configuration loaded, the router brings up a FlexVPN tunnel (IKEv2/IPSec) to the Netgraph platform. The tunnel carries the control plane: session state, events, policy updates and telemetry. Guest traffic never enters it. BGP is optional, runs inside the tunnel, and advertises the guest subnets automatically. Each context is isolated in its own VRF.
Step 6 of 8 DHCP scopes, DNS and Option 114 DHCP runs in the Netgraph cloud. The gateway relays guest requests to the platform, so no on-site DHCP server is needed. You add one scope per VLAN, subnet or site: address range, default gateway, DNS servers, lease time, and Option 114 with the portal URL (RFC 8910), on by default and overridable per scope. DNS forwards to your resolvers in Plain mode, or filters as Cloud DNS.
Step 7 of 8 Sites, walled garden, modules and branding Sites Configuration ties scopes to sites, the walled garden lists what guests may reach before sign-in, Sign In Modules and Access Policies decide who signs in and how, and Look & Feel brands the portal. The Service Status cards on the Service Gateway page show DHCP, DNS, IPsec and BGP green when everything is up.
Step 8 of 8 Redundancy and local breakout One context can run several gateways, up to 10 on Enterprise: an active/standby or active/active pair at one venue, one per site, or geo-distributed. They share the context modules and policies. Only DHCP scopes, IPsec peers, BGP peers and DNS entries differ per gateway. Guest internet traffic breaks out locally at the gateway and never passes through the cloud.

From SSID to the internet

The same network as above, now with a guest connecting. Follow the packets: before sign-in they go up to the cloud, after sign-in they break out locally.

Step 1 of 6 The guest joins the SSID The device associates with the guest SSID like any other network, whatever the WLAN vendor. On a Cisco WLC, enable DHCP Addr. Required and keep 802.11r off on guest SSIDs so portal detection fires reliably.
Step 2 of 6 DHCP lease and portal detection The gateway relays the DHCP request to the cloud, which allocates an address from the scope. The lease carries Option 114 with the portal URL, so recent iOS, iPadOS, Android and macOS open the portal directly. Windows and older clients find it through classic detection: Apple CNA, Android generate_204, Windows NCSI or a plain HTTP redirect. Devices with rotating private MAC addresses simply get a fresh lease.
Step 3 of 6 Unauthenticated: only the walled garden Until the device has signed in, policy-based routing on the gateway steers its traffic up to the cloud and the captive portal appears. Only the walled garden is reachable: identity providers, CDNs and, if you add them, the OS probe endpoints. Everything else waits.
Step 4 of 6 Sign-in and policy The guest signs in with one of the enabled modules. An Access Policy decides who may use Meeting Host, Email Self-Provisioning and SAML Login, and on what terms: session length, device quota and redirect. The other modules are open to anyone who reaches the portal. The redirect follows a precedence: Access Policy, then site redirect, then the context default.
Step 5 of 6 Local internet breakout Once signed in, the device traffic goes out to the internet directly at the gateway via NAT, never back through the cloud. TrustSec with SGT and SXP can segment it, and NBAR on the router feeds Application Visibility.
Step 6 of 6 The session in Administration Portal The Dashboard shows online devices and logins. Network Services, Sites shows the lease, matched to its site by DHCP scope. The session ends when the policy says so, or earlier if the device is blacklisted or Opening Hours close the portal.

Meraki Integration step by step

Meraki is the one path without a gateway. Netgraph is the RADIUS server, Meraki is the client, and the captive portal comes from the cloud. IPs, DNS and routing stay with Meraki.

Step 1 of 7 Starting point A Meraki wireless network: MR access points managed from the Meraki Dashboard, guests with their own devices, and an internet connection. Nothing is installed at the site.
Step 2 of 7 Create the Sign-In Context In Administration Portal, the wizard asks for a name, the SSID name, a default redirect, Production or Demo, and the network integration: Cisco Meraki. The context gets its own captive portal URL. Under Service Integration, Enabled integrations, you turn on Meraki Integration Enabled.
Step 3 of 7 Pick the deployment type Under Service Integration, Meraki, Settings you choose MAC-based Access Control (Meraki authenticates each device by MAC and the guest lands on an ISE-style splash page, optionally with a Managed Pre-Shared Key so the SSID is encrypted) or Splash Page via RADIUS Server (Meraki redirects to a Custom Splash URL at the platform and uses Change of Authorization). For Splash Page you also state whether the venue has only APs, only MX, or both.
Step 4 of 7 Set the RADIUS secret, read the generated values Enter a strong RADIUS client secret. The card then shows the RADIUS servers and accounting servers (host, port, secret), the walled-garden entry and, for Splash Page, the Custom Splash URL. Netgraph is the RADIUS server and Meraki the client: plain RADIUS, no RadSec, no Dashboard API.
Step 5 of 7 Mirror it in the Meraki Dashboard On the guest SSID under Wireless, Access control: the security mode (MAC-based access control, Identity PSK with RADIUS, or Sign-on with my RADIUS server), Mandatory DHCP enabled, the splash page (ISE Authentication or the Custom Splash URL), the walled garden with Block all access until sign-on is complete, and the RADIUS and accounting servers with an interim interval of about 10 minutes.
Step 6 of 7 Device profiling and AP identity Enable RADIUS Accounting Device Profiling support so Sign In can recognise devices, and add AP Name to the Called-station-ID list so Sign In knows which access point a guest is on. Access points register automatically as they appear, identified by MAC. Assign them to sites for site-based redirects.
Step 7 of 7 Test and go live Connect a test device to the SSID: the captive portal renders and the login shows on the Dashboard. Meraki keeps handing out IPs, and DHCP, DNS and routing stay as they are. Application Visibility is not available on this path. Optionally, Location and Scanning gives Sign In live presence per SSID.

From SSID to the internet, over RADIUS

The same Meraki network, now with a guest connecting. Meraki asks Sign In over RADIUS, the guest signs in on the portal, and the session opens on the access point.

Step 1 of 6 The guest joins the SSID The device associates with the guest SSID on a Meraki MR access point. With MAC-based Access Control the SSID is open or protected by the venue-wide Managed PSK. With Splash Page it is open. Mandatory DHCP makes sure the device gets its lease from Meraki before anything else.
Step 2 of 6 Meraki asks Sign In over RADIUS The access point sends a RADIUS Access-Request with the device MAC and, as Called-station-ID, the AP Name. An unknown device gets no access yet: with MAC-based Access Control the guest is sent to the ISE-style splash page, with Splash Page via RADIUS Server to the Custom Splash URL at the platform.
Step 3 of 6 Unauthenticated: only the walled garden Before sign-in the device reaches only the walled garden configured in the Meraki Dashboard: the captive portal addresses shown in the Netgraph admin, with Block all access until sign-on is complete. Option 114 applies only if your own DHCP server advertises it. Otherwise detection works through the splash redirect.
Step 4 of 6 Sign-in on the captive portal The guest signs in with one of the enabled modules, and Access Policy terms apply as on any integration. A device whose MAC is tied to a policy signs in with no user at all, which is how printers and IoT equipment get on the same SSID.
Step 5 of 6 Access granted Sign In answers Meraki over RADIUS. In the Splash Page type, a Change of Authorization moves the session to its granted access. In MAC-based Access Control the splash page completes and Meraki opens the session. Guest traffic then leaves through the site uplink, and nothing passes through Netgraph. RADIUS accounting, with device profiling and interim updates, keeps the session view current.
Step 6 of 6 The session in Administration Portal The Dashboard shows the login and the device. Access Points lists the APs registered by MAC, and site-based redirects match on that MAC. Meraki hands out the IPs, so there are no leases here, and Application Visibility is not available. With Location and Scanning on, Sign In also sees which clients are active on the SSID.

Service Gateway at scale

Every customer is an isolated tenant in the same multi-tenant cloud. Inside a tenant, one context grows from one gateway to many sites and regions.

Step 1 of 6 One customer, one site Customer 1 has one site with one Service Gateway. In Netgraph Cloud the customer is a tenant of its own: an isolated organization with its own administrators, Sign-In Context, portal and data. The base license is throughput: 50, 200 or 500 Mbps.
Step 2 of 6 High availability at the site A second gateway in the same context, active/standby or active/active. Each router has its own IPsec peer on the Netgraph side and its own tunnel. Modules, policies and the portal stay shared.
Step 3 of 6 More sites, same tenant One gateway per site, all in the same context. Only the network layer differs per gateway: DHCP scopes, IPsec peers, BGP peers and DNS entries. The scope a guest gets an address from tells Sign In which site they are at, so each site can have its own redirect. Enterprise supports up to 10 gateways per context.
Step 4 of 6 Regions and residency Gateways in different regions serve different guest populations from the same context. The organization chooses where the cloud side lives: Global Cloud in EU data centers, or Nordic Sovereign Cloud hosted in Sweden. The platform runs across three availability zones, with no inherent limit on geographic expansion.
Step 5 of 6 A second customer, its own tenant Customer 2 arrives with two sites and gets its own tenant in the same cloud. Nothing is shared with Customer 1: not administrators, not policies, not guest data, not the portal. The platform is multi-tenant SaaS, so a tenant is created from three fields in the MSP Portal, and the quickstart takes about fifteen minutes from a new context to a first guest login.
Step 6 of 6 Partner scale A partner runs both customers, and many more, as tenants from the MSP Portal. One Service Gateway Framework seeds every new gateway, Alerts show gateway health across all tenants, and each customer administers its own tenant in its own Administration Portal. A service provider can also serve many customers from one shared gateway, one VRF per customer.

Meraki at scale

Every customer is an isolated tenant in the same multi-tenant cloud. Inside a tenant, access points register as they appear, sites group them, and new regions need nothing shipped.

Step 1 of 6 One customer, one network Customer 1 has one Meraki network: MR access points on the guest SSID and nothing installed at the site. In Netgraph Cloud the customer is a tenant of its own: an isolated organization with its own administrators, Sign-In Context, portal and data. The base license is per activated access point.
Step 2 of 6 More access points New access points register automatically as they appear and claim a license, or you Batch Upload many at once. Each is identified by its MAC address and listed under Access Points.
Step 3 of 6 More sites, same tenant Assign access points to sites. Site-based redirects match on the AP MAC, so a guest at each venue lands on that venue page. Everything else stays shared within the context: modules, policies and branding.
Step 4 of 6 Regions and residency Meraki is cloud-managed, so a new region is access points plus configuration, nothing to ship. The organization chooses where the cloud side lives: Global Cloud in EU data centers, or Nordic Sovereign Cloud hosted in Sweden. The platform runs across three availability zones, with no inherent limit on geographic expansion.
Step 5 of 6 A second customer, its own tenant Customer 2 arrives with two sites and gets its own tenant in the same cloud, with its own Meraki integration and RADIUS secret. Nothing is shared with Customer 1: not administrators, not policies, not guest data, not the portal. A tenant is created from three fields in the MSP Portal.
Step 6 of 6 Partner scale A partner runs both customers, and many more, as tenants from the MSP Portal, provisions each Sign-In Context, and hands day-to-day administration to the customer while keeping a portfolio-wide view. Each customer administers its own tenant in its own Administration Portal.

Admin & reporting

Cloud admin. Delegated work.

One cloud Administration Portal manages every site, brand, and login method. Designed so the people closest to the work (IT, marketing, reception) can run things themselves without filing tickets at HQ.

Personalize the Captive Portal

Brand colors, logos, messaging. Every Sign-In Context can have its own look and feel, edited inline and live in seconds.

Pick from 10+ sign-in methods

Activate the methods that fit each network. Run multiple methods in parallel with their own redirects, durations, and policies.

Real-time usage & analytics

See who's online, where they are, and what they're using. Traffic graphs, per-method counts, exportable session data.

Manage DHCP & DNS services

Built-in DHCP and DNS controls keep IP addressing and domain resolution under your management, with no extra tooling needed.

Delegated administration

Role-based access: site admins manage one venue, group admins manage many. Reception staff get exactly the rights they need.

Audit & compliance built in

Every change tracked. Export user activity for compliance audits. Retention policies configured per Sign-In Context.

Netgraph Sign In administration portal, dashboard view

Self-Service Portal

Connect. Manage. Smile. Without a help-desk ticket.

The Self-Service Portal puts day-to-day access management in the hands of the people who actually need it. Employees approve guests, residents add devices, consultants onboard themselves. IT gets out of the bottleneck.

Smooth visitor access

Visitors land on the Wi-Fi, request access, and an employee approves with one click in their inbox.

HOT

Connect smart devices

Whitelisting for smart TVs, coffee machines, IoT. Distributed admin without IT in the loop.

Create Conference IDs

Generate unique IDs so larger groups onboard themselves seamlessly at events and classes.

Secure personal devices

Employees and consultants connect their own devices safely, on policy, in a few clicks.

Track visitors and devices

Clear summary of who's approved, what's online, and when access expires.

Choose your login method

Secure portal access via SAML SSO or email verification. Same identity wherever you work.

Compliance & data privacy

Compliant by design, controllable in detail

Netgraph Sign In is built so the right things are easy and the wrong things are hard. Personal data has a lifecycle. Audit trails are exportable. Every visitor sees exactly the terms you choose to show them.

Configurable retention

Set retention in days, months or years per Sign-In Context. Personal data is automatically deleted when the window closes, in full GDPR alignment.

Search & report on demand

Look up any user by MAC, email, or phone. Detailed engagement reports. Honour opt-out, removal, and anonymization requests with a few clicks.

Terms & privacy acknowledgement

Visitors accept your terms and acknowledge your privacy policy before access is granted. Auditable, traceable, and per-context configurable.

Audit trails for everything

Every admin action, every login, every policy change, logged and exportable. Make audits a copy-and-paste exercise instead of a project.

Retention policy configuration in the Netgraph admin portal

Guest Wi-Fi that
just works. For everyone.

Welcome to AcmeCo HQ

One engine. Every brand on top.