Management Plane Isolation¶

The management plane is everything used to administer infrastructure — web GUIs, SSH, SNMP, syslog collectors and vendor discovery protocols. Isolating it means those services answer only a defined set of sources instead of every host that can route to them. This page covers the principle, then a concrete implementation on pfSense and Cisco IOS, building on Firewall Rules & Aliases, VLANs & Inter-VLAN Routing and Security Hardening.

The Principle¶

Data-plane traffic and management traffic have different reachability requirements, but most equipment gives them the same one by default. A switch with an SVI in a user VLAN answers HTTPS and SSH from every host in that VLAN; an access point answers its own admin page on whatever subnet it was addressed in.

Management interfaces should be reachable from a defined set of sources, not from every network that happens to have a route
This applies equally to switches, wireless controllers, access points, firewalls, PDUs and any appliance with an admin interface — an exposed controller admin page reaches every access point it manages
Restriction is enforced at two places: on the device itself (vty ACLs, allowed-management-subnet settings) and on the router or firewall between segments. Both are worth having; the device-level control survives someone plugging into the wrong segment
Disabling unused management services is part of the same job — see Security Hardening

A Dedicated Management VLAN¶

The first structural step is to stop management traffic sharing a broadcast domain with user traffic.

Give infrastructure its own VLAN and subnet, carrying only device management addresses — switch SVIs, controller and AP management interfaces, appliance admin interfaces, out-of-band controllers
Move it off VLAN 1. VLAN 1 is the default for every unconfigured port and every untagged frame, so anything left there is reachable by accident. See VLANs & Inter-VLAN Routing for changing the native VLAN on trunks
Keep the management VLAN off ports that serve users, and off wireless SSIDs. See Wireless VLAN Build for the SSID-to-VLAN mapping side of that
Routing into the management VLAN is then a firewall decision rather than a default. On pfSense, inter-VLAN traffic is blocked until a rule permits it — see VLAN Basics in pfSense

A management VLAN narrows exposure to one VLAN; pinning narrows it to named hosts.

Pinning Access to a Specific Host¶

Restricting a rule to a single administrative workstation only works if that host's address cannot change and cannot be taken by something else. Three pieces, in order.

1. A Stable Address¶

A rule keyed on 10.0.99.25 is worthless if the host gets a different address after a lease expires, and dangerous if a different host gets that one.

Create a static mapping (reservation) rather than relying on a dynamic lease: Services → DHCP Server, the tab for the relevant interface, Static Mappings → Add, supplying the host's MAC and the address to hand it
Reserved addresses sit outside the dynamic pool range — the GUI does not allow a static mapping inside a pool, so the same address cannot also be leased to another client
A statically configured address on the host itself also works, but a reservation keeps the record centrally where it can be audited alongside every other assignment. See DHCP Fundamentals

2. A Host Alias¶

Firewall → Aliases → IP → Add, type Host(s), containing the single reserved address
Name it for its role rather than its owner — MGMT_ADMIN, not a person or a device model
Rules then reference the alias, so changing the permitted host is one edit in one place instead of an edit per rule. See Firewall Rules & Aliases

3. Rules Keyed on the Alias¶

Use the alias as the Source on pass rules that reach management services
Nothing else in the rule set names the address directly, so there is no stale copy to miss later

Static ARP Entries¶

An address reservation stops the DHCP server handing the address to someone else. It does not stop another host on the same segment simply configuring that address manually and inheriting whatever access the rules grant it. A static ARP entry binds the address to one MAC to close that gap — see MAC Addresses & ARP for how ARP resolution normally works.

The static mapping form carries a per-mapping checkbox, documented as ARP Table Static Entry, which pins that MAC and IP pair in the firewall's ARP table. It stops other MAC addresses using that IP address; it does not stop that MAC using other IP addresses
Availability depends on the DHCP backend. Static ARP was an ISC-only feature, and Netgate's current documentation still marks it that way; Kea support was added in pfSense Plus 25.07 (Redmine feature #15654), where the per-mapping checkbox needs the interface-level static ARP option enabled to take effect. Confirm the option, its wording and its position on screen

Two different options with similar names. The per-mapping ARP Table Static Entry option and the interface-wide static ARP option (in the DHCP server's Other DHCP Options section, historically labelled Enable Static ARP entries) are not the same thing. The interface-wide option stops any host without a static mapping communicating with the firewall on that interface — every client on that segment needs a reservation first, including the host currently connected to the GUI, or it loses access. Enable the per-mapping option unless the whole-interface behaviour is what is actually wanted.

To confirm the binding is in place, from the pfSense shell (Diagnostics → Command Prompt, or a console/SSH session):

arp -an

Statically bound entries are reported as permanent rather than ageing out. The same table is visible in the GUI at Diagnostics → ARP Table.

Out-of-Band Access¶

Every change described here can remove the path currently being used to make it. The order of operations:

Build the replacement path — the dedicated recovery port, the second admin host, the console cable
Prove it works — connect over it and complete a real login, from the machine and cable that would actually be used
Then remove the old path

Take a configuration backup first, so a bad rule set can be restored rather than reconstructed — see Configuration Management.

Anti-Lockout Rules¶

pfSense automatically maintains an anti-lockout rule permitting traffic to the firewall's own GUI port and, where SSH is enabled, TCP 22 — regardless of what the rest of the rule set says. Where two or more interfaces are assigned the rule is placed on the interface designated LAN; where only one interface is assigned it is placed on that interface. It appears in the rule list at Firewall → Rules → LAN as an automatically generated entry that cannot be edited in place.

The guarantee is tied to that one interface, so a recovery port only benefits from it if the port belongs to the LAN interface
The rule follows the configured GUI port, so changing the GUI from the default port does not invalidate it
It can be switched off at System → Advanced, Admin Access tab, with the option to disable the webConfigurator anti-lockout rule. Doing so removes the guaranteed way back in, so only disable it once another proven path exists
It covers the firewall's own management services. It grants no access to anything else, and does not exist on other interfaces

Serial Console¶

Console access survives a broken rule set or a wrong address, since it does not depend on IP reachability at all. Serial settings and cable type vary by platform — see Device Setup Fundamentals and Netgate 6100 MAX Administration.

A Worked Rule Pattern¶

Rules are evaluated top to bottom, first match wins, on the interface where traffic enters. A management-restricted interface therefore follows a fixed shape — exceptions above the block that would otherwise catch them.

Order	Action	Source	Destination	Purpose
1	Pass	`MGMT_ADMIN` alias	`MGMT_TARGETS` alias	Admin host exception — the only source allowed to reach management addresses
2	Pass	This interface's subnet	This firewall, ports 53 / 123	Local services — DNS and NTP on the gateway address
3	Block	This interface's subnet	`MGMT_TARGETS` alias	Isolation block — everything else is denied to management addresses
4	Pass	This interface's subnet	Any	General access — internet and anything not blocked above

Rule 2 sits above the block because clients on the segment still need the gateway's own services; without it they lose name resolution when the block is added — see DNS Filtering & Redirection
Rule 3 must precede rule 4, or the general pass rule matches first and the block never applies. Netgate's guidance is Reject rather than Block on internal segments, so blocked clients fail immediately instead of waiting for a timeout
MGMT_TARGETS is a network or host alias covering the management subnet and any individual infrastructure addresses living outside it
Logging rule 3 shows which hosts are attempting management access and from where — see Syslog, and Packet Capture Method for confirming what is actually reaching the interface

The same pattern applies on the device itself. On a Cisco switch, restrict the vty lines rather than relying solely on the upstream firewall. Cisco IOS — global configuration mode (conf t):

ip access-list standard MGMT_HOSTS
 permit 10.0.99.25
 deny   any log
!
line vty 0 15
 access-class MGMT_HOSTS in
 transport input ssh

access-class ... in filters inbound management sessions only; it has no effect on transit traffic. Apply it to every vty range the platform has — check with show run | section line vty. See Enable SSH on a Cisco Switch for getting SSH working first, and Security Hardening for the wider device hardening set.

The Trade-Off¶

Pinning management access to one host trades resilience for security. If that host is unavailable — powered off, reimaged, or simply elsewhere — the only remaining way in is the out-of-band path.

A middle ground is an alias containing two or three permitted hosts rather than one, each with its own reservation and ARP binding. The alias makes that a single edit
Test the recovery path on a schedule — see Testing Procedures