Maintaining Web Filtering on Take-Home Chromebooks (At Scale)

Published: December 2025 • Field notes from a large-scale K-12 environment

---

When Chromebooks leave campus, most traditional web-filtering strategies quietly fall apart. Home networks are unmanaged. DNS is user-controlled. VPNs introduce reliability and support issues. And students are significantly more motivated to bypass controls once they’re off-site.

This post documents a production approach we used to maintain Palo Alto enforcement for take-home Chromebooks, without relying on always-on VPNs and without pushing filtering logic down to the endpoint.

The Core Problem

Off-campus devices break several assumptions at once:

• The district no longer controls the network
• DNS behavior becomes unpredictable
• IP-based policy loses meaning
• Traffic often never reaches district infrastructure

At the same time, expectations around student safety, compliance, and visibility remain unchanged. The goal was simple to state but hard to execute:

Ensure all student web traffic continues to be filtered by Palo Alto firewalls, even when devices are off-network.

Architectural Overview (High Level)

Rather than forcing traffic through a single choke point, we designed a distributed proxy model with centralized enforcement.

• Multiple lightweight Linux proxy servers are deployed
• Each server runs:
  • Apache (to host a PAC file)
  • Squid (pass-through only, no filtering)
• Squid does not make filtering decisions
• Palo Alto firewalls remain the only enforcement point

The proxy layer exists solely to steer traffic back into inspection, not to evaluate it.

Why Squid Was Used (and What It Wasn’t Used For)

This is important to clarify.

Squid was not used as a filtering proxy. Instead:

• No content decisions were made at Squid
• No categories were enforced
• No policy logic lived on the proxy

Squid’s role was limited to:

• Accepting explicit proxy connections
• Forwarding traffic toward Palo Alto enforcement
• Remaining simple, fast, and predictable

This kept the proxy tier operationally boring — which is exactly what you want.

PAC Files as the Control Plane

Chromebooks were configured via device management to use a PAC file hosted on Apache. The PAC file determined:

• Which destinations could go DIRECT
• Which destinations must go through the proxy

Conceptually, the logic looked like this:

function FindProxyForURL(url, host) {
  if (isTrustedEducationalOrPlatformDomain(host))
    return "DIRECT";
  return "PROXY proxy.example.org:8080";
}

In practice, the DIRECT list included core platform domains (identity, classroom services, and other performance-sensitive destinations). Everything else was proxied.

This ensured:

• Performance-sensitive services weren’t penalized
• Unknown or risky traffic remained visible
• New destinations defaulted to inspection

DNS Behavior: On-Campus vs Off-Campus

One subtle but critical detail:

• On-campus, the proxy hostname does not resolve → traffic flows naturally through Palo Alto
• Off-campus, DNS resolves externally → the proxy hostname resolves to one of the proxy endpoints (load-balanced)

The device behavior stays the same. The network behavior changes underneath it. This eliminated the need for users to toggle settings or understand where they were.

Load Balancing and Scale

Rather than relying on a single proxy:

• Multiple proxy servers were deployed
• DNS provided distribution
• No session state was required at the proxy layer

If a proxy failed, clients naturally retried another. No user intervention was required.

Identity Enforcement (Critical)

Traffic was not allowed to flow simply because a device could reach a proxy. Access required:

• User authentication on the Palo Alto
• Valid user identity mapping
• Active session state

If a user was not authenticated, traffic failed closed — nothing “sort of worked.” This prevented anonymous abuse and kept policy identity-driven.

External Authentication Support

Two supporting components were built:

1. A lightweight browser extension
   • Authenticates the user to the firewall from off-network
   • Maintains identity mapping tied to the external IP
2. A re-authentication web portal
   • Integrated with directory services
   • Uses Palo Alto APIs to refresh authentication state
   • Allows users to recover cleanly when sessions expire

These are significant enough to warrant separate posts.

Operational Lessons Learned

• PAC files age — they require ownership
• Behavioral enforcement matters more than static domains
• Identity failures are louder off-campus
• Parents notice problems faster than teachers
• Simplicity at the proxy tier pays dividends

The firewall should remain the brain. Everything else should be plumbing.

What’s Intentionally Omitted

This write-up intentionally avoids publishing:

• Exact PAC file contents
• Internal domain names
• Authentication logic and API workflows
• Network paths and environment-specific tuning

The value here is the design pattern, not a brittle copy/paste solution.

What’s Next

• Post: The off-campus authentication browser extension (design + flow)
• Post: The re-authentication portal (AD + Palo Alto API pattern)
• Post: Proxy-evasion patterns seen off-campus (what actually shows up in logs)