incidents / INC-0002
My own firewall rule broke the smart home
A new ESP32 sensor wouldn't adopt and LAN-controlled lights never answered. The deny rule from SEC-0001 was dropping reply traffic.
- ticket
- INC-0002
- type
- incident
- priority
- P3
- status
- resolved
- opened
- 2026-09-06
- detected by
- New device failed to adopt in Home Assistant
- time to resolve
- ~1h
Symptom
A newly flashed ESP32 Bluetooth proxy joined Wi-Fi fine, but Home Assistant couldn’t connect to it. On closer look, LAN control for the smart bulbs had never worked either. They only ever responded through the cloud.
Triage
- The device had a strong signal (-51 dBm) and a DHCP lease, and it answered ping from the personal VLAN. So the Wi-Fi was fine.
- Home Assistant lives on the server VLAN and the device on the personal VLAN. Connections from HA to the device timed out.
- Pulled up the change history: the personal → server deny rule from SEC-0001 had gone in a week earlier.
Root cause
The deny rule matched all connection states. When Home Assistant opened a connection to a device, the device’s reply travelled Personal → Servers and got dropped as if it were a new, unauthorized connection. The segmentation rule was stopping the servers from ever hearing back.
Fix
Changed the rule to match only NEW and INVALID states. Untrusted devices still can’t start a connection into the server VLAN, and replies to connections the servers started are allowed back through.
Verification
- HA adopted the ESP32 (area set, 12 BLE devices seen right away).
- All four LAN-controlled bulbs respond locally, with no cloud round-trip.
- Admin laptop → server VLAN still works; an untrusted device → server VLAN is still blocked.
- Reboot test: hard-reset the ESP32, the API was back in 10s, and HA re-registered it automatically.
Lesson
A security fix is a change like any other: it needs a test plan that covers what should still work, not just what should now be blocked.
Hiring for this
The resume has the formal version.
See resume →