Future Consideration TL-SG105E / TL-SG108E How to Block Management VLAN
Future Consideration TL-SG105E / TL-SG108E How to Block Management VLAN
Business case: TL-SG108E can be used for basic QoS and Egress rate limiting.
Problem: The management interface is exposed on every VLAN, and DHCP is also taken from the first DHCP server to respond not from the specific management VLAN1.
Feature Request: Request to attach the Management Interface and DHCP to a specific VLAN or at least isolate it to only to VLAN1.
Background
Aim: to pair an eero6+ with an SG108E and have the SG108E "smartness" compensate for the lack of features on the eero while still taking advantage of the eero6+ mesh wifi.
Note: the SG108E would give you 5 spare device ports, with this configuration.
The Ideal Setup:
+---------------------------------------------+
| switch — SG105E / SG108E |
+----------------.----------------------------+
| VLAN 500 | VLAN 1 |
+-------.--------+---------.--------.---------+
| port 1 | port 2 | port 3 | port 4 | port 5 |
+--------+------+---------^--------^---------+
| NBN | WAN | LAN | DEVICE 1 — n |
+-------+-------^--------+-------------------+
| ROUTER |
+-----------------+
I was hoping that the management page for the switch would only be accessible from VLAN1. It turns out that it is accessible from any VLAN so long as you know its IP address. This kind of setup is not great having an external network (NBN) be directly interfaced as anyone on the other end of the cable (ISP) could potentially access the management page and with some time access the device.
That was the idea.
I've tried a few implementations of that idea. Starting with variants of the basic port vlan feature of the smart switch. That includes:
- VLAN 1 : Ports 1,2 — VLAN 2 : Ports 3,4,5,6,7,8
- VLAN 2 : Ports 1,2 — VLAN 1 : Ports 3,4,5,6,7,8
- VLAN 2 : Ports 1,2 — VLAN 3 : Ports 3,4,5,6,7 — VLAN 1 : Port 8
No matter which port you plug in you may access the management interface. Do let me know if I missed something obvious.
Moving onto the more advanced 802.1Q VLAN mode. I tried the following variations:
- VLAN 500 : untagged Ports 1,2 — VLAN 1 : untagged Ports 3,4,5,6,7,8
Port 1-2 PVID : 500
Port 3-8 PVID: 1 - VLAN 500 : untagged Ports 1,2 — VLAN 600 : untagged Ports 3,4,5,6,7,8 — VLAN 1 : no members
Port 1-2 PVID : 500
Port 3-8 PVID: 600 - VLAN 500 : untagged Ports 1,2 — VLAN 600 : untagged Ports 3,4,5,6,7 — VLAN 1 : untagged 8
Port 1-2 PVID : 500
Port 3-7 PVID: 600
Port 8 PVID: 1
Then I read the manual and it describes the behaviour such as if a port receives a tagged frame it will read the tag and forward to the appropriate vlan. If a port receives an untagged frame it will add the pvid as a tag and forward as if it were tagged. This leads me to believe the implementation is very basic, which would be also fine, as I can force what I want by being 'clever'. And the 'very basic' assumption also fits with the fact the user interface allows you to enable more than one untagged vlan on one port simultaneously (which should be an error).
- VLAN 500 : untagged Port 1 — VLAN 600 : untagged Port 2 — VLAN 1 : untagged 3,4,5,6,7,8
Port 1 PVID : 600
Port 2 PVID: 500
Port 3-8 PVID: 1
Note: the swapping of PVID on Port 1 and 2.
I had hoped that on receipt of an untagged packet on Port 2 it wold be forwarded to VLAN 500 and emerge untagged at Port 1 and similarly a receipt of an untagged packet on Port 1 would be forwarded to VLAN 600 and emerged untagged at Port 2. However this is not the case, vlan membership is controlled by the egress rule only (tagged/untagged/not member) despite the PVID value set, so traffic is blocked since the port pvid is corresponds to a non member and the description of the forwarding in the user guide is not exactly what it seems (omitted the blocking description). Note: this would have worked nicely as anyone trying to access the switch from the outside world on Port 1 would have had their response packets forwarded to Port 2 the router wan interface. Effectively dropping the data.
This finally led me to another tricky solution, making the ports an opposite tagged member of the other port, only to make each an opposite VLAN member, so the data would not drop.
- VLAN 500 : untagged Port 1, tagged Port 2 — VLAN 600 : untagged Port 2, tagged Port 1
Port 1 PVID : 600
Port 2 PVID: 500
VLAN 1 : untagged 3,4,5,6,7,8
Port 3-8 PVID: 1
Expectation: a switch should not output on the input port. Thus,
- Untagged enter on Port 1, PVID 600, will exit on VLAN 600 untagged on Port 2.
- Tagged 600 enter on Port 1, will exit VLAN 600 untagged on Port 2.
- Tagged 500 enter on Port 1, will exit VLAN 500 tagged on Port 2.
- Untagged enter on Port 2, PVID 500, will exit on VLAN 500 Port 1 untagged.
- Tagged 500 enter on Port 2, will exit VLAN 500 untagged on Port 1.
- Tagged 600 enter on Port 2, will exit VLAN 600 tagged on Port 1.
Anyway, while this tricked to the switch into not blocking the untagged packets, the switch still responds to requests but as tagged on the same port, so the expectation that it would not was not correct, also this cross config has the side effect of allowing tagged traffic to be responded to from the management interface as well.
The reason I'm making this post is because I am a bit burned out after all this testing and I can't think if there is another tricky solution or not. Again, I am looking for passthrough communications in port 1 and 2 as if it were a straight cable, while also blocking the management interface on those ports. Do let me know if you think a different config would work for that.
This feature request (option to isolate the management interface to VLAN1 and take DHCP only on VLAN1) could be solved by a firmware update.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
I've just bought the Zyxel switch. Thank you for encouraging me not to buy TP-Link products anymore.
This thread is a perfect example of how TP-Link deals with customers. I've been using TP-Link products for many years while having used D-Link, Zyxel and other brands as well. Telling me to "go somewhere else" when trying to affirm feedback to improve your products is just ridiculous.
I'd assess the missing feature like management VLAN as security vulnerability. The management interface should never be accessible e.g. via a guest VLAN. This should have been implemented right from the beginning.
To answer your point regarding "Easy Smart" != "Smart Managed": These are marketing terms coined by TP-Link. D-Link uses for the suggested product line "Simple. Easy. Smart". They are comparable in features and price, but the DGS-1100 series allows for setting a dedicated management VLAN.
The Zyxel GS1900 series is indeed more feature-rich at a small price premium, giving TLS/SSL web-ui as well.
- Copy Link
- Report Inappropriate Content
Hi @imoula
imoula wrote
I've just bought the Zyxel switch. Thank you for encouraging me not to buy TP-Link products anymore.
This thread is a perfect example of how TP-Link deals with customers. I've been using TP-Link products for many years while having used D-Link, Zyxel and other brands as well. Telling me to "go somewhere else" when trying to affirm feedback to improve your products is just ridiculous.
I'd assess the missing feature like management VLAN as security vulnerability. The management interface should never be accessible e.g. via a guest VLAN. This should have been implemented right from the beginning.
To answer your point regarding "Easy Smart" != "Smart Managed": These are marketing terms coined by TP-Link. D-Link uses for the suggested product line "Simple. Easy. Smart". They are comparable in features and price, but the DGS-1100 series allows for setting a dedicated management VLAN.
The Zyxel GS1900 series is indeed more feature-rich at a small price premium, giving TLS/SSL web-ui as well.
I am not interested in arguing the naming format. It is not my decision as well and I cannot change it. If you don't believe it, I recall some websites have explanations on our router, switch, and AP naming format. I came across that site and was amazed at its accuracy for a non-employee to conclude the naming format accurately like that. That's basically right on most parts.
The internal training materials have mentioned the naming format and it is a fact. Yet, I cannot share that training material with you. But it does nothing good to me to lie on this matter.
If you believe they are equal, so be it. But we divide them into four tiers and they are equipped with the features the dev team thinks are right. It is also something you or I can change. Yet, thank you for your feedback on it. You think that might be wrong, that's your opinion. And I make sure it's heard but if there is a change or not, it is not guaranteed. (Every request I have explained is not guaranteed and will go through evaluation. Or you should have an expectation it may fail the evaluation. Not every request seems to make sense when you put in the whole product line and stratification.)
As there is no constructive result from this, I discussed this and explicitly and inexplicitly recommend you move to Omada series which supports Management VLAN or other solutions to resolve the problem instead of complaining here. It's your choice and freedom to either consider the Omada series or a different brand while things are in dilemma or stagnant.
It is really impossible to foresee everyone loves a brand. You can move along and forward as you dive further into the networking.
Some of your opinions are subjective and only for your benefit, that's beyond my worries.
- Copy Link
- Report Inappropriate Content
Due to the security issues with such a design, the marketing behind such products with limited feature sets and faulty/incomplete implementations, and users such as @Clive_A defending the product and marketing segments, I must draw attention to the issues affecting switches like the TL-SG108E which are not readily admitted and which this thread seems to suggest are never to be resolved:
- No HTTPS
- No SSH
- DHCP influenced by/traffic leaked to every VLAN accessible to the switch
- Management address and HTTP interface are available to every VLAN accessible to the switch
These seem to be significant issues for security and present simple/obvious operational implications should a DHCP server exist on more than one VLAN. I do not care what the products are named or how they are marketed. I care when the ability to use VLANs for security and isolation is crippled by faulty/incomplete implementation and questionable design choices - the sort of things that turn any defects in the web UI (and any ability to reveal the management password sent via HTTP) into exploits that can be used from (again) every VLAN accessible to the switch.
At this point, the posts so far at least acknowledge products by TP-Link and rival brands that may have proper functionality and suggests that the problematic behavior is "working as intended". Along with that conclusion based on messages so far and lack of evidence to the contrary, I challenge TP-Link as a company and every developer involved in such behavior to defend this behavior and the decisions that led to it. There is "no constructive result from this" defense of the product and naming strategy by Clive_A, and possibly no defense of the vulnerabilities in production firmware, the marketing strategy, lack of interest by the developers, and the continued sale of the products as if they fully implement VLANs in a useful and secure way. I expect, though, that it is at least worth asking if the problems could be fixed with a firmware update or if the hardware has been released in a way that dooms buyers to having hardware that can only give them risks they would not reasonably expect from the advertised feature list.
--Baker_DSP
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Self-explanatory.. this is a security issue if this is NOT implemented. Even for basic switch-gear. If it's sold as "managed" in any capacity, this needs to be there.
- Copy Link
- Report Inappropriate Content
Hi @utilsvcllc
Thanks for posting in our business forum.
utilsvcllc wrote
Self-explanatory.. this is a security issue if this is NOT implemented. Even for basic switch-gear. If it's sold as "managed" in any capacity, this needs to be there.
This is not a managed switch in terms of the switch hierarchy. It is not reaching that level of management in our plan.
We recommend you consider the Omada Easy Smart switch as we are shifting the resources to the Omada product line. If you plan to get this feature, please consider the integrated Omada Easy Smart switch which works with the Omada Controller.
As you can see the official website has listed several Omada Easy Smart switches and Unmanaged switches.
- Copy Link
- Report Inappropriate Content
@Clive_A I'm well aware of TP-Link's products.. You're not picking up what I'm puttin' down bud. Conceptualize my point at a big-picture level, and try again. This is an outright defective reply. Also, if you're going to be a p*ick, be a useful p*ick. And FFS, why are you people censoring stuff lol. I cant even type something that's remotely not even a swear word in here.. this is hilarious. If y'all want to be a real functional compeditor to Ubiquity, you need to GET REAL.
- Copy Link
- Report Inappropriate Content
Hi @utilsvcllc
Thanks for posting in our business forum.
utilsvcllc wrote
@Clive_A I'm well aware of TP-Link's products.. You're not picking up what I'm puttin' down bud. Conceptualize my point at a big-picture level, and try again. This is an outright defective reply. Also, if you're going to be a p*ick, be a useful p*ick. And FFS, why are you people censoring stuff lol. I cant even type something that's remotely not even a swear word in here.. this is hilarious. If y'all want to be a real functional compeditor to Ubiquity, you need to GET REAL.
You can stick to this model as I am internally informed that this was not considered recently. The full dev resources are shifting and this is an order from the head office and basically has the highest priority as I am aware. I will not further discuss and explain this.
As you are well aware of our products and how we have developed in the past decade, I think you'll understand what it means for us to catch up with the Omada solution full product line and shift from the old naming and subbrands. The update will gradually stop for these models over time.
We are multi-tasking to catch up not only with UBNT but also with Mikrotik and other giants. UBNT is not considered the biggest threat now. We are not only targeting the small and home users. Other platforms of ours are providing better solutions for the business users and it is expanding.
Note that I am not obliged to reply and explain what happens internally or if there is no further news or update to this. Merely for the sake of your interests.
- Copy Link
- Report Inappropriate Content
@imoula Bro here's just trash, don't worry.. I'm sure they're not all like him. The bigger issue is the fact this is sold on Amazon and other places as literally a Managed Switch, when it is in-fact, NOT. It ruins the reputation of some actually GREAT TP-Link products. I'm going to have a chat with my MSP rep an see if we can get this dude away from us on these forums maybe. This is impacting TP-Link's reputation in our industry, and I'm sure TP-Link doesn't want that.
- Copy Link
- Report Inappropriate Content
@Clive_A I don't even USE this switch model.. The issue is you're selling this/letting this be sold as a managed product when it isn't, not properly. I'm surprised TP-Link's US division allows this to be sold.. usually troublesome SKU's like this are gatekept away so only the Asian etc markets get this less-than-stable/desireable etc stuff. Again, you miss my (and other's) entire point and it's concept.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 4
Views: 1794
Replies: 20
Voters 4
