Networking on Backend Engineering Strategy Tools

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

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

Networking on Backend Engineering Strategy Tools

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

Why BGP for Kubernetes LoadBalancer IPs

Testing with a real BGP network

Related

OPNsense

Feature overview

OPNsense vs pfSense vs VyOS

Related

VyOS

Configuration model

Key features

VyOS vs OPNsense

Automation

Related