Alpine School District, Jordan School District, Canyons, and Davis between them have handed out a Chromebook to roughly every K–12 student in northern Utah at this point. For most families that means three or four school-issued laptops connecting to the home network every afternoon and behaving in ways that the rest of the house finds confusing, frustrating, or actively broken.
The complaint we hear most often: “Ever since the kids’ Chromebooks came home, certain websites don’t load on the family computer either,” or “Our Apple TV stopped seeing the printer the week school started.” These problems have a shared root cause, and the fix is the same one we recommend for almost every “weird device on the home network” situation: put the school devices on their own VLAN.
What the school is actually doing to the Chromebook
School-issued Chromebooks are managed devices. The district enrolls them in Google Workspace for Education with a management profile that the kid can’t disable, can’t uninstall, and can’t opt out of even on the home network. That profile typically does the following:
- Forces all DNS lookups through a district-controlled resolver — usually a CIPA-compliant filter like Securly, GoGuardian, Lightspeed Filter, or ContentKeeper.
- Installs a district root certificate so the filter can man-in-the-middle inspect HTTPS traffic for flagged content.
- Forces specific Chrome extensions to be installed (Hapara, Securly Classroom, GoGuardian Teacher) and blocks the user from disabling them.
- Routes outbound traffic through a district VPN or proxy in some districts, especially during school hours.
- Locks down DNS-over-HTTPS to a specific endpoint.
None of that is malicious or unreasonable — the district is legally required to filter content under CIPA, and a managed device that filters everywhere is the cleanest way to comply. But on a home network, those policies bump into your home’s own DNS, your own router, your own printer discovery, and sometimes your own parental controls.
How this actually breaks your home network
1. DNS hijacking confuses your router
If you’ve set up NextDNS, Pi-hole, or another DNS-based filter at the router level, the Chromebook will simply ignore it. The school’s management profile pins DNS to the district’s resolver and uses DoH to bypass anything you set. Your DNS dashboard shows zero queries from the Chromebook, which makes it look like the device is offline — but everywhere else on the network the kids are browsing whatever the district allows, which may or may not match your house rules.
Worse, when the school’s DNS resolver goes down (it happens, especially overnight or during district maintenance windows), the Chromebook doesn’t fail over to your router’s DNS. It just stops resolving anything until the district’s servers come back. Kids assume the home internet is broken and start asking you to reboot the router.
2. The district root certificate is on the device, but only the device
The district installs its own root CA so it can inspect HTTPS. That cert is trusted by the Chromebook. It is not trusted by the rest of your house. That doesn’t directly break anything, but it does mean the Chromebook is making HTTPS connections that look perfectly valid to the kid and look like a man-in-the-middle attack to any privacy auditor. Worth understanding, especially if you’re thinking about how to share files between school and home devices — you can’t treat the Chromebook as a trusted endpoint for anything sensitive.
3. Captive-portal weirdness on guest Wi-Fi
If your kids are connecting Chromebooks to a proper isolated guest Wi-Fi, the captive-portal redirect that pops up on most devices the first time they connect can interact badly with the school’s mandatory proxy. Some Chromebooks just hang at the captive portal and never finish the handshake, especially if the portal uses a self-signed cert that the school’s management profile is configured to reject. You’ll see the kid say “the Wi-Fi doesn’t work” and the device shows connected with no internet. The fix is to give school devices a properly authenticated network with no captive portal — which is exactly what a dedicated VLAN does.
4. mDNS and printer discovery break
The Chromebook doesn’t see the home printer. You add the printer manually by IP, and that works for a week, then the printer’s IP changes and breaks again. AirPrint and Bonjour both rely on mDNS, and the Chromebook’s management profile often blocks mDNS responses from anything outside the school’s allowed scope. The household Apple TV, HomePods, and printers are all on mDNS too, and now nothing finds anything cleanly. We covered the broader mDNS pattern in the Sonos drops post; the Chromebook makes the same kind of mess.
5. School VPN traffic looks like an attack to your firewall
If the district routes Chromebook traffic through a cloud filter (Securly Classroom, GoGuardian Beacon, Cisco Umbrella), all outbound traffic from the device goes to a small set of cloud IPs. From your gateway’s perspective, that looks like a single device generating sustained heavy traffic to an unfamiliar destination — the same pattern an actual exfiltration attempt would make. UniFi’s IDS will flag it. Your UniFi dashboard will fill up with “suspicious connection” alerts that aren’t actually suspicious, just noisy. Without segmentation, you can’t tell the noise from a real event.
The fix: a school-devices VLAN
The clean answer is a dedicated VLAN for school Chromebooks (and the kids’ school iPads, if you have a younger cohort on Alpine’s K–2 iPad rollout). VLANs are the topic we covered in the VLANs-for-homeowners post; the school-device case is one of the cleanest applications of the concept.
A typical setup looks like:
- A new SSID called something like “Smith-School” on its own VLAN.
- The VLAN gets internet access but no access to the rest of the home LAN. Printers, NAS, smart home, work laptops — all invisible.
- Optional: a firewall rule allowing the school VLAN to reach the printer’s IP and port, so kids can still print homework.
- Optional: a separate, more aggressive parental-control DNS filter applied specifically to that VLAN — on top of the district’s filtering, not replacing it.
- QoS on the gateway giving school devices a lower priority than work and family devices, so a kid streaming during a teacher Zoom doesn’t fight your work calls for bandwidth.
The kids connect to the school SSID and never notice anything is different. The district’s filter does its thing. Your home network stops getting confused. The IDS alerts go quiet. Printer discovery works again because the noisy mDNS traffic is no longer competing with the home VLAN.
What you can’t do (and shouldn’t try)
A few things parents periodically ask us to do that we won’t:
- Block the district’s filter. The Chromebook is the district’s asset and runs the district’s software. If you block GoGuardian or Securly at your firewall, the kid’s schoolwork stops working — tests don’t submit, classroom integrations break, the teacher loses the ability to push assignments. Don’t do this.
- Strip the district root certificate. You can’t, on a managed Chromebook. Even if you could, you’d break the district’s ability to fulfill its CIPA obligation, which is grounds for the device being deactivated.
- Override school filtering with a home VPN. The Chromebook’s management profile prevents user-installed VPN extensions, and even a VPN at the router level won’t help — the district’s DNS pinning and filter still apply.
- Loosen the school’s rules in general. If you want your kids to have less-filtered internet, that’s a conversation with the district, not a networking change.
What you can do is keep the school’s rules from leaking into the rest of your house and keep the rest of your house from looking like an attack surface to the district’s filter.
What this looks like on UniFi specifically
Most of our Wasatch Front installs are on UniFi Cloud Gateway, UDM Pro, or UDM SE hardware. The school-VLAN setup on a UniFi network is a clean ten-minute config:
- Create a new network in the controller, call it “School,” assign it VLAN ID 40 or similar.
- Enable “Isolate Network” or build explicit firewall rules blocking the School VLAN from reaching LAN, IoT, and Cameras VLANs.
- Create a new SSID, assign it to the School VLAN, broadcast on 2.4 + 5 GHz (Chromebooks don’t need 6 GHz).
- Add a single firewall allow rule from the School VLAN to the printer IP on TCP 9100 (and 631 if AirPrint is in use).
- Enable QoS / Smart Queues on the gateway and assign the School VLAN a lower priority than the LAN and Work VLANs.
- Optionally point the School VLAN at a separate NextDNS profile for additional content filtering on top of the district’s.
We’ve done this exact configuration in dozens of homes across Highland, Lehi, Pleasant Grove, and Saratoga Springs — the Alpine District households — and another batch across Sandy, Draper, and Cottonwood Heights for Canyons and Jordan District families. The pattern is identical; only the SSID name changes.
What about the kid’s personal devices?
The personal phone, the personal iPad, the gaming console — those don’t go on the school VLAN. They go on the regular family LAN (or a kids VLAN if you want to apply parental controls separately, which we usually recommend). The principle is: the school owns the Chromebook’s network experience. You own everything else. Keep them on different VLANs and they stop interfering with each other.
This is the same pattern that makes the rest of the house cleaner — work on its own VLAN (we covered this in the home-office cabling post), IoT on its own VLAN, cameras on their own VLAN, guests on a guest VLAN, and now school devices on a school VLAN. That’s six segments in a typical Wasatch Front household, and on a properly designed UniFi network it costs nothing extra to maintain.
The bigger picture: why this is a Utah-specific problem
Utah has one of the highest 1:1-device deployment rates of any state. Alpine District started K–12 Chromebook deployment in 2015 and was effectively fully 1:1 by 2020. Jordan, Canyons, Davis, and Granite all run their own variants. By spring 2026, a typical Lehi or Highland household with three school-age kids has three district-issued Chromebooks coming home every weekday afternoon plus whatever personal devices the kids own. That’s routinely 10–15 devices on the home network from school-aged kids alone.
Without segmentation, those devices are competing with everything else for IP address space, mDNS response time, broadcast domain bandwidth, and firewall log space. With segmentation, they effectively disappear into their own world and the rest of the house works the way it’s supposed to.
Bottom line
School-issued Chromebooks aren’t broken or badly behaved — they’re heavily managed devices doing exactly what the district told them to do. On a flat home network, that management bumps into your DNS, your printer discovery, your IDS, and your parental controls. The fix is a dedicated school VLAN with internet access, narrow allow rules to the printer, lower QoS priority, and no visibility into the rest of the house.
It’s a 10-minute config on a properly designed UniFi network and it solves a category of problems that families otherwise just learn to live with for the next 13 years of school.
Keystone Integration designs and installs home networks with proper VLAN segmentation across Lehi, Highland, Alpine, Sandy, Draper, and the rest of the Wasatch Front — including dedicated school- device VLANs for Alpine, Jordan, Canyons, and Davis District families who are tired of their kids’ school laptops breaking the rest of the house. See our full service list or get in touch to scope a network upgrade.