OPNsense Home Setup

My network runs modem to OPNsense to a Cisco 2960G. The OPNsense box is a repurposed Dell thin client, and I 3D-printed a bracket so it mounts under the desk, completely out of the way. The interesting part isn’t the hardware though. It’s what the firewall does to the cheap cameras.

The problem with cheap cameras

The security cameras are inexpensive Amazon models, and by default they try to phone home to servers in China every 15 seconds. Watch your firewall logs with one of these on an open network and you’ll see constant outbound connection attempts: cloud registration, NTP to vendor servers, UDP heartbeats to IP ranges you never asked for. I wanted the video and none of the rest.

VLAN isolation first

The cameras live on their own VLAN so they can’t even see the rest of the house. In OPNsense that’s three steps: create the VLAN under Interfaces, Other Types, VLAN with the LAN port as the parent, assign it as a new interface, then give it its own subnet and DHCP scope. The switch port each camera plugs into gets set as an access port on that VLAN:

interface GigabitEthernet0/12
 description CAMERA-01
 switchport mode access
 switchport access vlan 30
 spanning-tree portfast

Firewall rules that actually enforce it

VLANs alone don’t isolate anything. Inter-VLAN traffic goes through OPNsense, so the rules on the camera interface are where the policy lives. Mine boil down to four rules, in order, and the order matters because OPNsense processes first match wins:

1. ALLOW  src: CAMERA_NET  dst: SECURITY_SERVER  port: RTSP/554 + camera web port
2. ALLOW  src: CAMERA_NET  dst: firewall self    port: NTP/123 (cameras need time)
3. BLOCK  src: CAMERA_NET  dst: any RFC1918      (no touching other internal nets)
4. BLOCK  src: CAMERA_NET  dst: any              log enabled

Rule 4 is the phone-home killer, and turning logging on for it was the best decision in the whole setup. The logs show you exactly how chatty these devices are, and if a camera ever starts trying something new, you see it. The security server pulls the RTSP streams from its side, so live view and recording work fine even though the cameras themselves can’t reach the internet at all.

Two caveats from running this for a while. First, give the cameras an NTP answer, either from the firewall or by redirecting their NTP requests with a port forward, because some models get weird when their clock drifts. Second, if you ever need to update camera firmware, you do it deliberately: temporarily allow that one camera out, update, then close the door again. That’s a feature, not a hassle. Firmware updates on devices like these should be a decision, not something that happens to you at 3am.

It’s simple, it works exactly how I want, and random IoT devices don’t get to decide what my network does.