pfSense

That's to lapidary.
Tagging is something which is handled by software and could be in hardware.
Without anything written I didn't believe.

That's in the code:

is_jumbo_capable - Test if interface is jumbo frame capable.  Useful for determining VLAN capability

But that's not the whole story. Tagging is always possible.
If your interface can't handle jumbo frames you have to reduce MTU and that's what freebsd does.

There are problems in VLAN tagging in that driver. That's outside of our control. Please replicate the problem on stock FreeBSD 10.1 and report upstream.

In XN there couldn't be tagging problems, because it didn't know anything about tagging.
They will tell me that the problems are of the reduced MTU and that some protocols have problems with Path MTU Discovery. Mostly UDP based protocols if fragmentation is disabled.

So what should I report?

I still have the opinion that it should be possible to use tagging on interfaces with smaller MTU.

VLANMTU shows only the fact that an interface can have packet sizes greater than 1512 bytes.

Can you add an switch on Advanced/Interfaces which allows to use tagging with smaller MTU?

http://en.wikipedia.org/wiki/Path_MTU_Discovery:

Problems with PMTUD

Many network security devices block all ICMP messages for perceived security benefits,[6] including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.[7]

Some implementations of PMTUD attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP Unreachable messages (type 3) should be permitted. A robust method for PMTUD that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821.[8]

A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.[9]

On Interfaces/VLAN is written:

Note:
Not all drivers/NICs support 802.1Q VLAN tagging properly. On cards that do not explicitly support it, VLAN tagging will still work, but the reduced MTU may cause problems. See the pfSense handbook for information on supported cards.

So this bug still exists (not only for xn).
It should be my decision if I use vlans for unsupported NICs.

Hello Chris,

I've read many reports about this issue and this one is the best by far. But I still think the problem deservers a bit more clarification. I'm not sure if we're discussing lack of a capability (in this case, VLANMTU) or a bug.

First, could you please provide a link to a report of any kind about the "major issues" encountered by people who "have forced their way around the fact that [the interfaces] don't show up [as VLAN-capable]"? Are these issues related to reduced MTU, as Grischa explained?

Also, you asked us to "please replicate the problem on stock FreeBSD 10.1 and report upstream." What "problem", exactly, are we talking about? VLAN tagging works with stock FreeBSD, unless you're mentioning a not so obvious bug. A FreeBSD developer tested it without problems (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195978) and I tested it too, as did Grischa, without any apparent issues.

In a broader sense, what I don't understand is this: FreeBSD's own vlan creating tool doesn't check if the physical interface reports itself with a VLANMTU capability. Should pfSense do it? As Grischa mentioned, quoting the "vlan" manpage, "other Ethernet interfaces can run VLANs using software emulation in the vlan driver." So, is there really a problem here or is pfSense being too zealous about this?

To sum everything up: are you recommending that we don't use xn NICs with VLANS because of the lack of VLANMTU capability (that's what pfSense checks for, after all) or because of other problems? In the latter case, can you please provide some sources for this?

Thank you,

Eduardo

FYI, manually adjusting the select box HTML using an inline edit from the browser allows you to create the VLAN on the correct interface. After doing this VLANs work as expected including DHCP addressing.

I think that pfSense shouldn't be restrictive here and should show all interfaces.