Networking

After enabling VLAN filtering on my MikroTik CRS310-8G+2S+ switch with an incorrect configuration, I lost all management access. The switch was unreachable via SSH, web UI, and ping. This post documents the recovery process using MAC-Telnet to regain access at Layer 2. The Problem The switch had VLAN filtering enabled with the uplink port (ether5, connected to OPNsense) configured as tagged for VLAN 1 when it should have been untagged. This meant: ...

Managing network devices via SSH typically involves remembering IP addresses, usernames, and sometimes non-standard ports. The SSH config file (~/.ssh/config) eliminates this overhead by defining named aliases with pre-configured connection parameters. The Problem Connecting to a MikroTik switch requires typing the full connection string each time: ssh [email protected] scp backup.rsc [email protected]:/ This becomes tedious with multiple network devices, each potentially having different usernames, ports, or key files. Solution Create an SSH config file with host aliases. ...

Linkerd provides automatic mTLS between all pods in the mesh. This encrypts traffic and provides identity verification. However, it does not restrict which pods can communicate with each other. Any pod in the mesh can connect to any other pod. Kubernetes NetworkPolicies add an additional layer of security by defining explicit allow rules at the network level. This provides defense-in-depth: if Linkerd’s proxy is somehow bypassed, NetworkPolicies still enforce access control. ...

My homelab has a dedicated DMZ network (192.168.4.0/24) that’s physically separated from my main LAN. The only machine currently on this network is minis, a Fedora workstation that also serves as a Kubernetes node for DMZ-facing workloads. I’ve been running a basic router on this segment, but I picked up a faster unit and wanted to document the before/after performance difference. Network Topology ┌─────────────────┐ │ OPNsense │ │ Main Firewall │ └────────┬────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐ │ LAN │ │ WLAN │ │ DMZ │ │192.168.2.x│ │192.168.3.x│ │192.168.4.x│ └─────┬─────┘ └───────────┘ └─────┬─────┘ │ │ K8s Cluster ┌─────┴─────┐ (4 nodes) │DMZ Router │ ← Upgrading this └─────┬─────┘ │ ┌─────┴─────┐ │ minis │ │192.168.4.50│ └───────────┘ Baseline Performance (Before Upgrade) Date: 2025-12-31 Router: Netgear GS110TP (8-port Gigabit Smart Switch with PoE) Test Machine: minis (Fedora 42, connected via ethernet) ...

If you’re running a homelab with multiple network segments, there’s a good chance you have at least one machine connected to more than one network. Maybe your workstation has a wired connection to your DMZ and wireless to your trusted WLAN. Convenient? Yes. A potential security hole? Also yes. The Problem My workstation sits on two networks: wireless connected to my home WLAN (192.168.3.0/24) and wired into my DMZ (192.168.4.0/24). The DMZ is intentionally isolated—it’s where I run services exposed to the internet. The WLAN is where everything else lives: personal devices, management interfaces, the stuff I actually care about protecting. ...

When I needed to add a node from my DMZ to my Kubernetes cluster on the LAN, I discovered OPNsense has a comprehensive REST API that lets you manage firewall rules programmatically. No clicking through the UI - just curl commands that create rules properly tracked in the configuration and included in backups. The Problem My Kubernetes cluster lives on my LAN (192.168.2.0/24), but I wanted to add a machine from my DMZ (192.168.4.0/24). By default, DMZ traffic can’t reach the LAN - that’s the whole point of a DMZ. I needed to punch specific holes for Kubernetes traffic while keeping everything else blocked. ...