Establish OPNsense bridge management before removing interface addresses

Bottom line: Prepare the separate management interface first. Keep the address plan for that interface distinct from the deliberately unnumbered bridge and traffic-facing members.

Source fact: what the authority says

The OPNsense transparent-bridge guide uses a separate management interface for the web interface and firmware updates. Its bridge procedure sets both IPv4 and IPv6 configuration types to None on WAN and LAN and disables DHCP servers bound to LAN. The documented bridge must remain unnumbered, with no IP addresses or VLANs assigned to it or its members, and without Enable link-local address selected. The guide says the transparent bridge is incompatible with Traffic Shaping.

What the source does not establish

This article concerns management separation in the guide’s unnumbered transparent design. It does not select a universal bridge filtering policy, approve broad allow rules or qualify every virtualized interface and tagged-trunk arrangement.

Applicability questions

• Which separate interface, address and cable will carry management traffic?
• Can the authorized workstation reach that interface before the traffic ports change?
• Do existing DHCP services or address assignments depend on the proposed bridge members?
• Does the proposed design require shaping or another feature needing separate review?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a three-part diagram showing management, first traffic-facing member and second traffic-facing member. Place the management address only in its intended row. Label both ends of each cable so a later operator can distinguish the maintenance connection from the production traffic path.

Establish and check the management connection before removing any member address. Review its required access rule and update connectivity with the firewall owner. Keep console recovery available during the rehearsal rather than assuming the management port has been wired correctly because it appears in the interface list.

Inventory services currently attached to the traffic-facing interfaces. Make the DHCP disposition and removal of their address configuration explicit steps in the cutover plan. Keep the unnumbered bridge requirement visible; do not move the former member address onto the bridge as though following a different numbered-bridge procedure.

Review filtering, IDS/IPS placement and any tagged-trunk requirements separately against the complete guide. Preserve existing rules and an approved physical reversal plan. Resolve a requirement for shaping before scheduling this design, rather than discovering the documented incompatibility after traffic has been moved.

Verification and evidence

Proposed verification: on an approved representative arrangement, confirm management login through the designated management port before the traffic cutover. After applying the planned interface configuration, inspect the bridge and both member address settings and compare them with the diagram. Record the effective DHCP state for the affected interface.

Exercise an approved harmless client transaction across the bridge and a separate management operation through the maintenance path. Record the interface and rule observations for each. If management depends on a traffic member address or the intended separate connection cannot be demonstrated, stop and restore the reviewed starting arrangement.

Official references

• OPNsense — Transparent Filtering Bridge — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.