Part 1: ?

The New Home Wi-Fi

I’d been running my home network the way most people do: an ISP-provided router handling WiFi, DHCP, DNS, and NAT. Everything plugged in, everything worked, nobody asked questions. The Chromecast cast. The printer printed. Life was simple.

Then I decided to upgrade. I had some enterprise-grade access points sitting around — the kind that give you proper control over RF, security policies, VLANs, client isolation, the works. The kind where the defaults assume you know what you’re doing, because the people deploying them usually do.

I moved my devices across to the new wireless network. Laptops, phones, tablets — all fine. But the Chromecast? It refused to connect.

Well, that’s not quite right, I discovered, logging into my wireless controller. It connected to the WiFi just fine. There it was in the user-table, associated, authenticated and with a DHCP-assigned IP address. But on my TV, it just sat there with a sad “Can’t connect to the internet” message, while every other device on the same network was browsing happily. What was different about the Chromecast?

It was time to find out what this thing actually does when it boots up..

The Chromecast Startup Sequence

Several over-the-air packet captures later, I had the full picture. When a Chromecast powers on, it follows a fairly standard sequence:

1. WiFi association — 802.11 authentication and association with the access point, followed by a WPA2 4-way key exchange. Standard stuff.

2. DHCP — requests an IP address, subnet mask, default gateway, and DNS servers from the DHCP server. Nothing unusual.

3. ARP — resolves the default gateway’s MAC address so it can actually send packets off the local network.

4. DNS lookups — resolves several Google-owned hostnames: connectivitycheck.gstatic.com, time.google.com, clients1.google.com, and a few others.

5. Connectivity check — makes an HTTP request to https://connectivitycheck.gstatic.com/generate_204. This is standard Android behaviour — most Android-based devices do this after joining a WiFi network. If it gets back an HTTP 204 (No Content), it knows it’s online. If it gets a redirect, it knows it’s behind a captive portal (hotel WiFi, airport login page). If it gets nothing, it reports “Can’t connect to the internet.”

6. NTP sync — contacts time.google.com to set its clock. The Chromecast has no battery-backed real-time clock, so it needs NTP after every reboot.

7. TLS connections to Google services — once online, it phones home to various Google endpoints over TLS to check for firmware updates, download idle-screen images, and register itself as available for casting.

This is all visible in a packet capture, and it’s mostly unremarkable. The Chromecast is doing what most IoT devices do: get an address, check connectivity, phone home. But step 4 is where things went wrong.

The DNS Trap

The Chromecast had an IP address and it had a gateway, and it had the same firewall policy that every other device on my network had – they were all reaching the internet just fine. But the Chromecast was stuck at “Can’t connect to the internet.” Apparently the connectivity check was failing.

I went back to my packet captures and checked the DNS queries again. That’s when I noticed something a little.. unorthodox:

The Chromecast ignores your DHCP-provided DNS servers.

My DHCP server hands out DNS servers — local resolvers that I control. The Chromecast receives them, acknowledges them, and then completely bypasses them. Instead, it sent DNS queries directly to 8.8.8.8 and 8.8.4.4 — Google’s public DNS servers. Hard-coded, no fallback to DHCP-provided servers, and no configuration option to change that behaviour.

On a consumer home router, this is invisible. Traffic is typically NAT’d out to the internet with no filtering. DNS to Google works, DNS to anyone works, and nobody notices.

But some ISPs block DNS queries to well-known public resolvers like Google’s 8.8.8.8. It’s a cheap way to enforce content filtering — by forcing all DNS through their own servers, they can apply blocks without deep packet inspection. If your ISP does this, you might never know unless a device tries to bypass the ISP’s DNS – which is exactly what the Chromecast does.

My network sits behind an OPNsense firewall. I could verify that my firewall wasn’t blocking Google DNS — but the queries were dying somewhere upstream, silently dropped somewhere in the ISP’s infrastructure. But I noticed that queries to Cloudflare’s DNS (1.1.1.1 & 1.1.0.0) worked just fine — presumably not yet on the ISP’s block list.

The problem was, the Chromecast didn’t fall back. It didn’t try the DHCP-provided servers or any others. It didn’t log a helpful error. It just said “Can’t connect to the internet” — a message about as useful as a concrete parachute.

The Fix: NAT Redirection

The solution was straightforward. On the OPNsense firewall, I added a NAT rule to redirect all DNS queries destined for 8.8.8.8 and 8.8.4.4 to 1.1.1.1 and 1.1.0.0 (Cloudflare) instead:

Outbound NAT: src=any dst=8.8.8.8 port=53 → redirect to 1.1.1.1
Outbound NAT: src=any dst=8.8.4.4 port=53 → redirect to 1.1.0.0

This catches the Chromecast’s hardcoded Google DNS queries and silently reroutes them to a resolver that works. The Chromecast doesn’t know the difference — it thinks it’s talking to Google. The connectivity check succeeds. The device comes online.

This isn’t just a Chromecast fix, either. Any device on the network that hardcodes Google DNS — and there are more than you’d think — now gets quietly redirected. Smart speakers, IoT sensors, cheap IP cameras. A surprising number of consumer devices assume Google DNS will be reachable. In fact, I had been observing some other network ‘gremlins’ at times, slow responses, timeouts and the link and I wondered if these would now be resolved? DNS is very often at the root of network connectivity issues.

What This Reveals

This first problem already tells us something important about the Chromecast — and about consumer IoT devices in general.

The Chromecast makes assumptions about the network it’s on: that DNS to Google is always available, that there’s no filtering between it and the internet, that the path is wide open. These assumptions tend to hold on a consumer router where the defaults are permissive. They start to break when you apply more deliberate network policy.

Home routers generally favour convenience — most traffic is allowed unless you go out of your way to block it. Enterprise gear tends to favour security — traffic is restricted unless explicitly permitted. The Chromecast was built for the first environment and doesn’t adapt gracefully to the second.

This is a recurring theme with consumer IoT. Devices that “just work” on a home router often make invisible assumptions about network openness. When those assumptions fail, the error messages tend to be unhelpful, probably because the developers didn’t design for a network where Google DNS might be unavailable.

Keep this in mind. It won’t be the last time the Chromecast’s assumptions about network permissiveness cause problems.

The Chromecast Is Online. But Where Is It?

So great, the NAT redirect worked. The Chromecast finally connected, synced its clock, downloaded a firmware update, and settled into its idle screen showing landscape photos. By every measure, it was online and healthy.

I picked up my phone, opened YouTube, and tapped the Cast button.

Nothing. No devices found.

The Chromecast was on the network, happily talking to Google’s servers, but completely invisible to every other device on the same LAN. My phone couldn’t see it. My laptop couldn’t see it. It was as if it didn’t exist.

The first problem was about getting the Chromecast onto the network. This next one is about how devices find each other once they’re there.

That’s Part 2.

Next: Part 2 — “Why Can’t I See My Chromecast On My New Wireless LAN?”