[
  {
    "slug": "camera-vlan-not-working-troubleshooting",
    "title": "Camera VLAN Not Working: Fix NVR, RTSP, DNS, and Firewall Issues",
    "description": "Diagnose camera VLAN failures when streams, NVR access, NTP, DNS, firewall rules, or isolated mobile viewing stop working.",
    "pubDate": "2026-06-27T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "network-hardening",
      "security-cameras",
      "local-first",
      "local-first-storage"
    ],
    "image": "/_astro/camera-vlan-not-working-troubleshooting.D8wJxOEI.jpeg",
    "coverImage": {
      "src": "/_astro/camera-vlan-not-working-troubleshooting.D8wJxOEI.jpeg",
      "width": 1376,
      "height": 768,
      "format": "jpg"
    },
    "body": "A camera VLAN usually does not fail all at once. It gets an address, then the NVR cannot record. RTSP comes up, but the web UI does not. Recording works, but the timestamps are off. The vendor app only behaves when the camera can reach the internet. That pattern is annoying, but it is also useful: these problems usually come from a small set of design mistakes, not from some mysterious VLAN curse.\n\nThe useful way to troubleshoot this is to separate Layer 2, IP addressing, routing, firewall policy, and application behavior. If you change everything at once, you will not know whether you fixed the VLAN, weakened the isolation, or quietly let the cloud path back in.\n\n## Troubleshooting Map\n\nUse this map before changing rules. The camera VLAN should have a clear expected path: camera ports enter VLAN `30`, cameras receive `10.30.0.0/24` addresses, the NVR reaches cameras on the ports it actually uses, cameras use local time services, and cameras cannot initiate WAN or main LAN traffic.\n\n## Symptom: The Camera Gets No IP Address\n\nThe most likely cause is a switch port or SSID VLAN assignment problem. A wired camera normally expects an untagged access port. If the port is configured as a tagged trunk, the camera may send untagged DHCP requests into the wrong network or just never reach DHCP in the first place.\n\nRanked causes:\n\n1. Camera port is tagged instead of untagged/access for the camera VLAN.\n2. Switch uplink does not carry the camera VLAN.\n3. DHCP is not enabled for the camera subnet.\n4. Camera still has an old static IP from a previous network.\n5. The camera is connected through an unmanaged switch in a way that strips or mixes VLAN expectations.\n\nDiagnostics:\n\n- Check the switch port profile for the physical camera port.\n- Check the uplink between switch and router.\n- Look at the DHCP lease table for the camera MAC address.\n- Temporarily connect one known-good camera directly to a known-good access port.\n- If the camera had a static IP, factory reset or temporarily place a laptop in the old subnet to recover it.\n\nFix:\n\nSet the camera-facing port as an access port for the camera VLAN. Make sure the switch uplink carries that VLAN back to the router. Confirm the DHCP scope exists for the camera subnet, then create a DHCP reservation once the camera appears. This is one of those cases where being precise is easier than being clever.\n\n## Symptom: The Camera Has an IP, but the NVR Cannot See It\n\nThis is the classic forum-thread failure: the VLAN exists, DHCP works, isolation was applied, and then recording dies. Usually the firewall is blocking the NVR from initiating connections into the camera VLAN.\n\nRanked causes:\n\n1. No allow rule from NVR IP to camera subnet.\n2. Rule exists but is below a broader inter-VLAN deny rule.\n3. NVR is using the old camera IP address.\n4. Camera stream port differs from the assumed RTSP port.\n5. Camera web UI works, but RTSP credentials or path changed.\n\nDiagnostics:\n\n- From the NVR host, test whether the camera IP responds.\n- Test the camera web UI from the NVR network if allowed.\n- Test the RTSP URL from the NVR host with the same credentials the recorder uses.\n- Check firewall logs for blocks from NVR IP to camera IP.\n- Confirm the camera reservation matches the NVR configuration.\n\nFix:\n\nCreate a narrow allow rule from the NVR IP to the camera subnet on the ports the recorder uses. Keep the rule directional. The NVR reaches cameras; cameras do not get broad permission to initiate traffic back into the NVR network.\n\n## Symptom: RTSP Works, but the Camera Web UI Does Not\n\nThis usually means your NVR exception is working for video but not for management. That may be intentional. RTSP recording does not require the camera admin page to be reachable from every laptop in the house.\n\nRanked causes:\n\n1. Firewall allows RTSP but blocks HTTP or HTTPS.\n2. The camera uses a non-standard management port.\n3. Admin access is attempted from a workstation that has no rule into the camera VLAN.\n4. Browser access depends on a plugin, redirect, or HTTPS certificate behavior.\n\nDiagnostics:\n\n- Test from the NVR host and from the admin workstation separately.\n- Confirm the camera's management port.\n- Check whether HTTP redirects to HTTPS or another port.\n- Look at firewall logs for workstation-to-camera attempts.\n\nFix:\n\nIf admin access is needed, create a temporary or narrow rule from a trusted admin workstation to the camera subnet on management ports. Do not use that as an excuse to open the whole main LAN into the camera VLAN permanently.\n\n## Symptom: Recording Works, but Timestamps Are Wrong\n\nThis is usually an NTP problem. Cameras can keep streaming while their internal clocks drift, reset, or sit in the wrong timezone. That makes footage much harder to correlate with door locks, motion events, alarms, and router logs.\n\nRanked causes:\n\n1. Camera was previously using public NTP, and WAN is now blocked.\n2. Camera cannot reach local NTP.\n3. Camera timezone is wrong even though NTP time is correct.\n4. Camera firmware expects DNS resolution before attempting NTP.\n\nDiagnostics:\n\n- Check camera time after a reboot.\n- Check firewall logs for blocked UDP `123`.\n- Point one test camera to the router or local server as NTP.\n- Compare NVR event time, camera overlay time, and system log time.\n\nFix:\n\nProvide local NTP and allow the camera VLAN to reach it. If cameras require a hostname instead of an IP address, resolve that hostname locally or configure a local DNS record. Reopening full WAN just to fix timestamps is the kind of shortcut that comes back later.\n\n## Symptom: The Vendor App Stopped Working\n\nThis is not always a bug. If the app depends on vendor cloud relays, push services, or outbound camera sessions, blocking WAN from the camera VLAN will break it. In a local-first setup, that is often the point of the isolation.\n\nRanked causes:\n\n1. Camera cannot reach vendor cloud endpoints.\n2. Phone app expects cloud relay instead of local NVR access.\n3. DNS is blocked, so the app setup flow cannot resolve vendor services.\n4. UPnP or automatic port mapping no longer works.\n\nDiagnostics:\n\n- Check whether local NVR viewing still works.\n- Check DNS logs for vendor domain lookups.\n- Check firewall logs for blocked camera-to-WAN traffic.\n- Test from the local network versus cellular.\n\nFix:\n\nChoose the architecture. The community workaround is to let the camera have internet access until the app works. The local-first fix is to stop depending on the camera vendor app for critical viewing and route remote access through a controlled VPN, NVR interface, or home automation dashboard. If you intentionally need vendor cloud features, document that exception and limit it as much as the platform allows.\n\n## Community Workaround vs Correct Fix\n\nThe common workaround is broad: allow the camera VLAN to the internet, allow the main LAN to the camera VLAN, and call the VLAN \"isolated\" because the cameras have a different subnet. That usually makes apps and NVRs work quickly, but it keeps the risky parts of the original flat network intact.\n\nThe correct fix is slower but cleaner: identify the path that failed, then allow only that path. If the NVR cannot record, allow NVR-to-camera RTSP. If time is wrong, allow camera-to-local-NTP. If admin access is needed, allow one workstation temporarily. If the vendor app requires cloud, decide whether that feature is worth weakening the design.\n\nA practical example: a camera at `10.30.0.22` records fine from the NVR at `10.10.0.50`, but the timestamp resets after every power outage. Opening internet access would probably hide the issue. The better fix is local NTP: allow `10.30.0.0/24` to reach `10.30.0.1` on UDP `123`, then point cameras at the router or local time server.\n\n## Symptom: Home Assistant Events Stopped Working\n\nHome Assistant integrations often break when the VLAN changes because they were previously talking directly to cameras on the flat LAN. After isolation, discovery, event callbacks, or snapshot URLs may stop crossing the firewall.\n\nRanked causes:\n\n1. Home Assistant has no rule to reach the camera VLAN.\n2. The integration was using old camera IPs.\n3. Discovery does not cross VLANs.\n4. Events should be coming from the NVR, not directly from cameras.\n\nDiagnostics:\n\n- Check whether Home Assistant talks to cameras directly or through the NVR.\n- Replace hostnames with reserved IPs during testing.\n- Check firewall logs from the Home Assistant IP to camera IPs.\n- Confirm the NVR integration still receives events.\n\nFix:\n\nPrefer integrating Home Assistant with the NVR when possible. That keeps cameras contained and makes the recorder the trusted event source. If direct camera access is required, allow Home Assistant's IP to reach only the camera ports that integration actually needs.\n\n## Verification Checklist\n\nAfter fixing one issue, confirm you did not undo the isolation.\n\n- [ ] Cameras receive addresses in the camera subnet.\n- [ ] Camera switch ports are access ports for the camera VLAN.\n- [ ] The switch uplink carries the camera VLAN.\n- [ ] The NVR can record every camera stream.\n- [ ] Cameras cannot initiate WAN traffic.\n- [ ] Cameras cannot initiate traffic to the main LAN.\n- [ ] Local NTP keeps timestamps correct after reboot.\n- [ ] DNS behavior is understood and not accidentally broad.\n- [ ] Admin access exists only from approved devices or temporary rules.\n- [ ] Home Assistant works through the NVR or a narrow direct exception.\n\nIf the fix required a broad allow rule, treat that as a temporary diagnostic step, not the end state. The final state should be narrower than the troubleshooting state."
  },
  {
    "slug": "isolate-ip-cameras-on-a-vlan",
    "title": "How to Isolate IP Cameras on a VLAN Without Breaking Local Recording",
    "description": "Learn the mental model for isolating IP cameras on a VLAN while keeping local NVR recording, NTP, DNS, and admin access predictable.",
    "pubDate": "2026-06-27T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "network-hardening",
      "security-cameras",
      "local-first",
      "home-automation"
    ],
    "image": "/_astro/isolate-ip-cameras-on-a-vlan.fzC3t04T.jpeg",
    "coverImage": {
      "src": "/_astro/isolate-ip-cameras-on-a-vlan.fzC3t04T.jpeg",
      "width": 1376,
      "height": 768,
      "format": "jpg"
    },
    "body": "An IP camera should be treated like an untrusted network appliance, not like a laptop. It has firmware you do not fully control, cloud features you may not need, and a service life where updates tend to get irregular. If that camera sits on the same flat network as phones, laptops, smart locks, NAS storage, and home automation, a small camera compromise can become a much larger home network problem.\n\nThe goal of a camera VLAN is not just to create a separate Wi-Fi name or make the topology look neat. The goal is to make camera traffic local, restricted, and understandable. Cameras should record to a local NVR. The NVR should have the access it needs. The cameras should not be able to wander across the rest of the LAN or phone home to vendor services unless you decide that trade-off is worth it.\n\n## The Isolation Architecture\n\nA clean local-first camera design has three basic zones: the main LAN, the camera VLAN, and the recording system. The camera VLAN contains only camera devices. The NVR, NAS, or security server is the controlled bridge into that zone. Normal user devices do not need broad access to camera admin panels, and the cameras do not need broad access back into the main LAN.\n\nIn a representative setup, the camera VLAN might be VLAN 30 with subnet `10.30.0.0/24`. Cameras receive addresses such as `10.30.0.21`, `10.30.0.22`, and `10.30.0.23`. The NVR might live at `10.10.0.50` on a server VLAN or main infrastructure VLAN. Firewall policy allows the NVR to pull RTSP streams from cameras, but blocks camera-originated traffic to the internet and to personal devices.\n\n## Should IP Cameras Be on a Separate Network?\n\nYes, if the separate network comes with firewall rules. A separate subnet without policy is mostly organization. A camera VLAN becomes useful when it changes what the cameras are allowed to reach.\n\nThe normal consumer setup is backwards: cameras can usually reach the internet, vendor APIs, mobile notification services, local devices, and sometimes other cameras. That is convenient for app setup, but it is a poor default for a security system. A local-first setup starts from the opposite position: cameras are blocked by default, and only the required local paths are added back.\n\nThere are trade-offs. Blocking internet access may disable vendor app previews, cloud motion alerts, automatic firmware checks, or push notifications. Keeping cloud access enabled may preserve convenience, but it also keeps the vendor in the critical path. The right decision depends on whether you want a consumer camera app or a local security architecture. For local recording, the camera only needs to stream video to the recorder, keep accurate time, and remain manageable by an administrator.\n\n## How to Separate a Camera Network Using VLANs\n\nA VLAN separates traffic at Layer 2 while the router or firewall controls traffic between subnets. For a small home security network, the minimum design looks like this:\n\n- VLAN ID: `30`\n- Camera subnet: `10.30.0.0/24`\n- Gateway: `10.30.0.1`\n- Camera DHCP range: `10.30.0.20` to `10.30.0.99`\n- NVR address: fixed address outside the camera VLAN, such as `10.10.0.50`\n- Local NTP source: router, firewall, or internal server\n- Admin access: temporary or restricted, not broad and permanent\n\nThe important part is not the exact number `30`; it is consistency. Camera ports on a switch should be access ports for the camera VLAN, which means the camera itself does not need to understand VLAN tagging. Uplink ports between switches and the router should carry the camera VLAN as a tagged network. If Wi-Fi cameras are involved, the camera SSID should map to the camera VLAN instead of dumping devices into the main LAN.\n\nStatic DHCP reservations are usually safer than manually configured static IPs on the camera. The DHCP server remains the source of truth, but each camera always receives the same address. That makes firewall rules, NVR stream URLs, and documentation stable without forcing you to touch each camera interface every time the subnet changes.\n\n## How to Isolate an IP Camera Without Losing NVR Recording\n\nThe common mistake is blocking the camera VLAN so aggressively that the NVR cannot record. Isolation does not mean every packet disappears. It means every permitted path has a reason.\n\nA good starting traffic policy is:\n\n- Camera VLAN to WAN: block.\n- Camera VLAN to main LAN: block.\n- Camera VLAN to router NTP: allow.\n- Camera VLAN to external DNS: block or redirect to local DNS.\n- NVR to camera VLAN: allow required video and management ports.\n- Admin workstation to camera VLAN: allow only when needed.\n\nFor many IP cameras, the recorder pulls video using RTSP on TCP `554`, HTTP/HTTPS for snapshots or admin access, and sometimes ONVIF discovery or event metadata. The exact ports vary by camera, but the direction matters more than the port list: the NVR should be allowed to reach the cameras; the cameras should not be allowed to initiate arbitrary connections back into the rest of the house.\n\nIf the NVR is inside the camera VLAN, recording is simple but management can become less flexible. If the NVR is outside the camera VLAN, firewall rules need to be more precise, but the NVR can also serve as the controlled integration point for Home Assistant, notifications, and storage. For most local-first homes, the second approach is cleaner because the cameras stay contained while the recorder becomes the trusted boundary.\n\n## Blocking the Route to the Internet\n\nThe SERP snippets point to the core rule: do not let the camera VLAN route anywhere by default. That is the right instinct, but it needs to be implemented as an ordered policy instead of a vague idea.\n\n- **WAN block rule:** deny traffic from `10.30.0.0/24` to the WAN or any non-local destination. This prevents cameras from contacting vendor APIs, cloud storage, telemetry endpoints, and public NTP or DNS services.\n- **Local NTP:** allow cameras to reach a local NTP server, for example `10.30.0.1` or an internal infrastructure host. Accurate timestamps matter for evidence review and event timelines. A camera with the wrong time is still recording, but the footage becomes harder to trust.\n- **Local DNS:** cameras often do not need external DNS for local recording. If a camera becomes unstable when DNS is blocked, route its DNS requests to a local resolver and observe what names it tries to resolve. That tells you whether the device is trying to reach vendor services or simply failing because its firmware expects DNS to exist.\n- **NVR exception:** allow the NVR IP to reach camera IPs on the ports your recorder actually uses. Avoid broad bidirectional rules such as \"allow main LAN to camera VLAN\" because they undo the isolation you just built.\n\nThis policy gives you a strong default without pretending every environment is identical. A fully local camera may work with no DNS and only local NTP. A cloud-first camera may become noisy or partially broken. That is useful information: the device is telling you how dependent it is on the vendor.\n\n## How to Isolate an IP Camera?\n\nStart by deciding what the camera must do locally. For a security camera, the critical functions are video stream, time sync, power, storage path, and controlled admin access. Everything else is optional until you prove you actually need it.\n\nThe process is:\n\n1. Move camera ports or camera Wi-Fi into a dedicated VLAN.\n2. Assign stable IP addresses with DHCP reservations.\n3. Confirm the NVR can see the streams before adding strict firewall rules.\n4. Block camera traffic to WAN.\n5. Block camera traffic to the main LAN.\n6. Add local NTP and DNS handling.\n7. Add only the NVR and admin exceptions needed.\n8. Test from the camera side and the LAN side.\n\nThe best test is not whether the app still opens. The best test is whether the recorder still captures footage while the camera cannot reach the internet and cannot initiate traffic to personal devices. That is the local-first standard.\n\n## Verification Checklist\n\nRun verification from both directions. A camera VLAN can look correct in the router UI and still be wrong in practice.\n\n- [ ] The NVR can view live streams from every camera.\n- [ ] The NVR keeps recording after router and switch reboots.\n- [ ] A laptop on the main LAN cannot open camera admin pages unless an explicit admin rule exists.\n- [ ] Cameras cannot reach public internet targets.\n- [ ] Cameras keep accurate time using local NTP.\n- [ ] DNS behavior is understood: blocked, redirected, or intentionally allowed.\n- [ ] Home Assistant receives the intended events through the NVR or a controlled integration path.\n- [ ] Vendor cloud features are either disabled, blocked, or intentionally allowed as a conscious trade-off.\n\nThe final architecture should be boring: cameras stream locally, the recorder records locally, and every cross-VLAN path exists because you can explain why it is there."
  },
  {
    "slug": "unifi-camera-vlan-isolation",
    "title": "UniFi Camera VLAN Isolation for Local NVR Recording",
    "description": "Configure a UniFi camera VLAN that blocks WAN access, keeps RTSP recording local, and gives the NVR exactly the access it needs.",
    "pubDate": "2026-06-27T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "network-hardening",
      "security-cameras",
      "local-first",
      "home-automation"
    ],
    "image": "/_astro/unifi-camera-vlan-isolation.CWWtlnMF.jpeg",
    "coverImage": {
      "src": "/_astro/unifi-camera-vlan-isolation.CWWtlnMF.jpeg",
      "width": 1376,
      "height": 768,
      "format": "jpg"
    },
    "body": "import { Image } from 'astro:assets';\nimport imgArchitecture from '../../assets/2026/unifi-camera-vlan-isolation-diagram.jpeg';\n\nThis draft assumes a UniFi gateway such as a UDM Pro, UDM SE, Cloud Gateway, or equivalent UniFi gateway, plus a UniFi PoE switch for wired cameras. The target is not a generic \"secure camera network.\" The target is a specific UniFi design: cameras on a dedicated VLAN, local NVR access allowed, WAN access blocked, and management exceptions kept narrow.\n\nThe SERP around this topic is dominated by Reddit, forums, and YouTube because most users get stuck between two bad defaults. They either leave cameras on the main LAN because it works, or they isolate the VLAN so hard that the NVR stops recording. In UniFi, the cleaner path is to build the camera network first, assign ports deliberately, then create traffic and firewall policy around the NVR.\n\n## The UniFi Isolation Architecture\n\nUse VLAN `30` for cameras and subnet `10.30.0.0/24`. Put camera switch ports in that VLAN as access ports. Keep the NVR on an infrastructure network, for example `10.10.0.50`, unless your NVR appliance is physically tied to the camera switch and you intentionally want it inside the camera VLAN.\n\nThe policy goal is simple: cameras can talk to the local infrastructure they need, but they cannot initiate traffic to WAN or the main LAN. The NVR can initiate traffic to cameras. Admin access is either from a single workstation or opened temporarily during maintenance.\n\n<Image\n  src={imgArchitecture}\n  alt=\"UniFi camera VLAN topology with PoE cameras on VLAN 30, a local NVR exception, local NTP and DNS handling, and blocked WAN access\"\n  width={800}\n  height={450}\n  class=\"my-8 h-auto w-full rounded-lg border border-white/20 object-cover shadow-md\"\n/>\n\n## Create the Camera Network in UniFi\n\nIn UniFi Network, create a dedicated network for cameras with VLAN ID `30` and subnet `10.30.0.0/24`. Use the UniFi gateway as the gateway for the subnet at `10.30.0.1`. Enable DHCP for the camera subnet, but plan to reserve each camera address.\n\nUse a reserved range like this:\n\n- Gateway: `10.30.0.1`\n- Cameras: `10.30.0.21` to `10.30.0.80`\n- Future camera expansion: `10.30.0.81` to `10.30.0.120`\n- Infrastructure exceptions: avoid placing the NVR here unless the design requires it\n\nIn Port Manager, assign each wired PoE camera port to the camera network as the native or untagged network. Cameras normally should not receive tagged VLAN traffic directly. The switch uplink back to the gateway should carry the camera VLAN as tagged traffic.\n\n{/* REVIEW: confirm the exact UniFi OS labels match your installed Network application version. UniFi has changed wording around port profiles and traffic rules across releases. */}\n\n## Reserve Camera IP Addresses Before Locking Down Rules\n\nDo not build firewall rules around random DHCP addresses. In UniFi, identify each camera by MAC address and create DHCP reservations inside the camera network. Use a naming pattern that will still make sense six months later:\n\n- `cam-front-door` -> `10.30.0.21`\n- `cam-driveway` -> `10.30.0.22`\n- `cam-garage` -> `10.30.0.23`\n- `cam-backyard` -> `10.30.0.24`\n\nThen configure the NVR using those stable addresses. If the recorder uses RTSP URLs, keep the URL inventory in a password manager or documentation file, not only inside the NVR UI. A VLAN design is easier to debug when camera identity, IP address, switch port, and physical location all line up.\n\n## Allow the NVR Into the Camera VLAN\n\nThe NVR exception should be narrow and directional. The NVR needs to reach the cameras; the cameras do not need to initiate connections back into the NVR network.\n\nFor a typical recorder, allow from NVR IP `10.10.0.50` to camera subnet `10.30.0.0/24` for:\n\n- RTSP, commonly TCP `554`\n- HTTP, commonly TCP `80`, if snapshots or admin access require it\n- HTTPS, commonly TCP `443`, if the camera web interface or API uses it\n- ONVIF or vendor discovery ports only if your recorder actually depends on them\n\nAvoid a broad \"Main LAN to Camera VLAN: allow all\" rule. It works, but it turns the camera VLAN into decoration. If you need an admin workstation, create a separate rule from one trusted workstation IP to the camera subnet, and disable or tighten it after commissioning.\n\n## Block Camera WAN Access\n\nCreate a rule that blocks the camera network from reaching the internet. In UniFi terms, this usually means a traffic or firewall rule matching source network `Camera VLAN` and destination `Internet` or WAN, with action `Block`.\n\nThe important detail is ordering. Allow local infrastructure first if UniFi evaluates your rules in a way that requires specific allows before broader blocks. Then block camera-originated access to WAN and to other internal networks.\n\nA practical policy set is:\n\n1. Allow NVR `10.10.0.50` to camera subnet `10.30.0.0/24` on required ports.\n2. Allow camera subnet `10.30.0.0/24` to local NTP at `10.30.0.1` or another trusted local host.\n3. Allow or redirect camera DNS only if required.\n4. Block camera subnet to WAN.\n5. Block camera subnet to main LAN and sensitive internal networks.\n\nIf a camera vendor app stops working after this, that is expected. You removed the vendor cloud path. Decide whether the app is more important than local-first isolation before adding exceptions.\n\n## Local NTP and DNS in UniFi Camera Networks\n\nTime matters. Security footage with wrong timestamps is hard to correlate with door events, alarms, logs, and Home Assistant automations. Cameras should use local NTP. If UniFi's gateway or another internal host provides NTP, point cameras there. If cameras insist on public NTP names, redirect or document that behavior before allowing broad internet access.\n\nDNS is different. Many cameras do not need DNS at all for local RTSP recording. If a camera keeps trying to resolve vendor domains, blocking DNS can make the dependency visible. A stricter setup blocks external DNS and allows only local resolver access. A more permissive setup lets cameras resolve names but still blocks WAN, which helps you observe vendor behavior without allowing traffic out.\n\nDo not open full WAN just because DNS logs look noisy. DNS resolution is not the same as a justified outbound connection.\n\n## Should UniFi Cameras Be on a Separate Network?\n\nFor third-party IP cameras, yes. For UniFi Protect cameras, the design depends on the Protect appliance and adoption model, but the same principle applies: camera devices should not be mixed casually with user devices. Keep camera traffic predictable and keep recording local.\n\nIf the cameras are third-party RTSP cameras feeding Frigate, Blue Iris, Synology Surveillance Station, or another local NVR, VLAN isolation is straightforward. If the cameras are first-party UniFi Protect devices, verify adoption, controller visibility, and firmware update behavior before applying the strictest blocks. The target is still containment, but the exact exception list may differ.\n\n{/* REVIEW: add your actual UniFi Protect or third-party camera baseline here if this article is meant to target one specific camera family. */}\n\n## Verification Checklist\n\nAfter applying the rules, verify behavior from the NVR, from a normal laptop, and from the camera VLAN.\n\n- [ ] Each camera receives the expected reserved IP in VLAN `30`.\n- [ ] Each PoE camera port is assigned to the camera network, not the main LAN.\n- [ ] The switch uplink carries VLAN `30`.\n- [ ] The NVR can pull every camera stream.\n- [ ] A normal main LAN client cannot browse to camera admin pages.\n- [ ] Cameras cannot reach the WAN.\n- [ ] Cameras keep correct time through local NTP.\n- [ ] DNS behavior is either blocked, local-only, or intentionally allowed.\n- [ ] Home Assistant or automation events still work through the NVR path.\n\nWhen the setup is correct, UniFi becomes boring in the right way: camera ports are predictable, the NVR sees what it needs, and the cameras have no reason to touch the rest of the home network."
  },
  {
    "slug": "isolate-ip-cameras-vlan",
    "title": "How to Isolate IP Cameras on a VLAN",
    "description": "A practical local-first guide to isolating IP cameras from your main home network without breaking recording or access.",
    "pubDate": "2026-06-27T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "network-hardening",
      "security-cameras",
      "local-first"
    ],
    "image": "/_astro/isolate-ip-cameras-vlan.bbtJ1zbg.png",
    "coverImage": {
      "src": "/_astro/isolate-ip-cameras-vlan.bbtJ1zbg.png",
      "width": 1600,
      "height": 900,
      "format": "png"
    },
    "body": "Most homeowners install IP cameras as if they were harmless appliances. They connect the camera to Wi-Fi, open the vendor app, accept the cloud prompts, and assume the job is done.\n\nThat setup works until the camera becomes the weakest device on the network.\n\nThe local-first approach is different: the camera should record locally, talk only to the systems it must reach, and stay away from laptops, phones, work machines, and private storage.\n\n## The goal\n\nThe goal of a camera VLAN is simple:\n\n- cameras can send video to your recorder\n- cameras cannot scan or reach your main devices\n- cameras do not need open access to the internet\n- management access is limited to trusted devices\n\nThis design gives you the convenience of smart cameras without treating every vendor device as a trusted computer.\n\n## Recommended network layout\n\nA practical home setup can use three network zones:\n\n- main LAN for phones, laptops, desktops, and trusted devices\n- camera VLAN for IP cameras\n- server VLAN or trusted host for your NVR\n\nThe NVR can be a dedicated recorder, a NAS, or a small server running software like Frigate. The key point is that cameras should initiate or expose video only to the recorder, not to the whole house.\n\n## Firewall rules\n\nStart with a deny-by-default mindset for the camera VLAN.\n\nAllow only what is needed:\n\n- camera VLAN to NVR on RTSP or ONVIF ports\n- trusted admin device to camera web UI when maintenance is needed\n- DNS and NTP if the cameras need correct time\n\nBlock everything else:\n\n- camera VLAN to main LAN\n- camera VLAN to guest network\n- camera VLAN to storage shares\n- camera VLAN to the internet unless a specific feature truly requires it\n\nThis is where many smart home installs fail. They create the VLAN but leave broad allow rules in place, which removes most of the security benefit.\n\n## Remote viewing\n\nAvoid exposing camera ports directly to the internet. If remote access is required, use a VPN, a secure reverse proxy to the NVR interface, or a private tunnel that terminates on a system you control.\n\nThe camera itself should not be the public-facing service.\n\n## Common mistakes\n\nThe most common mistake is mixing cameras and personal devices on the same Wi-Fi network. The second most common mistake is trusting the vendor cloud as the only recording layer.\n\nA better design records locally first and treats cloud access as optional, not foundational.\n\n## Final recommendation\n\nIf you already own IP cameras, do not replace them first. Re-architect the network first. A simple VLAN, strict firewall rules, and local recording can turn a fragile smart camera setup into a much safer home security system."
  },
  {
    "slug": "build-local-nvr-with-frigate",
    "title": "Build a Local NVR With Frigate and No Cloud Subscription",
    "description": "Learn how a local-first NVR with Frigate can record security cameras at home without relying on paid cloud storage.",
    "pubDate": "2026-06-26T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "local-first-storage",
      "security-cameras",
      "home-automation"
    ],
    "image": "/_astro/build-local-nvr-with-frigate.Cev1o-6n.png",
    "coverImage": {
      "src": "/_astro/build-local-nvr-with-frigate.Cev1o-6n.png",
      "width": 1600,
      "height": 900,
      "format": "png"
    },
    "body": "import { Image } from 'astro:assets';\nimport imgArquitetura from '../../assets/2026/pnx.png';\n\nCloud camera subscriptions are convenient, but they create a permanent dependency. If the vendor changes prices, limits features, or has an outage, your security system becomes less useful exactly when you need it.\n\nA local NVR gives you a different operating model: your cameras record inside your home, your clips stay on storage you control, and cloud access becomes optional.\n\n## Why Frigate fits local-first security\n\nFrigate is popular because it combines local recording with object detection. It can receive camera streams, detect events, and integrate with Home Assistant without forcing every clip through a vendor cloud.\n\nFor a practical home setup, the main advantages are:\n\n- local recording\n- event-based clips\n- Home Assistant integration\n- support for RTSP cameras\n- hardware acceleration options\n\nThe result is a security architecture that is closer to a small professional system than a consumer subscription bundle.\n\n## Basic architecture\n\nA clean local NVR setup has four parts:\n\n- IP cameras on a camera VLAN\n- Frigate running on a small server, NAS, or mini PC\n- local storage for recordings and clips\n- Home Assistant for automation and alerts\n\n<Image\n  src={imgArquitetura}\n  alt=\"Diagram of a local NVR architecture showing Frigate, Home Assistant, and isolated IP cameras\"\n  width={800}\n  height={450}\n  class=\"my-8 h-auto w-full border border-white/20 object-cover shadow-md\"\n/>\n\nThe cameras should stream to Frigate. Frigate should store the footage locally. Home Assistant can use Frigate events to notify you, turn on lights, or trigger other automations."
  },
  {
    "slug": "smart-lock-without-cloud",
    "title": "Smart Locks Without the Cloud: What to Look For",
    "description": "Choose smart locks that keep access control reliable at home without depending entirely on vendor cloud services.",
    "pubDate": "2026-06-25T00:00:00.000Z",
    "author": "Renan",
    "tags": [
      "smart-locks-access",
      "home-automation",
      "local-first"
    ],
    "image": "/_astro/smart-lock-without-cloud.DbMoGsCB.png",
    "coverImage": {
      "src": "/_astro/smart-lock-without-cloud.DbMoGsCB.png",
      "width": 1600,
      "height": 900,
      "format": "png"
    },
    "body": "A smart lock is not just another smart home gadget. It controls physical access to your house. That makes reliability and ownership more important than flashy app features.\n\nMany smart locks work well until the cloud service is slow, the app stops working, or the vendor changes account requirements. A local-first access strategy avoids making a remote service the single point of failure.\n\n## What local-first means for smart locks\n\nFor a smart lock, local-first means the lock should remain useful even when the internet is unavailable.\n\nAt minimum:\n\n- physical key or keypad fallback should work\n- local wireless control should be possible\n- access history should not depend only on a cloud dashboard\n- automations should keep working inside the home\n\nCloud features can still exist, but they should not be required for basic entry.\n\n## Protocols to consider\n\nSmart locks commonly use Wi-Fi, Bluetooth, Z-Wave, Zigbee, Matter, or a proprietary bridge.\n\nWi-Fi locks are simple, but they often depend more heavily on vendor apps and cloud services. Z-Wave and Zigbee locks can fit better into a local-first setup when paired with a local hub. Matter may improve interoperability, but you still need to check how much of the lock's behavior remains local.\n\nThe important question is not only \"does it connect?\" The better question is \"what stops working when the internet is down?\"\n\n## Access control design\n\nA good smart lock setup separates convenience from authority.\n\nConvenience includes phone unlock, automations, notifications, and temporary codes. Authority includes the ability to enter the house, revoke access, and recover from failure.\n\nDo not put all authority inside a vendor account.\n\n## Home Assistant integration\n\nHome Assistant can be useful when the lock supports local integration. You can build automations such as:\n\n- lock the front door at night\n- turn on entry lights when the door unlocks\n- alert when the door remains unlocked too long\n- disable risky automations while nobody is home\n\nKeep these automations conservative. A lock should not unlock because a fragile presence sensor guessed wrong.\n\n## Common mistakes\n\nThe biggest mistake is buying a lock based only on app reviews. Another common mistake is ignoring battery behavior and fallback access.\n\nBefore relying on any smart lock, test:\n\n- dead battery behavior\n- internet outage behavior\n- hub outage behavior\n- manual unlock behavior\n- guest code removal\n\n## Final recommendation\n\nPick a smart lock like you would pick infrastructure, not like you would pick a gadget. The best choice is the one that keeps secure access working when the app, cloud, hub, or internet connection fails."
  }
]