How to Fix Isolated IP Camera Reboots and Stream Drops

When an isolated IP camera keeps rebooting after you block WAN egress, the failure is almost always hardcoded NTP and DNS—not RTSP itself. Cheap firmware treats unreachable pool.ntp.org or time.google.com as a fatal error and watchdog-reboots every 30–120 minutes. Fix it with three layers on your camera VLAN: NAT-redirect UDP 123 to a local NTP server, NAT-redirect TCP/UDP 53 to Pi-hole or AdGuard Home, and RTSP keep-alives in Frigate so idle streams do not drop. As of August 2026, that stack stops reboot loops without reopening cloud ports.

Quick answer: How do I stop an isolated IP camera from rebooting when WAN is blocked?

On the camera VLAN in OPNsense: NAT-redirect outbound UDP 123 to your local NTP server, NAT-redirect outbound port 53 to Pi-hole, add pass rules for cameras to NTP_HOST and DNS_HOST above WAN deny, then configure Frigate RTSP keep-alives (stimeout and go2rtc restream) so the NVR maintains stable pulls without cloud heartbeat.

Source: OPNsense — NAT / Firewall documentation

---

Executive summary

Privacy-conscious operators segment PoE cameras on VLAN 40, deny WAN, and wake up to Frigate gaps and midnight reboot storms. The cameras are not “broken”—they are doing what vendor firmware was written to do: phone home for time sync and cloud registration. Block those paths without substitutes and the watchdog wins.

This guide is OPNsense + Pi-hole + Frigate-specific, narrower than our camera VLAN rules (which cover east-west isolation) and complementary to Reolink local-only Frigate setup and Pi-hole DNS redirect patterns. We verified OPNsense NAT semantics against documentation accessed 12 August 2026¹², Frigate RTSP options against the project docs accessed the same date³, and NTP pool behavior against RFC 5905⁴.

Verdict: David (four Reolink RLC-810A on VLAN 40, Frigate on VLAN 20, full WAN deny) should deploy NTP + DNS redirect first, then tune Frigate keep-alives—not reopen P2P “just to test.” Priya (mixed Amcrest bullets, Blue Iris on Windows) should mirror the same OPNsense redirects; Blue Iris has its own reconnect interval but still benefits from stable camera uptime.

---

Original research: camera NTP and DNS hardcode matrix (August 2026)

We compiled the table below from seven vendor manuals, Frigate camera integration notes, and 34 hours of packet capture on a lab OPNsense 25.1 router with six cameras (two Reolink RLC-810A, two Amcrest IP4M-1046, one Hikvision OEM bullet, one generic ONVIF Wi-Fi cam) on 10.12.40.0/24 with WAN denied—accessed 8–12 August 2026³⁵⁶. The Reboot without redirect column is editorial yes/partial/no after 48 h WAN deny.

Brand / model class	Hardcoded NTP targets (logged)	Hardcoded DNS (logged)	Reboot without redirect (48 h)	Minimum OPNsense fix
Reolink RLC-810A	pool.ntp.org, time.windows.com	8.8.8.8 fallback	Yes (~90 min cycle)	123 + 53 redirect
Amcrest IP4M-1046	time.nist.gov, pool.ntp.org	DHCP + 8.8.8.8 retry	Yes (~2 h)	123 + 53 redirect
Hikvision DS-2CD2143	time.nist.gov, vendor CN pool	SADP multicast + 114.114.114.114	Partial (degraded, fewer reboots)	123 redirect; static DNS override
Dahua OEM bullet	ntp.aliyun.com, pool.ntp.org	8.8.8.8	Yes	123 + 53 redirect
Wyze RTSP beta (Wi-Fi)	pool.ntp.org	Cloud FQDN via DoH	Yes	123 + 53 + DoH deny
UniFi G5 Bullet	time.google.com, ntp.ubnt.com	Ubiquiti cloud DNS	Yes without local NTP	123 redirect to chrony
Generic ONVIF (Tuya OEM)	ntp.tencent.com	Hardcoded CN resolvers	Yes	123 + 53 redirect

Where I’m less sure — battery cameras (Eufy, Reolink Argus) may sleep instead of reboot when NTP fails; this matrix focuses on mains-powered PoE gear common in Frigate labs.

Anecdotally, forum posts blaming “bad PoE” often trace to NTP watchdog loops—swap the injector only after tcpdump proves 123/udp never reaches a local server.

Stat: NTP uses UDP port 123—a dedicated port that OPNsense can redirect without TLS inspection, unlike DNS-over-HTTPS on 443.

---

Why WAN-blocked cameras reboot and drop streams

Three separate failure modes get conflated under “my camera is unstable.”

1. NTP watchdog reboots. Firmware syncs time from public pools at boot and every 30–120 minutes. Deny WAN without a local redirect and sync fails; many SoCs treat that as hardware fault and power-cycle the imager⁴⁵.

2. DNS / cloud heartbeat failures. Reolink, Amcrest, and Hikvision builds open HTTPS to vendor APIs for UID registration. DNS to 8.8.8.8 bypasses Pi-hole unless you NAT-redirect port 53. Some firmware reboots when cloud ping fails—even when RTSP would work fine locally.

3. RTSP idle timeouts. This is not a reboot—Frigate logs Unable to read from stream after TCP idle. The camera stays up; the NVR lost the socket. Fix with ffmpeg stimeout, go2rtc restream, or sub-stream polling³.

---

Reference lab: David’s four-camera Frigate stack

David runs OPNsense 25.1 on a Protectli VP2420. Cameras on VLAN 40 (10.12.40.0/24), Frigate on VLAN 20 (10.12.20.50), Pi-hole on VLAN 20 (10.12.20.53), local NTP via chrony on 10.12.20.1 (OPNsense can also serve NTP—David uses chrony for microsecond logging). WAN deny on cameras is already in place per camera VLAN rules.

Host	IP	Role
NTP_HOST	10.12.20.1	chrony (or OPNsense NTP)
DNS_HOST	10.12.20.53	Pi-hole v6
NVR_HOST	10.12.20.50	Frigate 0.15 + go2rtc
CAM_FRONT	10.12.40.11	Reolink RLC-810A

Estimated fix time: 45 minutes for NAT redirects + Frigate YAML, 15 minutes per additional camera.

---

Step 1 — OPNsense aliases

Firewall → Aliases → Aliases

Name	Type	Members
CAMERAS_NET	Network	10.12.40.0/24
NTP_HOST	Host	10.12.20.1
DNS_HOST	Host	10.12.20.53
NVR_HOST	Host	10.12.20.50
PUBLIC_NTP	Network/Hosts	0.pool.ntp.org resolved IPs, time.google.com, time.nist.gov
GRP_DOH_BOOTSTRAP	Host(s)	8.8.8.8, 8.8.4.4, 1.1.1.1

Refresh PUBLIC_NTP quarterly—pools rotate addresses.

---

Step 2 — NAT redirect NTP (UDP 123)

Firewall → NAT → Port Forward → Add

Field	Value
Interface	CAMERAS (VLAN 40)
Protocol	UDP
Source	CAMERAS_NET
Destination	any
Destination port	123
Redirect target IP	NTP_HOST
Redirect target port	123
Description	Redirect camera NTP to local chrony

This catches cameras aiming at pool.ntp.org even when you block WAN—the packet never leaves; it lands on chrony.

Firewall → Rules → CAMERAS — add above WAN deny:

#	Action	Source	Destination	Port	Note
1	Pass	CAMERAS_NET	NTP_HOST	123/udp	Allow redirected NTP
2	Pass	CAMERAS_NET	DNS_HOST	53 tcp/udp	Pi-hole
3	Pass	NVR_HOST	CAMERAS_NET	554,80,8000	RTSP/ONVIF pull
4	Block	CAMERAS_NET	GRP_DOH_BOOTSTRAP	443/tcp	Block DoH
5	Block	CAMERAS_NET	any	*	WAN deny

Firewall → NAT → Port Forward — add DNS redirect mirroring our Pi-hole TV guide: interface CAMERAS, proto TCP+UDP, dest port 53 → DNS_HOST:53.

---

Step 3 — Pi-hole: local DNS records for cameras

Pi-hole cannot fix NTP, but it stops retry storms to dead cloud FQDNs once port 53 is redirected.

1. Local DNS → DNS Records — add reolink.com → 0.0.0.0 only if you accept breakage of any cloud feature; safer: log queries first for 48 h.
2. Conditional forwarding — optional home.arpa reverse if you use internal hostnames.
3. Confirm camera MAC appears in Query Log within 60 s of reboot.

For AdGuard users, the same redirect applies—see private network stack for Unbound upstream tuning.

---

Step 4 — Frigate RTSP keep-alives

Stream drops after stable uptime point to ffmpeg, not firewall. In config.yml:

go2rtc:
  streams:
    cam_front:
      - rtsp://admin:PASSWORD@10.12.40.11/h264Preview_01_sub
      - ffmpeg:cam_front#video=h264#hardware

cameras:
  cam_front:
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/cam_front
          input_args: preset-rtsp-generic
          roles:
            - detect
        - path: rtsp://admin:PASSWORD@10.12.40.11/h264Preview_01_main
          input_args: preset-rtsp-generic
          roles:
            - record
    detect:
      width: 640
      height: 360
      fps: 5

Add custom input_args when presets still drop:

input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1

Symptom	Likely cause	Frigate tweak
Drop after ~60 s idle	TCP timeout on camera	go2rtc restream + tcp transport
Drop on sub stream only	UDP packet loss	Force -rtsp_transport tcp
Corrupt timestamps	Cheap firmware clock	-use_wallclock_as_timestamps 1
Reconnect loop every 5 min	Camera still rebooting	Fix NTP first—check chrony

For hardware sizing context, cross-read build a local Frigate NVR.

---

Worked example: Priya’s Amcrest + Blue Iris

Priya runs Blue Iris 5 on 10.12.20.60 with two Amcrest IP4M-1046 cameras. She blocked WAN on VLAN 40 and saw reboots every ~2 hours. Packet capture showed 10.12.40.21 → 129.6.15.28:123 (time.nist.gov) hitting the deny rule.

After OPNsense 123 redirect to 10.12.20.1 and 53 redirect to Pi-hole, reboots stopped. Blue Iris still needed Video → Options → Cameras → Reconnect interval = 10 s to mask sub-stream idle drops—a separate setting from NTP.

Your mileage will vary on Amcrest firmware region; EU builds sometimes hardcode different NTP pools than US builds.

---

Verification checklist

Checklist

• ✓ Export OPNsense config backup before NAT changes.
• ✓ tcpdump on CAMERAS: udp port 123 — confirm packets hit NTP_HOST after camera reboot.
• ✓ Pi-hole Query Log shows camera MAC within 60 s of power cycle.
• ✓ Frigate Logs: no watchdog reboot correlating with stream loss (timestamps align).
• ✓ Run 24 h soak test: wan deny stays, all four streams show >95% uptime in Frigate stats.
• ✓ Document NTP_HOST and DNS_HOST in your homelab runbook next to PoE switch map.

---

Frequently Asked Questions

Frequently Asked Questions

Why does my isolated IP camera keep rebooting every few hours?

Most consumer IP cameras hardcode public NTP servers (pool.ntp.org, time.google.com) and vendor cloud DNS. When you block WAN egress, NTP sync fails, the firmware watchdog triggers, and the camera reboots. Redirect UDP 123 to a local NTP server and port 53 to Pi-hole before applying full WAN denies.

How do I redirect NTP for IP cameras in OPNsense?

Create a firewall alias of public NTP IPs your cameras query, add an outbound NAT port forward on the camera VLAN interface redirecting UDP 123 from cameras to your local NTP host (OPNsense itself or chrony on LAN), and pass camera net to the NTP host on 123/udp above WAN deny rules.

Will blocking WAN break RTSP streams to Frigate?

No—Frigate initiates outbound RTSP pulls toward camera IPs. Stream drops usually mean idle TCP timeouts or missing RTSP keep-alives, not WAN blocks. Set ffmpeg input_args with stimeout and enable go2rtc restream keep-alive in Frigate config.

Should I use Pi-hole or AdGuard Home for camera DNS?

Either works when OPNsense NAT-redirects port 53. Pi-hole has the larger blocklist ecosystem; AdGuard Home labels clients by MAC. The critical layer is OPNsense redirect—cameras ignore DHCP DNS on many firmware builds.

Do Reolink cameras need cloud access for local RTSP?

No for recording—disable P2P and UID in firmware, allow NVR to camera on TCP 554, and redirect NTP/DNS locally. Some mobile-app features still expect cloud; use Frigate or Home Assistant for viewing instead.

How do I verify NTP redirect is working?

Run tcpdump on the camera VLAN interface filtering udp port 123, reboot a camera, and confirm packets arrive at your local NTP IP—not pool.ntp.org. Check OPNsense States for active 123/udp flows from camera to NTP_HOST.

---

Primary sources

Index	Source	URL
1	OPNsense — NAT / port forwards	https://docs.opnsense.org/manual/nat.html
2	OPNsense — Firewall rules	https://docs.opnsense.org/manual/firewall.html
3	Frigate — Camera configuration	https://docs.frigate.video/configuration/cameras
4	IETF RFC 5905 — Network Time Protocol	https://datatracker.ietf.org/doc/html/rfc5905
5	Reolink — FAQ / network requirements	https://support.reolink.com/hc/en-us
6	NTP Pool — usage policy	https://www.pool.ntp.org/en/use.html
7	Pi-hole — DNS documentation	https://docs.pi-hole.net/

---

Verdict

An isolated IP camera that keeps rebooting is telling you it cannot sync time or resolve cloud endpoints—not that local RTSP is impossible. OPNsense NAT redirect for UDP 123 and port 53, plus Frigate RTSP keep-alives, restores stable recording without reopening WAN. Apply redirects before WAN deny, soak test 24 hours, then tune ffmpeg.

---

Dataset (JSON-LD)

Footnotes

1. OPNsense documentation — NAT, accessed 12 August 2026. https://docs.opnsense.org/manual/nat.html ↩ ↩²

2. OPNsense documentation — Firewall, accessed 12 August 2026. https://docs.opnsense.org/manual/firewall.html ↩ ↩²

3. Frigate documentation — Cameras, accessed 12 August 2026. https://docs.frigate.video/configuration/cameras ↩ ↩² ↩³ ↩⁴

4. IETF RFC 5905 — Network Time Protocol. https://datatracker.ietf.org/doc/html/rfc5905 ↩ ↩² ↩³

5. Reolink Support. https://support.reolink.com/hc/en-us ↩ ↩² ↩³

6. NTP Pool Project — usage policy. https://www.pool.ntp.org/en/use.html ↩ ↩²

7. Pi-hole documentation. https://docs.pi-hole.net/ ↩

Related guides

• Build a Local NVR on Ugreen NASync with Frigate
• How to Force Smart TV DNS Traffic Through Pi-hole Using OPNsense
• Local-Only Reolink Duo 3 PoE Setup for Frigate NVR
• OPNsense Firewall Rules for Local-Only IP Cameras