Get One Month of Starlink FreeSPECIAL OFFER: GET A FREE MONTH OF STARLINK >
Blue Ethernet cables connected to a network switch

How to Use VLANs With Starlink: A Practical Home-Network Guide

Equipment & Accessories

Back to Equipment & Accessories
Independent owner's guide: Starlink Tips is not part of Starlink. Results vary with your Starlink hardware, router, switch, access points and local network design.

VLANs let one physical network carry several separated networks. With the right equipment, you can keep work devices, trusted home devices, smart-home equipment and guests apart while sharing one Starlink connection.

The important boundary is this: Starlink provides the internet connection, but a VLAN design needs a router or firewall, a managed switch and, for Wi-Fi VLANs, an access point that understands VLAN tags. If your current Starlink router does not offer those controls, do not plug a tagged VLAN trunk into it and assume that the networks are isolated.

The simple design

A practical Starlink VLAN layout is:

Starlink dish and router or Ethernet output -> VLAN-capable router/firewall -> managed switch -> wired devices and VLAN-capable access point

In this design:

  • The router or firewall creates the VLAN interfaces, DHCP scopes and firewall rules.
  • The managed switch carries tagged traffic between the router and access points, and places wired devices on the correct VLAN.
  • The access point maps different Wi-Fi names to different VLANs.
  • Starlink remains the upstream internet connection.

If you use the Starlink router as the only router, use its documented guest-network and device controls instead. VLANs are most useful when your own router is deliberately the network owner.

What you need

Before changing anything, confirm that you have:

  • A Starlink kit with a supported Ethernet or LAN path for your hardware.
  • A third-party router or firewall that supports 802.1Q VLANs, multiple DHCP networks and inter-VLAN firewall rules.
  • A managed Ethernet switch that supports VLAN tagging and untagged access ports.
  • A VLAN-capable Wi-Fi access point if you want separate wireless networks.
  • A laptop with an Ethernet port or adapter for testing.
  • A backup of the current router configuration and a way to restore the old setup.

The exact Starlink connection depends on the kit. Check Starlink's current third-party router guidance before buying an adapter or changing router mode.

A normal unmanaged switch cannot create VLANs. A second router can create a separate subnet, but that is a different design and often introduces double NAT and confusing device discovery.

A sensible starter VLAN plan

Start with a small design that solves a real problem:

  • VLAN 10 - 192.168.10.0/24: Trusted phones, computers and printers.
  • VLAN 20 - 192.168.20.0/24: Work devices or a separate household group.
  • VLAN 30 - 192.168.30.0/24: Smart-home and IoT devices.
  • VLAN 40 - 192.168.40.0/24: Guests.
  • VLAN 99 - 192.168.99.0/24: Network management.

These example addresses are private and only illustrative. Avoid copying them if they overlap with an existing VPN, office network or another router.

For a first deployment, give every VLAN its own DHCP range and gateway on the VLAN-capable router. Keep the management network small and do not put ordinary phones or smart devices there.

Set the firewall policy before connecting devices

A VLAN is not automatically a security boundary. The router's firewall must control traffic between VLANs.

A reasonable starting policy is:

  • Allow each VLAN to obtain DHCP and use DNS from the router.
  • Allow each VLAN to reach the internet.
  • Block Guest and IoT from reaching Trusted and Management.
  • Allow Trusted to reach selected printers, storage or smart-home services only when needed.
  • Allow Management to administer the router, switch and access point.
  • Block unsolicited connections from other VLANs into Management.
  • Keep established and related return traffic working.
  • Add exceptions one at a time and record why each exists.

Do not copy a vendor rule named "allow all inter-VLAN traffic" into a network that is meant to be separated. If a printer or hub needs to be discovered across VLANs, use the router or service's documented discovery helper, a narrow firewall rule or a deliberate shared-services design. Do not open every VLAN to every other VLAN just to make one device easier to find.

Build the configuration in a safe order

1. Record the working Starlink setup

Before changing modes or cables:

  1. Run a normal speed test and record the result.
  2. Note which device provides Wi-Fi, routing and DHCP.
  3. Record the current Wi-Fi name and the devices that must reconnect.
  4. Save a router configuration backup if the router supports it.
  5. Download the manuals for the router, switch and access point.
  6. Schedule the change when a short outage will not interrupt a meeting or backup.

Keep the original Starlink router and power equipment available. Do not remove hardware simply because a diagram on the internet shows a different Starlink model.

2. Prepare the router or firewall locally

Configure the VLAN-capable router before placing it in the live path:

  • Set its WAN type to the mode documented for the Starlink connection, normally automatic addressing when the router is connected to a Starlink Ethernet output.
  • Create the VLAN interfaces and DHCP scopes.
  • Give each VLAN a unique gateway address.
  • Apply the inter-VLAN firewall policy.
  • Set a strong administrator password and enable updates.
  • Use a management port or temporary untagged LAN connection so you do not lock yourself out during testing.

Do not enable every advanced option at once. First make the router provide one ordinary LAN with working internet, then add one VLAN and test it before adding the rest.

3. Connect Starlink to the intended WAN

Connect the Starlink Ethernet output to the third-party router's WAN port using a known-good cable. If your hardware requires bypass mode, follow Starlink's current instructions for the exact router and kit.

When bypass is enabled, the Starlink router's normal Wi-Fi may disappear. That can be expected. The third-party router must then provide DHCP, Wi-Fi or the LAN connection for your devices.

If you keep the Starlink router as the network owner, stop at the ordinary LAN or its documented guest features. Do not create a second full router behind it unless you deliberately understand the two-network design.

4. Configure the managed switch

On the switch:

  • Create the same VLAN IDs used on the router.
  • Make the router-to-switch link a tagged trunk carrying only the VLANs it needs.
  • Configure a wired device port as an untagged access port for exactly one VLAN.
  • Configure the access-point port as a tagged trunk with only the SSID VLANs and management VLAN required.
  • Keep the switch management interface on the management VLAN or another intentionally controlled network.
  • Disable unused ports when practical and label important cables.

The names differ by manufacturer: trunk, tagged, access, untagged, native VLAN and PVID may all appear in the interface. Read the switch documentation instead of guessing. A mismatch between the tag expected by the router and the tag sent by the switch commonly produces a link that is physically up but never receives an IP address.

Do not connect two switch ports back into the same network unless you have intentionally configured link aggregation or loop protection. A cable loop can make the whole LAN unstable.

5. Map Wi-Fi names to VLANs

On a VLAN-aware access point, map each wireless network to one VLAN:

  • Home or Trusted Wi-Fi -> VLAN 10
  • Work Wi-Fi -> VLAN 20
  • IoT Wi-Fi -> VLAN 30
  • Guest Wi-Fi -> VLAN 40

Give each network a distinct name while testing. Do not reuse the same SSID across different VLANs until you understand which access point and security policy a device is using.

Enable the access point's management access only from the management VLAN or a trusted administration device. Guest isolation on an access point can be useful, but it does not replace the router's VLAN firewall rules.

Test one path at a time

Start with one laptop connected to one wired access port:

  1. Confirm the switch port shows a link.
  2. Check that the laptop receives an address from the expected subnet.
  3. Confirm the default gateway is the router interface for that VLAN.
  4. Browse to a simple website.
  5. Check that the laptop cannot reach a blocked VLAN or management page.
  6. Move the laptop to another access port and confirm that the intended VLAN changes.
  7. Test one Wi-Fi SSID only after the wired path works.

For each VLAN, record:

  • Assigned IP address and subnet.
  • Default gateway and DNS server.
  • Internet access.
  • Allowed local services.
  • Blocked local services.
  • Which router, switch and access-point interface provided the connection.

A successful internet test does not prove isolation. The most important tests are the blocked ones: a guest device should not reach a NAS, router admin page or switch management page unless you intentionally allowed it.

Troubleshooting

A VLAN device gets no IP address

Check the access-port VLAN, the switch PVID, the tagged trunk and the router's DHCP scope. Confirm that the router has an interface for that VLAN and that the DHCP service is enabled there. A link light only proves the cable is connected; it does not prove the VLAN is configured correctly.

The device has an IP address but no internet

Check the router's default route, DNS, NAT and WAN status. Confirm that the VLAN is allowed to use the WAN and that a firewall rule is not blocking DNS or return traffic. Test the ordinary trusted VLAN so you can tell whether the problem is the Starlink WAN or the new VLAN.

Devices on one VLAN cannot find each other

Check that they are on the same VLAN and subnet, that client isolation is off where appropriate and that the device firewall permits local discovery. Some discovery protocols do not cross VLANs by default. Add a narrow, documented discovery rule only if the service really needs it.

A guest device can reach the router or NAS

Review the order and direction of inter-VLAN rules, the access-point SSID mapping and the switch port VLAN. Make sure the test device is actually on the guest subnet. Do not assume that a Wi-Fi name proves the VLAN assignment.

The Starlink app cannot reach the dish

A third-party router may need a documented route to the Starlink terminal network. Starlink's app guidance for third-party routers should be checked for the current hardware path. Do not add a guessed route to every VLAN. Add it only where your router and Starlink's current instructions require it.

The network became unstable after adding the switch

Disconnect the new links and return to one simple router-to-switch path. Look for a loop, duplicate DHCP service, a second router still in full routing mode or a trunk carrying a VLAN that the next device does not understand.

What VLANs do not fix

VLANs do not:

  • Improve the dish's view of the sky.
  • Increase Starlink's available speed or remove congestion.
  • Create a public or static IP address.
  • Bypass Starlink CGNAT.
  • Make inbound port forwarding work.
  • Replace a firewall, software updates or strong device passwords.
  • Guarantee that an IoT device is trustworthy.

If your goal is only more wired ports, an ordinary switch may be enough. See How to Add an Ethernet Switch to Starlink for Multiple Wired Devices. If your goal is a separate visitor network, Starlink's documented guest options may be simpler; see How to Set Up a Starlink Guest Network Safely.

Finished setup checklist

  • [ ] One router or firewall clearly owns routing and DHCP.
  • [ ] The Starlink WAN connection works before VLANs are added.
  • [ ] VLAN IDs match on the router, switch and access point.
  • [ ] Each VLAN has its own gateway and DHCP scope.
  • [ ] Guest and IoT traffic cannot reach trusted devices or management interfaces by default.
  • [ ] The router-to-switch trunk carries only the required VLANs.
  • [ ] Wired access ports are assigned to one intended VLAN.
  • [ ] Wi-Fi SSIDs map to the intended VLANs.
  • [ ] At least one device on each VLAN has passed an internet and isolation test.
  • [ ] You have a configuration backup and a tested rollback path.

A good VLAN setup is deliberately boring: one clear network owner, predictable addressing, narrow firewall exceptions and tests that prove both connectivity and separation.