Admin remote access and the bastion pattern — keeping the keys off the perimeter

Every production network has two access planes: the user plane (employees reaching the resources they need to do their jobs) and the admin plane (operators reaching the systems they need to keep running). The two planes look superficially similar — both involve remote connections, both involve authentication, both involve encryption — but the security consequences of a compromised credential on each plane are very different. A compromised user credential reaches user resources; a compromised admin credential reaches the entire network.

This lesson covers the patterns for the admin plane: direct management access to OPNsense itself, the bastion host pattern, the jump host pattern, session recording, and the discipline of keeping administrative access separate from user VPN.

The two planes

The user plane carries employee traffic to business resources. It is high-volume, broad in destination, and authenticated for the resource being reached (a web app, a database, a file share). The credential that protects it is a user credential; compromise means an attacker reaches what the user reaches.

The admin plane carries operator traffic to infrastructure. It is low-volume, narrow in destination (the firewalls, the routers, the switches, the hypervisors), and authenticated with operator credentials plus a second factor. The credential that protects it is an admin credential; compromise means an attacker reaches the infrastructure and, transitively, every resource on the network.

The mistake many teams make is to put both planes on the same VPN. The user VPN reaches the corporate subnet; the admin VPN reaches the same corporate subnet but is meant for operator workstations. The same VPN handles both — and a compromised user credential that includes VPN access reaches the admin plane as a side effect. The discipline: separate the planes. Different authentication, different addressing, different audit trails.

Direct management of the OPNsense firewall

The simplest pattern is direct management: the operator’s workstation connects to the OPNsense GUI or SSH directly. The firewall listens on a management interface (often a dedicated management VLAN, or the LAN if there is no separate management), accepts HTTPS on 443 and SSH on 22, and authenticates with a local account or an external directory (LDAP, RADIUS).

The production hardening:

• Restrict the source. The management interface accepts connections only from an operator_hosts alias (or a management VPN pool). Direct management from the entire LAN is the default anti-pattern.
• Enforce HTTPS only. Disable HTTP on the management interface. Redirect any HTTP request to HTTPS. Generate a certificate from the internal CA (not a self-signed certificate that triggers browser warnings operators learn to click through).
• Enforce SSH keys, not passwords. Disable password authentication on the SSH listener. Operators authenticate with keys loaded into ssh-agent; brute force against the SSH port is then impossible regardless of password complexity.
• Enforce MFA. TOTP via the OPNsense TOTP plugin, or RADIUS to an MFA-enabled directory. The anti-lockout lesson covers the production pattern for source-restricted management.

# Confirm the GUI is restricted to the operator alias and MFA is enabled.
pfctl -s rules | grep -A 2 'https' | head -5

The discipline is that every one of these controls is independent: a missing source restriction can be compensated by MFA, a missing MFA can be compensated by source restriction, but all four together is what production looks like. The operator who disables one of them because “the others cover it” has not understood the layered model.

The bastion host pattern

The bastion host sits on a network segment that is reachable from operators but not from users. Operators SSH to the bastion; from the bastion they SSH to the inside systems they need to reach. The bastion is the only host on the network that is directly reachable from the operator’s network; the inside systems are reachable only from the bastion. The inside systems do not need to accept SSH from the operator’s network at all.

The architecture:

Operator workstation -> Bastion host (management VLAN) -> Inside systems
                                ^
                                |
                          only path in

The bastion itself is hardened: minimal OS, only the SSH service exposed, MFA on the bastion’s own authentication, session recording, restricted source IPs, and an audit trail of every connection made through it.

SSH bastion mechanics

The bastion pattern relies on SSH agent forwarding (or ProxyJump), not password forwarding. The operator’s workstation has the private key for the inside systems; the bastion never sees the private key — it only relays the authentication handshake.

# Direct SSH to an inside system via the bastion.
ssh -J bastion.operator.internal inside-host.corp.internal

# Two-hop with explicit agent forwarding.
ssh -A bastion.operator.internal
bastion$ ssh inside-host.corp.internal

The -J flag (ProxyJump) is the modern equivalent; the bastion acts as a TCP forwarder for the SSH connection. The operator’s private key is presented to the inside system; the bastion only sees encrypted bytes.

Session recording

Production bastions record every session. The recording is a typed transcript of the SSH session — what the operator typed, what the system responded — written to append-only storage with a tamper-evident audit trail. Tools like sudosh, tlog (from the systemd world), or commercial session recorders provide this.

The discipline:

• Record everything by default. Operators on the bastion accept that their work is recorded. This is part of the admin plane’s security model.
• Index by operator and time. A search interface that lets auditors find every session an operator ran on a given day is the difference between an audit trail that catches problems and one that does not.
• Retain per compliance. Some compliance regimes require 90 days, others require a year or more. The retention policy is part of the bastion design.
• Protect the recording itself. The audit trail is itself sensitive — a compromised audit trail can rewrite history. Append-only storage, off-host backup, and restricted access to the audit log are mandatory.

# A sudosh session transcript (illustrative; the actual session is in the file).
$ sudosh
sudosh: starting recording to /var/log/sudosh/operator1-2026-08-14-1030.log
[operator1@bastion ~]$ ssh inside-host.corp.internal
[operator1@inside-host ~]$ sudo systemctl status sshd

The anti-patterns

The admin plane accumulates anti-patterns over the life of a network. The ones the operator encounters in production:

• Admin on the same interface as users. The LAN carries user traffic and accepts management access to the firewall. A compromised user host can reach the GUI. The fix is a management VLAN with its own allow rules.
• MFA on the perimeter, no MFA on the inside. The VPN requires MFA but the inside SSH does not. A compromised VPN credential reaches the inside; the inside accepts password SSH from any host on the corporate subnet. The fix is MFA at every hop, including the bastion.
• Session recording on the bastion only, not on the inside hosts. The bastion records the operator’s keystrokes; the inside hosts do not. A compromise of the inside host’s audit trail is undetectable. The fix is recording at every hop or at least a sampled subset.
• Shared admin accounts. A single admin account used by every operator, no individual accountability. The fix is per-operator accounts with named audit trails.

Verification

After any change to the admin plane, verify:

1. From a non-operator host, attempt to reach the GUI on the management interface — must fail.
2. From an operator host, attempt to reach the GUI on the management interface — must succeed.
3. From the bastion, attempt SSH to an inside host with the operator’s key — must succeed.
4. From the bastion, view the session recording — must contain the transcript.
5. From an inside host, attempt SSH to another inside host directly — must fail (only bastion-mediated access is permitted).

A change that passes 1-2 but fails 3-5 is incomplete; the bastion is reachable but not enforcing.