DEV Community: Hugo | DevOps | Cybersecurity

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.

Proxmox SDN: Software-Defined Networking for Multi-Node Clusters

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

I got the call at 2:47 AM. A junior admin had deleted a VNet while five production VMs were running. All of them dropped off the network simultaneously. The /etc/pve/sdn/ directory had no backups. We spent the next four hours reconstructing VNI-to-VLAN mappings from memory and stale monitoring logs. That was the night I stopped treating Proxmox SDN as optional infrastructure and started treating it like a core system that demands the same rigor as your storage backend.

This guide is for senior DevOps and sysadmins running Proxmox clusters with more than three nodes. If you're still editing /etc/network/interfaces by hand and managing VLANs through a spreadsheet, you're one misconfig away from a production outage. After reading this, you'll be able to deploy VXLAN-based SDN with head-end replication, configure VLAN-backed zones for legacy environments, implement firewall security groups, and avoid the mistakes that cost me that 2 AM call.

:::note[TL;DR]

Proxmox SDN abstracts network configuration from hypervisor bridges into zones, VNets, and subnets
Use VXLAN with head-end replication for clusters over 5 nodes — it scales to ~100 nodes without multicast headaches
VLAN-backed SDN is a stepping stone: you hit the 4094 VLAN limit faster than you think
SDN firewalls and security groups provide tenant isolation that VM-level firewalls can't match
Backup /etc/pve/sdn/ before every change — there's no dry-run mode :::

Prerequisites

Proxmox VE 7.x or later (SDN is stable since 7.2)
L3 routing between all cluster nodes (no STP loops)
At least one dedicated physical NIC or VLAN trunk per node for SDN traffic
pvesh CLI access on any cluster node
For VXLAN: UDP port 4789 open between all nodes

Core Concepts – Zones, VNets, and Subnets

Zones = Network Domains

Zones define the encapsulation method and underlay requirements. Proxmox supports four types: VLAN, VXLAN, EVPN, and Simple. Your choice determines how far your network can scale and how much your network team will hate you.

I once audited a cluster where a team used a Simple zone for ten nodes. Simple zones are flat Layer 2 domains with no isolation. They learned about broadcast storms when a misconfigured VM generated 200 Mbps of ARP traffic that saturated every host. Use Simple zones only for single-node testing.

Here's the decision matrix:

Zone Type	Underlay Requirement	Max Networks	Use Case
VLAN	L2 adjacency	4094	Small clusters, existing switch infrastructure
VXLAN	L3 routing + UDP 4789	16 million	Multi-node, multi-site, cloud/colo
EVPN	BGP + VTEP	Unlimited	Carrier-grade, dynamic routing
Simple	None	1	Single-node, testing only

VNets = Virtual Networks

VNets map to VLAN IDs or VXLAN VNIs. They're your tenant networks. Naming conventions matter: prod-db-vlan100 tells you what it is; vlan100 tells you nothing after you've created fifty of them.

Here's a VLAN zone configuration:

# /etc/pve/sdn/zones.cfg
vlan: prod-zone
    type vlan
    bridge vmbr1
    vlan-id 100-500

This creates a zone named prod-zone that uses bridge vmbr1 as the trunk interface and allows VLANs 100 through 500. The bridge must exist on every node before Proxmox will activate the zone.

Subnets = IPAM and DHCP Integration

How to Protect Your Homelab and API with a Free Self-Hosted WAF (SafeLine Docker Install)

Hugo | DevOps | Cybersecurity — Thu, 02 Jul 2026 14:15:04 +0000

Why I Stopped Trusting Cloudflare Alone

My site recently crossed 5,000 daily visitors. Sounds like a celebration. What it actually means is that the volume of garbage hitting my server — automated scanners, credential stuffing bots, SQL injection probes — scaled up with the legitimate traffic.

Cloudflare catches most of it. Most. The remaining 5–10% that leaks through the CDN layer goes straight at your origin, and if you're running APIs or self-hosted services, that origin is the actual target. Enterprise WAFs from Fortinet or F5 would solve this, but they start at thousands of dollars per year. That's not a homelab budget. That's not even a small business budget.

Enter SafeLine WAF — a completely self-hosted, Docker-based Web Application Firewall with a legitimate free Community Edition. No call-home telemetry. No per-GB pricing that punishes visibility. Just a container that sits between the internet and your services and kills the bad traffic before it reaches your application layer.

Here is what changed after I deployed it, and exactly how you can do the same in under ten minutes.

What SafeLine Actually Does (And What It Doesn't)

Before you deploy anything, understand what you're getting.

SafeLine is a reverse proxy WAF built on a modified Nginx engine called Tengine. All traffic goes through it first. It inspects each request against a rule engine, blocks anything that looks malicious, and forwards clean traffic to your backend service.

It blocks:

SQL injection (' OR 1=1, UNION SELECT, etc.)
Cross-site scripting (XSS) payloads in headers and query strings
Path traversal attacks (../../../etc/passwd)
Scanner and bot fingerprints (Nuclei, sqlmap, Nikto, Masscan)
Brute force attacks via rate limiting
HTTP protocol violations

It does not replace:

A firewall at the network level (ufw, iptables, cloud security groups)
Proper secrets management
Input validation in your application code

SafeLine is one layer. Defense in depth means you still need the other layers.

Community Edition vs Pro — What You Actually Get for Free

The free Community Edition covers everything a homelab or small deployment needs:

Feature	Community	Pro
WAF protection	✅	✅
Custom block rules	✅	✅
Dashboard + analytics	✅	✅
Sites supported	Unlimited	Unlimited
Rate limiting	✅	✅
CAPTCHA challenges	✅	✅
Dynamic protection rules	❌	✅
Support SLA	Community	Priority
Authentication protection	Basic	Advanced

For a homelab, personal API, or small production deployment: the free tier is enough.

Prerequisites

You need:

A Linux server (Debian/Ubuntu/Rocky — anything with Docker support)
Docker Engine 20.10+ installed
Docker Compose v2
Ports 80, 443, and 9443 available
At least 1 GB RAM free

If you don't have Docker installed yet:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Installing SafeLine WAF — The 60-Second Method

SafeLine ships an automated setup script that handles everything: pulls images, creates the docker-compose.yml, sets up volumes, and starts the stack.

Step 1 — Run the installer:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)"

The script will ask for an installation directory (default: /data/safeline). Accept the default unless you have a specific reason to change it.

Proxmox Network Configuration: Bridges, Bonds, and VLANs

Hugo | DevOps | Cybersecurity — Sun, 28 Jun 2026 09:32:12 +0000

I once spent a Sunday afternoon restoring a client's 12-node Proxmox cluster because someone thought balance-rr on a single switch was a good idea. The switch's MAC table filled up in 47 seconds, the STP reconvergence took down their Ceph storage network, and three production databases went read-only. The root cause wasn't a hardware failure — it was a network config that looked fine in a 3-node lab.

This guide is for senior sysadmins who manage Proxmox in production. You already know how to install Proxmox and create a VM. What you need is the battle-tested knowledge of how to design and debug network configurations that survive kernel updates, switch failures, and junior admin mistakes. By the end, you'll be able to architect multi-VLAN, multi-bond setups with confidence and debug the inevitable failures without panicking.

:::note[TL;DR]

Default vmbr0 on a single NIC is for testing, not production
Use LACP bonding (mode=4) for any host with redundant paths
Separate storage traffic (Ceph) from VM traffic with dedicated bridges and VLANs
Always test network changes with ifreload -a before rebooting
Version control your /etc/network/interfaces files :::

Prerequisites

Proxmox VE 7.x or 8.x installed (physical or virtual)
Root shell access to the Proxmox host
At least two physical NICs if you're following the bonding examples
A managed switch that supports LACP (802.3ad) and VLAN tagging
IPMI/iDRAC/iLO access for out-of-band recovery

Why Default Proxmox Networking Will Bite You in Production

The default Proxmox installer creates a single bridge (vmbr0) attached to one NIC. This works beautifully for a home lab with three VMs. In production, it's a single point of failure that will fail at the worst possible moment.

The "It Worked in My Lab" Trap

Here's the default config that Proxmox generates:

# /etc/network/interfaces — default, dangerous for production
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

This config has exactly one failure domain: eno1. If that cable gets unplugged, the NIC fails, or the switch port goes down, your entire Proxmox host goes dark. No SSH, no web interface, no VMs.

I had a client who lost all connectivity during a routine kernel update. The update triggered a driver reload on eno1, the NIC came back with a different MAC address (thanks to a firmware bug), and the bridge refused to forward traffic. Without a bond for failover, they were down for two hours while someone drove to the datacenter.

The Hidden Cost of Complexity

I'm not saying every Proxmox host needs four bonds and eight VLANs. If you're running a single host with three VMs for your home media server, a single bridge is fine. The complexity tax is real — every bond, VLAN, and bridge you add is another thing that can break.

But if you're running:

A multi-node Proxmox cluster with HA
Ceph or any other distributed storage
Multiple tenants with separate network requirements

Then you need proper network segmentation. If you're running Ceph on a single bridge shared with VM traffic, you're already fired. Ceph's OSD heartbeat traffic and replication will fight with your production VMs for bandwidth, and when the cluster gets busy, you'll see OSD flapping and slow requests.

The One File to Rule Them All

Lock Down SSH: Configuring Two-Factor Authentication (2FA) with Google Authenticator

Hugo | DevOps | Cybersecurity — Sat, 27 Jun 2026 07:05:49 +0000

Secure Your Server: Forcing 2FA on SSH Connections

Every single day, automated bots and bad actors scan the internet for open Port 22 configurations, attempting to brute-force their way into vulnerable Linux servers. While using SSH Keys is the standard best practice, adding an additional layer of Time-based One-Time Passwords (TOTP) ensures that even if your private key is compromised, the attacker cannot gain access.

In this guide, we will configure libpam-google-authenticator on an Ubuntu/Debian server to require both an SSH Key and a 6-digit Google Authenticator code.

Prerequisites

A Linux Server (Ubuntu/Debian). For this lab, we are using a highly secured VPS provided by our infrastructure partner, Zone.eu.
Root or sudo privileges.
The Google Authenticator app (or Authy/Bitwarden) installed on your smartphone.

Valters IT YouTube Tutorial

Step 1: Install the PAM Authenticator Module

First, update your package list and install the required Google Authenticator PAM (Pluggable Authentication Module).

sudo apt update
sudo apt install libpam-google-authenticator -y

Step 2: Generate the TOTP Secret

Run the authenticator command as the user you use to log in via SSH (do not run this as root unless you explicitly log in as root).

google-authenticator

The terminal will prompt you with a series of questions:

Make tokens time-based? Press y.
A giant QR code will appear in your terminal. Scan this with your authenticator app.
Save your emergency scratch codes in a secure password manager. If you lose your phone, these are your only way back in!
Update your ~/.google_authenticator file? Press y.
Disallow multiple uses of the same token? Press y (Protects against replay attacks).
Increase time skew window? Press n (Unless you have severe clock drift issues).
Enable rate-limiting? Press y (Limits to 3 logins every 30 seconds).

Step 3: Configure PAM for SSH

Now, we need to tell the PAM system to require the Google Authenticator module for SSH connections.

sudo nano /etc/pam.d/sshd

Scroll to the bottom of the file and add the following line:

# Require Google Authenticator 2FA
auth required pam_google_authenticator.so

Save and exit the file (CTRL+O, Enter, CTRL+X).

Step 4: Force SSH Daemon to Require 2FA

By default, SSH might skip 2FA if you are using an SSH Private Key. We need to explicitly tell the SSH daemon to require both the public key and the interactive keyboard prompt (which will ask for the 2FA code).

sudo nano /etc/ssh/sshd_config

Find and modify (or add) the following directives in the file:

# Ensure PAM is enabled
UsePAM yes

# Allow interactive keyboard authentication
KbdInteractiveAuthentication yes
# Note: On older versions of Ubuntu, this might be called 'ChallengeResponseAuthentication yes'

Split Tunneling: Performance vs Security in the Remote Work Era

Hugo | DevOps | Cybersecurity — Sun, 03 May 2026 12:33:03 +0000

I recently sat in a boardroom where a non-technical CISO was pounding the table, demanding that every single byte of data from 500 remote employees be forced through the corporate VPN. "Full Tunneling is the only way to ensure security!" he shouted.

Meanwhile, back in the server room, the network engineers were watching the office's primary 1Gbps fiber uplink choke to death. Why? Because half the staff was working from home with Netflix running in the background, or downloading 50GB Call of Duty updates, and all that irrelevant, non-business traffic was being hauled across the country into our datacenter, decrypted, inspected by a firewall that was never sized for that much throughput, and then shoved back out to the internet.

Congratulations. You’ve successfully "secured" your network by making it completely unusable for everyone.

If your "Security Policy" involves turning your office into a bottlenecked proxy for the entire internet's entertainment traffic, you aren't an architect; you're a glutton for punishment. It’s 2026. We have the tools to be surgical. It’s time to talk about Split Tunneling—the right way.

The Mechanics: Full Tunneling (The "Hammer" Approach)

In a Full Tunnel configuration, the VPN client modifies the operating system's routing table to set the "Default Gateway" to the virtual VPN interface. In networking terms, we are pushing a 0.0.0.0/0 route into the tunnel.

1. The Bottleneck Problem

When a remote worker is on a Full Tunnel, their computer says: "I don't care if I'm looking for a spreadsheet on the internal file server or a cat video on YouTube—send it all to the VPN."

This creates a massive "tromboning" effect. A packet goes from the user's home in New York, to the office in Chicago, gets inspected, and then goes back out to a server in Virginia. This adds massive latency (RTT) and consumes twice the bandwidth on your corporate circuit—once for the "ingress" from the user, and once for the "egress" to the destination.

2. The False Sense of Security

Admins love Full Tunneling because it allows them to use their expensive "Next-Gen" Firewalls to perform Deep Packet Inspection (DPI) on all user traffic. They think they are catching malware. In reality, most malware today is delivered over encrypted HTTPS (TLS 1.3) with Certificate Pinning. Unless you are performing invasive SSL decryption (which breaks half the modern web and opens its own can of privacy worms), your firewall is just watching encrypted blobs fly by. You are killing your performance for a security benefit that is largely theoretical for most remote workloads.

The Mechanics: Split Tunneling (The "Scalpel" Approach)

Split Tunneling is the practice of only sending specific, corporate-owned IP ranges through the VPN tunnel. Your internet traffic (Google, YouTube, Office 365) goes out through your local home ISP, while your internal traffic (Jira, GitLab, Database) goes through the VPN.

1. The Routing Logic

Instead of 0.0.0.0/0, the VPN client only adds specific routes—like 10.0.0.0/8 or 192.168.50.0/24—to the tunnel interface. The OS sees that a request for 10.0.5.20 matches the specific VPN route, but a request for 8.8.8.8 falls back to the default local gateway.

Tailscale & ZeroTier: Why You're Fighting CGNAT and Losing

Hugo | DevOps | Cybersecurity — Sat, 02 May 2026 12:33:03 +0000

I recently talked to a developer who spent three days trying to set up a WireGuard tunnel to his home server. He had the config perfect. He had the port forwarded on his router. He had the dynamic DNS updating every five minutes. But no matter what he did, he couldn't get a handshake.

I told him to check his WAN IP on his router and compare it to what "WhatIsMyIP" told him. Sure enough, his router showed a 100.64.x.x address.

"You're behind CGNAT," I said. "Your ISP isn't giving you a public IP. You're effectively behind a firewall that you don't own and can't control. You can't forward a port if the port doesn't belong to you."

If you’re still trying to use traditional "inbound" VPNs in an era where ISPs are hoarding IPv4 addresses like digital dragons, you aren't fighting a technical battle; you're fighting a losing war against the exhaustion of the internet's address space. It’s 2026. If you want to connect your devices without losing your mind to "Double NAT" hell, it’s time to embrace the "magic" of overlay networks like Tailscale and ZeroTier.

The Rant: The CGNAT Death Trap

Carrier-Grade NAT (CGNAT), specifically defined in RFC 6598, is the ISP's solution to the fact that we ran out of IPv4 addresses years ago. Instead of giving every customer a unique public IP, the ISP puts thousands of customers behind a single public IP. Your router gets a private address in the 100.64.0.0/10 range.

This works fine for 99% of people who just want to browse TikTok. But the moment you want to host a VPN, a Minecraft server, or a Plex instance, you hit a brick wall. Because you don't have a unique public IP, there is no way for a packet from the outside world to "find" your router. Traditional port forwarding is dead.

You can call your ISP and beg for a "Static IP" (which they will happily charge you $15/month for), or you can stop living in the past and use a mesh VPN that was designed to handle this exact nightmare.

The Mechanics: How the "Magic" Works

Tailscale and ZeroTier are often described as "magic" because you just install them, log in, and suddenly your devices can talk to each other as if they were on the same switch, regardless of firewalls, NAT, or CGNAT.

This isn't magic; it's sophisticated orchestration using three core technologies: STUN, TURN, and UDP Hole Punching.

1. STUN (Finding the Exit)

STUN (Session Traversal Utilities for NAT) is how a device finds out what it "looks like" to the outside world. Your server sends a packet to a STUN server on the public internet. The STUN server replies: "Hey, I saw your packet coming from public IP 203.0.113.5 on port 54321."

Now your server knows its external "mapped" address.

2. UDP Hole Punching (The Handshake)

This is the brilliant part. Most firewalls are "stateful." They block incoming packets by default, but they allow outgoing packets. Crucially, if you send an outgoing UDP packet to a destination, the firewall opens a temporary "hole" to allow a response from that same destination to come back in.

Tailscale’s coordination server tells both Peer A and Peer B: "Okay, both of you send a UDP packet to each other's mapped STUN addresses at the same time."

The MTU Nightmare: Why Your VPN Connection is Fragmenting to Death

Hugo | DevOps | Cybersecurity — Fri, 01 May 2026 12:33:04 +0000

I’ve lost count of how many times I’ve had to explain this to "Senior" DevOps engineers who think they’ve discovered a ghost in the machine. The symptoms are always the same: The VPN tunnel is "Up." You can ping the remote gateway. You can even SSH into the server. But the moment you run ls -al in a directory with 500 files, or try to scp a database dump, the terminal just... hangs.

The website starts to load—you see the favicon and the title in the tab—and then it spins forever, eventually timing out with a "Connection Reset."

You check the logs. Nothing. You check the CPU. Idle. You check the bandwidth. Plenty.

Congratulations. You aren't being hacked, and your app isn't buggy. You are suffering from an MTU mismatch, and your packets are being ruthlessly discarded by a "black hole" router that someone—likely a junior security admin with an itchy trigger finger—configured to block the very protocol meant to prevent this exact disaster.

The Mechanics: The 1500-Byte Delusion

To understand why your VPN is dying, you have to understand the Maximum Transmission Unit (MTU). On a standard Ethernet network, the MTU is almost universally 1500 bytes. This is the largest frame that can be sent across the physical wire without being broken into pieces.

When your application sends a packet, it assumes it has 1500 bytes of "room." It builds a 1500-byte IP packet. But your application is inside a VPN tunnel.

1. The VPN Tax (Overhead)

A VPN is an encapsulation protocol. It takes your original 1500-byte packet and wraps it inside another packet (the tunnel header) to send it across the internet.

WireGuard adds roughly 60-80 bytes of overhead.
OpenVPN or IPsec can add 60 to 100+ bytes depending on the cipher and padding.

If your original packet was already 1500 bytes, and you add 80 bytes of WireGuard headers, you now have a 1580-byte packet. When that packet hits the physical network interface, the OS realizes it’s too big for the 1500-byte limit of the physical wire.

2. Fragmentation vs. The "Don't Fragment" Bit

In a perfect world, the router would just "fragment" the packet—break it into two smaller pieces. But modern TCP/IP implementations almost always set the DF (Don't Fragment) bit. Why? Because fragmentation is computationally expensive and introduces massive latency.

When a 1580-byte packet with the DF bit set hits a router with a 1500-byte MTU, the router is supposed to drop the packet and send back an ICMP message: Type 3, Code 4: "Destination Unreachable, Fragmentation Needed and DF set."

This message includes the "Next-Hop MTU," telling the sender exactly how small the packet needs to be to fit. This process is called Path MTU Discovery (PMTUD).

The "Black Hole" Router: A Security Admin's Crime

Here is where the nightmare begins. Many "security-conscious" admins think that ICMP is "scary" or "dangerous." They configure their firewalls to DROP all ICMP traffic, thinking they are hiding from pings.

By dropping all ICMP, they have effectively blinded the network. Your server sends the 1580-byte packet. The intermediate router drops it and sends the "Fragmentation Needed" message. Your firewall sees the ICMP message, thinks it’s an attack, and drops it.

VLAN Segmentation: Why Your Smart Fridge Shouldn't Talk to Your File Server

Hugo | DevOps | Cybersecurity — Tue, 28 Apr 2026 12:33:04 +0000

I recently audited a homelab belonging to a "Senior Developer" who had over $10,000 worth of enterprise-grade server hardware. He had a 100TB ZFS storage array, three Proxmox nodes, and a dedicated Opnsense firewall. But when I looked at his network map, I nearly walked out.

Everything—his production database, his high-end workstation, his guest's iPhones, and thirty-five unpatched, $5 Chinese-made smart lightbulbs—was sitting on a single, flat 192.168.1.0/24 subnet.

"It makes it easier for the apps to find the devices," he told me.

If your definition of "easier" is providing a friction-less, high-speed highway for a Russian botnet to move from your $12 smart fridge to your corporate file server, then sure, a flat network is "convenient." But in the world of modern network architecture, a flat network is a sign of fundamental laziness. If you aren't segmenting your traffic, you aren't running a secure network; you're just hosting a digital mosh pit where the guy with the most infectious disease gets to hug everyone else.

The Mechanics: The "Inside-Out" Attack

To understand why a flat network is a disaster, you have to understand the concept of Lateral Movement.

Most hobbyists and junior admins think of security as a "perimeter" problem. They build a big, thick wall at the edge of the network (the firewall) and assume everything inside the wall is "trusted." This is an archaic 1990s mentality.

1. The IoT Trojan Horse

IoT devices—your smart cameras, lightbulbs, vacuum cleaners, and fridges—are notorious for having the security posture of a wet paper bag. They run ancient, unpatched Linux kernels (often 2.6.x), they have hardcoded "backdoor" credentials for manufacturer testing, and they almost never receive security updates.

When an attacker finds a vulnerability in that $12 Wi-Fi camera you bought on a whim, they don't use it to watch you sleep. They use it as a persistent, low-power pivot point. Because that camera is on the same subnet as your file server, the attacker is already "inside." They don't have to bypass your $500 firewall. They are already standing in your living room.

2. ARP Spoofing and Scanning

Once an attacker has a foothold on a single "dirty" device in a flat network, the entire subnet is at their mercy. They can perform ARP Spoofing (Man-in-the-Middle) to intercept your unencrypted traffic. They can run nmap scans to find every open port on your NAS. They can attempt to exploit known vulnerabilities in your PC.

In a flat network, there is no internal gatekeeper. Every device can "see" every other device. A compromise of the least secure device on your network is, by extension, a compromise of the most secure device on your network.

The Mechanics of the Fix: 802.1Q and Isolation

The Senior Network Architect's fix is Micro-Segmentation via VLANs (Virtual Local Area Networks).

Using the IEEE 802.1Q standard, we can take a single physical switch and "slice" it into multiple logical networks. Each slice is a separate broadcast domain. A device on VLAN 10 cannot even "see" a device on VLAN 20 unless you explicitly configure a router (and a firewall) to allow that traffic.

The 3-VLAN Blueprint

For a secure home or small office, you need a minimum of three distinct zones: