DEV Community: Hugo | DevOps | Cybersecurity

Proxmox Backup Server: Incremental Backups and Restore Testing

Hugo | DevOps | Cybersecurity — Wed, 11 Nov 2026 15:15:03 +0000

A mid-sized shop I worked with ran 18 months of "successful" nightly backups. Every job exited 0. Every dashboard was green. Then ransomware hit, they reached for the backups, and discovered the datastore had been silently corrupting chunks for months — the underlying disk had been throwing write errors that the verify jobs (which they'd never scheduled) would have caught. Eighteen months of green checkmarks, zero recoverable data. The post-mortem was short: nobody had ever restored a single VM.

Proxmox Backup Server (PBS) is genuinely good infrastructure. The content-addressed chunk store deduplicates well, the QEMU dirty-bitmap integration makes incrementals cheap, and the verify tooling exists. But "backup job exited 0" is not a restore test, and PBS won't test restores for you unless you build the pipeline. This guide covers both halves: getting the incremental/dedupe model right, and automating the restore verification that nobody wants to do manually.

This is written for the sysadmin or platform engineer who already has PBS running (or is about to) and wants it to survive contact with an actual incident. By the end you'll have a working restore-test script, sane GC/prune retention, an encryption key strategy that doesn't brick your recovery, and the five alerts that precede data loss.

:::note[TL;DR]

PBS incrementals rely on QEMU dirty bitmaps — a lost bitmap means a full backup, so schedule with headroom, not at 99% of the window.
Prune marks, GC reclaims. If GC never runs outside the backup window, your datastore fills up and you find out at 3 AM.
The encryption master key is a single point of total loss. Escrow it offline or you have no backups, only ciphertext.
"Verify" checks chunk integrity, not recoverability. Automate a full VM boot test on an isolated bridge — that's the only proof that matters.
Pull-sync to offsite from the offsite side. A compromised primary should never be able to delete your offsite copy. :::

Prerequisites

Proxmox VE 8.x and Proxmox Backup Server 3.x (check the official docs for current versions — the API surface is stable but flags evolve).
A PBS datastore with at least one backup job configured and one snapshot present.
Root or DatastoreAdmin access on both PVE and PBS.
proxmox-backup-client installed on any host that will run restore tests (it ships with PVE).
An isolated bridge or VLAN on your PVE cluster for boot tests — no uplink, no DHCP to production.
A Prometheus + Alertmanager stack if you want the monitoring section to be more than reading comprehension.

Why PBS Beats Your rsync/ZFS-send Script (And Where It Doesn't)

PBS is a content-addressed, chunk-based deduplicating store — not a file copier. It splits VM disk images into fixed-size chunks, hashes them, and stores each unique chunk once. A second VM with the same OS install dedupes against the first almost entirely. That's the whole value proposition, and it's why the "I'll just rsync the raw disks" crowd has an RTO measured in days, not hours: raw disk copies don't dedupe, don't do incrementals without snapshot gymnastics, and restore at disk speed.

Fixed chunks, dirty bitmaps, and what "incremental" actually means

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Proxmox Backup Server: Incremental Backups & Restore Testing

Hugo | DevOps | Cybersecurity — Tue, 10 Nov 2026 15:15:04 +0000

Everyone's backups work until the first real restore. Then the dashboard goes green, the ticket gets escalated, and someone discovers the datastore was a single consumer SSD that had been silently corrupting chunks for a year and a half. Eighteen months of nightly PBS jobs, zero restore tests, and a retention policy that had pruned the last known-good snapshot three weeks before the incident.

This is for senior sysadmins and security engineers running Proxmox VE in production who already have PBS installed and want to stop treating it as a checkbox. After reading, you'll understand what PBS "incremental" actually means at the storage layer, how to size and lay out a datastore that survives an audit, and how to build an automated restore-test harness that proves your guests boot — because PBS proves nothing of the sort.

Scope: PBS 3.x/4.x, PVE 8.x, and working familiarity with proxmox-backup-client, proxmox-backup-manager, qm, and pct. If those mean nothing to you, this article will hurt.

:::note[TL;DR]

PBS "incremental" is content-defined chunk dedup across the whole datastore — not a disk delta. Design storage for it.
Client-side encryption is non-negotiable; the key lives with you, not on the PVE host.
Verification checks chunk hashes against indexes. It does not prove your VM boots. Restore testing does.
Automate restore-to-scratch-VM on a schedule, emit Prometheus metrics, and page on failure — or you have rumors, not backups. :::

Prerequisites

Proxmox VE 8.x cluster with qemu-guest-agent installed in every guest you intend to back up.
Proxmox Backup Server 3.x/4.x with at least one ZFS-backed datastore.
A dedicated restore-test PVE node (or an isolated bridge/VLAN on an existing node) with scratch VMID range reserved (e.g., 9000–9099).
proxmox-backup-client, jq, and curl on the restore-test node.
Prometheus + Alertmanager (or your equivalent) reachable from the PBS host.

Why PBS Incremental Is Not Your Old rsync Script

If you think "incremental" means "diff of the VM disk," you will size your datastore wrong and then wonder why GC is rewriting indexes into a full filesystem. PBS incremental is a property of the storage layer, not a delta of the guest.

Chunking, Dedup, and What "Incremental" Actually Means Here

PBS splits every backup stream into variable-length chunks using content-defined chunking (a rolling hash, not fixed-size blocks). Each chunk gets hashed, and if the hash already exists in the datastore, the chunk is not written again — only the new per-snapshot index file references the existing chunk. Dedup is global: across snapshots, across guests, across time. That's the feature.

It's also a footgun. One corrupted chunk can invalidate every snapshot that references it, which is why verification and ZFS checksums are not optional. The index file per snapshot is small; the chunk store is the thing you protect.

What Gets Sent Over the Wire vs. What Lives on Disk

On the PVE side, the dirty bitmap tracks changed extents since the last backup. Those extents get chunked and hashed, and only chunks whose hashes are absent from the datastore are uploaded. First backup of a 500 GB VM is expensive; the second is cheap only if the guest churns slowly. A database writing 200 GB/day will not be cheap, no matter what the marketing deck said.

Datastore Creation With Sensible Defaults

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ZimaBlade NAS + Router Combo: PCIe Build Guide

Hugo | DevOps | Cybersecurity — Mon, 09 Nov 2026 15:15:04 +0000

A client called me at 11pm because their "NAS" had been silently corrupting backups for six weeks. The culprit wasn't ZFS, wasn't the drives, and wasn't the filesystem. It was a USB 3.0 enclosure with a UAS controller that reset itself under sustained load, dropped the pool offline, and re-imported it without complaint. They found out only when a restore failed during an actual incident. Forty terabytes of "backups" that were never tested, on a transport layer nobody should trust with a zpool.

That story matters here because the ZimaBlade is exactly the kind of board people buy to do everything at once — NAS, router, DNS, containers — on a single x86 SBC with a real PCIe slot. Done right, it's a beautiful little combo box. Done the way most forum posts suggest, it's a single point of failure with a cheerful front panel.

This guide is for sysadmins and security engineers who already know their way around zpool, iptables/nft, and a hypervisor, and want a build that won't embarrass them in six months. By the end you'll have a Proxmox host with PCIe passthrough, a ZFS NAS layer with sanoid snapshots, an OPNsense router VM on its own NIC, VLAN segmentation that doesn't loop, and a backup and monitoring story that actually proves itself.

:::note[TL;DR]

The ZimaBlade's single PCIe lane is real but electrically constrained — verify your board revision before buying a quad-NIC or HBA.
Run Proxmox VE as the host, OPNsense as a VM, and the NAS as an LXC with a passed-through SATA controller. Never put WAN and LAN on the same bridge.
Use ashift=12 always, prefer a PCIe SATA controller (ASM1166/JMB585) with external power over USB for any ZFS pool.
Backups must be off-box, immutable, and restore-tested. Untested backup is not a backup. :::

Prerequisites

A ZimaBlade board (verify revision and PCIe electrical width before purchase), 16GB RAM minimum, a small NVMe boot drive.
A PCIe NIC (Intel i210 or i226-v) for the router role, and optionally a PCIe SATA controller for storage.
A USB stick with the Proxmox VE ISO (grab the current release from the official site — versions move).
Console access (HDMI + USB keyboard or serial) for first boot.
A second machine to run ssh, zfs, and prometheus tooling from.

Why the ZimaBlade Is a Weirdly Good Fit (And Where It Isn't)

This section exists because half the internet treats the ZimaBlade as either a Raspberry Pi killer or a datacenter replacement. It's neither. It's an x86 SBC with one PCIe lane, and that lane is what makes the NAS+router combo viable at all.

What the ZimaBlade Actually Is

The board ships in configurations based on Intel Celeron N-series silicon (N3450/J4125-class parts depending on SKU — check the vendor spec sheet for the exact model you buy). The critical detail is the PCIe slot: physically x4, but on some board revisions it's electrically wired as x1. That distinction is the difference between "a quad-NIC works fine" and "a quad-NIC negotiates down and drops links under load."

Before you buy anything, confirm what you actually have:

# Confirm the board revision and slot topology
sudo dmidecode -t baseboard | grep -E "Manufacturer|Product|Version"
sudo lspci -vvv | grep -A2 "PCI bridge" | head -20

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

cloudflare.lv: Why I Gave It to Cloudflare for Free

Hugo | DevOps | Cybersecurity — Sun, 08 Nov 2026 15:15:04 +0000

Liquid syntax error: Variable '{{% raw %}' was not properly terminated with regexp: /\}\}/

GL.iNet Slate 7 Pro Review: Wi-Fi 7 Travel Router That Fixed My Homelab Bottleneck

Hugo | DevOps | Cybersecurity — Fri, 06 Nov 2026 15:15:04 +0000

The Problem: When Your "Good Enough" Network Isn't

Running self-hosted services on serious hardware means your network bottleneck stands out immediately. Mine was a TP-Link RE550 range extender — a device built for casual web browsing, not 24/7 production workloads.

The breaking point: Moving a 40 GB video project from my editing workstation to the NAS took 2 hours 30 minutes. SSH sessions to Proxmox would randomly drop. Jellyfin, Vaultwarden, Uptime Kuma, and Netdata all competed for the same congested airspace on a single chip with no hardware VPN acceleration.

The GL.iNet team sent over their newest flagship: the GL.iNet Slate 7 Pro (GL-BE10000). This is a full month of daily homelab use, not a weekend unboxing impression.

🛒

Exclusive deal for ValtersIT readers — Wi-Fi 7 Flash Sale
Affiliate link · I earn a commission at no extra cost to you

View Deal →

Hardware: GL-BE10000 Specifications

Component	Specification
SoC	MediaTek MT7988A (Filogic 880), 4× Cortex-A73 @ 2.0 GHz
RAM	1 GB DDR4
Flash	512 MB NAND
2.4 GHz	802.11be, 2×2 MIMO, up to 688 Mbps
5 GHz	802.11be, 4×4 MIMO, up to 2882 Mbps (160 MHz)
6 GHz	802.11be, 4×4 MIMO, up to 5764 Mbps (320 MHz)
MLO	Multi-Link Operation — bonds all 3 bands simultaneously
Ethernet	2× 2.5 Gbps (WAN/LAN configurable)
USB	USB 3.0 Type-A + USB-C PD power
Display	2.8" color IPS touchscreen
Cooling	Active fan (thermostat-controlled)
WireGuard	1100 Mbps (hardware-accelerated)
OpenVPN-DCO	1000 Mbps (kernel-space acceleration)
OS	OpenWrt 23.05 + GL.iNet Panel

Why the MediaTek MT7988A (Filogic 880) Matters

The Filogic 880 includes dedicated hardware acceleration for both WireGuard and OpenVPN-DCO — the same silicon class used in mid-range enterprise APs. The 1100 Mbps WireGuard figure is real and repeatable under load, not a zero-client theoretical number.

With 1 GB DDR4, you can comfortably run AdGuard Home with 2M+ blocklist entries (~180 MB resident), a WireGuard server with 10+ clients, and several OpenWrt packages simultaneously. Consumer routers at 256 MB RAM struggle with just one of those tasks.

SSH Access and OpenWrt Configuration

Every GL.iNet UI setting maps directly to UCI config files under /etc/config/. Vendor UIs change; OpenWrt config is stable and fully scriptable.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

IPv6 in Production: Dual-Stack Without Breaking IPv4

Hugo | DevOps | Cybersecurity — Thu, 05 Nov 2026 15:15:04 +0000

You enabled IPv6 on a Friday afternoon. The change window was clean, the ip -6 addr output looked right, smoke tests passed. By Monday, half your monitoring was green and lying to you. Your blackbox exporter was happily probing https://10.0.4.12/health over IPv4 while user traffic from mobile carriers — which are all v6-first now — fell over a cliff on a path your dashboards never touched.

That is the defining property of dual-stack failure: it doesn't break IPv4 loudly. It breaks it silently, by making IPv6 preferred (RFC 6724 address selection) and then failing on a path nobody instrumented. A broken v6 route doesn't lose to a working v4 route — it wins, and then it times out.

This guide is for sysadmins, SREs, and network/security engineers running real infrastructure. By the end you'll have working configs for Linux hosts, nginx, HAProxy, systemd-resolved, and nftables, plus a rollout order that keeps you off the 3am page. The thesis throughout: dual-stack is a policy problem disguised as a config problem. Happy Eyeballs, DNS AAAA leaks, and asymmetric firewall rules are where you actually get burned — not in ip addr add.

:::note[TL;DR]

IPv6 is preferred by the kernel's address selection; a broken v6 path silently beats a working v4 path. Instrument both or you're blind.
Write your firewall once in the inet family. Two parallel rule sets is a drift bug waiting to happen.
AAAA is a traffic switch. Sequence it: infra → monitoring → internal DNS → canary → full publish.
Never block ICMPv6 types 1–4 and 128–136. You will break PMTUD and neighbor discovery.
Have a five-minute AAAA rollback before you publish anything. :::

Prerequisites

A Linux host with a v6-capable kernel (any modern distro; check ip -6 addr returns something).
nftables (the default on current Debian/Ubuntu/RHEL families; iptables-nft shim is fine but write native nft).
nginx and/or haproxy if you're fronting traffic.
systemd-resolved or a resolver you control, for split-horizon testing.
A lab GUA (global unicast) allocation or a Hurricane Electric tunnel if your uplink has no native v6. Do not test on production first.

1. Why Dual-Stack Fails Quietly

The failure mode is baked into the standard. When a host resolves both an A and an AAAA record, the kernel's getaddrinfo ordering (RFC 6724) puts IPv6 first. Applications that don't implement Happy Eyeballs — and plenty don't — connect to the v6 address, wait for the TCP timeout, and never fall back. Even Happy Eyeballs is a client-side heuristic with roughly a 250ms head start, not a contract; servers and middleboxes still lie about reachability.

The three silent killers:

Happy Eyeballs is not a guarantee. It's a race with a head start. If your v6 path black-holes packets (as opposed to sending RST), the client may still win the race to a broken socket.
DNS AAAA asymmetry. Your internal resolver hands out AAAA for a host that has no v6 route back. Traffic goes into a hole.
Firewall default-deny on v6 only. You carried v4 rules over but never wrote v6 equivalents — so v6 is either silently wide open or fully blocked, depending on your default policy.

Before anything else, confirm the kernel is actually doing v6 and understand what an address/route looks like:

# Confirm v6 is enabled and see the address + route reality
sysctl net.ipv6.conf.all.disable_ipv6
ip -6 addr show dev eth0
ip -6 route show default

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ntopng Traffic Analysis: Finding Bandwidth Hogs

Hugo | DevOps | Cybersecurity — Wed, 04 Nov 2026 15:15:04 +0000

ntopng Traffic Analysis: Finding Bandwidth Hogs Without Losing Your Mind

It's 3:14 AM. PagerDuty fires. The WAN link on your primary DC is pinned at 98% and has been for 40 minutes. You SSH into the edge router, run show interface GigabitEthernet0/0/0, and see... bytes. Lots of bytes. No idea who. You open a second terminal, run iftop, watch it scroll for ten minutes, and learn exactly nothing actionable. Meanwhile the on-call Slack channel fills with "is it the network?" from people who should know better.

This is the failure mode ntopng exists to eliminate. Flow-based analysis tells you who is talking, to whom, over what protocol, and for how long — in seconds, not after a packet capture marathon. Packet capture has its place (deep forensics, payload inspection, protocol debugging), but for the question "what is eating my bandwidth right now," flows win every time.

This guide is for sysadmins, NetOps, and SecOps engineers who already know their way around a terminal. By the end you'll have a working ntopng deployment, flow export from your edge, dashboards that answer real questions, alerting that doesn't fire on noise, and a mental model for scaling it. If you're still running show interface in a loop as your bandwidth strategy, this is for you.

:::note[TL;DR]

ntopng is an analysis layer, not a flow store. Pair it with ClickHouse or InfluxDB for anything past a week of retention.
Flow export (NetFlow/IPFIX/sFlow) scales; direct packet capture does not. Use flows for capacity, packets for forensics.
Default thresholds are wrong for your environment. Baseline for two weeks, then set alerts at 3σ.
Never expose port 3000 to the internet. Reverse proxy with auth or don't bother.
Bandwidth analysis is a security control. The crypto miner you didn't notice is a bandwidth hog you did notice. :::

Prerequisites

A Linux host (Debian 12, Ubuntu 22.04/24.04, or RHEL 9) with at least 4 vCPU, 8 GB RAM, and 100 GB SSD for a small-to-mid deployment.
Docker and Docker Compose v2 (for the recommended install path).
A router or switch capable of NetFlow v9, IPFIX, or sFlow export.
Root or sudo on the collector host, and the ability to open UDP 2055 (NetFlow/IPFIX) and 6343 (sFlow).
Basic familiarity with Redis and a time-series database — you'll be running both.

Why ntopng and Not the Other Twelve Tools

The tooling landscape for traffic analysis is crowded and mostly mediocre. nfdump/nfsen is fast and scriptable but has a UI from 2008 and no real-time view worth using. Elastic with Packetbeat is fine until you discover the ingest cost of doing it at line rate. PRTG and SolarWinds NTA are commercial products priced for enterprises that mostly want a checkbox. Wireshark is a protocol analyzer, not a monitoring platform — using it for capacity analysis is like using a microscope to survey a highway.

ntopng wins because it does real-time flow analysis with a usable UI, ships with Lua scripting for custom logic, has built-in alerting, and deploys in under ten minutes. It loses because long-term retention is genuinely weak — the built-in timeseries is fine for days, not months. Treat it as the analysis layer and push history somewhere else.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

ZimaBoard Home Server: Pushing the Celeron N3450

Hugo | DevOps | Cybersecurity — Mon, 02 Nov 2026 15:15:04 +0000

ZimaBoard as a Home Server: Pushing the Celeron N3450 to Its Limits

Everyone buys a ZimaBoard, slaps Proxmox on it, and then wonders why the thing falls over at 40°C ambient in a closet with the door shut. I've watched this exact failure mode play out more than once — including the time a ZimaBoard happily ran 14 containers for three months until someone enabled a single Jellyfin transcode and the box went from "fine" to "unresponsive" in about ninety seconds. The iGPU couldn't keep up, the CPU pegged at 100% across all four cores, and the OOM killer started eating services one by one.

This guide is for the sysadmin or security engineer who already owns a ZimaBoard (or is about to) and wants to know where the actual wall is — not the marketing wall. The N3450 is a 6W TDP, 4-core, no-HyperThreading Apollo Lake chip with 8GB of soldered LPDDR4. It is not a NUC. It's a router-class SoC with delusions of grandeur. Treat it like what it is and it will serve you faithfully for years. Treat it like a mini server and it will teach you about thermal throttling.

By the end you'll know which workloads fit, how to budget memory, how to boot safely, how to network the thing, and the exact signals that mean it's time to upgrade.

:::note[TL;DR]

The N3450 is memory-bound at 8GB, not CPU-bound. Plan around RAM first.
Boot from SATA SSD, never eMMC. eMMC is a landmine with a TBW countdown.
Bare Docker on Debian beats Proxmox on this box for 90% of use cases.
The HD 500 iGPU does H.264 QuickSync; HEVC is partial, AV1 is a hard no.
If you need more than two simultaneous 1080p transcodes, stop reading and buy a used SFF. :::

Prerequisites

A ZimaBoard (model 216 or 832; the 832's dual GbE and SATA are worth the extra)
A SATA SSD (120GB minimum, 240GB+ recommended) and a SATA data + power cable
Debian 12 netinst USB stick
Basic familiarity with systemd, docker, and netplan
A second machine to SSH from — you will lock yourself out at least once

Know Your Silicon: What the N3450 Actually Is (and Isn't)

The spec sheet lies by omission. Knowing what the silicon can't do saves you from building a workload it will never survive.

The Spec Sheet vs. Reality

The Celeron N3450 is a 4-core/4-thread Apollo Lake (Goldmont) part running 1.1GHz base with 2.2GHz burst, 6W TDP, 2MB L2, and an Intel HD 500 iGPU with 12 execution units. There is no AVX, no HyperThreading, and the PCIe lanes are gen 2.0. The 8GB of LPDDR4 is soldered — non-ECC, non-upgradeable. That last point is the one that matters.

Storage reality: one SATA III port, one eMMC module (usually 32GB), and an M.2 2242 slot that is not NVMe on all revisions — check your board revision before you buy an M.2 drive, because some ZimaBoards ship with SATA-only M.2.

The Memory Ceiling Is the Real Ceiling

8GB is the binding constraint, full stop. The CPU will happily idle at 5% while the OOM killer is murdering your Postgres container because ZFS ARC decided it wanted 4GB of your RAM for cache. If your plan includes ZFS, ARC will eat your RAM and your soul. On a box this size, use ext4 or XFS on the SSD and put your snapshot strategy at the application layer (restic, borg, whatever), not the filesystem layer.

zram is your friend. Swap-on-ZFS is suicide — it causes write amplification that will kill your SSD and thrash the CPU simultaneously.

Thermals and the Passive-Cooling Lie

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

VLAN Design Patterns: Segmenting IoT, Servers, and Management Traffic

Hugo | DevOps | Cybersecurity — Sun, 01 Nov 2026 15:15:04 +0000

The printer was on the same Layer 2 segment as the domain controllers. Default admin password, firmware from 2016, web UI reachable from every workstation in the building. When the incident response team pulled the ip neigh table off the core switch, the "oh no" moment wasn't a single compromised host — it was 340 devices in one broadcast domain, all of them one ARP spoof away from talking to each other. The attacker didn't need a zero-day. They needed the printer, and the printer was already inside the perimeter.

This guide is for the sysadmin or network engineer who inherited a flat 192.168.1.0/24 and a prayer, and now has to explain to leadership why segmentation is not optional. By the end, you'll have a four-zone model you can actually deploy, a VLAN numbering schema that survives a staff turnover, and the firewall and switch configs to enforce it. I've done this migration in regulated environments and in shops that had exactly one switch and no budget. Both are solvable.

The flat network is a liability, not a convenience. Every device can ARP-spoof every other device. Every broadcast is a blast radius. Ransomware crews know this — lateral movement across a flat L2 is the easiest part of their playbook, and Mirai-style IoT botnets have been turning cameras and DVRs into pivot points since 2016. Segmentation is the cheapest lateral-movement control you're not using.

:::note[TL;DR]

Four zones cover 95% of orgs: Management, Servers, Clients, IoT/Untrusted. More zones mean firewall rule sprawl and troubleshooting hell.
Every inter-zone flow goes through a firewall. L3 switch routing is fine within a zone, never between zones.
Management VLAN holds switch mgmt, IPMI, iDRAC, iLO, and PDUs — reachable only from a jump host.
IoT is hostile. Treat it like the internet: internet egress allowed, RFC1918 denied, log everything. :::

Prerequisites

Before you touch a switch, have the following ready:

IPAM tool — NetBox, phpIPAM, or even a disciplined spreadsheet. You need a source of truth before you create VLAN 20.
A firewall that can route — pfSense/OPNsense, Palo Alto, Fortinet, or an L3 switch with ACLs if that's all you have.
Console access to your switches — you will lock yourself out at least once. Have the console cable and the serial adapter.
A maintenance window — yes, even for "just adding a VLAN." You are changing the default gateway for devices.
Inventory of every device with its current IP, MAC, and what it talks to. nmap -sn and arp -a are your friends here.

Why Flat Networks Keep Getting People Fired

The 192.168.1.0/24 that "just works" works right up until it doesn't. A single broadcast domain means every device can reach every other device at Layer 2 — no firewall, no ACL, no logging, no policy. When the incident response team asks "how did the attacker move from the HVAC controller to the file server," the answer is "they were on the same VLAN."

The war story I keep coming back to: a mid-sized manufacturer had a networked label printer on the same segment as their ERP servers. The printer's web interface had a default credential that nobody changed because "it's just a printer." An attacker used it as a foothold, dumped the ARP table, and had a map of every internal host within minutes. The printer was the entry point; the flat network was the multiplier.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Consul Connect: Service Discovery and mTLS Without Kubernetes

Hugo | DevOps | Cybersecurity — Thu, 29 Oct 2026 15:15:07 +0000

A team I worked with inherited a 40-node VM fleet, three Kubernetes clusters, and a mandate to "adopt a service mesh." They picked Istio because that's what the conference talks said. Six months later they were still debugging sidecar injection edge cases on the VM workloads — workloads that Istio had no clean story for in the first place. The mesh project got cancelled. The underlying problem — services couldn't find each other reliably and everything talked in plaintext — was still there.

Here's the thing nobody tells you: service discovery and mutual TLS are orthogonal to orchestration. You can do both without a control plane welded to Kubernetes. Consul treats them that way, which is exactly why it fits the "unholy hybrid" environments most of us actually run.

This guide is for engineers who need a working mesh across VMs, bare metal, and maybe some K8s — and want to know what it takes to run Consul Connect for real. By the end you'll be able to bootstrap a TLS-and-ACL-hardened cluster, register services with honest health checks, enable mTLS with sidecars, and write intentions that survive an audit.

:::note[TL;DR]

Consul Connect gives you service discovery plus mTLS with intentions as the authz layer — no Kubernetes required.
Harden from day one: gossip encryption, RPC TLS, and ACL bootstrap before you expose the API. "We'll add ACLs later" is a lie you tell yourself.
Intentions are identity-based allow rules that work cross-platform; firewalls are still your outer perimeter.
Transparent proxy mode is powerful and will lock you out of SSH if you don't exclude the lifeline ports.
Snapshot, restore-drill, and watch Raft — uptime is not the same as health. :::

Prerequisites

Consul 1.16 or newer (check the official docs for the current release; the CLI and config surface described here are stable across recent 1.x).
Three hosts for servers with reliable clocks and low-latency networking between them.
Root or sudo on target hosts for transparent proxy mode.
Optional but recommended: Vault or cert-manager for cert lifecycle, and S3 (or equivalent) for snapshot storage.

Why You Probably Don't Need Istio

The cargo cult is real: "service mesh" has been quietly redefined to mean "Kubernetes-native service mesh." That framing is a vendor convenience, not a technical truth. Istio and Linkerd are excellent — inside a single, well-behaved K8s cluster. The moment you have workloads Istio can't inject into cleanly (legacy VMs, appliances, cron boxes, that one Java app nobody will touch), you're either excluding them from the mesh or paying a tax in glue code.

Consul's bet is that discovery and mTLS are platform-agnostic primitives. Agents run anywhere a process runs. Servers form a Raft cluster. Sidecars are just Envoy processes. Nothing in that chain requires a scheduler.

Be honest about when Consul is the wrong answer: if you're 100% Kubernetes and happy with Istio or Linkerd, stay there. If you have a small static environment where a config file and a reverse proxy would do, you don't need a mesh at all. Consul's complexity is real; the payoff is cross-platform uniformity. If you don't need that uniformity, don't pay for it.

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

Wazuh SIEM: Deploy Open Source Threat Detection

Hugo | DevOps | Cybersecurity — Wed, 28 Oct 2026 15:15:07 +0000

If your threat detection strategy is "wait for the SOC vendor to email us," you don't have one. You have a hope. I've watched a mid-size SaaS company pay six figures a year for a commercial SIEM and still miss a compromised WordPress plugin for eleven days — because the detection rules that would have caught it were behind a premium content pack nobody bought. Meanwhile, a two-node Wazuh cluster on hardware they already owned flagged the same class of behavior in under four minutes. That's the entire pitch: detection coverage is a function of rules and telemetry, not licensing.

This guide is for engineers who already know what a SIEM is and are tired of the "just use the Docker compose, it's easy" blog posts that fall apart the moment you point 200 production agents at them. By the end you'll be able to size a distributed Wazuh deployment, install it without painting yourself into a corner, write and tune detection rules that don't drown your on-call, scope FIM so it doesn't melt your manager, set retention on day one, and route alerts to humans who will actually act on them.

:::note[TL;DR]

Wazuh is a detection platform — HIDS, FIM, SCA, log analysis, and vulnerability detection in one stack. It is not a detection strategy; you still have to tune it.
Skip the all-in-one VM for anything real. Distributed Manager/Indexer/Dashboard is the only topology that survives contact with production.
The OpenSearch fork dependency is the biggest operational liability — plan your index lifecycle and upgrade path before you install.
Tune rules or die. Out-of-the-box Wazuh will happily generate 10k alerts a day and teach your team to ignore all of them. :::

Prerequisites

Two or more Linux hosts (Ubuntu 22.04 LTS or RHEL/Rocky 9 recommended) with static addresses and a management VLAN.
Root or sudo on all nodes. Wazuh's manager runs privileged daemons that read system logs — treat it accordingly.
A DNS name for the dashboard and API, plus a decision on TLS (self-signed certs from the installer are fine to start, not fine forever).
Working knowledge of systemd, firewalld/nftables, and OpenSearch basics. If you've never tuned a JVM heap, read the sizing section twice.
Roughly 8 GB RAM minimum for a lab; 32 GB+ per indexer node for production. More on that below.

What Wazuh Actually Is (And Isn't)

Wazuh is four things bolted together: a manager (the rule engine and agent coordinator), an indexer (an OpenSearch fork that stores alerts), a dashboard (a Kibana fork), and agents (the shippers on your hosts). The data flow is strictly one direction — agents talk to the manager on 1514/tcp, the manager forwards alerts to the indexer via Filebeat, and the dashboard reads from the indexer. If you understand that pipeline, you understand 80% of Wazuh's operational behavior.

  [Agent] --1514/tcp--> [Manager] --Filebeat--> [Indexer] <-- [Dashboard]
     |                     |  (1515 enrollment)      |            (443)
     |                     |                        |
  syscheck,             rules/decoders,        wazuh-alerts-*
  logcollector,         vulnerability feed,    wazuh-archives-*
  SCA, rootcheck        integratord

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/

What Is Tailscale? The VPN That Doesn't Suck

Hugo | DevOps | Cybersecurity — Tue, 27 Oct 2026 15:15:04 +0000

What Is Tailscale? The VPN That Doesn't Suck

The last time you configured OpenVPN, you spent three hours debugging a certificate chain, another two fighting tun vs tap, and then had to explain to your CTO why the "secure" tunnel was routing all remote traffic through a single t3.micro in us-east-1 that was already at 90% CPU from a runaway log shipper.

That's not a VPN. That's a distributed denial-of-service attack you're paying for.

Tailscale is WireGuard with a control plane, an identity layer, and NAT traversal that actually works. It is not magic. It is simply well-engineered, and that's rarer than it should be.

This guide is for sysadmins, DevOps engineers, and security engineers who've been burned by OpenVPN or IPsec and want to understand what Tailscale actually does under the hood — not the marketing version. By the end, you'll know how the control plane and data plane split works, how to roll it out on real infrastructure with tags and ACLs, where the production footguns live, and when Tailscale is the wrong tool.

We're not going deep on DERP internals or enterprise pricing negotiation. Those are separate posts.

:::note[TL;DR]

Tailscale = WireGuard data plane + a coordination server that handles key exchange, NAT traversal, and ACL distribution. Your traffic does not flow through Tailscale's servers except via DERP relays when direct connections fail.
The value isn't the protocol — WireGuard is ~4000 lines of C. The value is identity, ACLs, and the ops surface.
Tags are ACLs. Untagged nodes are owned by a user; tagged nodes are owned by the tailnet. Never tag a laptop.
The default ACL allows every node to reach every node. In prod, that is a security incident waiting for a calendar invite.
If you're running raw WireGuard at scale, you've rebuilt 60% of Tailscale badly. If you're running OpenVPN in 2026, you're paying an ops tax for no benefit. :::

Prerequisites

Root or sudo on Linux nodes you plan to enroll
An identity provider you actually control (Google Workspace, Okta, Entra ID, GitHub org) for SSO
A tailnet — the free tier supports 3 users and 100 devices, which is fine for a homelab and useless for anything else
Basic familiarity with CIDR notation and firewall rules, because subnet routers will force you to remember

The VPN Landscape Is a Dumpster Fire (And Why)

Before we talk about what Tailscale does right, we need to be honest about why the previous generation of VPNs is so painful. It's not that IPsec and OpenVPN are bad protocols — it's that they were designed for a world that no longer exists.

IPsec — The Protocol That Requires a PhD to Debug

IPsec was designed for site-to-site tunnels between two static endpoints that trusted each other. It was never designed for a laptop that roams between coffee shops, home Wi-Fi, and a hotel captive portal. IKEv2 phase 1 and phase 2 negotiate security associations in a way that makes sense to a cryptographer and is inscrutable to anyone trying to debug why a tunnel won't come up at 2 AM.

I once spent a full day on a Cisco ASA because someone typed esp-aes instead of esp-aes-256. The logs told us nothing useful. The tunnel came up. Traffic didn't flow. The fix was a single token in a config file, and the cost was eight hours of a senior engineer's time.

OpenVPN — Works Everywhere, Fast Nowhere

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/