How to Set Up a Captive Portal on Starlink for Guest WiFi

Welcome to the Purple Technical Briefing. Today we are covering a question that comes up more and more often as Starlink reaches venues that fiber simply cannot. How do you set up a proper captive portal for guest WiFi on a Starlink connection? I am going to walk you through the architecture, the constraints you need to understand before you touch a single config file, and the implementation steps that actually work in production. We will cover two real-world scenarios, the five pitfalls I see most often, and finish with rapid-fire answers to the questions IT teams ask us every week. Let us start with why this is not a trivial problem. Starlink has genuinely changed the connectivity picture for venues that were previously stuck with slow, expensive satellite links or patchy 4G. A remote mountain hotel, a cruise vessel, a festival site in a field, a construction welfare unit - all of these can now get between 100 and 220 megabits per second from a dish the size of a large pizza. That is remarkable. But raw connectivity is only half the job. The moment you put that connection in front of guests, you need authentication, access control, CCPA/CPRA-compliant consent capture, and bandwidth management. Starlink does not give you any of that out of the box. That is where a captive portal comes in. Section one: understanding the Starlink network constraints. Before you touch a router, you need to understand what Starlink actually gives you at the WAN interface. The standard Starlink dish connects to a proprietary router that handles DHCP and NAT. By default, you are behind Carrier Grade NAT - what engineers call CGNAT. Your WAN IP address sits in the 100.64 to 100.127 range. It is not a public IP. You cannot receive inbound connections from the internet. And that matters enormously for captive portal architecture. Starlink's residential and Roam plans cap concurrent sessions at 1,200. For a busy hotel or event venue with hundreds of devices, that limit becomes a real constraint. The fix is bypass mode. You enable this in the Starlink app under Settings, then toggle Bypass Starlink WiFi router. Once enabled, the Starlink dish passes the CGNAT address directly to your enterprise router's WAN port. The Starlink router stops doing DHCP and NAT. Your router takes over. You are still behind CGNAT, but now you have full control of the routing layer. One critical point: if the Starlink dish is factory reset for any reason, bypass mode is disabled. You will need to re-enable it. Build that into your site runbook. Now, Starlink offers three plan tiers relevant to venue operators. Residential and Roam give you up to 100 megabits down, best-effort priority, and no static IP option. Starlink for Business gives you up to 220 megabits, priority data allocation, and a static IP add-on. Starlink Maritime gives you the same speeds with global portability - essential if the vessel moves between ocean regions. For any multi-user venue, I would recommend Business or Maritime as a minimum. Best-effort data on the residential plan means your guests get deprioritized whenever the satellite cell is congested. Section two: the architecture stack. Here is the four-layer stack you are building. Layer one is the Starlink uplink in bypass mode. Layer two is your enterprise router or firewall. Layer three is VLAN segmentation at the switch or access point level. Layer four is the cloud captive portal, which handles authentication, consent, and analytics. Let me spend a moment on VLAN segmentation because it is non-negotiable. You need at minimum three VLANs. VLAN 10 for staff - this carries your point-of-sale systems, back-office applications, and management traffic. VLAN 20 for guests - this is the internet-only segment that hits the captive portal. VLAN 30 for IoT - cameras, smart thermostats, building management systems. These three networks must not be able to talk to each other. Inter-VLAN routing should be blocked at the firewall. A guest on VLAN 20 must never be able to reach your POS terminal on VLAN 10. That is not just good practice - it is a PCI DSS requirement if you are processing card payments anywhere on the same physical infrastructure. The captive portal itself sits in the cloud. When a guest connects to your guest SSID and opens a browser, the router intercepts the HTTP request and redirects it to the portal login page. The guest authenticates - via email, social login, or a voucher code - accepts your terms of service, and the portal signals the router to grant that MAC address internet access. The whole flow should complete in under 10 seconds on a cell phone. Purple's cloud portal integrates directly with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. You configure the RADIUS or API integration once, and Purple handles the authentication handshake. No on-premises authentication server required. That is critical for remote venues where you cannot run a local RADIUS server. Section three: the CGNAT problem and how to solve it. Here is the challenge that catches most IT teams out. Standard captive portal architectures assume the cloud portal can reach back into your network. With CGNAT, that is impossible. Inbound connections are blocked. The solution is a reverse tunnel. Your router establishes an outbound connection to the cloud portal and keeps it open persistently. All authentication traffic flows through that tunnel. The cloud never needs to initiate an inbound connection. Purple cloud overlay architecture handles this natively. If you do need a static IP, Starlink Business and Maritime offer a static IP as an add-on. Check Starlink current plan pages for your specific territory. Section four: CCPA/CPRA and data compliance. This is where remote venues often get caught out. The fact that your venue is in a remote location does not exempt you from CCPA/CPRA if you are collecting data from California residents. Your captive portal must present a specific, unchecked consent checkbox for marketing communications. It must clearly state what data you are collecting, why, and how long you will retain it. The terms of service must be accessible before the guest authenticates. Purple is ISO 27001 certified, GDPR compliant, CCPA compliant, and Cyber Essentials certified. Every login event is logged with a timestamp, IP address, and consent record. That audit trail is what protects you if a regulator asks questions. Section five: bandwidth management. On Starlink, bandwidth is your most constrained resource. A single guest streaming 4K video can consume 25 megabits per second continuously. On a venue with 50 guests and a 220 megabit connection, that is one person taking 11% of total capacity. You address this at the captive portal and router level. Set per-device bandwidth limits. Implement fair-use policies that throttle after a daily data allowance. Use traffic shaping to prioritize web browsing over video streaming. And consider tiered access: a free tier for basic connectivity, a paid premium tier for streaming. That converts your WiFi from a cost line into a revenue stream. Now let me give you two real-world scenarios. Scenario one: a remote mountain resort with 40 rooms and no fiber. They run Starlink for Business at an average of 150 megabits. HPE Aruba access points cover the main building and three outbuildings. Guests authenticate via email on Purple portal. Guest WiFi complaints dropped by 60% compared to their previous 4G bonding setup. The portal also captures first-party email data, which feeds directly into their post-stay marketing campaigns. Scenario two: a 120-cabin cruise vessel running Starlink Maritime at 220 megabits. The operator deploys Cisco Meraki access points throughout the vessel with three VLANs - crew, passenger, and ship systems. Purple captive portal handles passenger authentication via email or a cabin number lookup integrated with the property management system. WiFi revenue covers the Starlink subscription cost, and the operator has a growing direct marketing list. Implementation pitfalls. Let me run through the five I see most often. One: forgetting to re-enable bypass mode after a dish reset. Document this in your runbook. Two: not blocking inter-VLAN routing. Every deployment I have reviewed that had a security incident had this misconfigured. Check it twice. Three: using HTTP redirect on a network where guests are using HTTPS-first browsers. Modern browsers default to HTTPS. Your router needs to handle the HTTPS intercept correctly, or guests will see certificate errors before they reach the portal. Four: not testing on iOS and Android separately. Apple Captive Network Assistant and Android network probe behave differently. Test both before go-live. Five: ignoring latency. Starlink low-Earth orbit constellation delivers 20 to 40 millisecond latency. But during handoffs between satellites, you can see brief spikes. Set session keepalive intervals to 60 seconds or less. Rapid-fire questions. Do I need a static IP for a captive portal on Starlink? No, if your portal uses a cloud-hosted architecture with reverse tunneling. Yes, if you are running on-premises RADIUS. Can I run multiple SSIDs on Starlink? Yes. Your enterprise access points handle SSID creation. Starlink in bypass mode just provides the uplink. Does Purple work with Starlink out of the box? Yes. You configure bypass mode on the Starlink dish, connect your supported access points, and point the RADIUS or API integration at Purple cloud. The portal is live within the hour. What happens if the Starlink connection drops? Purple portal caches active sessions locally on the router for a configurable period - typically 24 hours. Guests who are already authenticated stay online. To summarize. Starlink gives you the pipe. Your enterprise router in bypass mode gives you control of the routing layer. VLAN segmentation isolates your guest, staff, and IoT traffic. A cloud captive portal handles authentication, CCPA/CPRA consent, bandwidth policy, and first-party data collection. The CGNAT constraint is solved by reverse tunnel architecture, not by static IP. Purple operates across 80,000 live venues in over 90 countries and processed 440 million logins in 2024. The platform is hardware-agnostic, cloud-native, and deploys as a layer on top of your existing infrastructure. No rip and replace required. If you want to see how this works in your specific environment, visit purple.ai and book a technical consultation. The team will map the architecture to your hardware and have a proof of concept running within a day. Thanks for listening. I will see you in the next briefing.