How to Add a Captive Portal to Starlink Guest Wi-Fi Safely

A captive portal puts a sign-in or welcome page in front of guest Wi-Fi. It can be useful for a small office, workshop, campsite, event or holiday property, but the standard Starlink router is not a captive-portal controller. You normally need a third-party gateway, firewall or managed Wi-Fi system that can run the portal.

This guide shows how to place that equipment in the network, keep guest devices away from private equipment, limit shared bandwidth and test recovery before relying on it.

The network layout to aim for

For a clean design, make the third-party gateway the device that provides routing, DHCP, firewall rules and the captive portal:

Starlink dish -> Starlink router -> third-party gateway -> switch -> access points

On Starlink hardware that supports it, bypass mode lets the third-party gateway take over routing. The exact adapter, port and app labels depend on your Starlink kit, so check the current instructions for that model before changing modes.

If bypass mode is not available or you deliberately keep the Starlink router as the main router, the gateway may sit behind it. That can work for outbound guest browsing, but it adds another routed layer and can complicate local discovery, remote administration and troubleshooting. Do not choose that layout accidentally.

What you need

• A Starlink kit with a compatible Ethernet path for the gateway.
• A third-party router, firewall or managed Wi-Fi platform that explicitly supports captive portals.
• One or more access points that support the platform's guest or VLAN design.
• A switch and suitable cabling if you need more than one access point.
• A private management device that will not depend on the guest portal.
• A written recovery path, including how to reconnect the original Starlink network.

Before buying anything, confirm that the platform supports the features you actually need: guest isolation, DHCP, DNS handling, a portal or voucher flow, bandwidth limits, session timeouts, firmware updates and a local fallback if the internet is unavailable.

Plan the networks before connecting cables

Keep at least three logical roles separate:

• Management: the gateway, switches and access points. Do not expose this network to guests.
• Private: household, staff, payment or trusted devices.
• Guest: the portal-controlled network with client isolation and a bandwidth policy.

A different Wi-Fi name is not the same as network isolation. If the platform supports VLANs or separate interfaces, use them. If it does not, use its documented guest-network mode and verify the firewall behaviour rather than assuming it is secure.

Choose a private subnet for each routed network and make sure it does not overlap with the Starlink LAN or any remote VPN network you use. Write the choices down before setup. Overlapping subnets make later troubleshooting much harder.

Build and test the gateway first

Do the first setup while you still have working Starlink Wi-Fi:

1. Photograph the current Starlink cable connections and record the Wi-Fi name and password.
2. Update the gateway and access-point firmware if the manufacturer recommends it.
3. Connect the gateway WAN port to the Starlink Ethernet output using the documented arrangement.
4. Set the gateway WAN to the mode expected by the Starlink kit, commonly automatic addressing unless the current instructions say otherwise.
5. Give the gateway a private LAN range that is different from the Starlink LAN.
6. Create one management network and one guest network. Add a private network only when you need it.
7. Confirm that only the intended gateway provides DHCP and routing for each network.
8. Connect one access point and test with a spare device before adding the rest.

Do not switch to bypass mode while people are relying on the connection. Schedule the change outside a call, event or payment window, and keep the original cable arrangement available so you can restore it.

Configure the captive portal

Portal menus differ by platform, but the important controls are similar:

• Give the guest SSID a clear name that does not resemble the management or private network.
• Require the sign-in, acknowledgement or voucher step you actually intend to use.
• Keep the welcome page short and readable on a phone.
• Set a session timeout so old guest access does not remain open indefinitely.
• Add a reasonable per-device speed limit and, where available, a total guest-network limit.
• Enable client isolation so one guest device cannot initiate connections to another guest device.
• Block access from the guest network to gateway, switch, access-point and private-network administration pages.
• Allow only the services the portal needs for DNS, DHCP and sign-in.
• Use a small, intentional bypass list. Do not bypass the portal for every device just because one test device is difficult.
• If the platform supports vouchers, set an expiry time and decide how staff will revoke a lost or shared voucher.

Never collect a guest's Starlink password, payment-card details or unrelated personal information on a home-built splash page. Use the platform's documented secure flow, keep the data request minimal and review its privacy settings before enabling analytics or marketing fields.

Put the access points in the right mode

Use the access point mode documented by the gateway platform. The gateway should remain the routing and portal authority unless the platform explicitly describes another architecture.

Place access points where guests need service, not merely where they are easy to plug in. Use wired backhaul when available. For outdoor or detached locations, use equipment, cable entry and power protection rated for that environment.

Keep access points away from large metal objects and heat sources. A strong Wi-Fi signal does not fix a weak Starlink service path, and adding more access points will not increase the satellite connection's total capacity.

Test the portal from a clean device

Use a phone or laptop that has not already accepted the portal. Test from the guest area, then repeat while the private network is in use:

1. Forget the guest network or use a separate test device.
2. Join the guest SSID and confirm the device receives an address from the intended guest network.
3. Check that the sign-in or welcome page appears.
4. Complete the portal step and open several ordinary websites.
5. Disconnect and reconnect, then confirm the session behaviour matches your timeout setting.
6. Test a second guest device at the same time.
7. Check the speed limit during a real download or video call, not only with a single speed test.
8. From the guest device, try to reach the gateway administration address, a private computer, a printer and another guest device. These should be blocked unless you deliberately allow a specific service.
9. From the management device, verify that you can still administer the gateway and access points.
10. Reboot the gateway and one access point, then confirm the portal returns without manual intervention.

Some devices handle captive portals better than others. A phone may show a sign-in notification while a laptop may need a browser window. If the portal does not appear, open a normal non-HTTPS page or use the platform's documented test address. Never tell users to ignore a certificate warning or enter credentials into an unexpected page.

Common problems

Guests connect but never see the portal

Check that the device is on the intended guest SSID, receives guest DHCP settings and can resolve DNS. Confirm the gateway is actually in the traffic path and that the access point is not running a second isolated router mode. A previously accepted session, private DNS setting or VPN can also hide the redirect.

The portal keeps looping

Check the device clock, session timeout, browser cookies, randomised Wi-Fi identity and voucher status. Review the portal's allowlist and make sure its own sign-in services are not being blocked by a custom DNS or firewall rule.

Guests have internet but can reach private devices

Stop using the network until the policy is corrected. Check guest-to-LAN rules, VLAN assignments, access-point client isolation and any switch trunk configuration. Test from both directions: guest to private and private to guest.

The portal works but the network feels slow

Guest traffic still shares the Starlink connection with every other user. Lower the per-device limit, set a total guest limit and protect interactive traffic with the gateway's documented traffic-management controls. Test at the busiest expected time.

The Starlink app or gateway is unreachable after the change

Connect a management device to the correct network, check power and link lights, and verify which device is providing DHCP. If you cannot recover the gateway, restore the documented original Starlink layout instead of repeatedly changing modes.

Keep a recovery plan

Before opening the guest network to real users, save the gateway and access-point configuration if the platform supports backups. Record the hardware locations, cable labels, management addresses, firmware versions and the steps needed to disable the portal.

Keep one private management path that does not depend on portal acceptance. If the gateway supports local administration, confirm it works while the Starlink service is offline. Keep a spare cable and a known-working access point or laptop available for fault isolation.

Review the setup after firmware changes, a Starlink router swap, a new access point or a change to the service plan. Re-test guest isolation each time. A portal that worked last month is not proof that a new network mode is safe.

Final checklist

• [ ] The third-party gateway's role is documented.
• [ ] Only the intended device provides routing and DHCP.
• [ ] Management, private and guest traffic are separated.
• [ ] Guest clients cannot reach private devices or network administration.
• [ ] The portal works from a clean phone and laptop.
• [ ] Session expiry, vouchers and bandwidth limits behave as intended.
• [ ] The Starlink connection remains usable for private devices during guest activity.
• [ ] Configuration backups and cable labels are available.
• [ ] The original Starlink layout can be restored.

Starlink hardware, app labels and third-party portal features change over time. Check the current instructions for your exact kit and gateway before changing router modes.

Official reference

• Starlink third-party router guidance
• Starlink Support

Reviewed 29 October 2026. Starlink Tips is independent; current hardware, plan and third-party gateway behaviour should be verified before installation.