Keep pfSense's generated QinQ interface group under the QinQ configuration's control

Manually altering the automatic group can break it because its interfaces are not ordinary assigned members.

Source facts

Netgate describes QinQ as nested VLAN tags with an outer provider tag carrying member VLANs. Its optional generated QinQ interface group permits shared filtering across subinterfaces. The guide warns not to edit that automatic group manually; to recreate it, delete the group and edit and save the QinQ instance again.

Source: Netgate — QinQ Configuration.

Applicability

This concerns pfSense’s generated QinQ grouping and its documented recreation method.

DSE recommendation

DSE recommends recording outer tag, inner member range, tag type, and endpoint mapping in one service worksheet. Manage generated group membership from the QinQ object rather than treating it as a normal hand-maintained group. Limit shared rules to the intended member population. Coordinate any recreation with the remote endpoint owner and preserve the previous configuration so a maintenance action does not unexpectedly affect every carried VLAN. Ask the network owner to identify the QinQ instance responsible for the generated group before any membership cleanup. Keep the outer tag and representative inner tags in the same acceptance record. Treat a proposed hand edit as a design question rather than routine group maintenance.

Verification

In a lab or approved maintenance window, compare the generated group with the intended member range. Test one permitted flow in each representative inner VLAN and one prohibited cross-VLAN flow. Confirm stacked tags at the transport boundary and verify that group recreation restores the intended filtering tab and membership.

Official reference

Netgate — QinQ Configuration. Reviewed October 20, 2026.