pfSense

Having run some tests this appears to be broken beyond just exposing the raw interface names.
Choosing the QinQ name in interface assignments results in the interface appearing to be disabled.
Choosing the raw name shows the interface as up but I'm unable to pass any traffic across the resulting QinQ link. Though the first level VLAN is able to pass traffic if the raw name is selected. It prevent a clean boot though as described above.
With a QinQ interface assigned the following error is shown at boot: ngctl: send msg: No such file or directory.

There appear to be three distinct issues here. Documenting it before I forget.
1. The generated netgraphcmd file seems incorrect, it's using the parent interface instead of the VLAN interface.
This can be corrected by changing 'qinqif' to 'vlanif' where the first half of the file is generated in interface_qinq_configure() in /etc/inc/interfaces.inc.
Doing just that allows traffic to flow and captures show both tags.
2. The interface assigned when 'QinQ 100', for example, is chosen is incorrect. It assigns 'vlan21_100' (for example) but that does not exist it should be assigning em1_21_100.
That can be corrected in the 'add qinq interfaces section' of /usr/local/www/interfaces_assign.php. That then allows you to choose 'QinQ 100'rather than the raw interface name. That name should be better though IMHO. Somthing like 'QinQ 100 in VLAN 21 on em1'.
3. QinQ interfaces need to be excluded from the interfaces mismatch check in 'is_interface_mismatch()' in /etc/inc/util.inc. They don't exist when it's run. It might be easier to just include 'vlan' in the name somehow.

I have a set if patches that attempt to address the three points above. They seem to allow QinQ to work in my testing but could probably use some refinement.
1. Allow the QinQ interfaces to pass the interface mismatch check:
https://github.com/stephenw10/pfsense/commit/6a03a8ca8d528449a59f1ac1fed24cc3cfd8d024
2. Create the netgraphcmd file to use the vlan interface not it's parent:
https://github.com/stephenw10/pfsense/commit/c821a915b1228ed734a6439d816d4ab04590e8cb
3. Allow sellecting the QinQ interface in interface assingment, alsop removing the underlying VLAN:
https://github.com/stephenw10/pfsense/commit/b3b59037bcd268337ae907a7d4969e987bf72d83

That last one is more of a suggestion because it doesn't remove the actual interface.

This commit is also required to get the QinQ interface selection correct:
https://github.com/stephenw10/pfsense/commit/643cf3e805714bce2ce432fb09bd6e012259ff9f

This is still broken in 2.3 though the exact form of the problem seems to have changed slightly.
See: https://forum.pfsense.org/index.php?topic=110459.0

The patch 1. is missing on 2.3.2-RELEASE-p1. Booting system with QinQ interfaces assigned will only trigger vlan assignment tool because of missing interfaces.

Manually patching /etc/inc/util.inc to ignore vman interfaces identified by "_\d{0,4}_\d{0,4}" fixed the issue. Now I have working QinQ interfaces.

Would be nice to have this fixed in future releases, any manual patching is very bad for upgrades.

Steve Wheeler wrote:

I have a set if patches that attempt to address the three points above. They seem to allow QinQ to work in my testing but could probably use some refinement.
1. Allow the QinQ interfaces to pass the interface mismatch check:

Timo Nieminen wrote:

The patch 1. is missing on 2.3.2-RELEASE-p1. Booting system with QinQ interfaces assigned will only trigger vlan assignment tool because of missing interfaces.
Manually patching /etc/inc/util.inc to ignore vman interfaces identified by "_\d{0,4}_\d{0,4}" fixed the issue. Now I have working QinQ interfaces.

https://github.com/pfsense/pfsense/pull/3635

Merged, please test with latest 2.3.4/2.4 snapshot.