Networking on Backend Engineering Strategy Tools

Gardener on Cleura

Tue, 16 Jun 2026 00:00:00 +0000

Getting hands-on with Gardener on Cleura — a European OpenStack cloud — ahead of using it professionally. The focus is on the networking and traffic ingress side: how does a Gardener shoot cluster on OpenStack expose services, what does the LoadBalancer path actually look like, and when does ingress apply versus when it does not.

The test application is a Minecraft server with Velocity proxy — useful precisely because it is raw TCP rather than HTTP, which forces the full LoadBalancer path rather than an ingress shortcut.

→ Gardener on Cleura — technical notes

Steps

1 — Shoot cluster

Provision a Gardener shoot cluster on Cleura. Cleura wraps Gardener behind their own REST API — gardenctl and the Gardener Terraform provider require the garden cluster kubeconfig, which Cleura does not expose. Cluster lifecycle goes through their REST API instead.

→ Provisioning via Cleura REST API
→ Cleura docs issue #533 — IaC and gardenctl access

2 — Minecraft via standard LoadBalancer

Deploy itzg/minecraft-server as a StatefulSet with a plain LoadBalancer service for TCP 25565 — the direct Octavia path, no Gateway involved. Gets the server running quickly and confirms TCP exposure works on Cleura independently.

Internet
 |
TCP 25565
 |
Octavia LB (direct LoadBalancer service)
 |
Minecraft Pod (itzg/minecraft-server)
 |
PVC (Cinder)

Manifests: stateful_set.yaml · service.yaml

Apply directly from this repo:

kubectl apply -k "https://github.com/Backend-Engineering-Strategy-Tools/site//static/scripts/mc?ref=main"

Check the rollout and grab the external IP:

kubectl get all -l app=mc-example

kubectl get svc mc-example \
 -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}'

2.5 — Migrate to Helm chart

Swap the raw manifests for the itzg/minecraft-server-charts Helm chart — actively maintained, covers server type, persistence, RCON, backups, and extra ports (BlueMap, Dynmap). The raw YAML stays useful as a reference for the underlying shape.

Manifests: values.yaml

helm repo add minecraft-server-charts https://itzg.github.io/minecraft-server-charts/
helm upgrade --install mc minecraft-server-charts/minecraft \
 -f https://backend-engineering-strategy-tools.github.io/site/scripts/mc-helm/values.yaml

Check the rollout and grab the external IP:

kubectl get all -l app.kubernetes.io/instance=mc

kubectl get svc mc-example -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}'

3 — Envoy Gateway

Deploy Envoy Gateway into the shoot cluster — the CNCF implementation of the Kubernetes Gateway API. The NGINX Ingress Controller is deprecated; Gateway API is the forward path with a standardised spec for both HTTP and TCP.

Envoy Gateway exposes a single LoadBalancer service via Octavia. Everything routes through it.

4 — HTTPRoute, certificates, and BlueMap

Deploy BlueMap — a Minecraft mod that renders the world as a live 3D web map served over HTTP. Route it through the Gateway with a HTTPRoute and wire cert-manager to provision a Let’s Encrypt certificate.

A real HTTP service with a real use, not a throwaway test page. Validates the full HTTP + TLS path before touching the game server.

5 — Migrate to TCPRoute

Migrate the TCP service to a TCPRoute through Envoy Gateway. TCPRoute is in the Gateway API experimental channel — this step validates that a single Gateway handles both HTTP and raw TCP.

Internet
 |
Octavia LB (one Gateway LoadBalancer)
 |
Envoy Gateway
 |
+------------------------------+------------------------------+
| |
HTTPRoute → BlueMap TCPRoute → Minecraft

6 — Velocity (if needed)

Add Velocity as a TCP proxy in front of the Minecraft server if multi-server routing becomes relevant — lobby, modded, survival as separate backends. Skip if a single server is enough.

→ Minecraft project

7 — Plugin pipeline

A colleague is building a Minecraft plugin. The goal is a Dagger pipeline with GitHub Actions — the same build running locally and in CI, covering the JVM toolchain and packaging steps.

8 — AI

Something with NPC behaviour, a bot, or plugin-side automation. Low priority, high fun.

IaC gap

Cleura does not expose the garden cluster kubeconfig. That one limitation closes off the entire Gardener tooling ecosystem: gardenctl requires it, the Gardener Terraform provider requires it, and any Crossplane provider built on the Gardener API would require it too. There is no HCL path here.

What remains is Cleura’s own REST API — which is fine for interactive use but falls short the moment you want to drive cluster lifecycle from a pipeline. A bash script wrapping curl and jq works, and that is what cleura-shoot.sh does, but it is a workaround rather than a solution. No state, no plan, no diff — just imperative API calls.

Options if this needs to graduate beyond a script:

Crossplane provider-http — can wrap the REST API declaratively, but has no native polling or deletion hooks, so the reconciliation story is awkward
Custom Terraform provider — full plan/apply semantics, but requires writing a Go provider from scratch
Pulumi dynamic provider — similar effort, Python or TypeScript

A feature request for gardenctl access or a native IaC provider has been filed with Cleura (→ cleura/docs#533). Until something changes there, the bash script is as good as it gets.

Status

Step	Status
1 — Shoot cluster on Cleura	done
2 — Minecraft via LoadBalancer (itzg)	planned
2.5 — Migrate to Helm chart	planned
3 — Envoy Gateway	planned
4 — HTTPRoute + cert-manager + BlueMap	planned
5 — Migrate to TCPRoute	planned
6 — Velocity	planned
7 — Plugin pipeline (Dagger)	planned
8 — AI	planned

Building this out — notes will expand as each step lands.

Gardener on Cleura

Tue, 16 Jun 2026 00:00:00 +0000

Gardener is a Kubernetes-as-a-Service framework that runs on Kubernetes and manages the lifecycle of other clusters declaratively. Rather than managing control planes by hand, Gardener treats clusters as a resource — defined, created, upgraded, and deleted via the Gardener API.

Concepts

Gardener uses three layers:

Layer	What it is
Garden cluster	Runs Gardener itself — the management control plane
Seed cluster	Hosts the control planes of shoot clusters (as pods)
Shoot cluster	The cluster you actually use — nodes run on the target cloud

The shoot cluster’s API server does not run on the shoot nodes. It runs as a pod inside the seed cluster. From the outside it behaves like any other Kubernetes cluster; internally the control plane is isolated from the data plane.

Shoot clusters are defined as Shoot resources applied to the garden cluster:

apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
metadata:
 name: my-cluster
 namespace: garden-my-project
spec:
 cloudProfileName: openstack
 region: sto2
 provider:
 type: openstack
 workers:
 - name: worker-pool
 machine:
 type: l2.c2r4
 minimum: 1
 maximum: 3
 kubernetes:
 version: "1.30"
 networking:
 type: calico
 pods: 100.128.0.0/11
 nodes: 10.250.0.0/16
 services: 100.112.0.0/13

Shoot cluster on Cleura

Cleura is a European OpenStack provider. Gardener provisions shoot nodes as OpenStack VMs via the OpenStack machine controller.

Key integrations:

Component	Implementation
Node provisioning	OpenStack VMs via Gardener machine controller
Load balancers	Octavia via cloud-controller-manager
Block storage	Cinder via CSI driver
DNS	Manual or external-dns
CNI	Calico (default) or configurable

Gardener on Cleura does not provide an ingress controller or API gateway — these are brought in separately.

Networking

Gardener manages the cluster network configuration as part of the shoot spec. Pod, node, and service CIDRs are defined at cluster creation and must not overlap with the OpenStack network.

On Cleura, nodes get OpenStack floating IPs for egress. Pod-to-pod traffic stays within the cluster overlay network (Calico by default). Traffic entering from outside the cluster goes through a LoadBalancer service — either directly for raw TCP, or via a gateway controller for HTTP.

Ingress — classic vs Gateway API

The classic Kubernetes Ingress resource is HTTP-only, has no TCP support, and its feature set varies across implementations via non-standard annotations. The NGINX Ingress Controller — the most widely used implementation — is deprecated; NGINX now focuses on their Gateway API implementation instead.

The Kubernetes Gateway API is the forward path — a set of CRDs (Gateway, HTTPRoute, TCPRoute, TLSRoute) with a standardized spec and first-class support for both HTTP and TCP.

Resource	Protocol	API	Status
`Ingress`	HTTP only	Kubernetes	Stable, legacy
`HTTPRoute`	HTTP/HTTPS	Gateway API	Stable
`TCPRoute`	Raw TCP	Gateway API	Experimental
`TLSRoute`	TLS passthrough	Gateway API	Experimental

Envoy Gateway

Envoy Gateway is the CNCF implementation of the Kubernetes Gateway API using Envoy as the data plane. It supports HTTPRoute, TCPRoute, and TLSRoute through a single Gateway resource — one entry point, both protocols.

Octavia LB ← one LoadBalancer service per Gateway listener
 |
Envoy Gateway pod
 |
+------------------+------------------+
| |
HTTPRoute → ClusterIP pods TCPRoute → ClusterIP pods

Envoy Gateway is deployed into the shoot cluster and exposes a LoadBalancer service via Octavia, the same as any other service. The Gateway API resources then declare what routes through it.

TCPRoute — declaring TCP services

TCPRoute attaches to a Gateway listener and routes raw TCP traffic to a backend service. This is how a non-HTTP workload (e.g. a game server, a database proxy, a custom protocol service) gets exposed through the Gateway API rather than a standalone LoadBalancer service.

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
 name: my-tcp-service
 namespace: my-app
spec:
 parentRefs:
 - name: my-gateway
 sectionName: tcp-listener
 rules:
 - backendRefs:
 - name: my-service
 port: 1234

The corresponding Gateway listener:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
 name: my-gateway
 namespace: my-app
spec:
 gatewayClassName: envoy-gateway
 listeners:
 - name: tcp-listener
 protocol: TCP
 port: 1234
 - name: http-listener
 protocol: HTTP
 port: 80

One Gateway, both protocols declared explicitly. The TCPRoute API is in the experimental channel and requires opting in when installing Envoy Gateway.

HTTPRoute — HTTP services

HTTPRoute handles HTTP and HTTPS traffic with routing by hostname, path, header, or method — without annotations.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
 name: my-http-service
 namespace: my-app
spec:
 parentRefs:
 - name: my-gateway
 sectionName: http-listener
 hostnames:
 - my-app.example.com
 rules:
 - matches:
 - path:
 type: PathPrefix
 value: /
 backendRefs:
 - name: my-service
 port: 8080

LoadBalancer — direct TCP via Octavia

For cases where a TCPRoute is not appropriate (or the Gateway API experimental channel is not enabled), a LoadBalancer service provisions an Octavia LB directly:

apiVersion: v1
kind: Service
metadata:
 name: my-tcp-service
 namespace: my-app
spec:
 type: LoadBalancer
 selector:
 app: my-app
 ports:
 - port: 1234
 targetPort: 1234
 protocol: TCP

Annotations control Octavia behaviour — timeouts, health check parameters, internal vs external. These are provider-specific and not standardised across OpenStack deployments.

Storage

Cinder block volumes are available via the CSI driver. A PersistentVolumeClaim provisions a Cinder volume automatically using the cluster’s default storage class.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-data
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 20Gi

Cinder volumes are ReadWriteOnce — they attach to a single node. For stateful workloads, use StatefulSet rather than Deployment to get stable volume binding across pod restarts.

Provisioning a shoot cluster on Cleura

Cleura wraps Gardener behind their own REST API at rest.cleura.cloud. The garden cluster kubeconfig is not exposed — gardenctl does not work directly. Cluster lifecycle is managed through HTTP calls.

Authentication

Every call requires a token obtained once per session:

curl -s -X POST https://rest.cleura.cloud/auth/v1/tokens \
 -H "Content-Type: application/json" \
 -d '{"auth": {"login": "you@example.com", "password": "yourpass"}}' \
 | jq '{token: .token}'

Pass X-AUTH-LOGIN and X-AUTH-TOKEN headers on all subsequent calls.

Bootstrap (once per project/region)

Before creating any clusters, the project must be bootstrapped — this wires up the OpenStack credentials that Gardener uses to provision nodes:

curl -X POST \
 https://rest.cleura.cloud/gardener/v1/public/secret/kna1/{projectId}/bootstrap \
 -H "X-AUTH-LOGIN: ..." -H "X-AUTH-TOKEN: ..."

Safe to call repeatedly; idempotent.

Create a shoot cluster

curl -X POST \
 https://rest.cleura.cloud/gardener/v1/public/shoot/kna1/{projectId} \
 -H "X-AUTH-LOGIN: ..." -H "X-AUTH-TOKEN: ..." \
 -H "Content-Type: application/json" \
 -d '{
 "shoot": {
 "name": "my-cluster",
 "kubernetes": {"version": "1.31.0"},
 "provider": {
 "infrastructureConfig": {"floatingPoolName": "ext-net"},
 "workers": [{
 "name": "default",
 "machine": {
 "type": "4C-8GB-50GB",
 "image": {"name": "ubuntu", "version": "22.4.20230301"}
 },
 "minimum": 1,
 "maximum": 3,
 "volume": {"size": "50Gi"}
 }]
 }
 }
 }'

Poll until ready

curl https://rest.cleura.cloud/gardener/v1/public/shoot/kna1/{projectId}/my-cluster \
 -H "X-AUTH-LOGIN: ..." -H "X-AUTH-TOKEN: ..." \
 | jq '.lastOperation | {state, description, progress}'

Poll until lastOperation.state == "Succeeded". Takes roughly 10–15 minutes on first provision.

Fetch kubeconfig

The Cleura docs reference two kubeconfig paths — GET /kubeconfig (lowercase) and POST /Kubeconfig (uppercase, different casing). Neither worked reliably in practice. The endpoint that actually returns a kubeconfig is:

curl -s -X POST \
 https://rest.cleura.cloud/gardener/v1/public/shoot/kna1/{projectId}/my-cluster/adminkubeconfig \
 -H "X-AUTH-LOGIN: ..." -H "X-AUTH-TOKEN: ..." \
 -H "Content-Type: application/json" \
 -d '{"config": {"expirationSeconds": 3600}}' \
 | jq -r > my-cluster-kubeconfig.yaml

The expirationSeconds field controls credential lifetime. A bug report has been filed with Cleura about the endpoint inconsistency — the adminkubeconfig path is not documented.

Path	Method	Documented	Works
`/kubeconfig`	GET	yes	unclear
`/Kubeconfig`	POST	yes	unclear
`/adminkubeconfig`	POST	no	yes

→ Cleura docs issue #534 — kubeconfig endpoint inconsistencies in Gardener REST API

Script

A bash script wrapping the full workflow (list, create, wait, kubeconfig, delete) is available: cleura-shoot.sh

export CLEURA_LOGIN="you@example.com"
export CLEURA_PASSWORD="yourpass"

./cleura-shoot.sh list
./cleura-shoot.sh create my-cluster
./cleura-shoot.sh wait my-cluster
./cleura-shoot.sh kubeconfig my-cluster
./cleura-shoot.sh delete my-cluster

IaC options

No native Terraform provider exists for Cleura’s Gardener REST API. The Gardener Terraform provider (registry.terraform.io/providers/gardener/gardener) requires the garden cluster kubeconfig, which Cleura does not expose. Options:

Approach	Notes
Bash + curl	Minimal deps — just `curl` and `jq`
Crossplane `provider-http`	Declarative, Kubernetes-native, reconciliation loop
Custom Terraform provider	Full `plan`/`apply` semantics — requires Go provider development
Pulumi custom dynamic provider	Python/TypeScript, similar effort to custom Terraform provider

BIFROST — Raspberry Pi jump node

Fri, 05 Jun 2026 00:00:00 +0000

The homelab needed a permanent always-on entry point — something low power, always reachable, a stable first hop. A first-gen Raspberry Pi in the rack fills that role. BIFROST.

Hardware

Raspberry Pi 1 Model B running Raspbian, mounted in the rack with a 3D printed 1U mount. Draws under 2W at idle. Nothing runs on it except sshd.

How it works

ssh -p 22222 user@bifrost.mjnet.info

The chain:

bifrost.mjnet.info — Route53 CNAME pointing to router.mjnet.info
router.mjnet.info — HEIMDAL (SYS-009), kept current via DDNS
OPNsense port forward: external TCP 22222 → Pi:22
OPNsense DNS override: bifrost.mjnet.info → Pi’s internal IP

The DNS override means the same hostname resolves to the internal IP when used inside the network — no split config needed in ~/.ssh/config.

OPNsense config

Port forward (Firewall → NAT → Port Forward):

Interface: WAN
Protocol: TCP
Destination port: 22222
Redirect target: Pi internal IP, port 22

DNS override (Services → Unbound DNS → Host Overrides):

Host: bifrost
Domain: mjnet.info
IP: Pi internal IP

SSH config

Add to ~/.ssh/config on any client:

Host bifrost
 HostName bifrost.mjnet.info
 Port 22222
 User pi

Then ssh bifrost from anywhere.

If a more robust solution becomes necessary later (no open ports, survives CGNAT), the options doc covers Tailscale, Cloudflare Tunnel, and WireGuard.

Bastion / jump server

Fri, 22 May 2026 00:00:00 +0000

A bastion host (jump server) is a single, hardened machine exposed to the outside that acts as the entry point into a private network. You SSH into the bastion, then hop from there to internal hosts — or configure your SSH client to do it transparently in one step.

The pattern is simple: minimise the network attack surface to one well-monitored machine, harden that machine specifically, and keep everything else off the public internet.

Basic jump: manual two-hop

# Step 1: SSH into the bastion
ssh user@bastion.example.com

# Step 2: from bastion, SSH into internal host
ssh user@192.168.1.100

Works, but requires your private key to be on the bastion — which you want to avoid.

ProxyJump (recommended)

ProxyJump tells SSH to tunnel through the bastion transparently. Your key never leaves your local machine.

# One-liner
ssh -J user@bastion.example.com user@192.168.1.100

# Or in ~/.ssh/config
Host internal
 HostName 192.168.1.100
 User user
 ProxyJump bastion

Host bastion
 HostName bastion.example.com
 User user
 IdentityFile ~/.ssh/id_ed25519

After this, ssh internal works as a single command with no key on the bastion.

Agent forwarding vs ProxyJump

Agent forwarding (-A, ForwardAgent yes) forwards your SSH agent socket through the bastion so you can authenticate onward with your local key. Older approach — it works but the agent socket is briefly accessible on the bastion host, which is a lateral movement risk if the bastion is compromised.

ProxyJump is strictly better for the common case: the connection to the internal host is established from your machine through an SSH tunnel, not from the bastion itself. No agent socket on the bastion.

Use ProxyJump unless you specifically need agent forwarding for something else.

Hardening basics

A bastion is only useful if it’s actually hardened. Minimum:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers jumpuser

Key-only authentication — no passwords
Dedicated user with no shell access to the bastion itself (optional: ForceCommand to restrict what they can do)
Non-standard port reduces log noise, not actual security
fail2ban or equivalent for rate-limiting auth attempts
Minimal installed software — the bastion should do one thing
Regular log review (/var/log/auth.log)

Restricting to jump-only

If you want users to be able to jump through the bastion but not get a shell on it:

# In authorized_keys, prefix the key with:
restrict,port-forwarding ssh-ed25519 AAAA...

Or use AllowTcpForwarding yes with ForceCommand /usr/sbin/nologin — though the interaction between these options is subtle; test carefully.

For making the bastion reachable from outside without a public IP → Tunnels
For exposing internal web services via public URLs → Tunneled reverse proxy platforms

Dynamic DNS (DDNS)

Fri, 22 May 2026 00:00:00 +0000

Most home internet connections have a dynamic IP — the ISP can reassign it at any time. Dynamic DNS (DDNS) keeps a DNS hostname pointed at whatever IP you currently have, by running a small client that detects changes and updates the DNS record automatically.

Relevant when using port forwarding or WireGuard to reach a private network from outside — you need a stable hostname to connect to.

How it works

You register a hostname with a DDNS provider (e.g. myhome.duckdns.org)
An update client runs on your router or a machine on your network
The client periodically checks your public IP (or watches for changes) and calls the provider’s API to update the DNS record
DNS TTL is kept short (60–300s) so changes propagate quickly

Providers

Provider	Cost	Domain	Notes
DuckDNS	Free	`*.duckdns.org`	Simple, no account required beyond OAuth login
Cloudflare	Free (if you own a domain)	Your own domain	Best option if you already use Cloudflare for DNS
No-IP	Free (limited)	`*.ddns.net` etc.	Requires manual renewal every 30 days on free tier
Dynu	Free	`*.dynu.net` etc.	More generous free tier than No-IP
Afraid.org	Free	Shared subdomains	Long-running community service

Cloudflare is the best option if you own a domain — you get a real subdomain (home.yourdomain.com), the API is reliable, and the client support is universal.

DuckDNS is the easiest if you don’t own a domain — no configuration beyond a token.

OPNsense

OPNsense has a built-in DDNS client under Services → Dynamic DNS. Supports Cloudflare, DuckDNS, No-IP, Route53, and others out of the box.

Configuration for Cloudflare:

Service: Cloudflare
Hostname: home (the subdomain to update)
Domain: yourdomain.com
Username: your Cloudflare account email
Password: Cloudflare API token with Zone:DNS:Edit permission for the domain
Check IP: leave default (uses OPNsense’s WAN interface)

OPNsense updates the record whenever the WAN IP changes, detected via interface monitoring.

Linux update clients

If the router doesn’t have a built-in client (or you want updates from a specific host):

ddclient — the standard, supports most providers:

apt install ddclient

# /etc/ddclient.conf (Cloudflare example)
protocol=cloudflare
zone=yourdomain.com
login=your@email.com
password=<api-token>
ttl=1
home.yourdomain.com

inadyn — lighter alternative, similar provider support:

apt install inadyn

# /etc/inadyn.conf
provider cloudflare.com {
 username = your@email.com
 password = <api-token>
 hostname = home.yourdomain.com
 ttl = 1
 proxied = false
}

Limitations

DDNS does not help if your ISP uses CGNAT — if your router’s WAN IP is a private address (10.x, 100.64.x, 192.168.x), port forwarding and DDNS will not work. See Tunnels for options that work without a public IP.

DNS propagation delay means there’s a brief window after an IP change where connections will fail. Keep TTL at 60–300s to minimise this.

Firewall and router OS options

Fri, 22 May 2026 00:00:00 +0000

Options for running a software-defined firewall or router, from homelab appliances to full routing OS deployments.

The main split: appliance vs routing OS

Most options fall into one of two categories:

Firewall appliances (OPNsense, pfSense, IPFire) — web UI-first, designed around the perimeter firewall use case. NAT, DHCP, DNS, VPN, IDS/IPS out of the box. Routing is possible but secondary.

Routing operating systems (VyOS, MikroTik RouterOS, FRRouting) — CLI-first, designed around dynamic routing protocols (BGP, OSPF). Firewall rules exist but feel like an afterthought compared to the routing capabilities.

For a homelab perimeter gateway: appliance. For BGP peering, complex routing topologies, or network-as-code: routing OS.

OPNsense

Open-source firewall and routing platform based on FreeBSD. Fork of pfSense, with a stronger emphasis on community ownership and more frequent security updates.

Full gateway function: stateful firewall, NAT, DHCP, DNS (Unbound), TFTP/PXE, VPN (WireGuard, OpenVPN, IPsec), traffic shaping, IDS/IPS (Suricata), DDNS.

BGP is available via the FRRouting plugin but is not a first-class feature — VyOS is better suited for BGP-heavy setups.

→ OPNsense reference

Best for: homelab perimeter gateway, home network, small office. The current actively-maintained community fork of the pfSense lineage.

pfSense

The original FreeBSD-based firewall appliance. Same underlying capabilities as OPNsense — they share a common ancestor (m0n0wall).

Now owned by Netgate. The Community Edition (CE) remains open source; pfSense Plus is commercial and ships only on Netgate hardware or as a cloud image. Development focus has shifted toward Plus; CE updates have been slower.

The practical difference between OPNsense and pfSense CE is increasingly small at the feature level. The main reasons to choose one over the other are familiarity, UI preference, and update cadence. OPNsense is the more actively developed option for community use.

Best for: environments where pfSense is already deployed, or where existing documentation/tooling targets it.

VyOS

Open-source network OS built on Debian. Configured via a CLI with a commit/rollback model (similar to Juniper JunOS). Native BGP, OSPF, IS-IS via FRRouting.

Configuration is declarative and version-controlled — the entire running config is a text file, which makes it automation-friendly (Ansible, Terraform).

The rolling release is free; LTS releases require a subscription.

→ VyOS reference

Best for: BGP peering, complex routing topologies, automation-driven network config, VM-based routing inside a cluster.

MikroTik RouterOS

Commercial OS that runs on MikroTik hardware and as a VM (CHR — Cloud Hosted Router). Full routing OS with BGP, OSPF, MPLS, and a firewall. Configured via Winbox GUI, web UI, or CLI.

Very capable at the price point. Hardware is inexpensive. The learning curve is steeper than OPNsense but shallower than VyOS for most tasks. Community is large and documentation is thorough.

CHR (the VM version) is free for speeds up to 1Mbps; licensed tiers above that. On physical hardware, the license is included.

Best for: cost-conscious deployments that need routing features, or environments already using MikroTik hardware.

IPFire

Linux-based firewall focused on simplicity and security hardening. Web UI, stateful firewall, IDS (Snort/Suricata), VPN (OpenVPN, WireGuard, IPsec), proxy.

Less feature-rich than OPNsense but lighter and more opinionated. No BGP. Easier to get to a secure baseline quickly.

Best for: simple gateway where you want a small attack surface and don’t need advanced routing or a plugin ecosystem.

Untangle / Arista Edge Threat Management

Commercial product with a free tier (NG Firewall). Web UI, application-layer filtering, content inspection, threat management features. More enterprise-oriented than the others.

Requires registration. The free tier is limited; the feature set that differentiates it from OPNsense is mostly in the commercial tiers.

Best for: environments that need application-layer filtering with a managed UI, or commercial support requirements.

Comparison

	OPNsense	pfSense CE	VyOS	MikroTik RouterOS	IPFire
Base OS	FreeBSD	FreeBSD	Debian	Proprietary	Linux
Primary interface	Web UI	Web UI	CLI	Winbox / CLI	Web UI
BGP / OSPF	Plugin (FRR)	Plugin (FRR)	Native (FRR)	Native	No
IDS/IPS	Suricata	Snort/Suricata	No	No	Snort/Suricata
WireGuard	Yes	Yes (Plus)	Yes	Yes	Yes
DDNS	Yes	Yes	Via script	Yes	Yes
Cost	Free	Free (CE)	Free (rolling)	Hardware license	Free
Community	Active	Slowing (CE)	Active	Active	Active

Tunneled reverse proxy platforms

Fri, 22 May 2026 00:00:00 +0000

A step beyond raw tunnels. These platforms expose services running on a private network as public HTTPS URLs — no open ports, no public IP required. The key difference from a VPN: you don’t get network-level access to the remote machine, you get a link to a specific service.

Typical flow:

Internet → public server (VPS) → tunnel → private network → your service

The private machine maintains an outbound connection to the public server. Inbound traffic arrives at the public server and is forwarded back through the tunnel to the service.

Pangolin

Self-hosted platform built specifically for this use case. You run the server component on a VPS; client agents (called Newt) run on machines inside your private network and establish outbound tunnels. Services get public HTTPS URLs. Access control is built in — you can gate services behind auth without touching the service itself.

Components:

Pangolin — the server, runs on a VPS, handles routing and auth
Newt — the tunnel client, runs on private machines, connects out to Pangolin
Gerbil — WireGuard-based tunnel layer (handled automatically)
Traefik — reverse proxy, managed by Pangolin for routing

# On the VPS (docker-compose)
# Pangolin + Traefik + Gerbil run together

# On a private machine
docker run -e SERVER_URL=https://pangolin.yourdomain.com \
 -e TUNNEL_SECRET=... \
 fosrl/newt

Services then appear at subdomains: service.yourdomain.com — proxied through the tunnel, with optional SSO/auth in front.

Property
Self-hosted	Yes — you own the VPS and the data
Open ports on private network	No
Public IP required	VPS only (not home)
Auth built in	Yes
Cost	Free, open source
Maturity	Newer project (2024–)

Good fit for homelabs where you want public-facing services but don’t want to expose your home IP or open ports on your router.

ngrok

The original in this space. Run a single command, get a public URL. No server to manage — ngrok’s infrastructure handles it.

ngrok http 8080
# → https://abc123.ngrok.io

The URL changes on every restart unless you’re on a paid tier. Custom domains, persistent tunnels, and traffic inspection (useful for debugging webhooks) are paid features.

Property
Self-hosted	No
Open ports on private network	No
Auth built in	Yes (paid)
Cost	Free tier limited; paid for custom domains
Maturity	Established, widely used

Best for: quick testing, webhook development, demos. Not ideal for a permanent homelab setup due to the dependency and cost at scale.

frp (Fast Reverse Proxy)

Lightweight, self-hosted. You run frps (server) on a VPS and frpc (client) on private machines. More DIY than Pangolin — you configure the routing yourself, no built-in auth or dashboard.

# frps.toml (on VPS)
bindPort = 7000

# frpc.toml (on private machine)
serverAddr = "your-vps-ip"
serverPort = 7000

[[proxies]]
name = "my-service"
type = "http"
localPort = 8080
customDomains = ["service.yourdomain.com"]

Property
Self-hosted	Yes
Open ports on private network	No
Auth built in	Basic (token auth between client/server)
Cost	Free, open source
Maturity	Established, widely used in homelab

Good fit if you want full control and are comfortable wiring things together. No UI — config files only.

Expose (BeyondCode)

PHP-based self-hosted ngrok alternative. Dashboard included, custom domains, multiple tunnels.

expose share http://localhost:8080

Less common than frp or Pangolin, but polished for a self-hosted tool.

Comparison

	Pangolin	ngrok	frp	Expose
Self-hosted	Yes	No	Yes	Yes
Auth / access control	Yes (built-in)	Paid	No (DIY)	Basic
Dashboard	Yes	Yes	No	Yes
Custom domains	Yes	Paid	Yes	Yes
Complexity	Medium	Low	Medium	Medium
Maturity	Newer	Established	Established	Moderate

When to use which

Pangolin if you want a self-hosted, permanent setup with auth and public URLs for homelab services. The right choice if you’re already running a VPS.

ngrok for quick tests, webhook development, or one-off sharing. Not for permanent services.

frp if you want maximum control and minimal overhead, and are comfortable configuring a reverse proxy separately.

For network-level access (not service URLs) → Tunnels
For SSH entry points → Bastion / jump server

Tunnels — remote network access

Fri, 22 May 2026 00:00:00 +0000

Approaches for accessing a private network (home lab, office) from outside, when you don’t have a static public IP and may be behind NAT or CGNAT.

First: check if you’re behind CGNAT

Run on a device inside the network:

curl ifconfig.me

Compare the result to the WAN IP shown in your router. If they match — you have a real public IP (possibly dynamic). If they differ — you’re behind CGNAT, and port forwarding will not work regardless of router config.

Tailscale

WireGuard-based mesh VPN. Each device gets a node in a private overlay network coordinated by Tailscale’s control plane. Connections are peer-to-peer where possible; relay servers (DERP) handle cases where direct traversal fails.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Subnet routing: one node (e.g. a Pi on the LAN) advertises the local subnet. Other Tailscale nodes route through it — the whole LAN becomes reachable, not just that one node.

sudo tailscale up --advertise-routes=192.168.1.0/24

Exit node: route all internet traffic through a Tailscale node — useful on untrusted networks.

Property
Open ports required	No
Public IP required	No
Works through CGNAT	Yes
Third-party dependency	Yes (coordination server)
Free tier	100 devices
Self-hostable	Yes — Headscale

The coordination server must be reachable to establish new connections. Existing sessions survive outages. Headscale replaces the coordination server while reusing the same clients.

Cloudflare Tunnel

The device on your private network runs cloudflared, which holds an outbound connection to Cloudflare’s edge. Cloudflare proxies inbound traffic through it. No open ports, no public IP needed.

Works for SSH, HTTP, and other TCP services. Native SSH support: access via cloudflared access ssh or a browser terminal.

cloudflared tunnel login
cloudflared tunnel create homelab
cloudflared tunnel route dns homelab ssh.yourdomain.com
cloudflared tunnel run homelab

Property
Open ports required	No
Public IP required	No
Works through CGNAT	Yes
Third-party dependency	Yes — traffic passes through Cloudflare
Requires	Domain on Cloudflare
Cost	Free (Zero Trust free tier)

Traffic passes through Cloudflare’s infrastructure. For SSH this means an encrypted session transiting a third party’s edge.

WireGuard (self-hosted)

WireGuard server on a node in the private network. Remote clients connect with a config containing the server’s public key and endpoint. Encrypted point-to-point, no intermediary.

Requires a real public IP at the WAN, UDP port forwarding on the router (default 51820), and DDNS if the IP is dynamic.

# /etc/wireguard/wg0.conf (server)
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <server-private-key>

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.0.0.2/32

Property
Open ports required	Yes (UDP 51820)
Public IP required	Yes
Works through CGNAT	No
Third-party dependency	No
Complexity	Medium

Full ownership, no external dependency, very fast. Key distribution is manual unless you layer a management tool on top (e.g. wg-easy, Netbird).

Port forwarding + DDNS

Forward a port on the router to the target host. Use a DDNS provider (DuckDNS, Cloudflare, etc.) to keep a hostname pointed at the dynamic IP.

Exposes a service directly to the internet. Minimum hardening for SSH:

Key-only auth (PasswordAuthentication no)
Non-standard port
fail2ban or equivalent
Regular review of auth logs

Property
Open ports required	Yes (TCP)
Public IP required	Yes
Works through CGNAT	No
Third-party dependency	DDNS provider only
Complexity	Low–Medium

Comparison

	Tailscale	Cloudflare Tunnel	WireGuard	Port forward
Open ports	No	No	Yes	Yes
Public IP	No	No	Yes	Yes
CGNAT	Works	Works	Fails	Fails
Traffic via third party	Metadata only	Yes	No	No
Self-hostable	Yes (Headscale)	No	Yes	Yes
Complexity	Low	Low–Med	Medium	Low–Med

Which to use

Start with Tailscale if you want the least friction and aren’t sure whether you’re behind CGNAT. Subnet routing covers the entire LAN through a single node.

Use Cloudflare Tunnel if you have a domain on Cloudflare and want browser-accessible SSH or HTTP without client software.

Use WireGuard if you have a confirmed public IP and want no third-party in the data path.

Use port forwarding only if you already have DDNS working and want no new software — it has the highest hardening overhead.

For a hardened SSH entry point → Bastion / jump server
For exposing internal web services via public URLs → Tunneled reverse proxy platforms

BGP

Thu, 14 May 2026 00:00:00 +0000

BGP (Border Gateway Protocol) is the routing protocol that holds the internet together. Every major network operator uses it to advertise which IP prefixes they own and to exchange that information with peers. In a homelab context the scale is different but the mechanics are the same.

BGP is a path-vector protocol: each router advertises routes along with the path (sequence of ASNs) taken to reach them. Routers choose the best path based on a set of attributes and policy rules, then advertise that path to their peers.

eBGP vs iBGP

eBGP (external BGP) — sessions between routers in different autonomous systems. Each party has a different ASN. This is what you configure between VyOS and OPNsense, and between VyOS and MetalLB.

iBGP (internal BGP) — sessions between routers in the same autonomous system. Used inside large networks to distribute external routes internally. Not relevant for a basic homelab setup.

ASNs for private use

Autonomous System Numbers in the range 64512–65534 are reserved for private use (RFC 6996) — the same concept as RFC 1918 private IP addresses. Assign one to each participant in your BGP topology:

Participant	Example ASN
OPNsense	64512
VyOS	64513
MetalLB (Talos cluster)	64514

Why BGP for Kubernetes LoadBalancer IPs

Kubernetes LoadBalancer services need something external to the cluster to route traffic to them. In a cloud environment the cloud provider handles this automatically. On bare metal you need to do it yourself.

Two common approaches with MetalLB:

L2 mode — MetalLB uses ARP (IPv4) or NDP (IPv6) to announce service IPs directly on the LAN. Simple to set up. Limitations: only one node handles traffic for each IP at a time (no real load balancing at the network layer), and the service IP must be in the same subnet as the nodes.

BGP mode — MetalLB establishes a BGP session with an upstream router (VyOS, for example) and announces service IPs as /32 prefixes. The router learns the route and can ECMP across all nodes that are advertising it. More correct: actual load balancing, no subnet constraint, clean separation between cluster and network layer.

The tradeoff is that BGP mode requires a BGP-capable router in the path, which is why VyOS exists in this topology.

Testing with a real BGP network

DN42 is a community-run experimental network that simulates the real internet using actual BGP, DNS, and whois infrastructure. Participants connect via WireGuard or other tunnels and peer with each other using real BGP sessions and real (private-range) ASNs. A good way to practice BGP outside the homelab without needing a production ASN.

VyOS — the BGP peer router
VyOS + BGP experiment — the actual setup in this homelab

OPNsense

Thu, 14 May 2026 00:00:00 +0000

OPNsense is an open-source firewall and routing platform based on FreeBSD. It is a fork of pfSense, with a stronger emphasis on community ownership, a cleaner UI, and more frequent security updates. Both are descendants of m0n0wall.

It covers the full gateway function: stateful firewall, NAT, DHCP, DNS, TFTP, VPN, traffic shaping, and IDS/IPS — all through a web UI or via the API.

Feature overview

Feature	Notes
Stateful firewall	Zone-based rules, aliases, scheduling
NAT	Outbound, inbound (port forwarding), 1:1
DHCP	ISC DHCPv4 and Kea; supports network boot options
DNS	Unbound resolver with DNSSEC; optional forwarding
TFTP	Simple server at `/usr/local/tftp`; used for PXE boot
VPN	WireGuard, OpenVPN, IPsec
IDS/IPS	Suricata integration
Traffic shaping	HFSC, PRIQ, CAKE
BGP / routing	FRRouting plugin available (not enabled by default)

OPNsense vs pfSense vs VyOS

	OPNsense	pfSense	VyOS
Base	FreeBSD	FreeBSD	Debian Linux
License	BSD (true FOSS)	BSL (mixed)	GPL
Model	Firewall appliance	Firewall appliance	Network OS
Config interface	Web UI + API	Web UI	CLI (commit/rollback)
BGP	Via FRRouting plugin	Via FRRouting plugin	Native (FRRouting built-in)
Typical use	Edge gateway, firewall	Edge gateway, firewall	Router, BGP peer, lab router VM

OPNsense and pfSense are both appliance-style: you configure them through a UI and they manage all the underlying services for you. VyOS is a network OS in the Juniper/Cisco tradition — CLI-first, commit/rollback, intended for use as a router or BGP peer rather than a full gateway appliance.

OPNsense documentation
OPNsense plugins
iPXE + OPNsense — PXE boot configuration via OPNsense DHCP and TFTP
OPNsense in the homelab — current setup and planned redo

OPNsense in the homelab

Thu, 14 May 2026 00:00:00 +0000

OPNsense running on the Sun Fire X4150 — perimeter gateway for both the homelab and the home network.

Current state: inherited setup, not clean, not properly documented. It works, but it was not built with intention. A redo is on the todo list.

Dual role is intentional and will stay that way — OPNsense on the Sun Fire handles both the homelab and the house. One box, one gateway.

The Sun Fire X4150 handles it without breaking a sweat. Old, but solid.

TODO: Clean reinstall

Fresh OPNsense install on the Sun Fire
Rename from router.mjnet.info → heimdal.mjnet.info
Document the full configuration: firewall rules, DHCP, DNS (Unbound), TFTP/PXE, BGP peering with VyOS

On the hostname rename: making the router’s hostname publicly resolvable is a mild information disclosure — it signals which host is the perimeter device. In practice the IP is what matters, and if it’s already reachable the name adds little. Still worth being deliberate about what resolves publicly.

Intended role

ISP/WAN → OPNsense (heimdal.mjnet.info) → LAN switch → rack

Perimeter firewall and NAT gateway
DHCP for the LAN
DNS via Unbound
TFTP/PXE for bare-metal provisioning
eBGP peer upstream of VyOS (future — see VyOS + BGP)

VyOS

Thu, 14 May 2026 00:00:00 +0000

VyOS is an open-source network operating system built on Debian Linux. It runs on bare metal or as a VM, and is configured via a CLI with a commit/rollback model similar to Juniper JunOS. Configuration changes are staged and only take effect when you explicitly commit — there is no live-editing a running config and hoping nothing breaks.

It ships FRRouting (FRR) as the routing engine, giving it native support for BGP, OSPF, IS-IS, and other protocols. This is its main distinction from OPNsense for homelab use: OPNsense is a firewall appliance that can do some routing; VyOS is a routing OS that can also do firewall.

Configuration model

vyos@router# set interfaces ethernet eth0 address '192.168.1.254/24'
vyos@router# set protocols bgp system-as '65001'
vyos@router# commit
vyos@router# save

configure enters configuration mode. set stages a change. commit applies it. save persists it to disk. rollback reverts to the last committed state if something goes wrong. The separation between staging and applying is genuinely useful when changing routing configuration remotely.

Key features

Feature	Notes
BGP	Via FRRouting; full eBGP/iBGP support
OSPF / IS-IS	Also via FRR
Static routing	Standard
VLAN	802.1Q trunking
NAT	Source and destination NAT
Firewall	Zone-based, stateful
WireGuard	Built-in
OpenVPN	Built-in
DHCP server	Built-in
VXLAN	Supported

VyOS vs OPNsense

VyOS is the right choice when you want a dedicated BGP peer or a router VM with a clean CLI config model. OPNsense is the right choice when you want a full gateway appliance with a web UI.

Automation

VyOS is designed to be automated — the commit/rollback model maps cleanly onto infrastructure-as-code workflows.

REST API — built-in HTTP API for retrieving and applying configuration programmatically. Useful for scripting config changes without SSH.

Ansible — official vyos.vyos collection on Ansible Galaxy. Modules for interfaces, BGP, firewall rules, and more. Changes go through the normal commit/rollback cycle.

Terraform — community provider available. Less mature than the Ansible collection but usable for provisioning router config alongside other infrastructure.

VyOS documentation
VyOS REST API
VyOS Ansible collection
VyOS rolling release downloads
BGP — protocol background
OPNsense — the complementary edge gateway
VyOS + BGP in the homelab — the actual setup

Cables & Transceivers Inventory

Wed, 13 May 2026 00:00:00 +0000

SAS Cables

Component ID	Type	Connectors	Length	Qty	Notes
CBL-SAS-001	Internal Mini-SAS	SFF-8087 → SFF-8087	?	?
CBL-SAS-002	Int → Ext Mini-SAS	SFF-8087 → SFF-8088	?	?	Needed for internal cards (CTRL-002/003) to reach DAS
CBL-SAS-003	Ext SAS	SFF-8470 → SFF-8088	?	?	CTRL-006 → MIMIR

Ethernet Cables

Component ID	Type	Speed	Length	Qty	Notes
CBL-ETH-001	Cat5e/Cat6	1GbE	?	?

SFP / SFP+ Transceivers

Component ID	Type	Speed	Wavelength	Reach	Qty	Where used
SFP-001	SFP	1GbE	?	?	?	BIFROST-01/02 (28 cages each); MODI (4 cages)
SFP-002	XFP	10GbE	?	?	?	ASGARD switch ports 20-21 (2× XFP per module × 2)

Adapters

Component ID	Description	From	To	Qty	Notes
ADP-001	SFF-8470 → SFF-8088	SFF-8470	SFF-8088	?	Passive; alternative to CBL-SAS-003 if cabling via adapter

Network Inventory

Wed, 13 May 2026 00:00:00 +0000

NIC Catalog

Component ID	Manufacturer	Model / FRU	Ports	Speed	Interface	Notes
NIC-001	IBM	Onboard (x3550 M3 mobo)	2	1GbE	RJ45	Integrated; present on all x3550 M3
NIC-002	IBM	Dual-port GbE Daughter Card (FRU 43V6927)	2	1GbE	RJ45	Add-in daughter card slot
NIC-003	Sun / Intel	Onboard quad GbE (Sun Fire X4150)	4	1GbE	RJ45	Integrated; all 4 ports on rear
NIC-004	HP / Emulex	FlexFabric 554FLB (647584-001)	2	10GbE	SFP+ FLB	FlexibleLOM slot; FCoE + Flex-10 capable; BL460c Gen8

NIC Placement

Asset ID	Hostname	Component ID	Total Data Ports	Mgmt Port	Notes
SYS-005	ODEN	NIC-001	2× GbE	1× IMM
SYS-006	LOKE	NIC-001 + NIC-002	4× GbE	1× IMM	Daughter card FRU 43V6927
SYS-009	HEIMDAL	NIC-003	4× GbE	1× mgmt	OPNsense firewall

Network Addresses

Asset ID	Hostname	Interface	Role
SYS-005	ODEN	eth0	data
SYS-005	ODEN	eth1	data
SYS-005	ODEN	mgmt	IMM
SYS-006	LOKE	eth0	data
SYS-006	LOKE	eth1	data
SYS-006	LOKE	eth2	data
SYS-006	LOKE	eth3	data
SYS-006	LOKE	mgmt	IMM

Switch Ports

Asset ID	Hostname	Port Type	Count	SFP Cages	Uplink	Notes
SYS-012	BIFROST-01	SFP Fiber	28	28	?	All-SFP switch
SYS-013	BIFROST-02	SFP Fiber	28	28	?	All-SFP switch
SYS-014	MODI	RJ45 + SFP	24+4	4	?	24× GbE PoE + 4× SFP
SYS-015	MAGNI	RJ45	24	?	?	24× GbE managed
SYS-016	VALI	RJ45	24	?	?	Fanless; 24× GbE

NGINX

Mon, 01 Jan 2024 00:00:00 +0000

NGINX is a high-performance web server and reverse proxy built around an event-driven, non-blocking architecture. Where Apache spawns a thread per connection, NGINX handles thousands of concurrent connections from a small, fixed number of worker processes — making it well-suited to acting as the entry point for modern distributed systems.

Server blocks

NGINX configuration is structured around server blocks (analogous to Apache’s VirtualHost). Each block defines how to handle requests for a given hostname or port:

server {
 listen 80;
 server_name example.com;

 location / {
 root /var/www/html;
 index index.html;
 }
}

Multiple server blocks in a single NGINX instance handle traffic for different domains — NGINX selects the block by matching the Host header against server_name.

Reverse proxy

The primary use case in infrastructure work: NGINX sits in front of application servers and forwards requests to them. The application never needs to be exposed directly.

server {
 listen 80;
 server_name api.example.com;

 location / {
 proxy_pass http://127.0.0.1:8080;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

X-Forwarded-For and X-Real-IP headers pass the original client IP to the upstream — without these the application sees only the proxy address.

SSL termination

NGINX handles TLS and speaks plain HTTP to backends. This centralises certificate management and offloads crypto from application processes:

server {
 listen 443 ssl;
 server_name example.com;

 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;

 location / {
 proxy_pass http://127.0.0.1:8080;
 }
}

# Redirect HTTP → HTTPS
server {
 listen 80;
 server_name example.com;
 return 301 https://$host$request_uri;
}

Pair with Let’s Encrypt and Certbot for automated certificate issuance and renewal.

Load balancing

NGINX distributes traffic across multiple upstream instances using an upstream block:

upstream app {
 server 10.0.0.1:8080;
 server 10.0.0.2:8080;
 server 10.0.0.3:8080;
}

server {
 listen 80;
 location / {
 proxy_pass http://app;
 }
}

Default is round-robin. Other strategies: least_conn (fewest active connections), ip_hash (sticky sessions by client IP), hash (consistent hashing by arbitrary key).

Static files

NGINX serves static assets efficiently — far more so than most application frameworks. A common pattern: serve static files directly from NGINX, proxy only dynamic requests to the application.

location /static/ {
 alias /var/www/static/;
 expires 1y;
 add_header Cache-Control "public, immutable";
}

location / {
 proxy_pass http://app;
}

Useful patterns

Rate limiting — protect endpoints from abuse:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
 limit_req zone=api burst=20 nodelay;
 proxy_pass http://app;
}

Health check path — expose a simple status endpoint:

location /healthz {
 access_log off;
 return 200 "ok\n";
 add_header Content-Type text/plain;
}

Test config before reloading: nginx -t. Reload without dropping connections: nginx -s reload.

Networking on Backend Engineering Strategy Tools

Gardener on Cleura

Steps

1 — Shoot cluster

2 — Minecraft via standard LoadBalancer

2.5 — Migrate to Helm chart

3 — Envoy Gateway

4 — HTTPRoute, certificates, and BlueMap

5 — Migrate to TCPRoute

6 — Velocity (if needed)

7 — Plugin pipeline

8 — AI

IaC gap

Status

Gardener on Cleura

Concepts

Shoot cluster on Cleura

Networking

Ingress — classic vs Gateway API

Envoy Gateway

TCPRoute — declaring TCP services

HTTPRoute — HTTP services

LoadBalancer — direct TCP via Octavia

Storage

Provisioning a shoot cluster on Cleura

Authentication

Bootstrap (once per project/region)

Create a shoot cluster

Poll until ready

Fetch kubeconfig

Script

IaC options

BIFROST — Raspberry Pi jump node

Hardware

How it works

OPNsense config

SSH config

Bastion / jump server

Basic jump: manual two-hop

ProxyJump (recommended)

Agent forwarding vs ProxyJump

Hardening basics

Restricting to jump-only

Related

Dynamic DNS (DDNS)

How it works

Providers

OPNsense

Linux update clients

Limitations

Firewall and router OS options

The main split: appliance vs routing OS

OPNsense

pfSense

VyOS

MikroTik RouterOS

IPFire

Untangle / Arista Edge Threat Management

Comparison

Further reading

Tunneled reverse proxy platforms

Pangolin

ngrok

frp (Fast Reverse Proxy)

Expose (BeyondCode)

Comparison

When to use which

Related

Tunnels — remote network access

First: check if you’re behind CGNAT

Tailscale

Cloudflare Tunnel

WireGuard (self-hosted)

Port forwarding + DDNS

Comparison

Which to use

Related

BGP

eBGP vs iBGP

ASNs for private use