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
Information
Helpful: 3
Views: 1684
Replies: 14
Voters 3
