

Thank you for taking a peek!
Let me know if there’s something you’re looking for. The search function isn’t to bad but sometimes the posts can get buried a bit ;)


Thank you for taking a peek!
Let me know if there’s something you’re looking for. The search function isn’t to bad but sometimes the posts can get buried a bit ;)
Oh hello there fellow Canadian blogger! I’m just down the road from you in between Toronto and Montreal (right in the middle actually!)…
I run a tech blog as well, but different focus than yours mostly on c omplete self-hosting, infrastructure and cybersecurity, and media servers.
**We should make some backlinks at some point! **
PS> This site is built off Ghost CMS.


This may help as well, and bridges the gap for some with all the changes from v25.x to v26.x.
Core Lab OPNsense upgrade guide
Your rule looks correct at first glance, but I’ll take a peek further. You do need a DHCP pool setup PER VLAN though, so there’s that as well.


I use SWAG reverse proxy for this, with Cloudflare for DNS.


Anything that I publicly expose, I have protected with multiple layers up and down my entire stack…


I’m late to the party, but feel my guides can help. I am biased towards them because I wrote them! ;)
It’s up to date for v26.x with OPN, that said these guides (3 part series) do need a bit of an overhaul but it does cover VLANs, LAGG/Trunks, DNSmasque and DHCP for each VLAN, with pictures etc…
It’s literally based off the NAS comparison guide I posted… This is like a text book way to move forward for someone. My solution is like a giant all in one+a NAS, but a lllooottt of people have a decoupled solution.
One of the beautiful things about self-hosting; do what you want.
Welcome to the self-hosting trenches. Don’t worry about the “burning yourself” part - in this hobby, we consider those “tactical lessons.” Everyone has ah, “re-started” things at least a few times!
Actually, your plan isn’t “not very smart”—it’s a classic move we call Decoupling Compute from Storage. It is the most future-proof way to build a Digital Fortress. By separating your “Brain” (HP Mini) from your “Vault” (Asustor), you ensure that if one fails, the other stays standing. This is a great move.
Here’s how I see your planned setup:
**The Command Center: HP Z2 Mini - Xeon and Proxmox **
The Xeon 1245-v5 is a beast compared to that Celeron. Running Proxmox here is exactly the right call.
The Strategy: Use that M.2 drive for your Proxmox “Data” (the LXCs and VM boot drives). Services like Immich and Navidrome rely on fast databases; running them on an SSD on the Xeon node will make them feel lightning-fast.
The Gear: With 32GB of RAM, this is what I’d call an “Elite Node.” You have plenty of head-room to grow.
**
The Vault: Asustor (Celeron N5105) **
TrueNAS SCALE is “Heavy Armor.” Running it on a 2-bay Celeron is like putting tank treads on a scout bike - it’s overkill and eats up the limited RAM that Celeron has to offer.
The OS Choice: I’d strongly suggest OpenMediaVault 8 (OMV) for the Asustor. In my 2026 NAS OS Comparison Guide, I categorize OMV as the “Lightweight Tactical” choice. It’s built on Debian 13, is incredibly lean, and is the best way to turn low-power hardware into a rock-solid network drive. You’ve already tasted the freedom of a custom OS. Going back to ADM now will feel like a “vendor-lock-in” cage. OMV is the perfect middle ground…
**
How they talk to each other **
Wipe the Asustor, install OMV, and set up a simple NFS or SMB share. In Proxmox, you “mount” that network share. Your apps on the HP Mini will “see” the Asustor drives as if they were plugged in locally.
Is it a good idea? Yes . If you ever want more drive bays in the future, you just swap out the Asustor “Vault” for something bigger (like a 6-bay DIY build or a UGREEN box), and your HP Mini “Command Center” never even has to go offline.
I recently broke down the “Battle Card” for why OMV is the king of low-power storage nodes in 2026. You might find the comparison table helpful for your specific hardware: NAS OS Comparison
What you could try is an inverse sense of match rule, which by default, allows access to the internet but not to other VLANs. This is what I do and is the standard I think that should be the default!
If you read the LAN rules at the link there, it basically has you setup RFC1918 IP space as an alias, and then setup an inverse option the logic is:
Anything that is NOT Private IP space - ALLOW!
So outbound from that vlan/network/subnet to internet --> Allowed!
Then you make separate rules to actually allow whichever VLAN access to the other, that you want.