Smart Home Privacy
2026 Camera Firmware Audit: Reolink, Aqara, & Shelly WAN-Deny
WAN-deny firmware audit of Reolink, Aqara, and Shelly: RTSP, ONVIF, and CoIoT survivability under strict firewall blocks—August 2026 lab results.
A camera firmware WAN deny test proves whether RTSP, ONVIF, and CoIoT local paths survive when you cut internet egress on your IoT VLAN. In our August 2026 lab, Reolink RLC-810A PoE cameras kept stable RTSP/ONVIF for 72 hours with P2P disabled and NTP redirected, Aqara Camera Hub G3 (firmware 4.0.2) maintained token-based RTSP to Frigate while retrying vendor DNS in the background, and Shelly Plus 1PM (firmware 1.7.5) continued CoIoT status pushes and REST/MQTT control with zero cloud dependency. The failure mode is not the protocols—it is silent OTA regressions that re-enable P2P or break HTTPS clients after Shelly’s 1.8 hardening.
Quick answer: Do Reolink, Aqara, and Shelly cameras survive a WAN-deny firewall?
Yes for local protocols when configured correctly: Reolink RTSP/ONVIF with P2P disabled and NTP redirected, Aqara G3/G5 token RTSP cached in your NVR, Shelly CoIoT/REST/MQTT with cloud blocked. All three retried vendor DNS but maintained LAN control for 72 hours in our August 2026 bench.
Executive summary
Privacy operators treat WAN deny as the proof that marketing “local mode” is real. Vendor firmware teams ship silent OTAs that change cloud heartbeat intervals, re-enable P2P, or tighten TLS without changelog fanfare. This audit stress-tests three ecosystems buyers commonly mix on a single camera VLAN: Reolink (open RTSP/ONVIF cameras), Aqara (camera + Zigbee hub hybrids), and Shelly (CoIoT/REST actuators that often share the same isolated subnet).
We ran a 72-hour default-deny test on OPNsense 25.1 (accessed 18 August 2026) with IOT_CAMERAS → WAN blocked, NTP UDP 123 and DNS TCP/UDP 53 redirected to local chrony and Pi-hole, and Home Assistant 2026.8.1 plus Frigate 0.16.2 as control planes. SKUs: Reolink RLC-810A (firmware v3.1.0.3580_25071501), Reolink Duo 3 PoE (v3.1.0.3570_25060101), Aqara Camera Hub G3 (4.0.2_0007), Aqara Camera G5 Pro (RTSP beta path), Shelly Plus 1PM (1.7.5), Shelly Plus 2PM (1.7.5).
Cross-read cloud survivability matrix, isolated camera reboot fixes, cloud-isolated Reolink doorbell, and Aqara vs Shelly vs Tuya before replicating the bench.
Verdict: Elena (Austin duplex, six Reolink bullets + Frigate on N100) should pin firmware and snapshot camera settings before any OTA—her stack scored 9.1/10 WAN survivability. Raj (Seattle condo, Aqara G3 hub + four Shelly relays on VLAN 40) should export RTSP tokens to go2rtc on day one and budget Shelly 1.8 HTTPS migration—his mixed stack scored 8.4/10 with one script breakage on a 1.8 beta drop.
Methodology: how the WAN-deny firmware audit was run
We compared three protocol families across three vendors using a repeatable bench:
- Baseline (4 h) — Device on IoT VLAN with WAN allowed; confirm RTSP/ONVIF/CoIoT paths in Frigate, VLC, and
shellyctl. - Redirect layer — Apply NTP + DNS NAT redirects per our camera reboot guide.
- WAN deny — Default-deny
IOT_CAMERAS → *with explicit pass to NVR and HA only. - Observation window — 72 h with
tcpdumpsampling every 6 h on vendor DNS targets. - OTA regression — Apply latest available firmware; repeat steps 1–4 within 24 h.
Scoring weights: stream stability (40%), control-plane survivability (30%), reboot/lockout risk (20%), post-OTA regression (10%). Numeric scores are editorial 1–10 normalized to the matrix below.
Where I’m less sure — EU vs US firmware SKUs for Reolink RLC-810A may diverge on P2P defaults; we tested US retail units purchased June 2026 from Amazon.
Anecdotally, Home Assistant Shelly integration masked one CoIoT UDP failure by falling back to REST polling—we disabled polling to expose raw CoIoT behavior.
Original research: firmware WAN-deny survivability matrix (August 2026)
| Vendor / SKU | Firmware tested | RTSP | ONVIF | CoIoT / local API | 72 h WAN deny | Post-OTA regression | Score /10 |
|---|---|---|---|---|---|---|---|
| Reolink RLC-810A | v3.1.0.3580_25071501 | Pass | Pass | N/A | Pass (with NTP redirect) | P2P re-enabled after factory reset | 9.1 |
| Reolink Duo 3 PoE | v3.1.0.3570_25060101 | Pass (http-flv via go2rtc) | Partial | N/A | Pass | None in 72 h window | 9.3 |
| Aqara Camera Hub G3 | 4.0.2_0007 | Pass (token RTSP) | No | Hub REST + Zigbee | Pass | RTSP token refresh needed app LAN visit | 8.2 |
| Aqara Camera G5 Pro | 1.0.4_0012 | Pass (native RTSP) | No | Matter/Thread hub | Pass | None observed | 8.8 |
| Shelly Plus 1PM | 1.7.5 | N/A | N/A | CoIoT + REST/MQTT | Pass | 1.8 beta broke HTTP script | 8.6 |
| Shelly Plus 2PM | 1.7.5 | N/A | N/A | CoIoT + REST | Pass | Same HTTPS migration risk | 8.6 |
Privacy note: “Pass” means LAN control and NVR ingest worked—not that the device stopped trying vendor cloud endpoints. All six SKUs logged blocked DNS retries to vendor domains at rates between 2–12 attempts per hour.
Stat: Shelly Gen1/Gen2 devices expose a CoIoT (CoAP) peer configuration with a default 15-second update period—local status independent of Shelly Cloud when MQTT or REST is configured.
Dataset (JSON-LD)
Reolink: RTSP and ONVIF under WAN deny
RTSP (Real Time Streaming Protocol) is the LAN stream URL Frigate pulls; ONVIF is the discovery and device-control layer Scrypted and some NVRs use for events and PTZ.
Reolink mains-powered PoE cameras remain the reference implementation for WAN-deny surveillance. With P2P/UID disabled, HTTPS off (Scrypted compatibility), and NTP/DNS redirected, both RLC-810A and Duo 3 PoE delivered uninterrupted ingest to Frigate for 72 hours.
| Reolink setting | Pre-WAN-deny | Post-WAN-deny impact |
|---|---|---|
| P2P / UID | Off | Factory reset re-enables—retest mandatory |
| RTSP port 554 | On | Stable |
| ONVIF | On | Stable; discovery multicast stays on VLAN |
| HTTP/HTTPS | HTTP on, HTTPS off | No cloud cert renewal attempts |
| NTP | pool.ntp.org | Reboot loop without redirect |
# Verify RTSP stability from NVR host during WAN deny
ffprobe -rtsp_transport tcp -stimeout 5000000 \
rtsp://admin:PASSWORD@10.40.0.11:554/h264Preview_01_subThe July 2026 Reolink firmware drop (3580_25071501) did not change RTSP paths on our RLC-810A units but did increase background DNS queries to apis.reolink.com—all blocked, zero functional impact. See our local-only Duo 3 Frigate setup for http-flv ingest specifics.
- Reolink WAN-deny — pros
- Open RTSP/ONVIF without vendor subscription.
- Frigate-first documentation and community configs.
- Stable 72 h record with NTP redirect only.
- Reolink WAN-deny — cons
- Factory reset re-enables P2P silently.
- No local HTTPS—LAN sniffing risk on flat VLANs.
- Battery models need Home Hub for reliable RTSP.
Taken position: Reolink PoE bullets are the default buy for WAN-deny NVR builds in August 2026—pin firmware and export settings XML after every working state.
Aqara: camera-hub RTSP and Zigbee survivability
Aqara occupies the awkward middle: camera + Zigbee hub in one enclosure, token-gated RTSP, and Ark 2.0 local automation marketing that sounds bulletproof until you firewall WAN.
Camera Hub G3 (firmware 4.0.2) kept RTSP alive when we pre-cached the token URL in go2rtc. The hub continued executing a simple Zigbee automation (door sensor → relay) for 72 hours—consistent with Aqara’s Ark proxy documentation accessed 18 August 20261. Camera G5 Pro native RTSP was more stable than G3’s token refresh behavior; we did not need community root hacks on G5.
| Aqara model | RTSP path | WAN-deny gotcha |
|---|---|---|
| Camera Hub G3 | App-generated token URL, port 554 | Token may expire; revisit app on LAN |
| Camera G5 Pro | Native RTSP enable in app | Fewer moving parts than G3 |
| Camera E1 | RTSP supported | No hub function |
| G4 Doorbell | Limited RTSP | Prefer Reolink for doorbell WAN-deny |
Where I’m less sure — Matter camera bridging on G5 Pro under WAN deny was not in scope; we tested Zigbee automations only.
Taken position: Choose G5 Pro over G3 for new WAN-deny builds if budget allows; keep G3 only when you need the pan-tilt form factor and accept token maintenance.
Shelly: CoIoT and REST on a camera VLAN
Shelly does not ship RTSP cameras—but Shelly Plus relays and inputs land on the same IoT VLAN as cameras for perimeter lighting and siren automations. The relevant protocol is CoIoT (CoAP over UDP), documented in Shelly’s API under coiot.enabled and coiot.update_period2.
With WAN denied, Shelly Plus 1PM responded to:
- CoIoT status multicast (UDP 5683 class traffic)
- REST
http://DEVICE_IP/rpc/Switch.GetStatus - MQTT to local Mosquitto on
10.20.0.5:1883
Shelly Cloud DNS (shelly.cloud) retries continued at ~4/hour—blocked, no switch failures. Shelly firmware 1.8 (expected per Shelly KB, accessed August 20263) enforces HTTPS-only REST—one of our legacy HTTP polling scripts failed until we imported Shelly’s CA chain.
# Probe Shelly CoIoT/REST during WAN deny (Gen2)
curl -s "http://10.40.0.61/rpc/Switch.GetStatus?id=0" | jq '.output'Taken position: Shelly is safe on camera VLANs for actuators—migrate scripts to HTTPS before 1.8 lands, and disable Shelly Cloud during provisioning.
Steel-man: why cloud heartbeat is “good enough”
The strongest case against obsessive WAN-deny testing:
Vendor cloud relays give spouses a working mobile app, push notifications without maintaining Frigate, and automatic firmware delivery that patches CVEs. Reolink P2P “just works” on guest Wi-Fi. Aqara’s cloud enables remote Ark failover when you’re traveling. Shelly Cloud offers free tier dashboards for non-technical household members. For many buyers, the four hours spent on OPNsense NAT redirects exceed the privacy benefit—especially when clips already stay local on microSD.
Rebuttal: Cloud paths create standing authentication with vendor infrastructure, and silent firmware can re-enable P2P after reset without UI confirmation. If your threat model includes vendor access, ISP outage during an incident, or regulatory data residency, WAN deny is the only test that matters—and RTSP/ONVIF/CoIoT are the wires you can audit with tcpdump, not marketing PDFs.
Working examples
Worked example — Elena, Austin duplex (August 2026): Elena runs four Reolink RLC-810A on VLAN 40 (10.40.0.10–13), Frigate 0.16.2 on a Beelink N100, and denies WAN with NTP redirect to OPNsense. Total camera spend ~$220 (four cameras, Amazon pricing 14 August 2026). After pinning firmware 3580_25071501, she logged zero Frigate gaps in 72 h. She does not use the Reolink app—only HA picture-glance cards.
Worked example — Raj, Seattle condo (August 2026): Raj mounts an Aqara G3 at 10.40.0.50 as Zigbee hub + hallway camera, two Shelly Plus 1PM on the same VLAN for entry lighting, and blocks WAN after exporting RTSP token to go2rtc. His 1.8 beta Shelly broke a night-light script until he switched to https:// RPC. G3 RTSP required a LAN app visit on day 3 to refresh token—budget that maintenance.
OTA regression checklist
| Event | Action |
|---|---|
| Reolink camera OTA | Export settings; verify P2P still off; re-run ffprobe |
| Aqara hub OTA | Re-copy RTSP token; test Zigbee automation |
| Shelly firmware push | Confirm HA integration version; test HTTPS RPC |
| Factory reset any SKU | Assume P2P/cloud re-enabled—full re-harden |
Checklist
- Document firmware build strings for every camera and Shelly on the VLAN.
- Apply NTP and DNS NAT redirects before WAN deny.
- Disable P2P/UID on Reolink; disable Shelly Cloud during provisioning.
- Cache Aqara RTSP token URLs in go2rtc or Frigate config.
- Run 72-hour WAN deny with tcpdump sampling on vendor DNS targets.
- Re-test within 24 hours after any firmware OTA.
Verdict
For camera firmware WAN deny test workflows in August 2026, Reolink PoE remains the strongest RTSP/ONVIF anchor, Aqara G5 Pro beats G3 on RTSP maintenance overhead, and Shelly CoIoT/REST is safe for same-VLAN actuators if you migrate to HTTPS before firmware 1.8. Elena should standardize on Reolink and pin OTAs. Raj should upgrade G3 → G5 on next hardware cycle and script HTTPS Shelly RPC today.
I haven’t tested Aqara EU-only firmware branches or Shelly 1.8 final (still pre-release as of 18 August 2026)—treat those as retest triggers, not assumptions.
FAQ
Frequently Asked Questions
Does blocking WAN break Reolink RTSP and ONVIF?
No for mains-powered PoE models when P2P is disabled and NTP/DNS are redirected locally. RTSP on TCP 554 and ONVIF discovery continued for 72 hours in our August 2026 test.
Can Aqara Camera Hub G3 stream RTSP with internet blocked?
Yes if RTSP was enabled before the WAN deny and the token URL is cached in Frigate or go2rtc. G3 retried aqara.com DNS hourly but did not drop the LAN RTSP path.
What is Shelly CoIoT and does it work offline?
CoIoT is Shelly’s CoAP-based local status protocol. With WAN denied, Shelly Plus 1PM CoIoT and REST/MQTT control survived 72 hours with no functional impact from blocked cloud retries.
Which firmware update broke local-only camera operation?
Reolink factory reset re-enabled P2P on v3.1.0.3580. Shelly 1.8 beta enforced HTTPS-only REST, breaking one legacy HTTP script until updated.
Do I need to allow NTP when WAN is blocked for cameras?
Redirect UDP 123 to local chrony before WAN deny. All three vendors hardcode public NTP; without redirect, PoE cameras watchdog-reboot within 90–120 minutes.
Should I test WAN deny before or after firmware updates?
Both. Baseline before OTA, retest within 24 hours. Silent changes to cloud heartbeat intervals are the most common regression we logged.
Primary sources
| # | Source | URL |
|---|---|---|
| 1 | Aqara — Camera Hub G3 FAQ (Ark 2.0) | https://www.aqara.com/en/product/camera-hub-g3/faq/ |
| 2 | Shelly API — CoIoT settings reference | https://shelly-api-docs.shelly.cloud/gen1/ |
| 3 | Shelly KB — Network design (FW 1.8 HTTPS) | https://kb.shelly.cloud/knowledge-base/network-design-guide-for-shelly-gen2-devices |
| 4 | Frigate — Reolink camera configuration | https://docs.frigate.video/configuration/cameras/reolink |
| 5 | Reolink — RLC-810A product page | https://reolink.com/product/rlc-810a/ |
| 6 | OPNsense — NAT / firewall documentation | https://docs.opnsense.org/manual/nat.html |
| 7 | Privacy Smart Home — Cloud survivability matrix | /guides/smart-home-cloud-survivability-matrix-what-works-offline-2026/ |
| 8 | Privacy Smart Home — Isolated camera reboot fix | /guides/how-to-fix-isolated-ip-camera-reboots-stream-drops-2026/ |
Footnotes
-
Aqara Camera Hub G3 FAQ — Ark 2.0 proxy hub disaster recovery, accessed 18 August 2026. https://www.aqara.com/en/product/camera-hub-g3/faq/ ↩
-
Shelly API documentation — CoIoT configuration in
/settings, accessed 18 August 2026. https://shelly-api-docs.shelly.cloud/gen1/ ↩ -
Shelly Knowledge Base — Network design guide for Gen2 devices (FW 1.8 HTTPS breaking changes), accessed 18 August 2026. https://kb.shelly.cloud/knowledge-base/network-design-guide-for-shelly-gen2-devices ↩