In the first part of this series, I put a Sophos XGS firewall inline on my home network in bridge mode — log-only, no blocking — just to see what was actually crossing the wire. That post ended on an unfinished note: both Wi-Fi radios in the house sat outside the monitored path, so every wireless device was still invisible to the firewall. I’d picked an Omada access point to fix it, but hadn’t yet proven it would actually do the job.

This post picks up exactly there. Three things got done: the access point went in for real, a set of IP cameras and an NVR joined the network, and — on the same infrastructure — I finally dealt with years of disorganised family photos and video. None of it was enterprise work. All of it taught something that applies directly to securing a small office, which is why it’s worth writing down.

Proving the access point before trusting it Link to heading

The temptation with new network gear is to bolt it in place and assume it works. I’ve seen that assumption cause enough outages that I bench-tested first, near the switch, before running any permanent cable.

The setup was deliberate: same SSID as the existing network, matched channel and width settings so the new radio wouldn’t fight the old ones during testing, and a static management IP confirmed reachable before I committed to anything physical.

Then the part that actually mattered — a proper walk-test. I disabled each existing Wi-Fi source one at a time, first the extension router, then the ISP router, and walked every room with a phone. Not glancing at signal bars — actually loading pages, because “three bars” and “usable” are not the same thing. The new access point covered more ground than the old ISP radio ever had.

The lesson here is the same one that bit me in part one, in reverse: don’t assume symmetry between radios. A radio added to fix coverage in one spot won’t necessarily cover a different spot just because it broadcasts the same name. The only way to know is to disable the thing you’re relying on and walk the space — before you’ve made the change permanent, not after.

With placement confirmed, I ran the cable, mounted the access point, and switched off the ISP router’s Wi-Fi for good. Every device on the network — wired or wireless — now passes through the monitored bridge. The blind spot that started this whole project is finally closed.

Getting third-party cameras onto an NVR: the ONVIF fight Link to heading

With the network settled, I added physical security — a small NVR and three PoE IP cameras. This is where “I know networking professionally” met “I have never wired up CCTV before,” and the gap was educational.

The wiring was the easy part. The NVR is a single-LAN-port unit with no built-in camera ports, so it and a separate PoE switch each connect independently back to the main managed switch. The cameras plug into the PoE switch, which delivers power and data over one cable each. Two devices, two uplinks, nothing wired directly to each other.

The hard part was getting a camera from one brand to talk to an NVR from another over ONVIF — the open standard that’s supposed to make cross-brand CCTV plug-and-play, and mostly does, right up until it doesn’t. My cameras showed up on the NVR as detected but “uncertified,” with no live feed.

Chasing it down was a lesson in isolating variables before changing anything:

  • First, confirm the camera’s own stream works at all, independent of the NVR. Its own web interface’s live view settled that in seconds — camera fine.
  • Next, test the raw network stream directly, pulling the RTSP feed into a media player. That ruled the NVR out entirely and put the fault on either the camera’s stream config or how the NVR handled it.
  • The culprit was mundane and infuriating: a password with a symbol that broke URL parsing inside the streaming protocol. A camera password that logs into the web UI perfectly can silently break an RTSP/ONVIF connection if it contains a character like @, which has special meaning inside a URL. Swapping to a plain password — alphanumeric plus hyphens and underscores, none of the reserved symbols — fixed it outright.

It’s a small thing. But it’s exactly the kind of small thing that eats an evening if you change three variables at once instead of ruling out each layer — camera, transport, NVR — one at a time. That discipline is most of what separates a two-hour fix from a two-day one, and it’s identical whether the device is a home camera or a client’s firewall.

Reclaiming the media pile: Jellyfin and Immich Link to heading

The last piece wasn’t security, but it lived on the same network and used the same thinking: years of family photos and video on an old NAS, never organised, never backed up sensibly, impossible to search.

Instead of a commercial cloud service, I went self-hosted — two open-source tools as Docker containers on a spare Linux box, with the NAS mounted in as the actual storage:

  • Jellyfin for movies and TV — a free, open alternative to the paid media-server platforms, with native apps on the TV and phones.
  • Immich for photos — the closest open option to a Google-Photos-style experience: automatic phone backup, face grouping, search by content, duplicate detection, none of it gated behind a paid tier.

The install is refreshingly simple once Docker is in place — each app is a single YAML file describing what to run and which folders to expose. The one real trip-up was a mount-path mismatch: the container has to be told which folder holds the media as the container sees it internally, not as the host sees it. Point the library setting at the wrong side of that mapping and the app starts cleanly but shows nothing — which looks alarming until you understand the mapping underneath.

Both tools now sit on the same monitored network as everything else. No exception, no special-casing — just two more devices on infrastructure that was already built to see them.

What’s actually next: segmentation Link to heading

Visibility, coverage, and physical security are in place. The real next phase is segmentation — and the camera work made the case for it better than any diagram could. IoT and CCTV gear are a classic weak point: cheap firmware, rarely patched, and no reason to trust it on the same flat network as everything else.

The plan is four segments, each its own VLAN and subnet with explicit rules about what may talk to what:

  • Family/personal for everyday devices
  • Work/official for anything client-facing or sensitive
  • Guest Wi-Fi, isolated from everything else
  • Cameras and NVR, locked down so they reach only what they need and nothing more

That means moving the firewall from bridge mode into routed mode — a meaningfully bigger job, and the subject of the next post. The switch and access point were both chosen up front to support it, which was deliberate, not luck.

The takeaway, if you’re doing this on someone else’s network Link to heading

None of this needed enterprise gear. A firewall, a switch, an access point, some cameras, a spare Linux box — and a lot of careful thinking about where cables go, what fails when the power blips, and how to isolate a fault instead of guessing at it.

That last habit is the one that pays. The camera problem looked like a compatibility failure and turned out to be a character in a password. You only find that by testing one layer at a time. Whether it’s a home camera or a client’s edge firewall, the method is the same: rule things out in order, change one variable at a time, and trust what you can observe over what you assume.

If you run a small business or shop and your own network has grown the same organic, nobody-really-planned-this way mine did — that eyes-open review is exactly the kind of work I do.

Next in this series: moving the firewall into routed mode and building the VLAN segmentation for real — what changes when the box stops watching and starts enforcing.