I’ve been satisfied with Reolink for a couple of years, and I’ll be installing another next week.
I use a hardware NVR with it’s own HDDs and it’s own separate PoE network connecting all of the cameras, but since you are using your ZFS storage you will substitute the NVR unit with something like Blue Iris. There are several options for NVR software.
I’d recommend dnsmasq for a DNS/DHCP server component. It is time tested, used on some consumer routers as a daily-driver industry component. It has a far easier learning curve compared to the like of ISC’s offering, and the feature gaps are not going to affect you until you have a firm grasp on many deeper DNS or DHCP nuances.
I’ve had similar thoughts some several months ago, but I haven’t even figured out how to get a stable desktop environment in a VM (my experience with Linux is mostly in server-land). My overall approach for idempotency is a git repository that has a Terraform blueprint and an Ansible blueprint, and the whole kit is pointed at my home ProxMox cluster.
With this workflow I can lift and shift my entire localnet wherever I want in the future.
You could use a much simpler blueprint approach to accomplish your Desktop Environment VM. You’ll want to externalize any data that won’t get included in a blueprint rebuild (databases, games save files, media libraries, etc.).
ip:port <-> ip:portFrom any particular host (be it on the WAN or LAN) every TCP/UDP transmission is sent from some specific address-port pair destined for some other specific address-port pair. From the WAN (i.e. the Internet), every destination address must be in a public range, and we ran out of those a while ago, which is why NAT became a thing at all.
Your router is the only machine on your LAN that also has a WAN address, so every transmission destined for inside your LAN must be (from the perspective of the Internet) addressed to some port on your router. Port numbers under 1024 are special, but most of the 60-thousand other ports are without special meaning, and these unremarkable ports are the ones used to send outgoing transmissions even if the destination is some well-known, meaningful port like 80 (HTTP) or 22 (SSH). When the server responds (such as with an HTTP GET result) they send the response to the address-port pair that sent the originating request.
The magic ingredient in NAT is that your router remembers that it just proxied a request from some LAN station, and it holds in reserve whichever port it used to send that request (since it knows that any responses from the WAN will be aimed at that port of the router).
When your router receives a transmission from the WAN, it consults the records it has kept to decide which LAN station is supposed to received that transmission. Here we get to the concept of Port Forwarding, which just short circuits that NAT lookup and assigns some arbitrary port on the router as a persistant pathway to some specific LAN station.
In short, yes, only the destination port is required for your router to decide.
If I stand on one side of a magic portal and there is a Nazi on the other side of the portal, that Nazi is in punching distance. Technology allows transmission of voices at the speed of light. Don’t be pedantic.