Administration networks and VLANs

The management plane is the set of services that administer the firewall itself: GUI, SSH, API, syslog destination, NTP source, monitoring agent. Mixing the management plane with user or server traffic on the same VLAN is the most common configuration mistake in firewall deployments. It puts the GUI on the same broadcast domain as a malware-infected workstation that a user brought back from a conference, and it forces every operator to traverse the user network to reach the GUI.

This lesson covers why the management plane needs its own VLAN, how to design that VLAN, the source-IP restrictions that protect it, and the patterns that scale to multi-site and HA estates.

Why the management plane needs its own VLAN

Three failure modes happen when the management plane shares a VLAN with user traffic:

1. Lateral movement. A compromised workstation on the user VLAN can scan the subnet, find the firewall IP, and attempt to authenticate to the GUI. With the management plane on a separate VLAN, the compromised host cannot reach the GUI even if it knows the IP.
2. Sniffing and on-path attacks. ARP spoofing, DHCP spoofing, and LLDP attacks on a flat user VLAN let an attacker position themselves on the path between an operator and the firewall. The management VLAN eliminates this because the attacker has no presence there.
3. Accidental traffic. A user running a network scanner, a developer doing packet captures, or a misconfigured monitoring agent that floods the subnet can interfere with the management plane. A separate VLAN keeps the management plane quiet.

The principle is the same as the principle that production servers live in a different security zone than developer workstations: the management plane is the highest-value target on the network and warrants its own segregation.

Designing the management VLAN

The management VLAN is a single IP subnet dedicated to firewall administration. The design decisions are:

Addressing

Pick an addressing range that does not overlap with any other VLAN and is documented in the network registry. Common choices:

• 10.255.0.0/24 for management, separate from the user 10.0.0.0/16 range.
• 172.16.255.0/24 for management, in a different RFC 1918 octet than user traffic.
• A dedicated range outside RFC 1918 (e.g. 198.18.0.0/15, reserved for benchmarking) — unusual but valid for a network with very large RFC 1918 estates.

The management VLAN needs only as many IPs as you have operator jump hosts plus the firewall management IP. A /24 is overkill for most sites; a /27 (30 usable IPs) or /28 (14 usable IPs) is right-sized for a single firewall. Larger estates with HA pairs and multiple operator workstations can go to /24 for headroom.

Gateway IP

The firewall IP on the management VLAN is the gateway. Pick a low, memorable address (.1) so operators type it correctly under pressure. The IP is the destination for every GUI, SSH, and API call from the management network.

DHCP

Disable DHCP on the management VLAN. Operator workstations and jump hosts must have static IPs. The reason is the same as for any sensitive network: dynamic addressing makes it impossible to source-restrict by IP because the IPs change. Static addressing is a prerequisite for the source restrictions covered below.

Routing

The management VLAN is a “directly connected” network on the firewall — no routing is required for traffic between the firewall and the management hosts. Traffic from other VLANs that needs to reach the management VLAN must be explicitly permitted in the inter-VLAN firewall rules.

$ ifconfig vlan0.100

vlan0.100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,VLAN_HWTAGGING,VLAN_HWCSUM,POLLING,VLAN_HWFILTER>
ether 00:1b:21:xx:xx:xx
inet 10.255.100.1 netmask 0xffffff00 broadcast 10.255.100.255
inet6 fe80::21b:21ff:fexx:xxxx%vlan0.100 prefixlen 64 scopeid 0x5
vlan: 100 parent interface: vlan0
groups: vlan
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,IFDISABLED,AUTO_LINKLOCAL>

Source-IP restrictions

The management VLAN is a quiet subnet with a small number of known hosts. The firewall should know exactly which hosts are authorised to administer it and reject everything else. The implementation is an alias of operator jump hosts, used as the source on the management-to-firewall rules.

Alias: mgmt_jumphosts

A list of the IPs of every operator jump host. The list is short — typically one or two hosts per site. The alias is maintained under Firewall → Aliases and referenced in the firewall rules.

Rules on the management interface

The rule set on the management interface:

This rule set has two important properties:

• The first three rules grant access from the jump hosts only. A workstation on the management VLAN that is not in the mgmt_jumphosts alias cannot reach the GUI or SSH even if it is on the same VLAN.
• The block rules at the bottom reject everything else. A workstation that does manage to send traffic to the firewall IP on an unlisted port is refused.

The jump host pattern

The jump host is a hardened server on the management VLAN that is the only host authorised to connect to the firewall. Operator workstations connect to the jump host first, then from the jump host to the firewall.

The jump host pattern has three production benefits:

1. Single audit point. Every operator session to every firewall originates from the jump host. The jump host shell history, session recordings, and auth log are the single audit trail for all operator activity.
2. Single key distribution point. Operator keys live on the jump host only. Adding an operator means adding their key to one host. Removing an operator means removing the key from one host.
3. Operational tooling. Backups, configuration pulls, API-driven audits, and packet captures can all run from the jump host with operator-level access, without giving every operator access to the tooling directly.

The jump host itself must be hardened: SSH key-only, MFA on the operator login, restricted source IPs for the operator login (typically a separate “operator access” VLAN), audit logging to a remote syslog, and minimal installed software.

Multi-site and HA patterns

For multi-site estates, the management plane scales by:

• One management VLAN per site. Each site has its own management VLAN with its own addressing. Site-to-site connectivity for management traffic uses a site-to-site VPN (WireGuard or IPsec) on the management VLAN, not the user VLAN.
• Central jump host with site-to-site VPN. The central jump host has VPN connections to every site management VLAN. Operators connect to the central jump host; the jump host connects to the site firewall via the VPN.
• HA pairs share the management VLAN. In an HA pair, both nodes have an IP on the management VLAN (for the GUI of each node, for pfsync, for diagnostics). The CARP VIP is also on the management VLAN and is the primary destination for operator traffic. Source restrictions apply to both node IPs and the VIP.

Summary

• The management plane needs its own VLAN. Segregation at Layer 2 plus source restrictions at Layer 3–4.
• Pick a dedicated addressing range. Disable DHCP. Use static IPs for operator hosts.
• Source restrictions: an alias of operator jump hosts, rules that permit the alias and deny everything else.
• The jump host pattern centralises audit, key distribution, and operational tooling.
• Multi-site: one management VLAN per site, site-to-site VPN for management traffic.