How to Set Up a Captive Portal on Starlink: A Guide for Maritime, Transport, and Remote Sites

How to Set Up a Captive Portal on Starlink: A Guide for Maritime, Transport, and Remote Sites [INTRODUCTION - approx 1 minute] Right. So you've got Starlink. You've got the dish on the roof of your ferry terminal, or bolted to the mast of a vessel, or pointed skyward from a remote construction camp. The internet is working. Brilliant. But here's the problem nobody warned you about: Starlink, out of the box, gives you a pipe. Just a pipe. No authentication. No branding. No GDPR-compliant consent capture. No way to know who's on your network, how much bandwidth they're burning, or whether you're even legally covered under data protection law. That's the gap this episode fills. I'm going to walk you through exactly how to layer a proper enterprise captive portal on top of Starlink - covering the architecture, the CGNAT problem you'll hit immediately, VLAN segmentation for maritime and remote sites, and how platforms like Purple integrate into this stack. Whether you're running a ferry route, a remote hotel, a motorway services site, or a construction camp, this is the same fundamental problem, and the solution is the same. Let's get into it. [TECHNICAL DEEP-DIVE - approx 5 minutes] First, let's understand what Starlink actually gives you at the network layer. Starlink delivers connectivity via low-Earth orbit satellites. The dish connects to a router - either the native Starlink router or, in the Business and Maritime tiers, an ethernet adapter that lets you plug in your own hardware. The key technical constraint you need to understand immediately is CGNAT - Carrier-Grade Network Address Translation. On standard Starlink plans, you're behind a shared public IP. You don't get a dedicated public IP address, and you cannot accept inbound connections. That's not a bug - it's how Starlink manages IP address space across millions of subscribers. Why does CGNAT matter for captive portals? Because traditional captive portal architectures often rely on inbound connections - for RADIUS authentication callbacks, for management access, for portal redirect logic. If your captive portal system requires a static public IP or inbound port forwarding, it will not work reliably behind Starlink's CGNAT. Full stop. The solution is a cloud-native RADIUS architecture. Instead of your on-site controller trying to receive inbound authentication requests, the authentication flow goes outbound - from your on-site hardware to a cloud RADIUS server. Purple's platform does exactly this. The controller on site initiates an outbound connection to Purple's cloud RADIUS infrastructure. The splash page is hosted in the cloud. The authentication exchange completes via that outbound tunnel. CGNAT is irrelevant because you never need an inbound connection. Now, the second thing you need to do is bypass the native Starlink router. The Starlink router is a consumer-grade device. It has no VLAN support, no captive portal functionality, no per-user bandwidth controls, and no integration points for enterprise authentication systems. You need to put it into bypass mode - or use the ethernet adapter on Business and Performance hardware - and replace it with a managed enterprise router. The platforms we work with most commonly in this context are Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, and Ubiquiti UniFi. All of them support VLAN tagging, RADIUS integration, and the walled garden configuration that captive portals require. Let me walk through the VLAN architecture you should implement. On a maritime vessel, you typically need at minimum three VLANs. VLAN 10 for guest or passenger WiFi - this is where the captive portal sits. VLAN 20 for crew or staff - typically on a separate SSID with different authentication. VLAN 30 for operations, navigation systems, or IoT devices - completely isolated from the other two, with strict firewall rules preventing any lateral movement. On a remote construction camp or transport hub, the same logic applies: guest access, staff access, and operational systems should never share a broadcast domain. The captive portal flow itself works like this. A passenger or guest connects to the open SSID on VLAN 10. Their device's Captive Network Assistant - the CNA - detects that internet access is blocked. On iOS, a pop-up appears. On Android, a notification fires. On Windows, a browser window opens. All of these redirect to Purple's splash page, hosted in the cloud. The visitor completes the login journey - email registration, social login, or a voucher code - and consents to your terms. Purple's splash page server sends a one-time authentication token back to the on-site controller. The controller forwards this to Purple's cloud RADIUS server. RADIUS returns an Access Accept. The controller removes the captive portal restriction for that device's MAC address. The visitor is online. The walled garden is a critical configuration step. Before authentication completes, the only domains the device can reach are those required for the portal to load - Purple's splash page infrastructure, any social login endpoints, and the CNA detection URLs that operating systems use. Everything else is blocked. You configure this walled garden in your enterprise router or wireless controller. Purple provides the specific domain list you need to whitelist - refer to the support documentation at support.purple.ai for the current list. One more thing on the technical side: SSL certificates. If you're using a Cisco WLC, there's a known issue where the web authentication redirect lands on an HTTP URL, not HTTPS. Modern browsers throw a security warning. The fix is to install a publicly trusted SSL certificate on the WLC and configure the virtual hostname to match the certificate's Common Name. Purple has a dedicated support article on this for Cisco Catalyst 9800 series controllers - I'll link it in the show notes. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - approx 2 minutes] Let me give you the three things that most commonly go wrong in Starlink captive portal deployments. Number one: not accounting for CGNAT on day one. Teams order the hardware, configure everything on the bench, test it on a standard broadband connection, and it works perfectly. Then they deploy it behind Starlink and authentication breaks. The fix is to choose a cloud RADIUS provider - like Purple - before you start, and confirm that your chosen platform uses outbound-only authentication flows. Do not assume any captive portal platform handles CGNAT gracefully. Ask the question explicitly. Number two: flat network design. I see this constantly on vessels and remote sites. The Starlink goes in, someone plugs a consumer WiFi router into it, and suddenly crew, guests, navigation systems, and CCTV cameras are all on the same subnet. One compromised crew device can reach operational systems. One guest streaming 4K video saturates the link for everyone. VLAN segmentation is not optional on a shared satellite connection. It is the difference between a managed network and a liability. Number three: forgetting about the CNA on macOS. Apple's macOS does not allow cookies in the CNA browser session. Purple's captive portal requires a session cookie to maintain the login journey. On macOS laptops, the CNA pop-up will redirect visitors to neverssl.com - a plain HTTP site that triggers the redirect correctly without SSL interference. Make sure your support staff know this, and consider adding a note to your splash page for laptop users. On the hardware side: for maritime deployments, use the Starlink Performance kit - the aluminium-encased unit designed for harsh environments. It's rated for 10-year survivability and operates on both AC and DC power. For remote land sites, the standard Business kit is usually sufficient, but plan for a UPS if power stability is a concern. [RAPID-FIRE Q AND A - approx 1 minute] Quick questions I get asked all the time. Can I use the native Starlink router for a captive portal? No. It has no VLAN support and no RADIUS integration. Bypass it. Do I need a static IP for Purple's captive portal to work? No. Purple's cloud RADIUS architecture works behind CGNAT. No static IP required. What happens when Starlink goes offline mid-session? Authenticated sessions typically persist until the session timeout expires. New authentications will queue until connectivity restores. Configure your session timeout to match your expected outage window. Is this GDPR compliant? Yes, when configured correctly. Purple captures conscious-choice opt-ins with explicit consent at the splash page. Data is processed in line with GDPR and Purple holds ISO 27001 certification. Can I run multiple sites from one dashboard? Yes. Purple's platform manages 80,000 plus live venues from a single pane of glass. Remote sites, vessels, and transport hubs all appear in the same management interface. [SUMMARY AND NEXT STEPS - approx 1 minute] Right, let's wrap up. The core message is this: Starlink solves the connectivity problem at remote and maritime sites. It does not solve the access control, compliance, or analytics problem. You need an enterprise layer on top. The three things to do this week: first, confirm your Starlink hardware tier and whether you have ethernet adapter access for bypass mode. Second, select an enterprise WiFi controller from the supported hardware list - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi are all solid choices. Third, talk to Purple about the Connect plan - it's the starting point for captive portal deployment and includes cloud RADIUS, the splash page editor, and GDPR-compliant consent capture. The full written guide with architecture diagrams, worked examples, and configuration references is at purple.ai. If you're deploying in a maritime or transport context specifically, the guides section has a dedicated article on this exact setup. Thanks for listening. Next episode, we're covering RADIUS authentication configuration for multi-site enterprise networks - same audience, same depth. See you there.