Service Gateway overview
Router-based deployment of Sign In on Cisco Catalyst, IOS-XE, or SD-WAN. The Service Gateway routes guest traffic, terminates an IPsec tunnel to Netgraph, and configures the cloud-served DHCP, DNS, and BGP for the context.
The Cisco Service Gateway integration — often abbreviated SG or SG-SP — runs Sign In on a Cisco router using standard routing. The router routes guest traffic, terminates an IPsec tunnel to Netgraph, and optionally peers with the venue’s network through BGP. DHCP and DNS for guests are served from the Netgraph cloud and configured under this integration, with the router relaying guest DHCP toward the platform. Application traffic flowing through the router feeds Application Visibility.
The Service Gateway is a Cisco router (for example ISR 1100/4400 or Catalyst 8000) that connects to the platform over a FlexVPN (IKEv2/IPSec) tunnel. The Captive Portal, DHCP, and DNS are served from the Netgraph cloud, with the router relaying guest DHCP. An unauthenticated guest is steered up to the cloud to sign in; once signed in, the guest's internet traffic breaks out locally at the Service Gateway and does not pass back through the Netgraph cloud.
Open Service Integration → Service Gateway in the Context admin to configure everything under this integration. The page has five tabs:
- Service Gateway — list of registered routers, plus common settings.
- DHCP — scopes served to guests.
- IPsec — tunnels between the routers and Netgraph.
- BGP — dynamic routing peers.
- DNS — custom DNS entries the Service Gateway serves.
What the integration provides
Section titled “What the integration provides”- Cloud-served DHCP — assign IPs to guests without a separate DHCP server of your own. Scopes are configured under this integration and served from the Netgraph cloud, with the router relaying guest DHCP. Supports multiple scopes for multi-VLAN deployments.
- Cloud-served DNS — resolve names for guests, with optional custom entries configured under this integration.
- IPsec tunnel to Netgraph — for control-plane traffic between the router and the platform.
- Optional BGP peering — for venues with dynamic routing.
- Deep-packet-inspection data — the source of Application Visibility.
When to choose Service Gateway
Section titled “When to choose Service Gateway”- The venue runs Cisco routing (Catalyst, IOS-XE, SD-WAN / Viptela).
- You want Application Visibility.
- You want platform-managed DHCP/DNS for guests instead of depending on the wider network.
- You need multiple Service Gateways per Context.
For pure Meraki deployments, Cisco Meraki is usually simpler.
Status card
Section titled “Status card”The Service Gateway page shows a Service Status card for each of DHCP, DNS, BGP, and IPsec, indicating whether the service is currently enabled for the context. A green check means the service is configured and active for the context; a greyed “Service is not enabled” means the corresponding tab has no configuration.
Site matching
Section titled “Site matching”Sign In identifies a guest’s site by the DHCP scope that allocated their address on Service Gateway deployments. Each DHCP scope carries a Connected to Site link, and the set of scopes bound to a Site defines which leases belong to that Site. Configure sites and their member scopes under Site-based redirects.
Multiple Service Gateways
Section titled “Multiple Service Gateways”A single Sign-In Context can have multiple Service Gateways — useful for high-availability pairs, multi-site deployments, or geo-distributed venues that share one Context. See Gateways for how to register additional routers.