Management network isolation, NTP sources, DNS hardening

The management plane is the most sensitive part of the firewall. A compromise of the GUI, the API, the SSH console, or the IPMI controller is a compromise of the firewall itself. The operational discipline that protects the management plane has three parts: isolate it on a dedicated network, source-restrict every access path, and ensure the supporting services (NTP, DNS) are robust enough that the management plane does not depend on the data plane.

This lesson walks through the management VLAN design, the source-restriction rules, the NTP and DNS hardening, and the anti-patterns the course has seen repeatedly.

The management VLAN

The management VLAN is a dedicated VLAN that carries:

• OPNsense GUI/API traffic (HTTPS to the firewall).
• OPNsense SSH traffic (if enabled).
• BMC / IPMI traffic to the firewall’s out-of-band controller.
• Monitoring traffic (SNMP, Prometheus exporters, API polling).
• Backup traffic (operator pulling config backups).
• DNS and NTP traffic to upstream resolvers and time servers (typically — the firewall itself uses these services).

The management VLAN is not the LAN. The LAN carries user traffic; the management VLAN carries operator and monitoring traffic. They are separate broadcast domains, with the firewall filtering between them.

A typical addressing plan:

Management VLAN (e.g. VLAN 99)
  Subnet: 10.0.99.0/24
  Firewall mgmt IP: 10.0.99.1
  Operator workstations: 10.0.99.10–10.0.99.20
  Monitoring: 10.0.99.30–10.0.99.40
  BMC IPs: 10.0.99.50–10.0.99.60 (out-of-band, separate switch)

The /24 is sufficient for hundreds of management hosts. The operator picks a subnet that does not collide with any LAN or WAN network the firewall also serves.

$ ifconfig ix0.99

ix0.99: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
      ether 00:50:56:00:00:99
      inet 10.0.99.1 netmask 0xffffff00 broadcast 10.0.99.255
      nd6 options=21<PERFORMNUD,ACCEPT_RTADV>

Source-restricting the management plane

Three access surfaces need source restrictions:

1. GUI / API (TCP 443). Reachable only from the management network. The operator creates an alias admin_net (10.0.99.0/24) and a rule on the management interface: pass in on ix0.99 inet proto tcp from <admin_net> to (self) port = https.
2. SSH (TCP 22). Same alias. The rule is pass in on ix0.99 inet proto tcp from <admin_net> to (self) port = ssh.
3. BMC / IPMI (TCP 443, TCP 5900 for KVM, UDP 623 for IPMI v2.0). Source-restricted at the switch level — the management VLAN has access, nothing else.

The anti-pattern is pass in from any to (self) port = https. This is the wizard’s default on some builds; it leaves the GUI reachable from every connected network, including the WAN if the operator exposes the interface. The fix is to delete the “any” rule and replace it with the source-restricted rule.

NTP sources

NTP for the management plane has three requirements:

1. Accurate. The firewall’s clock must be within tens of milliseconds of true time. Certificate validation, log correlation, HA skew, and IDS timestamps all depend on accurate time.
2. Redundant. Two or three NTP sources, ideally from different networks. A single NTP source that becomes unreachable leaves the firewall’s clock drifting within hours.
3. Authentic. Where the operator has the option, NTP authentication (ntp.keys) prevents an on-path attacker from feeding the firewall a bogus time. The OPNsense NTP service supports symmetric key authentication.

The wizard’s default is 0.opnsense.pool.ntp.org (the NTP pool). The production answer is two or three specific NTP servers:

• An internal NTP server (a chrony instance on a hardened host, or a hardware appliance). The firewall’s primary time source.
• A pool server as a secondary (different pool subdomain, e.g. 1.pool.ntp.org).
• An ISP-provided NTP server as a tertiary, if one exists.

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.internal.c .PPS.            1 u   8   64  377    0.232   0.041   0.084
*ntp2.internal.c .PPS.            1 u  14   64  377    0.312   0.012   0.097
0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000   0.000   0.002

A firewall whose clock drifts by minutes is a firewall with broken logs (timestamps wrong), broken HA (CARP skew is in seconds, but certificate validation depends on accurate time), and broken IDS (Suricata eve.json timestamps are wrong, correlating events across systems becomes impossible). The NTP configuration is one of the highest-leverage settings in the entire firewall configuration.

DNS resolvers for the management plane

The firewall itself uses DNS for:

• Resolving NTP server names.
• Resolving plugin update repository names.
• Resolving syslog destination names.
• Resolving API destination names (e.g. cloud services the firewall integrates with).

DNS for the management plane has the same three requirements as NTP: accurate, redundant, and authentic.

• Accurate. A DNS resolver that returns wrong answers is a firewall that talks to the wrong servers (the wrong NTP server, the wrong plugin repository, the wrong syslog destination). The operator picks resolvers that are known to be correct — Unbound with DNSSEC validation enabled is the production answer.
• Redundant. Two or more resolvers, on different networks. A single resolver that becomes unreachable leaves every service that uses DNS broken.
• Authentic. DNSSEC validation, where the operator’s upstream chain supports it. The OPNsense Unbound configuration enables DNSSEC by default; the operator verifies and trusts the root anchor.

Source-restricted firewall rules

The operator’s source-restriction rules in detail. The rule set on the management interface:

# Default deny on the management interface
block in on ix0.99 inet all

# Allow management from the management network
pass in on ix0.99 inet proto tcp from <admin_net> to (self) port = https
pass in on ix0.99 inet proto tcp from <admin_net> to (self) port = ssh
pass in on ix0.99 inet proto tcp from <monitoring_net> to (self) port = https

# Allow monitoring from the monitoring network
pass in on ix0.99 inet proto udp from <monitoring_net> to (self) port = 161

# Allow established and related
pass in on ix0.99 inet proto tcp from any to (self) flags S/SA keep state

The defaults to avoid:

• pass in on ix0.99 from any to (self) — the GUI/API is open to every network that can reach the management interface.
• pass in on ix0.99 from any to any port = https — opens the GUI to every network.
• Implicit allow all on management — many operators leave the default LAN rule (allow LAN to any) and then add the management VLAN as a LAN, exposing the management plane to user traffic.

The course’s lockout-prevention lesson (Part XXXIX) covers the specific rule patterns that lead to lockout; the lesson on management-plane security (Part VIII) covers the full privilege and rule matrix.

Anti-patterns

Three anti-patterns the course has seen repeatedly:

1. GUI on the LAN. The management VLAN is on the LAN. Every user on the LAN can reach the GUI login page. Phishing, credential stuffing, and accidental lockout (a user changes the admin password) become possible. The fix: separate VLAN for management, source-restricted.
2. Single NTP source. The firewall syncs from 0.pool.ntp.org. The pool is usually fine; when it isn’t (the firewall’s reach to the pool is blocked, the pool is under attack, the firewall’s DNS is broken), the firewall drifts. The fix: redundant NTP from different sources.
3. No source restriction on the management interface. The operator enables HTTPS on the management interface with the default “any” rule. The management plane is exposed to every network that can route to the management interface. The fix: alias + source-restricted rule, default-deny on the management interface.

Operational discipline

Four rules the course enforces for the management plane:

1. Management is on a dedicated VLAN, source-restricted. No exceptions for “temporary” — temporary becomes permanent.
2. Strong admin credentials in a password manager. The root account is for break-glass; daily operator accounts have the privileges the operator needs.
3. MFA enabled. The TOTP plugin adds a second factor. Daily operators use MFA; the root account has a long, strong password stored in a password manager and used only for break-glass.
4. Backups tested. The configuration backup is downloaded, stored off-box, and verified by restoring to a lab firewall. The backup is the recovery artefact; an untested backup is not a backup.

Summary

• The management plane is the most sensitive part of the firewall. It lives on a dedicated VLAN, source-restricted to the management network.
• NTP and DNS for the management plane must be accurate, redundant, and authentic. A firewall with broken time or broken DNS is a firewall with broken everything.
• The management plane should not depend on the data plane. Local caching, local NTP, or a separate uplink keeps the management plane working when the WAN is down.
• The anti-patterns — GUI on the LAN, single NTP source, no source restriction — are common. The fix is at deploy time, not later.