Cómo configurar un Captive Portal en Starlink: Una guía para establecimientos remotos y marítimos

Speak in British English with a confident, authoritative, and conversational tone - like a senior consultant briefing a client. Measured pace, clear articulation, warm but professional. No filler words. Occasional brief pauses for emphasis: Welcome to the Purple Technical Briefing. I'm going to walk you through everything you need to know about setting up a captive portal on Starlink - specifically for remote venues, maritime operators, and anyone running guest WiFi where fibre simply isn't an option. [medium pause] Let's start with the problem. Starlink has genuinely changed the connectivity picture for venues that were previously stuck with slow, expensive satellite links or patchy 4G. A cruise vessel, a remote highland hotel, a construction site welfare unit, a festival site in a field - all of these can now get 100 to 220 megabits per second from a dish the size of a large pizza. That's remarkable. But here's the thing: raw connectivity is only half the job. The moment you put that connection in front of guests, passengers, or crew, you need authentication, access control, GDPR-compliant consent, and bandwidth management. Starlink doesn't give you any of that out of the box. That's where a captive portal comes in. And that's what we're going to build today. [medium pause] 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're behind carrier-grade NAT - what engineers call CGNAT. That means your WAN IP address is in the 100.64 to 100.127 range. It's not a public IP. You cannot receive inbound connections from the internet. And that matters enormously for captive portal architecture. The fix is bypass mode - sometimes called bridge 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're 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'll need to re-enable it. Build that into your site runbook. [medium pause] Now, Starlink offers three plan tiers relevant to venue operators. Standard gives you up to 100 megabits down, best-effort priority, and no static IP option. Business gives you up to 220 megabits, priority data allocation, and a static IP add-on. Maritime gives you the same speeds with global portability - essential if the vessel moves between ocean regions. For any multi-user venue, I'd recommend Business or Maritime as a minimum. Best-effort data on Standard means your guests get deprioritised whenever the satellite cell is congested. [medium pause] Section two: the architecture stack. Here's the four-layer stack you're building. Layer one is the Starlink uplink in bypass mode. Layer two is your enterprise router or firewall - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Fortinet - any of these work. 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's non-negotiable. You need at minimum three VLANs. VLAN 10 for staff - this carries your POS 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's not just good practice - it's a PCI DSS requirement if you're processing card payments anywhere on the same physical infrastructure. [medium pause] 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 mobile device. With Purple, that 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-premise authentication server required. That's critical for remote venues where you cannot run a local RADIUS server. [medium pause] Section three: the CGNAT problem and how to solve it. Here's 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's 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's cloud overlay architecture handles this natively - you don't need to configure WireGuard or OpenVPN manually, though both are valid alternatives if you're running your own infrastructure. If you do need a static IP - for example, if you're running a RADIUS server on-site or need consistent IP allowlisting - Starlink Business and Maritime offer a static IP as an add-on. At the time of recording, that's available in most regions. Check Starlink's current plan pages for your specific territory. [medium pause] Section four: GDPR and data compliance. This is where remote and maritime venues often get caught out. The fact that your venue is on a vessel in international waters, or in a remote location, does not exempt you from GDPR if you're collecting data from EU residents. And if you're operating in UK waters post-Brexit, the UK GDPR applies. Your captive portal must present a specific, unticked consent checkbox for marketing communications. It must clearly state what data you're collecting, why, and how long you'll retain it. The terms of service must be accessible before the guest authenticates. And you must be able to demonstrate, on request, that a specific individual gave consent on a specific date and time. 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. [medium pause] Section five: bandwidth management. On Starlink, bandwidth is your most constrained resource. A single passenger streaming 4K video can consume 25 megabits per second continuously. On a vessel with 50 passengers and a 220 megabit connection, that's one person taking 11% of total capacity. You address this at the captive portal and router level. Set per-device bandwidth caps - for example, 5 megabits down and 2 megabits up per guest device. Implement fair-use policies that throttle after a daily data allowance. Use traffic shaping to prioritise web browsing and messaging 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. [medium pause] Now let me give you two real-world scenarios. Scenario one: a 120-cabin cruise vessel. The operator runs Starlink Maritime at 220 megabits. They deploy Cisco Meraki access points throughout the vessel with three VLANs - crew, passenger, and ship systems. Purple's captive portal handles passenger authentication via email or a cabin number lookup integrated with the PMS. Each passenger gets a 2-gigabyte daily allowance. Premium tier passengers get 10 gigabytes. The portal collects first-party email data for post-voyage marketing. Result: WiFi revenue covers the Starlink subscription cost, and the operator has a growing direct marketing list. Scenario two: a remote Highland hotel with no fibre. They run Starlink Business at 150 megabits average. HPE Aruba access points cover the main building and three outbuildings. Guests authenticate via email on Purple's portal. The hotel uses Purple's analytics to understand peak usage times and adjusts bandwidth policies accordingly. They've reduced guest WiFi complaints by 60% compared to their previous 4G bonding setup, according to their own operational data. [medium pause] Common 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 and set a monitoring alert on your router's WAN interface. Two: not blocking inter-VLAN routing. Every deployment I've reviewed that had a security incident had this misconfigured. Check it twice. Three: using HTTP redirect for the captive portal 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. Purple's portal handles this, but your router configuration needs to be correct. Four: not testing on iOS and Android separately. Apple's Captive Network Assistant and Android's network probe behave differently. Test both before go-live. Five: ignoring latency. Starlink's LEO constellation delivers 20 to 40 millisecond latency - far better than traditional geostationary satellite. But during handoffs between satellites, you can see brief spikes. Your captive portal timeout settings need to account for this. Set session keepalive intervals to 60 seconds or less. [medium pause] 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 tunnelling. Yes, if you're running on-premise RADIUS. Can I run multiple SSIDs on Starlink? Yes - your enterprise access points handle SSID creation. Starlink in bypass mode just provides the uplink. You can run as many SSIDs as your access points support. 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's cloud. The portal is live within the hour. What happens if the Starlink connection drops? Purple's portal caches active sessions locally on the router for a configurable period - typically 24 hours. Guests who are already authenticated stay online. New authentications queue until connectivity restores. [medium pause] To summarise. 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 - Purple's, in this case - handles authentication, GDPR consent, bandwidth policy, and first-party data collection. The CGNAT constraint is solved by reverse tunnel architecture, not by static IP. And bandwidth management at the portal level is what keeps your Starlink connection usable for everyone. If you're evaluating this for your venue, the next step is to check which access point hardware you're running - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet - and confirm Purple's integration documentation for that platform. You can find the full technical guide at purple.ai, and the Purple team can walk you through a proof-of-concept configuration for your specific site. Thanks for listening. I'll see you in the next briefing.