@R1D2 The LACP ports on the TP-Link where pfSense is connected are configured as GENERAL, not TRUNK, like thoese where the Ubiquiti is connected.

On pfSense itself, I have defined a new VLAN, selecting the interface where the LACP is. So in my specific case the interface on pfSense is called lagg0.20, being the VLAN20.

I don't have a specific reason for having untagged and tagged traffic, I only wanted to go step-by-step before tagging everything and I thought that on paper this should have worked.

I agreed that to avoid confusion and simplify things, the best option is to create a management VLAN and set all 4 ports, so for both pfSense and Ubiquiti, to TRUNK and tag both VLANs.

In the meantime, I have tried to change the egress rule of the GENERAL ports from UNTAGGED to TAGGED and everything has started working as expected.

This means that when you have egress rule UNTAGGED, the switch removed the VLAN tag from all the packets.

I wish this was documented somewhere! Can you confirm this is the intended behaviour?

Reading other threads in the forum, it looks like that the firmware that I have is very old and it still uses the old GUI, where in newer versions there isn't this distinction anymore between ACCESS, GENERAL and TRUNK on ports, if I understood correctly.

In this other thread, it is mentioned that you can use v2 firmwares on v1 hardware

https://community.tp-link.com/en/business/forum/topic/158231

but they are specifically referring to T2600-18TS.
I'm asking because when I had to select the product in this thread and I was search for TL-SG3216, only T2600-18TS was provided and as you can see, TL-SG3216 is in parentheses next to it.

The product and support pages are different though:
https://www.tp-link.com/us/business-networking/managed-switch/tl-sg3216/

https://www.tp-link.com/uk/business-networking/managed-switch/t2600g-18ts/

Do you know if I can upgrade the TL-SG3216v1 to a v2 firmware?
I don't want to risk to brick anything.

R1D2 wrote

The point with software VLANs on UNIX/Linux is that the virtual interface (VIF) usually removes tags on traffic received over a VIF like eth0.20 or lagg0.20. The switch tags the frames and the UNIX kernel directs those frames to lagg0.20, from where you can pick up the traffic.

 

Now the problem I see is diverting tagged and untagged traffic from the base interface (eth0 or lagg0). I have no pfSense, but use VLANs on Linux-based routers and on those platforms the base interface give you access to all frames arriving on either a VLAN VIF (tagged frames) and untagged frames.

 

Some Linux-based devices (e.g. ER-X) have a real switch, so you can use a PVID setting to direct untagged frames to, say, eth0.1 or any other VLAN VIF, but other systems which use kernel VLANs don't let one define a PVID. On the latter systems I use tagged-ony traffic to overcome this limitation.

pfSense is based on FreeBSD, so it might behave differently.
I don't know exactly how it works but I can say that the virtual interfaces in pfSense are not removing the VLAN tags, as after changing the egress to TAG, pfSense started recognising the traffic coming on VLAN 20 (after setting up such VLAN on pfSense of course).

Yes, that's correct. Trunks on switches of different vendors behave differently:

• Usually, on trunk ports the VLAN tag is retained on egress only if it is different from the trunk's PVID. So, if the trunk port is a member of, say, VLAN 10 and has PVID=10, unatgged frames on ingress get tagged (all switches do so), while on egress on frames which are tagged 10 the VLAN tag will be removed (like on pure access ports).
• Other vendor's switches did not strip the VLAN tag which equals a trunk port's PVID on egress.

 

This was the reason why some vendors introduced TRUNK and GENERAL settings. TRUNK always retains the VLAN tag on egress even if the switch did tag the frame due to the PVID setting, while a GENERAL port allows you to specify the behavior: you can set it to UNTAGGED to force the switch to remove the tag on egress or you can set it to TAGGED to force the switch to retain the VLAN tag on egress.

 

Modern switches allow to assign a port either as tagged or untagged member of a VLAN to control this behavior, so the TRUNK/GENERAL settings became obsolete.

Thanks for the explanation.
What I don't understand then, when would I need a GENERAL port with egress UNTAGGED? The definition says "The GENERAL port can be added in multiple VLANs" but if then if set the egress UNTAGGED, I make the VLAN tagging useless.

Indeed, I think that having to assign a port either as tagged or untagged member of a VLAN is simplifying everything, therefore I was looking if a firmware upgrade was possible.

The upgrade from v2 to v1 refers to the T2600G-18TS hardware.

 

I think the firmware will not install on the predecessor model TL-SG3216, but only TP-ink can answer this.

 

I tried to update a TL-SG2008 (which now has been replaced by T1500G-8T) with the latest T1500G-8T firmware and it didn't work. However, the switches usually check the firmware image and will refuse to update if it won't fit, but no guarantee that TL-SG3216 does so, too.

Thanks, I will try to contact TP-Link support then!

I know that it is basd on FreeBSD, that's why I wrote »UNIX«. I'm in UNIX business since more than 35 years and my first system was a Western Electric UNIX 7th edition, the predecessor to V32 from which BSD UNIX and (many years later) FreeBSD are forks of. I even know Brian Kernighan personally, who – with others from his crew – created the UNIX 7th edition and V32 while at Bell Labs back in this time.

Sorry, it wasn't my intention to undermine your experience.
 

FreeBSD also strips VLAN tags on the software side. Every VLAN must be terminated somewhere and the virtual interface is the only place to do so in a VLAN-aware OS (note that I see this from the perspective of the software which uses the virtual interface, not from the outside port assigned to this interface). On egress the VIF will add a tag to the frames, on ingress it will remove the tag from the frames. You can proof this with tcpdump / wireshark .

Thanks for the explanation!

No, it's not useless. You forgot that setting ACCESS allows membership of the port in one VLAN only. It can even makes sense to have a port an untagged member of different VLANs, e.g. for asymmetric VLANs.

 

Anyway, settings evolved over time. In modern firmware versions you can assign any port to be a tagged or untagged member of every VLAN, thus allowing to tag only frames in several VLANs while untagging frames in other VLANs. This allows very fine-grained setups. 

Thanks, I will study about asymmetric VLANs as they are outside of my knowledge, that's why I considered a GENERAL port with egress UNTAG useless.