VLAN0 why!? does feel as an "intendend"security leak!

louis2

There is a lot going on on this forum around ^vlan0^. But to be honest I do not like the concept.

A vlan is there to separate traffic streams and anything which allows packages to escape the vlan is ..... IMHO not OK / a security issue.

I do understand that there seems to be some doubt full !!?? situations where it is necessary to work around, things ....

Best explanation I found is https://community.cisco.com/t5/routing/what-is-vlan0/td-p/1817088

Does not take away that:

I still do not understand why it is required
and I would like to explicitly block it as I see it now

But perhaps someone can convince me that, it is really required and that I see it wrong.

awebster

Don't over think it... but you wouldn't want to block vlan 0.

Under the hood...
There are two main ways to indicate the priority of frames in an ethernet network, these are Class Of Service (COS), bits inside the header of an ehternet frame, and Differentiated Services Code Point (DSCP), bits inside the IP header of a frame). These bits inform the networking equipment if the packets should be expedited as priority packets, or if it is ok to queue or drop them during times of congestion.
However, a network port that is not participating in any VLANs (untagged) needs to have a way to indicate a specific Class Of Service of packets it sends, while DSCP is fine for layer 3 traffic, if it is a layer 2 frame, it needs to use CoS instead. This is where VLAN 0 comes in.

Deeper...
The VLAN tag is a 32 bit field in the packet, inserted in lieu of the lengh of the frame, indicating a length of 0x8100 (impossible for ethernet), so it really means that the next 16 bits are the VLAN tag information, and the real length comes after that.

Even deeper...
The VLAN tag information is further broken down into 3 bits of Class Of Service information for COS 0 to 7, 1 bit for CFI which we can ignore for now, and 12-bits to allow for VLAN 0 - 4095.

So what happens when a layer 2 packet with a Class Of Service other than 0 needs to be delivered out the port? The device inserts a VLAN tag into the frame, with the CoS bits set accordingly and the VLAN ID set to 0.
The receiving device knows that's the same thing as an untagged packet, except that it has priority bits set on it, so I'll queue it based on the priority requested.

A practical example:
Device A <===> Switch(es) <===> Device B
Both device A and B communicate with each other over VLAN 50 configured as untagged on each side of the switching infrastructure.
Packets to/from device A and the switch and device B and the switch are all untagged, but internally in the switch infrastructure, they are all tagged on VLAN 50.
Device A now wants to send high priority frames to device B to ensure that they aren't delayed in transit, so it requests a COS of 7, the highest level possible.

How does device A inform the switch of this?
It sends the packet out to the switch with VLAN=0 and COS=7, which the switch represents internally as VLAN=50, COS=7, and forwards it without delay to device B.
In order for device B to understand that this is also a high priority packet, the switch must send the packet as VLAN=0, COS=7, as device B wouldn't know what to do with a packet tagged as VLAN=50, COS=7.

So in the end, it is not a security leak, and if you blocked vlan 0, you'd effectively prevent any devices from communicating with a priority other than 0.
You don't need to "tell" the network interface about VLAN 0, the network stack understands this implicitly...But whether or not pfSense does, or more importantly the underlying FreeBSD OS supports it, you'll need to dig into FreeBSD's docs.

louis2

@awebster

Thanks very much for the explanation. I think the situation is as follows:

in the original layer-2 ether-net specification there is no priority field
however there is a need for priority packets
in a later version of the layer-2 spec there is the 802.1Q tag which add
-3bit Priority code point (PCP) / COS
-1bit Drop eligible indicator (DEI) / CFI
-12bit VLAN identifier (VID) / vlan number

To transport un-tagged frames with a priority mechanism they defined a trick "vlan0". That trick adding an 802.1Q tag to the original layer-2 frame, allows the add of the PCP/COS and the DEI/CFI.

A managed ( ) switch receiving such an ^updated level2 frame^, can then process the frame with the correct priority.

Of cause the switch administrator can tell the swith that it should add "whatever vlantag / number" to that in coming untagged frame, where I assume that the DEI and PCP will be set accordingly in that vlan 802.1Q field.

And after transporting the frame to the other end of the network, another managed switch can output that frame to an untagged port. Doing the inverse trick changing the VID from whatever VID-value ("50") to 0.

One potential problem, assume we hand over that ^modern semi-un -tagged^ frame to an unmanged switch or an end device like a PC what will happen !?

Does the managed switch at the end have three options forwarding the package as:

vlan package with a real vlan number
as a vlan0 package perhaps not understandable for the attached equipment
or forwarding the package as a classical untagged package

Below a picture I took from https://en.wikipedia.org/wiki/IEEE_802.1Q

I hope I described it correct this way.

Louis