TL-SG3428: Feeling ripped off
I'll try to keep this short, but I am frustrated by the lack of features and shoddy software associated with the TP-SG3428.
My setup is not overly complicated. A few EAP-225 access points, the SG3428 managed switch, and a small server running a number of virtualized services, including pfSense. My goal is simple. Segregate a number of clients in my network to different VLANs based on their role. Everything goes through the switch connected to the system running pfSense, so the managed switch will handle VLAN assignment, and pfSense will act as the router/firewall to allow managed access across VLANs.
Step 1. SDN to the rescue. I tried Omada. If I just wanted a dashboard, this would have been nice. What I found, though, is that configuring anything through Omada is cumbersome and I bumped into many features that are claimed to be supported by the switch, but are (currently?) unsupported in Omada. I gave up on Omada and decided I will just manage the switch on my own.
Step 2. Let's get things secure. All traffic arriving on access ports is expected to be untagged, and only the port connected to the server will carry tagged traffic. To avoid clients accessing secure/admin VLANs, I want to discard all packets that arrive tagged on an access port. Stupid me...the "switchport acceptable frame" command only accepts "all" or "tagged" as options. I want to accept *only* untagged frames, but this doesn't seem to be an option! Fine, I'll just use a packet-content ACL and match on a TPID of 0x8100 to discard these packets from the access ports. No dice. I can start to configure the ACL, but as soon as I attempt to bind it to a port, I am greeted with "no hardware resources available" in the WebUI or "Invalid parameter" in the CLI. Mind you, this is the *only* ACL I have configured and the specifications (https://www.tp-link.com/us/business-networking/managed-switch/tl-sg3428/#specifications) clearly show that "Packet Content ACL" is supported.
Step 3. Partition the network. I want to have a hardware-managed way to allow a client in my network. By default, I want clients to use the port-based default VLAN that has no access to anything. Only when *I* decide that a client is known and trusted, then I will move it to the appropriate VLAN. The approach that I was planning to use was to perform MAC-based VLAN assignment in the switch. Well, that didn't go well. I have a good number of clients on the network, only to find out that the MAC-based VLAN assignment table is full after adding only 30 entries.
Quite simply, I feel like I purchased toy-hardware with high school-project level software. I'm thankful that I only made the mistake of buying this junk for a non-critical environment, because calling this SMB or enterprise-grade is simply false advertising.