DEV Community: Hugo | DevOps | Cybersecurity

Network Segmentation: VLANs and Firewall Rules for Service Isolation

Hugo | DevOps | Cybersecurity — Fri, 24 Jul 2026 14:15:04 +0000

I've spent 15 years cleaning up the aftermath of flat networks. The worst was a 2020 incident where a Redis instance, left exposed on the default VLAN, became an attacker's highway. Within four hours, they'd pivoted through 200+ VMs, exfiltrated customer data, and planted cryptominers across three availability zones. The CISO's words still echo: "We thought the firewall at the edge was enough."

This guide is for platform engineers and DevOps teams who've outgrown the "just add a security group" mindset. You'll learn how VLANs and firewall rules actually work together—not just theory, but production-hardened configs that prevent lateral movement. By the end, you'll be able to design a segmented network that contains breaches instead of amplifying them.

:::note[TL;DR]

Flat networks are indefensible; one compromised service becomes your entire blast radius.
VLANs provide Layer 2 isolation, but firewall rules enforce actual access control between segments.
Group services by trust level, not by count—"one VLAN per service" creates management hell.
Egress filtering catches 90% of breaches; allow-all-outbound is a sieve.
Automate everything with IaC; hand-jammed rules are technical debt with interest.
Test segmentation monthly with port scans—trusting your config is how breaches happen. :::

Prerequisites

Access to a network device (Cisco IOS, Linux bridge, or cloud VPC) for VLAN configuration
Basic understanding of OSI model layers 2-4
A firewall platform (iptables/nftables on Linux, or cloud-native like AWS Security Groups)
nmap and tcpdump installed on test machines for verification
Terraform or similar IaC tool if automating (recommended)

Why Segmentation Matters — The "Flat Network is a Crime" Argument

A flat network is the architectural equivalent of putting all your servers in one room with the door unlocked. It's convenient for the first deployment, but the moment an attacker finds one vulnerability—an unpatched web app, a Redis without auth, a Jenkins with default creds—they own everything. Lateral movement becomes trivial because there are no boundaries to cross.

The principle is simple: least privilege applied to the network layer. Every service should only talk to exactly what it needs, on exactly the ports required, and nothing else. This isn't paranoia—it's physics. You cannot defend what you cannot isolate.

Q: "But my startup has 5 services—do I really need VLANs?"
Yes. You won't stay a startup forever, and retrofitting segmentation into a production network is a nightmare that involves downtime, broken dependencies, and late-night rollbacks. Start segmented from day one, even if it's just three VLANs. Your future self will thank you.

VLAN Fundamentals — Not Just for Network Engineers Anymore

What VLANs Actually Do (and Don't Do)

VLANs isolate broadcast domains at Layer 2. That's it. They prevent ARP storms from crossing segments and force traffic through a router for inter-VLAN communication. But they are not encryption, not authentication, and not a security boundary on their own. If you trunk VLANs together without firewall rules, you've built a flat network with extra steps.

Firewall 101: The 'Drop Everything by Default' Manifesto

Hugo | DevOps | Cybersecurity — Sun, 19 Jul 2026 14:15:04 +0000

I once audited a "secure" government-contractor network where the lead admin proudly showed me their $25,000 Next-Gen Firewall. It had every subscription active: AI-powered threat detection, SSL inspection, sandboxing—the works. Then I looked at the bottom of the filter list.

Rule #157: chain=forward action=accept src-address=0.0.0.0/0 dst-address=0.0.0.0/0 comment="Temporary fix for printer issues".

That "temporary fix" had been there for eighteen months. Because the admin couldn't figure out which specific ports the legacy Xerox scanner needed, they just opened the entire network to the entire world. They had spent $25,000 on a gatekeeper, and then handed the keys to everyone on the street because they didn't want to spend twenty minutes reading a packet capture.

If you have a "Permit All" or "Allow Any" rule at the end of your firewall, you don't have a firewall; you have a very expensive, very warm paperweight. You aren't practicing security; you are practicing hope. And in the world of 2026, hope is a remarkably poor defense against a motivated threat actor.

It is time to nuke your rules, embrace the "Default Deny" manifesto, and build a configuration where every single bit of data has to justify its existence before it’s allowed to pass.

The Rant: The "Troubleshooting" Lie

We’ve all heard it: "I’ll just disable the firewall for a second to see if that’s the problem."

That "second" becomes an hour. That hour becomes a weekend. That weekend becomes a year. Most "Permit All" rules are the scars of a sysadmin who got tired of fighting with a vendor’s vague documentation. Instead of doing the work—using tcpdump or the MikroTik Packet Sniffer to see exactly what traffic is being blocked—they take the path of least resistance.

The problem is that once you open that door, you never close it. You forget. Or you're afraid that closing it will break something you don't understand.

A Senior Sysadmin operates under a different philosophy: If I don't understand why a packet is moving, it shouldn't be moving. Security is not a feature you add on top of a working network. Security is the network. If your application doesn't work under a strict "Default Deny" policy, the application is broken, not the firewall.

The Mechanics: The Default Deny Principle

The "Default Deny" principle (also known as "Whitelist-only") is the only sane way to manage a network. In this model, you start with a completely empty routing table and a firewall that drops every single packet.

You then add "Allow" rules for specific, documented needs:

Allow DNS (UDP 53) to your trusted resolvers.
Allow HTTPS (TCP 443) to your web servers.
Allow SSH (TCP 22) only from your Management Jump Box.

Everything else—every random scan, every misconfigured IoT device phoning home, every lateral movement attempt from a compromised laptop—hits the "Implicit Drop" at the bottom of the list and vanishes.

Why "Blacklisting" Fails

Most consumer routers and amateur setups use "Default Allow." They allow everything and try to block "bad" things. This is a losing game. There are billions of "bad" IPs and thousands of "bad" ports. You cannot possibly maintain a list of everything you don't want. You must maintain a list of exactly what you do want.

The Mechanics: Stateful Packet Inspection (SPI)

To run a "Default Deny" firewall without losing your mind, you must use Stateful Packet Inspection.

If You Can't See It, You Can't Fix It: Network Monitoring with SNMP & Grafana

Hugo | DevOps | Cybersecurity — Sat, 18 Jul 2026 14:15:03 +0000

I recently sat in a war room where three senior developers were arguing about whose microservice was causing "latency spikes" in the production environment. They were staring at application logs, debating garbage collection cycles, and re-reading their distributed tracing spans. The CEO was breathing down their necks because the checkout page was taking six seconds to load.

I opened a Grafana dashboard, pointed to a jagged purple line that had hit a flat ceiling at 1,000 Mbps, and said: "Your app is fine. Your backup script is saturating the 1Gbps uplink between the database and the app server."

They looked at me like I was a wizard. I wasn't. I just had the basic decency to monitor my interfaces.

If your "Network Monitoring" strategy consists of waiting for a user to submit a ticket saying "the internet is slow," you are not a sysadmin; you are a reactive fire-fighter, and you are failing at your job. In the world of 2026, "slow" is just a subjective lie told by people who don't have data. Throughput, jitter, and packet loss are the objective truths of a network. If you aren't polling your OIDs and visualizing your traffic in real-time, you are flying a plane in a storm without an altimeter.

It is time to stop guessing and start measuring. It is time to embrace SNMP and the TIG stack.

The Rant: The Observability Gap

Most modern "DevOps" engineers are obsessed with application observability. They have Prometheus scraping every Go binary, they have Loki ingesting every log line, and they have Jaeger tracing every request. But they treat the network as a "given"—a magical, infinite pipe that just works.

Then, one Tuesday at 2 PM, the "Network is Slow" tickets start rolling in.

The reactive admin logs into the router, runs tool profile or top, sees the CPU is at 10%, and tells the user: "The router is fine, it must be your laptop." This is the ultimate sign of incompetence. A router's CPU can be at 10% while its interfaces are being absolutely throttled to death. A switch can be perfectly healthy while a single port is suffering from an MTU mismatch that is causing 40% packet fragmentation.

You cannot manage what you cannot see. If you don't have a 24-hour history of every bit that passed through every port on your core switch, you have no baseline. And without a baseline, you have no way of knowing what "normal" actually looks like.

The Mechanics: SNMP (The "Simple" Protocol That Isn't)

We’ve been using SNMP (Simple Network Management Protocol) since the late 1980s. It is old, it is clunky, it uses ASN.1 (Abstract Syntax Notation One), and its security (at least in version 2c) is a joke. But it is the universal language of hardware.

You can't install a Prometheus exporter or a Datadog agent on a Cisco Catalyst, a MikroTik CCR, or a Juniper backbone. These devices are closed boxes. To get data out of them, you must use SNMP.

1. The OID: The GPS of Data

Everything in an SNMP-enabled device is mapped to an OID (Object Identifier). An OID is a dotted-decimal string that represents a location in a hierarchical tree.

For example: 1.3.6.1.2.1.2.2.1.10.1

1.3.6.1.2.1 is the standard "mib-2" branch.
.2.2.1.10 is the "ifInOctets" (Input Bytes) branch.
.1 is the index of the specific interface.

When you "poll" an SNMP device, you are essentially asking: "Give me the value at this specific coordinate."

MikroTik FastTrack: The Performance Miracle That Breaks Your Firewall

Hugo | DevOps | Cybersecurity — Fri, 17 Jul 2026 14:15:04 +0000

I’ve been working with MikroTik since the days when the "RB" in RB450 stood for a board you had to manually case, and RouterOS was still struggling to figure out how to handle multi-core CPUs. If there is one feature that has caused more confusion, broken more QOS trees, and saved more underpowered ARM/MIPS chips than anything else, it is FastTrack.

It’s the classic sysadmin story: You upgrade a client from a 100Mbps fiber line to a 1Gbps circuit. You plug in their trusty hAP ac2 or an RB4011, and you realize the CPU is pinned at 100% while barely pushing 400Mbps. You go into the firewall, add that magical fasttrack-connection rule, and—boom—the throughput hits 950Mbps and the CPU drops to 15%.

You feel like a god. Until ten minutes later, when the VoIP phones start jittering, the IPsec tunnel to the branch office collapses, and your carefully crafted Mangle rules for traffic shaping stop marking a single byte.

Welcome to the FastTrack trade-off. You didn't just "optimize" your router; you told it to start ignoring its own instructions for 90% of your traffic.

The Mechanics: The "Slow Path" vs. The "Fast Path"

To understand why FastTrack breaks things, you have to understand the Standard Packet Flow in RouterOS (which is built on the Linux kernel's Netfilter/Xtables architecture).

1. The Slow Path (The Standard Flow)

In a standard configuration, every single packet in a stream is inspected. It goes through the prerouting chain, gets checked against the forward filter, passes through the mangle table for marking, hits the queue tree for bandwidth limiting, and finally undergoes postrouting (NAT). This is "The Slow Path." It is incredibly flexible, allowing you to do complex layer-7 filtering or per-connection QOS, but it is CPU-intensive because the kernel has to process every header for every packet.

2. The Fast Path (The Shortcut)

FastPath (the precursor to FastTrack) was the first attempt to skip this. If a packet is simple—no NAT, no firewall rules, no mangle—the kernel just shunts it straight from the input interface to the output interface.

3. FastTrack (The Hybrid)

FastTrack is the "Best of Both Worlds" (theoretically). It works by looking at the first few packets of a connection (the "handshake"). Once the connection is established and the firewall marks it as established,related, the FastTrack handler steps in. It marks that specific connection in the conntrack table.

From that point forward, most subsequent packets in that stream completely bypass the Linux kernel's networking stack. They skip the firewall filter. They skip the mangle table. They skip the queue trees. They are routed at near-wire-speed using minimal CPU cycles.

The Mechanics of the Break: Why Things Stop Working

The reason FastTrack "breaks" your firewall is simple: You can't filter what the CPU never sees.

1. The QOS Death

If you are using Simple Queues or a Queue Tree to prioritize VoIP (DSCP/TOS) or throttle a specific user, those queues rely on the kernel seeing the packets to calculate the bandwidth and enforce the limit. Because FastTracked packets bypass the queueing subsystem, your QOS rules become invisible. Your "guaranteed" 5Mbps for the SIP trunk is now competing for air with a FastTracked Steam download.

Port Forwarding is a Relic: Why You Should Nuke Your WAN-Facing Rules

Hugo | DevOps | Cybersecurity — Thu, 16 Jul 2026 14:15:03 +0000

I recently audited a "prosumer" home-office network for a developer who was quite proud of his setup. He had a top-of-the-line router, a 24-bay NAS, and a rack full of micro-servers. When I looked at his NAT configuration, I saw a list of twenty-five port forwarding rules.

Port 32400 for Plex. Port 8123 for Home Assistant. Port 25565 for a Minecraft server. Port 22 for SSH (but moved to 2222, because he’s "clever"). Port 80 and 443 for a reverse proxy.

I asked him, "Do you enjoy hosting a public arcade for the world's botnets?"

He looked at me like I was the crazy one. "It’s convenient," he said. "I can access my files from anywhere."

If your definition of "convenience" involves leaving twenty-five unlocked windows in your house and hoping nobody notices the one that leads directly to your jewelry box, then sure, port forwarding is great. But in the world of 2026, where automated scanners map the entire IPv4 space in hours and zero-day vulnerabilities in common consumer apps drop weekly, port forwarding is an architectural relic that needs to be nuked from orbit.

The Mechanics: The Shodan Spotlight

To understand why your "obscure" port forwarding rules are a disaster, you have to understand that "security through obscurity" is a myth that died twenty years ago.

1. The 45-Minute Window

The second you open a port on your WAN interface, you aren't just letting your phone connect to your Plex server. You are announcing your presence to every automated scanner on the planet. Tools like ZMap and Masscan allow attackers to probe the entire internet for specific open ports in under an hour.

Services like Shodan and Censys do the work for them. They don't just see that port 8123 is open; they perform banner grabbing. They identify that you are running Home Assistant version 2024.1.2. They see your SSL certificate. They fingerprint your OS. Within minutes of a port being opened, your IP address is indexed in a searchable database of vulnerable targets.

2. The Pre-Auth RCE Nightmare

You might think, "Well, my Home Assistant has a strong password." That doesn't matter if there is a vulnerability in the web server handling the request.

History is littered with pre-authentication Remote Code Execution (RCE) vulnerabilities in "safe" applications. Remember the Plex vulnerabilities? The QNAP ransomware outbreaks? The endless stream of PHP exploits? If an attacker can trigger a buffer overflow or a path traversal before the login prompt even appears, your "strong password" is about as useful as a screen door in a hurricane.

Once an attacker gets code execution on that one internal service, they are inside your network. They are sitting on your local VLAN. From there, they can sniff traffic, pivot to your unpatched printer, or use your NAS as a staging ground for a ransomware attack on your entire house or office.

The Fix: The VPN-Only Model

The Senior Sysadmin approach to remote access is binary: Zero open ports on the WAN. In 2026, there is absolutely zero justification for exposing a web UI or a game server directly to the internet. We have reached a point where VPN technology is faster, lighter, and more secure than it has ever been.

1. The Stealth of WireGuard

If you must open exactly one port, it should be for WireGuard. WireGuard is the gold standard of modern VPNs. It is incredibly fast, it runs in the kernel, and most importantly, it is "silent."

Proxy vs VPN: Stop Confusing Privacy with Security

Hugo | DevOps | Cybersecurity — Wed, 15 Jul 2026 14:15:03 +0000

I recently had a conversation with a developer who was convinced their home network was "fully secured" because they had a "VPN" extension active in Chrome. They were browsing a sensitive site in one tab while, in the background, their Windows OS was dutifully phoning home to Microsoft, their Discord client was leaking their actual public IP via WebRTC, and their Steam client was downloading a 40GB update over their unencrypted ISP gateway.

When I pointed this out, they were baffled. "But the icon in my browser is green!" they said.

This is the result of a decade of predatory marketing by "VPN" companies that sell glorified SOCKS5 or HTTP proxies as "System-wide Security Solutions." If you think a browser extension is a VPN, you aren't just wrong; you are operating under a false sense of security that is more dangerous than having no protection at all. In the world of networking, a proxy and a VPN are two fundamentally different tools designed for two fundamentally different jobs.

It’s time to look at the OSI model, stop trusting "one-click" solutions, and understand why your operating system is still snitching on you.

The Rant: The "Browser VPN" Scam

Let’s get one thing straight: If you only installed it in your browser, it is not a VPN.

A real Virtual Private Network (VPN) creates a virtual network interface at the OS level. It intercepts every single packet leaving your computer, regardless of which application generated it. A browser extension, by definition, is confined to the sandbox of the browser. It is a proxy—usually an HTTPS or SOCKS5 proxy—that tells the browser to route its specific requests through a middleman server.

The marketing departments of these companies use the term "VPN" because "Proxy" sounds like something from 1998. They know "VPN" sells subscriptions. But for a Senior Engineer, this distinction is critical. If your "VPN" doesn't have a tun0 or wg0 interface in your ifconfig or ipconfig output, you are just using a proxy. Your background system telemetry, your OS updates, your CLI tools (curl, wget, ssh), and your other desktop applications are all still naked on the public internet.

The Mechanics: Layer 3 vs. Layer 7

To understand why this matters, we have to look at the OSI (Open Systems Interconnection) Model. This isn't just academic fluff; it is the blueprint of how data moves across the wire.

1. Proxies: The Layer 7 (Application) Approach

A proxy works at the Application Layer. When you use an HTTP proxy, your browser doesn't just send raw packets; it sends a specific request to the proxy server: "Please fetch example.com for me." The proxy server then makes that request on your behalf, gets the result, and passes it back to you.

The Benefit: It’s incredibly lightweight. There is no complex encryption handshake for the whole system. You can have 50 different proxies for 50 different browser tabs.
The Failure: It only understands the protocol it was built for. An HTTP proxy won't handle your BitTorrent traffic. A SOCKS5 proxy won't help your DNS requests unless specifically configured. Crucially, it doesn't encrypt your traffic between the app and the proxy unless the proxy itself uses HTTPS (which many don't).

2. VPNs: The Layer 3 (Network) Approach

A VPN works at the Network Layer. It doesn't care about "requests" or "websites." It only cares about Packets.

SSH Tunneling: The Swiss Army Knife of Networking You're Not Using

Hugo | DevOps | Cybersecurity — Tue, 14 Jul 2026 14:15:03 +0000

I recently watched a DevOps team spend three days arguing over the routing tables of a new WireGuard Site-to-Site tunnel. They just wanted to give a single developer access to a staging Prometheus dashboard that was sitting on a private subnet behind an ivory tower of firewalls. Three days of YAML, routing conflicts, and security group adjustments for a task that could have been solved in three seconds with a single CLI command.

I walked over, typed ssh -L 9090:localhost:9090 staging-gw, and the dashboard was live on their local machine.

"Is that secure?" they asked.

If you don't trust the SSH tunnel you’re already using to manage the server, you have much bigger problems than a port forward.

In the era of "Zero Trust" and complex overlay networks, we’ve forgotten the raw, elegant power of the SSH tunnel. It is the Swiss Army Knife of networking. It bypasses firewalls, encrypts insecure protocols, and punches through NAT like a hot knife through butter. But it also has sharp edges. If you don't understand the difference between -L and -R, or if you try to use it as a permanent networking backbone, you’re going to find out exactly why "TCP-over-TCP" is a phrase that makes veteran network engineers break out in a cold sweat.

The Rant: The Over-Engineered VPN Trap

We have become obsessed with infrastructure as a service. We want a "solution" for everything. Need to access a database? "Deploy a VPN." Need to bypass a proxy? "Set up a SASE gateway."

Don't get me wrong; VPNs have their place (as I've written about extensively). But for the surgical, temporary, or emergency tasks that define the life of a Senior Sysadmin, a VPN is a sledgehammer where a scalpel is required.

The SSH daemon is already there. It’s audited, it’s hardened, and it’s already authenticated. Using it for port forwarding isn't "hacking" the system; it’s using the protocol for exactly what it was designed to do: provide a secure channel for data.

If you are setting up a 50-node mesh network just so one person can check a phpMyAdmin page on a legacy server, you aren't being "secure"—you're being inefficient.

The Mechanics: How SSH Port Forwarding Works

At its core, SSH tunneling is about Encapsulation. You are taking a raw TCP stream from a local or remote port and wrapping it inside the encrypted SSH session. The SSH client and server act as the "entry" and "exit" points for these packets.

There are three primary types of tunnels you need to master. If you have to look at the man page every time you use them, you haven't been in the trenches long enough.

1. Local Port Forwarding (`-L`): The "Pull"

Local forwarding is used when you want to access a service on a remote network as if it were running on your local machine.

The Syntax: ssh -L [local-address:]local-port:remote-host:remote-port server

Imagine a database server (db-internal) that only listens on localhost:3306 for security reasons. You are sitting at home, connected via SSH to a jump box (gateway).

When you run ssh -L 3306:db-internal:3306 gateway, your local SSH client starts listening on localhost:3306. When your local DB tool connects to localhost:3306, the SSH client intercepts the packets, encrypts them, sends them through the tunnel to the gateway, and the gateway then opens a connection to db-internal:3306.

Proxmox SDN: Multi-Node Cluster Networking

Hugo | DevOps | Cybersecurity — Mon, 13 Jul 2026 14:15:04 +0000

Introduction – Why SDN in Proxmox Isn’t Just a Buzzword

I watched a junior admin bring down a 12-node production cluster for four hours during a maintenance window because he copy-pasted bridge configs from Node A to Node B without realizing Node B had a different physical NIC naming scheme. The VLAN tags were off by one on three bridges. Live migrations failed silently for two weeks before we noticed.

That's the problem with traditional Linux bridges in multi-node Proxmox clusters: every node's /etc/network/interfaces is a snowflake. VLAN tagging drifts across hosts. Manual edits accumulate like technical debt. And when a VM live migration fails because the target node's bridge doesn't have the right VLAN trunked, you're left explaining to management why "just move the VM" isn't that simple.

Proxmox SDN solves this by separating network policy from physical topology. Instead of editing config files on each node, you define zones, VNets, and subnets once—cluster-wide. The SDN controller pushes that config to every node. Your bridges become consistent, migrations work, and you stop waking up at 3 AM for VLAN tag mismatches.

This guide covers building a resilient, multi-tenant SDN with VXLAN and VLAN zones. No hand-holding. No "just works" marketing. Just what I've learned from breaking and fixing Proxmox clusters in production since VE 7.4.

:::note[TL;DR]

Traditional bridge configs per node cause drift and migration failures in multi-node clusters
Proxmox SDN centralizes network config across all nodes via /etc/pve/sdn/
VXLAN zones support 16 million segments vs VLAN's 4096—use VXLAN for clusters >3 nodes
Live migrations work reliably with VXLAN but require identical peer configs on all nodes
Missing ifupdown2 package causes SDN changes to be silently ignored :::

Prerequisites

Proxmox VE 7.4+ or 8.x (tested on 8.2)
Cluster with 3+ nodes (quorum required for SDN changes)
L3 connectivity between all cluster nodes
ifupdown2 package installed on every node (apt install ifupdown2)
Physical switch MTU >= 1550 if using VXLAN (1500 + 50 byte overhead)
IGMP snooping enabled on switches if using VXLAN multicast

Proxmox SDN Architecture – The 30,000-Foot View (Without the BS)

Core Components – Zones, VNets, Subnets, and IPAM

Proxmox SDN has four building blocks. Understanding them before you touch the GUI saves hours of debugging.

Zone: Defines the transport mechanism. Options are vlan, vxlan, qinq, or simple. Pick one transport per zone—mixing them in the same zone causes pain I won't wish on anyone.

VNet: A logical network segment—think of it as a virtual switch. Create one VNet per tenant or workload type. I use prod-web, prod-db, dev-app naming.

Subnet: An IP range within a VNet. Must use CIDR notation and must be unique across the entire cluster. Overlap subnets between VNets? You'll get routing chaos.

IPAM: Proxmox's built-in IP address management. Optional, but use it if you hate maintaining IP spreadsheets. It tracks allocations per VNet and prevents duplicate IPs.

# Check current SDN status across the cluster
pvesh get /cluster/sdn/status --output-format json

This returns JSON showing each zone's state, VNet membership, and any errors. If you see "state": "error" on any zone, fix that before adding VMs.

Why VXLAN > VLAN for Multi-Node (and When VLAN Still Wins)

pfSense vs OPNsense: A Pragmatic Comparison for Self-Hosters

Hugo | DevOps | Cybersecurity — Sun, 12 Jul 2026 14:15:03 +0000

I've been running firewalls since the days of m0n0wall on CF cards, and I still remember the sinking feeling at 2 AM when a bad pfSense config push locked me out of a remote office. The Soekris box was blinking its lonely LED, and I was three time zones away with no IPMI. That was 2008, and the lessons from that era still apply today: your firewall is the most critical piece of infrastructure you'll touch, and choosing the wrong platform means accepting unnecessary risk.

This guide is for self-hosters, homelab operators, and small-to-medium business IT admins who need a production-grade firewall without the Cisco price tag. By the end, you'll understand the architectural differences between pfSense and OPNsense, know which one fits your operational profile, and have concrete migration paths if you need to switch. I'm not here to sell you on either — both are better than any consumer router, and both can ruin your weekend if you don't respect them.

:::note[TL;DR]

pfSense and OPNsense both run on FreeBSD with pf packet filter — the core is identical
OPNsense ships with boot environments, WireGuard, and Suricata built-in; pfSense requires packages for these
pfSense has better cloud marketplace presence and commercial support; OPNsense has better defaults and upgrade safety
Choose pfSense for enterprise/cloud deployments with existing ecosystem investment
Choose OPNsense for self-hosted environments where uptime and modern defaults matter :::

Prerequisites

Before diving in, you should have:

A dedicated x86 machine or VM with at least 2 GB RAM (4 GB recommended for IDS/IPS)
Basic understanding of TCP/IP, subnetting, and firewall rules
Access to the hardware's console or IPMI for initial setup
A backup plan — both firewalls can brick themselves on a bad config

Architecture & Base System — FreeBSD Under the Hood

The fork that created OPNsense in 2015 wasn't about technical capability — it was about licensing and development philosophy. Both projects started from m0n0wall, both use pfSense's original codebase, but they've diverged in ways that matter for daily operations.

Kernel and Boot Environment

pfSense migrated to HardenedBSD with version 2.5, using a monolithic kernel by default. ZFS is available but requires a manual installation — the installer still defaults to UFS. OPNsense has been on HardenedBSD since version 19.1, with ZFS as the default filesystem. This difference seems minor until you need to recover from a bad upgrade.

The boot environment feature is where OPNsense pulls ahead. With ZFS, you can snapshot your entire system before an upgrade and roll back in seconds if something breaks. pfSense requires manual ZFS setup and doesn't integrate boot environments into its upgrade workflow.

# OPNsense — built-in boot environment management
bectl list
BE                        Active Mountpoint Space Created
default                   NR     /          1.2G  2026-06-01 14:23
upgrade-24.1              -      -          1.5G  2026-07-10 03:15

# pfSense — requires manual ZFS boot environment creation
# This is not part of the standard install
zfs snapshot zroot/ROOT/default@pre-upgrade-2.7.0

Site-to-Site IPsec: Connecting Offices Without Losing Your Mind

Hugo | DevOps | Cybersecurity — Sat, 11 Jul 2026 14:15:03 +0000

I have spent a significant portion of my adult life staring at log buffers, watching two expensive routers scream at each other in a language they both ostensibly speak, yet neither understands. There is a specific kind of hell reserved for the sysadmin trying to connect a MikroTik at a branch office to a Cisco ASA at the headquarters.

You’ve got the subnets right. You’ve got the public IPs right. You’ve even double-checked the Pre-Shared Key (PSK) five times. And yet, there it is: phase1 negotiation failed or the even more insulting no proposal chosen.

If you’ve ever found yourself clicking through 50 different permutations of "3DES," "AES-128," "SHA1," and "MD5" just to get a tunnel to stay up for more than ten minutes, you aren't doing engineering; you're doing digital alchemy. It’s 2026. If you are still relying on legacy IKEv1 and "guessing" which encryption suite your vendor implemented correctly, you are a dinosaur. It is time to standardize, move to IKEv2, and stop treating your Site-to-Site tunnels like a delicate chemistry experiment.

The Rant: The "Phase 1 / Phase 2" Mismatch Hell

The core problem with IPsec is that it was designed by a committee that hated simplicity. Unlike WireGuard, which has one way to do things, IPsec has five thousand.

1. The Multi-Vendor Alphabet Soup

Every vendor (Cisco, MikroTik, Fortinet, Juniper, Ubiquiti) has a slightly different idea of what "Standard" means. Cisco might default to a 24-hour lifetime for Phase 1, while MikroTik defaults to 1 day (which is almost, but not quite, the same depending on how they count seconds). One vendor might include the "Local ID" in the identity check, while another ignores it.

The moment you try to connect two different brands, you enter the Mismatch Trap. You spend four hours on the phone with "The Cisco Guy" at HQ, both of you insisting your settings are correct, while the logs show a confusing mess of "Invalid ID Information" and "Notify: No Proposal Chosen."

2. The Legacy Burden

Most people are still using IKEv1 because "that’s what the tutorial said." IKEv1 is a bloated, slow, and insecure relic. It requires multiple round-trips to establish a session, it handles NAT poorly, and it is prone to fragmentation issues. If you are still using Main Mode or Aggressive Mode in 2026, you are inviting instability.

The Mechanics: IKEv2 and the Glory of NAT-T

If you want to keep your sanity, the first rule is: IKEv2 only. #### 1. IKEv2 (Internet Key Exchange v2)
IKEv2 was designed to fix everything that sucked about IKEv1. It has built-in support for MOBIKE (mobility), which means your tunnel can survive a brief IP change. It has a much more streamlined handshake (fewer packets, less latency). Most importantly, it handles Dead Peer Detection (DPD) as a core part of the protocol, not as a vendor-specific hack. If the tunnel drops, IKEv2 knows immediately and starts a re-negotiation.

2. NAT-Traversal (NAT-T)

In the age of CGNAT and multi-layered NAT, IPsec usually dies because it relies on protocol 50 (ESP), which doesn't have "ports" like TCP or UDP. Many cheap ISP routers have no idea how to handle ESP and simply drop it.

NAT-T solves this by wrapping the entire IPsec packet inside a UDP header on port 4500. This is mandatory for modern offices. If even one side of your tunnel is behind a NAT, you must enable NAT-T, or your Phase 2 will never initialize.

The Fix: Standardize Your Suite (AEAD)

Network Segmentation: VLANs and Firewall Rules for Production

Hugo | DevOps | Cybersecurity — Fri, 10 Jul 2026 14:15:07 +0000

Network Segmentation: Isolating Services with VLANs and Firewall Rules

Introduction: Why Your Flat Network is a Liability

I once walked into a post-mortem where a single compromised WordPress plugin led to an attacker pivoting from a public web server to a PCI-compliant payment database in under 90 seconds. How? The network was flat — one VLAN, one broadcast domain, no firewall rules between services. The attacker ran arp-scan, found the DB server, and started exfiltrating credit card numbers over port 3306. The CISO asked me, "How do we stop this?" My answer: VLANs and firewall rules, applied correctly.

Flat networks are fine for your home lab. In production, they're a breach waiting to happen. The problem is blast radius — if an attacker compromises one service, they can pivot laterally to everything. VLANs create logical barriers at Layer 2, and firewall rules enforce who talks to whom at Layers 3-4. Together, they're the minimum viable defense for any multi-service environment.

This guide is for senior engineers who already know what a VLAN is but need to design, implement, and maintain segmentation that actually works. After reading, you'll be able to kill lateral movement in your network, avoid the common misconfigurations that make segmentation useless, and sleep better at night.

:::note[TL;DR]

Flat networks let attackers pivot laterally — segment everything with VLANs and firewalls
Use 5-10 VLANs for "trust zones" (web, app, db, management, DMZ), not one per microservice
Default-deny firewall rules between VLANs; stateful inspection is mandatory
Version-control your firewall rules and monitor dropped packets
Test segmentation with nmap and tcpdump, not just ping :::

Prerequisites

Access to a managed switch (Cisco IOS, Aruba, or similar) with VLAN support
A Linux host (Ubuntu 22.04+ or Debian 12) with iptables or nftables installed
Basic understanding of IP addressing and subnetting
Root or sudo access on the Linux router/firewall

VLAN Fundamentals: The Logical Barrier You're Probably Misconfiguring

VLAN Tagging 101 (802.1Q) — What Most Tutorials Get Wrong

VLAN tagging using 802.1Q inserts a 4-byte tag into Ethernet frames to identify which VLAN a packet belongs to. Most tutorials skip the critical part: disable DTP (Dynamic Trunking Protocol) on every switch port that shouldn't be a trunk. DTP negotiates trunking automatically, and if an attacker plugs into an access port that has DTP enabled, they can negotiate a trunk and perform VLAN hopping — accessing traffic from other VLANs.

Here's the Cisco IOS config to kill DTP on access ports:

interface GigabitEthernet0/1
 description Web Server Access Port
 switchport mode access
 switchport access vlan 10
 no switchport trunk dynamic
 spanning-tree portfast

The switchport mode access forces the port to access mode and disables DTP negotiation. The spanning-tree portfast skips STP listening/learning for faster convergence on end-host ports. On Aruba/ProVision switches, the equivalent is:

interface 1/1
   vlan access 10
   no vlan trunk dynamic

In Linux bridging for virtualized environments (e.g., KVM with Linux bridge), you configure VLAN tagging at the interface level:

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.0.10.1/24 dev eth0.10
ip link set eth0.10 up

Deploying Encrypted DNS Internally: DoH and DoT Guide

Hugo | DevOps | Cybersecurity — Wed, 08 Jul 2026 14:15:04 +0000

I was on-call when it happened. 3 AM on a Tuesday, and every single production server in our us-east-1 region started resolving api.internal.example.com to a server in Belarus. Our recursive DNS resolver had been MITM'd by an attacker who'd gained access to a network tap in the colo facility. Four hours of chaos, a panicked VP, and a post-mortem that boiled down to: "Our DNS was plaintext over UDP, and we trusted the network."

That was 2022. If you're still running plaintext DNS internally in 2026, you're not just behind — you're negligent. This guide is for senior sysadmins and security engineers who need to deploy encrypted DNS (DoH and DoT) in their infrastructure without breaking everything. By the end, you'll have a working deployment, a migration plan, and the scars to know what goes wrong.

:::note[TL;DR]

Plaintext DNS is a massive security liability: on-path tampering, passive surveillance, and cache poisoning at the network edge
Use DoT for internal infrastructure (predictable, low overhead), DoH for external-facing resolvers (evasion, compliance)
Start with Unbound or CoreDNS — skip the overengineered solutions
Certificate management is the #1 cause of failure: automate rotation or suffer at 3 AM
Migrate gradually with opportunistic mode first, then enforce with firewall rules :::

Prerequisites

A Linux server (Ubuntu 22.04+ or RHEL 9+) for your DNS resolver — don't use your laptop
Root access and basic familiarity with systemd, openssl, and tcpdump
A DNS zone you control for testing (e.g., dns.internal.example.com)
kdig installed (apt install knot-dnsutils or yum install knot-dnsutils)
At least 30 minutes of uninterrupted time — this isn't a 5-minute config

Why You Should Care About Encrypted DNS (And Why Plaintext DNS Is a Security Liability)

Plaintext DNS over UDP is the cockroach of network protocols — it's everywhere, it's ugly, and it survives anything. Here's what it exposes you to:

On-path tampering: Any device between your client and the resolver can modify DNS responses. This isn't theoretical — I've seen attackers redirect traffic to phishing pages by poisoning ARP tables and injecting fake DNS responses.

Passive surveillance: Your DNS queries reveal every service, every internal hostname, and every external dependency you have. An attacker who sniffs your DNS traffic knows your infrastructure better than your CMDB does.

Cache poisoning at the network edge: If an attacker can inject a single fake DNS response before the legitimate one arrives, your resolver caches it for the TTL. This is how the Kaminsky attack worked, and it's still effective against poorly configured resolvers.

The false comfort of "internal network" security needs to die. In 2026, your internal network is not a trusted zone — it's a blast radius. If you're still running dnsmasq with no encryption, you're basically leaving the keys in the ignition with the engine running.

Here's what plaintext DNS looks like on the wire — run this on any server that's doing DNS queries:

# Capture a single DNS query to show how much leaks
tcpdump -i any -X -c 1 'udp port 53 and dst port 53'

This will show your query in clear text: hostnames, timestamps, and source IPs. Every network hop between you and the resolver sees this. If you're thinking "but we use DNSSEC," you're missing the point — DNSSEC validates response integrity but does nothing for confidentiality or transport security.

DEV Community: Hugo | DevOps | Cybersecurity

Network Segmentation: VLANs and Firewall Rules for Service Isolation

Prerequisites

Why Segmentation Matters — The "Flat Network is a Crime" Argument

VLAN Fundamentals — Not Just for Network Engineers Anymore

What VLANs Actually Do (and Don't Do)

Firewall 101: The 'Drop Everything by Default' Manifesto

The Rant: The "Troubleshooting" Lie

The Mechanics: The Default Deny Principle

Why "Blacklisting" Fails

The Mechanics: Stateful Packet Inspection (SPI)

If You Can't See It, You Can't Fix It: Network Monitoring with SNMP & Grafana

The Rant: The Observability Gap

The Mechanics: SNMP (The "Simple" Protocol That Isn't)

1. The OID: The GPS of Data

MikroTik FastTrack: The Performance Miracle That Breaks Your Firewall

The Mechanics: The "Slow Path" vs. The "Fast Path"

1. The Slow Path (The Standard Flow)

2. The Fast Path (The Shortcut)

3. FastTrack (The Hybrid)

The Mechanics of the Break: Why Things Stop Working

1. The QOS Death

Port Forwarding is a Relic: Why You Should Nuke Your WAN-Facing Rules

The Mechanics: The Shodan Spotlight

1. The 45-Minute Window

2. The Pre-Auth RCE Nightmare

The Fix: The VPN-Only Model

1. The Stealth of WireGuard

Proxy vs VPN: Stop Confusing Privacy with Security

The Rant: The "Browser VPN" Scam

The Mechanics: Layer 3 vs. Layer 7

1. Proxies: The Layer 7 (Application) Approach

2. VPNs: The Layer 3 (Network) Approach

SSH Tunneling: The Swiss Army Knife of Networking You're Not Using

The Rant: The Over-Engineered VPN Trap

The Mechanics: How SSH Port Forwarding Works

1. Local Port Forwarding (-L): The "Pull"

Proxmox SDN: Multi-Node Cluster Networking

Introduction – Why SDN in Proxmox Isn’t Just a Buzzword

Prerequisites

Proxmox SDN Architecture – The 30,000-Foot View (Without the BS)

Core Components – Zones, VNets, Subnets, and IPAM

Why VXLAN > VLAN for Multi-Node (and When VLAN Still Wins)

pfSense vs OPNsense: A Pragmatic Comparison for Self-Hosters

Prerequisites

Architecture & Base System — FreeBSD Under the Hood

Kernel and Boot Environment

Site-to-Site IPsec: Connecting Offices Without Losing Your Mind

The Rant: The "Phase 1 / Phase 2" Mismatch Hell

1. The Multi-Vendor Alphabet Soup

2. The Legacy Burden

The Mechanics: IKEv2 and the Glory of NAT-T

2. NAT-Traversal (NAT-T)

The Fix: Standardize Your Suite (AEAD)

Network Segmentation: VLANs and Firewall Rules for Production

Network Segmentation: Isolating Services with VLANs and Firewall Rules

Introduction: Why Your Flat Network is a Liability

Prerequisites

VLAN Fundamentals: The Logical Barrier You're Probably Misconfiguring

VLAN Tagging 101 (802.1Q) — What Most Tutorials Get Wrong

Deploying Encrypted DNS Internally: DoH and DoT Guide

Prerequisites

Why You Should Care About Encrypted DNS (And Why Plaintext DNS Is a Security Liability)

1. Local Port Forwarding (`-L`): The "Pull"