Opnsense on Backend Engineering Strategy Tools

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.

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

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)

PXE Booting with OPNSense + iPXE

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

How to configure OPNSense as a PXE boot server using its built-in DHCP and TFTP services, and how to write an iPXE boot menu that can chainload Talos Linux (or anything else).

OPNSense DHCP — Network Boot Fields

Services → ISC DHCPv4 → [LAN] → Network Booting

Field	Value
Enable network booting	✓
Next-server IP	`192.168.1.1` (OPNSense LAN address)
Default BIOS filename	`undionly.kpxe`
x86 UEFI (32-bit) filename	`ipxe.efi`
x64 UEFI/EBC (64-bit) filename	`ipxe.efi`
iPXE boot filename	`default.ipxe`

The DHCP server serves the correct boot file based on client architecture. BIOS clients get undionly.kpxe; UEFI clients get ipxe.efi. Both then chainload default.ipxe.

TFTP — Downloading the Boot Files

OPNSense runs a TFTP server rooted at /usr/local/tftp. SSH in and fetch the iPXE binaries:

fetch -o /usr/local/tftp/undionly.kpxe https://boot.ipxe.org/undionly.kpxe
fetch -o /usr/local/tftp/ipxe.efi https://boot.ipxe.org/ipxe.efi

iPXE Boot Script

Save as /usr/local/tftp/default.ipxe. This example has a boot menu with options for netboot.xyz, a Talos Omni boot, and a debug shell.

#!ipxe

dhcp
set menu-timeout 5000

:start
menu PXE Boot Menu
item --gap -- ----------------------------
item netboot Boot netboot.xyz
item talos Boot Talos (Omni)
item shell iPXE Shell
item --gap -- ----------------------------
choose target && goto ${target}

:netboot
chain http://boot.netboot.xyz || goto failed
goto start

:talos
echo Booting Talos via Omni...

set api https://<your-omni-instance>.omni.siderolabs.io
set token <join-token>
set event [<siderolink-ipv6>]:8090
set log tcp://[<siderolink-ipv6>]:8092

kernel tftp://${next-server}/talos/vmlinuz-omni \
 ima_template=ima-ng \
 ima_appraise=fix \
 ima_hash=sha512 \
 selinux=1 \
 consoleblank=0 \
 nvme_core.io_timeout=4294967295 \
 initrd=initramfs.xz \
 init_on_alloc=1 \
 slab_nomerge \
 pti=on \
 console=tty0 \
 console=ttyS0 \
 printk.devkmsg=on \
 talos.platform=metal \
 siderolink.api=${api}?jointoken=${token} \
 talos.events.sink=${event} \
 talos.logging.kernel=${log}

initrd tftp://${next-server}/talos/initramfs-omni.xz
boot || goto failed

:shell
shell

:failed
echo Boot failed, press Enter to continue...
read fake
goto start

The api, token, event, and log values come from the Omni console when you generate a join link.

Talos Kernel and Initramfs — Image Factory

The standard Talos release binaries do not include firmware for all hardware. Since Talos 1.6, several older NIC drivers (including Broadcom BNX2 / BCM5709) were removed from the mainline image and made available as extensions via the image factory.

Generate a custom image at factory.talos.dev with the extensions you need (e.g. siderolabs/bnx2), then download the PXE artifacts:

mkdir -p /usr/local/tftp/talos

fetch -o /usr/local/tftp/talos/vmlinuz-omni \
 "https://pxe.factory.talos.dev/image/<IMAGE_ID>/v1.10.1/kernel-amd64"

fetch -o /usr/local/tftp/talos/initramfs-omni.xz \
 "https://pxe.factory.talos.dev/image/<IMAGE_ID>/v1.10.1/initramfs-amd64.xz"

Replace <IMAGE_ID> with the schematic ID from the image factory, and adjust the version tag as needed.

Gotchas

UEFI boot and NIC memory limits — ipxe.efi can be too large to fit in the NIC’s PXE memory buffer on some older hardware. If the UEFI chain fails silently, switch to BIOS/legacy mode and use undionly.kpxe instead.

DHCP options 66/67 conflict — If you have previously set DHCP options 66 (next-server) and 67 (boot file) as raw additional options, remove them. OPNSense’s built-in network boot fields handle this; having both causes conflicts.

BIOS boot order after first boot — Talos writes its own bootloader on first boot. If the BIOS is set to PXE as the primary device, the machine will fall back to the PXE menu on every subsequent reboot. Set disk as the primary boot device once the cluster is up.

Opnsense on Backend Engineering Strategy Tools

BIFROST — Raspberry Pi jump node

Hardware

How it works

OPNsense config

SSH config

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

OPNsense

Feature overview

OPNsense vs pfSense vs VyOS

Related

OPNsense in the homelab

TODO: Clean reinstall

Intended role

PXE Booting with OPNSense + iPXE

OPNSense DHCP — Network Boot Fields

TFTP — Downloading the Boot Files

iPXE Boot Script

Talos Kernel and Initramfs — Image Factory

Gotchas