How a Google Nest Hub Took Down My Entire Network

I run a homelab with 12 VLANs, an OpenWrt firewall, and about 70 devices. Last night I enabled Cloudflare’s proxy (the \”orange cloud\”) on my domain realm.watch and woke up to find every device on my network had lost its IPv4 address. Phones, laptops, servers, IoT devices — all down. Here’s what happened and how I tracked it down.

The Symptom

After enabling CF proxy, devices on my admin VLAN (10.0.6.0/24) stopped renewing their DHCPv4 leases. My workstation was being handed a DHCPv6 address instead. Disabling the orange cloud immediately fixed it. Toggling it back on broke things again — reproducible every time.

The Investigation

My first instinct was to blame my own infrastructure. I checked:

• OpenWrt’s odhcpd on my firewall (gatekeeper) — disabled RA on all interfaces, confirmed via tcpdump it wasn’t sending any Router Advertisements
• dnsmasq on my hypervisor — stopped it entirely, RAs continued
• My realm-portal Alpine VM — confirmed it was receiving RAs, not sending them
• libvirt’s dnsmasq — only on virbr0 (isolated bridge), not on the VLAN bridge

None of my infrastructure was the source. So I ran a targeted tcpdump on the VLAN 6 bridge:

tcpdump -i br-lan.6 'icmp6 and ip6[40]=134'

And there it was — a device I didn’t expect:

fe80::1c3c:3716:1534:2392 > ff02::1: ICMP6, router advertisement
  Flags [managed, other stateful, ipv6 only]
  router lifetime 0s
  prefix: fd39:c3aa:8cfe:6bb8::/64, valid 1800s
  route: fd40:b451:5824:1::/64, lifetime 1800s

The Culprit: A Google Nest Hub

The source MAC was 24:e5:0f:d7:01:1d — a Google device. I hit its local API:

curl http://10.0.6.124:8008/setup/eureka_info

It was my Kitchen hub — a Google Nest Hub sitting on the counter. It was acting as a Thread/Matter border router, broadcasting IPv6 Router Advertisements with the ipv6 only flag (RFC 8781). This flag tells every device on the network: \”IPv6 is sufficient, you don’t need IPv4.\”

Why Cloudflare Proxy Triggered It

When you enable CF proxy on a domain, Cloudflare automatically publishes AAAA (IPv6) records alongside the A record. This introduces IPv6 DNS activity on the LAN — clients start making IPv6 lookups, generating multicast traffic. The Nest Hub’s Thread border router detected this IPv6 activity and responded by broadcasting Router Advertisements telling every device on the network to go IPv6-only.

The effect was immediate and reproducible: orange cloud on → RAs start → DHCPv4 leases expire → network down. Orange cloud off → IPv6 DNS activity drops → RAs stop → devices recover.

The Fix

Three layers of defense:

1. Firewall block — Added persistent nftables rules on my OpenWrt firewall to drop Router Advertisements from this MAC address:
   nft add rule inet fw4 forward ether saddr 24:e5:0f:d7:01:1d meta l4proto icmpv6 icmpv6 type nd-router-advert drop
2. Moved the device — Deauthed the Nest Hub from the admin SSID and moved it to the IoT VLAN where its RAs can’t affect critical infrastructure
3. Disabled RA/DHCPv6 on all firewall interfaces as an additional safety net

Lessons Learned

• Consumer smart home devices can break your entire network. A Google Nest Hub acting as a Thread/Matter border router was sending rogue Router Advertisements that poisoned DHCPv4 for every device on the VLAN.
• The \”ipv6 only\” RA flag (RFC 8781) is dangerous on mixed networks. It tells clients to stop using IPv4 entirely. One misbehaving device can take down your whole network.
• Segment your IoT devices. Smart speakers, hubs, and Thread/Matter devices should never be on the same VLAN as your servers and workstations.
• Enabling Cloudflare proxy can have surprising LAN-side effects by introducing AAAA records and increasing IPv6 activity, which can trigger latent issues with devices that react to IPv6 traffic.
• Google Cast devices expose a local API on port 8008 (/setup/eureka_info) that returns device identity without authentication — invaluable for identifying mystery devices.
• Use RA Guard or firewall rules to block unauthorized Router Advertisements. Only your actual router should be sending RAs.

The whole investigation took about an hour. The hardest part was accepting that my own infrastructure wasn’t the problem — it was a \$100 smart display on the kitchen counter.