TP-Link Easy Smart Switch security question
-
I'm new here so I don't know how things work around here and I don't mean disrespect, but these responses are definitely not what I expected.
We get a fair amount of people (usually with little networking knowledge) who think they're trying to secure their family photos from nefarious Russian super-hackzors. This usually leads to overly-complex configurations that nobody can decipher. Gauging your users & their abilities will help you to determine how tightly to wind the tinfoil around your head. I run networks at the office and at home. At the office, everything is locked down. At home, things are much looser since my family wouldn't know a network if they tripped over the Ethernet cable.
For what it's worth, I just bought the 105E over the holidays for $40, but I haven't had much time to play with it or its VLAN support.
-
No offense taken.
before I drop $150 on it.
What do you want to buy for $150?
A TL-SG108E is something like 25 Euros which should be $30 max, double that for a TL-SG1016DEPersonally, I don't like Esay Smart Switches and prefer one step up. Have a look at the TL-SG3210 of which I use multiple myself at home.
Don't use VLAN1 for anything and you should be fine and have proper isolation.
-
I've got 2 of the TL-SG108E and while they're basic in function, they are inexpensive and do work as intended. They will indeed provide the level of security you're looking for, as long as you have the networking knowledge to do so.
-
A TL-SG108E is something like 25 Euros which should be $30 max, double that for a TL-SG1016DE
Where do you find 1016DE for $60? Here 1016DE is about $125 but it's currently on sale on Amazon for $100, 108E is about $25-30.
-
Where do you find 1016DE for $60?
I just looked here
but it seems that those are only TL-SG1016D, which is the unmanaged version.
The version in question isn't that much more expensive though:
That is including 19% VAT.This isn't, that's dealer cost…
![Bildschirmfoto 2017-01-04 um 09.52.16.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 09.52.16.png_thumb)
![Bildschirmfoto 2017-01-04 um 09.52.16.png](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 09.52.16.png)
![Bildschirmfoto 2017-01-04 um 09.51.08.png](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 09.51.08.png)
![Bildschirmfoto 2017-01-04 um 09.51.08.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 09.51.08.png_thumb)
![Bildschirmfoto 2017-01-04 um 10.03.26.png](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 10.03.26.png)
![Bildschirmfoto 2017-01-04 um 10.03.26.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2017-01-04 um 10.03.26.png_thumb) -
Hi,
I just bought one TL-SG108E ( it is v2 with web management interface HTTP ) and price is ~30Euro.PVID 1 it is default and can't be changed.
I defined 3 VLANS
101 for WIFI private
103 for WIFI guests
105 for LAN privateI wanted to use port 8 as Trunk & port 6 & 7 for AP:
port 8 from pfSense interface Tagged ( for VLAN 101 & 103 & 105 )
port 7 Tagged to AP1 CISCO 2602 ( for VLAN 101 & 103 ).
port 6 Tagged to AP2 CISCO 2602 ( for VLAN 101 & 103 ).
port 3-2-1 Untagged to LAN devices ( for VLAN 105 ).It's working, but in this configuration watching with NTOPNG on each VLAN interface it reveal that all traffic, from other/all VLANs it is broadcasted / visible in every VLAN interface, not exactly what I wanted … any ideas ?
-
PVID 1 it is default and can't be changed.
Yes, it can. I have a simple setup with two of the TL-SG108E (one of which is V1, the other V2) and I changed the PVID of all ports to my primary VLAN ID (not 1). My primary VLAN is for my home LAN; the only other VLAN I have defined is for my guest network and that is provided entirely via wireless. So I set the port for my Ubiquiti AP to tag that one, and the port for my ESXi box (which hosts pfSense) to tag both. The tagged traffic is passed to the pfSense VM still tagged via a port group in ESXi with VLAN ID 4095 (which is ESXi's version of a trunk. In other words, pass all traffic with tags intact). I also have an uplink between the two switches, which tags both VLANS. No problems here; everything works as expected and traffic is isolated. It's not super intuitive if you've come from managing switches that have a Cisco-like CLI, but once you get it, it works.
I'm showing the web interface of the V2 switch here because I'm on my Mac and can only access the V1 switch with a Windows app (at least easily).
-
For me it look like you can change PVID for any port, only if that port is member in that VLAN… if you can show the VLAN Configuration page we can see exactly what you set.
-
For me it look like you can change PVID for any port, only if that port is member in that VLAN…
Then change the PVID to whatever VLAN you want that port to be a member of.
Here's my tagging config for my V2 switch. Port 1 is the trunk between the two switches. Port 4 is connected to my Ubiquiti AP. Bear in mind I have another V1 switch connected to this one, so you're not seeing the whole picture:
-
Exactly how I anticipated I already tested this model of config and for my config will not solve that all traffic is mirrored on all VLANs.
Now when you have time have a look with NTOPNG in every VLAN interface you defined and let us know if you see all tagged traffic from all VLAN.
For example in your VLAN 11 you will see all traffic from 44, for me this is not normal to be seen there.
In my test all traffic from all clients on LAN, WIFI can be seen also on GUESTS… etc.
-
The only thing I can see wrong with your config is that some of your ports are still set to PVID 1.
I'm coming from a world where I manage Dell Powerconnect switches. In Dell CLI parlance (and I think Cisco is similar), there are two main switchport modes, access, and trunk. Setting a switchport to access with the command "switchport access vlan 44" tells the switch to tag any incoming traffic on that port with VLAN 44, and to send any traffic on VLAN 44 out of that port, removing the tag in the process. In reality it's a bit more than that, since it is, after all, a switch, and learns MAC addresses, thereby avoiding sending all VLAN 44 traffic over all VLAN 44 ports. But let's ignore that for now.
So, to mirror that behavior on the TP-LINK switch, you need to set the port as an untagged member in VLAN 44, but you also need to set the PVID to 44. The reason for this, as I understand it, is that the untagged setting tells the switch to send VLAN44 out of the port, but it doesn't tell it what to do with incoming untagged traffic. That's what the PVID setting does. For a port with PVID 44, any incoming traffic that's not already tagged with a VLAN ID will get tagged with 44. (someone correct me if I'm wrong on this, please).
The other mode on the Dell switch is trunk. This is used in a situation where we want to send traffic with VLAN tags intact, so that the device on the other end can handle the VLANs. That device could be anything: a pfsense router with multiple VLAN interfaces, another switch, whatever. In that case, we set the port with "switchport trunk allowed vlan add 44" and "switchport trunk allowed vlan add 11". (I'm using my own VLAN IDs here, obviously). So, that works in the case where all the traffic on the port is tagged. But what if we want to handle untagged traffic on a trunk port as well? In that case, we also set "switchport trunk native vlan 15" and then any untagged ingress traffic will get VLAN ID 15. [EDIT: and egress traffic for VLAN 15 would be sent over the port as well, untagged.] That's roughly equivalent to the PVID setting on the TP-LINK switch. That comes in handy in the case of a device like the Ubiquiti AP, where the management network is untagged, but the SSIDs handle tagged traffic in different VLANs than the management network.
To mirror the trunk allowed setting on the TP-LINK switch, you just need to set the port as a tagged member of whichever VLANs you want to trunk. The PVID will still be in place, and will handle any untagged traffic coming into the port, if there is any. The PVID setting comes in handy again for devices like the Ubiquiti AP. My own has its management interface in VLAN44 and also serves an SSID in that VLAN. So the port it's connected to is untagged 44 and PVID 44. But it also serves an SSID in VLAN 11, so the port is also set to tag VLAN 11. That's port 4 in the screenshots I've posted.
I've checked with ntopng and also with tcpdump and I don't see any untoward traffic on any of my interfaces.
-
@n3by Are you sure ntopng is not listening on the parent interface in pfSense?
Even if the switch were leaking traffic from VLANs you don't have 103 or 101 untagged or set as PVID anywhere so it's hard to believe that traffic could end up on those?
Steve
-
I was really surprised and I double checked, also on history traffic log:
As you can see all VLAN 101-103-105 had the same high traffic spike ( one week ago ) but on VL103 = Guest I don't had / have any client.At the moment I am using SG-108E only as L3 switch for LAN.
Next day I disabled VL105 and moved back to separate network interface ( this is why in history log now is showed as opt2 instead of VL105 ).
I moved back on another separate network interface VL101 & VL103 managed only by pfSense ( and a no-managed switch as trunk to connect the APs to pfSense ) so no more problems with unwanted traffic on VLANs.
-
I want to restate what's being said here because I believe that these TP-Link "Easy Smart Switches" do indeed have a fundamental flaw with their VLAN implementation. I hope this can serve as a warning for future prospective buyers.
I am a networking professional and I have been using pfSense appliances in my personal network for years. Power consumption is something that I'm trying to minimize as of late, so I wanted to purchase a low power switch that supported VLANs so that I could implement a "pfSense on a stick" style network with a slightly older low power Intel NUC that only has one 1gbps port. It was to be a fairly simple deployment with one "access port" on a VLAN designated for the "WAN" (external network, VLAN99), several "access ports" designated for the "LAN" (internal network, VLAN10) and one "trunk" port which would trunk these two networks into the pfSense appliance.
Flaw #1: The first flaw with this switch is that you have no control over the management interface with regard to VLANs. On a Cisco switch, there is the concept of an "Interface VLAN" where you can select what VLAN you wish to attach a layer-three interface. Not only do these TP-Link switches switch lack that functionality, they instead allow access to their management IP interface from all ports on the switch regardless of the VLAN or PVID configured.
Here is how to test this: For anyone who has this switch configured with multiple VLANs, plug a computer into any port on the switch and hard-code your IP to be in the same subnet as the switches management IP and ping the switch. I am able to access the management IP of the switch from any port regardless of changes made to the "802.1Q VLAN Configuration" tab or the "802.1Q PVID Setting" tab. This is a huge security issue in router on a stick deployment such as the one outlined above
When I noticed this behavior, I quickly pulled out my old WireShark PC and the results were simply baffling:
Flaw #2: Any broadcast received on a port whose PVID is set to VLAN1 will be flooded out of all ports regardless of the VLAN or PVID settings. Easy enough, just don't use VLAN1 right? This was verified by injecting ARP requests into port 8 and monitoring every other port with WireShark (see photos which contain my configuration settings).
Flaw #3: Traffic sourced from the switch's management IP address is flooded out of all ports regardless of the destination MAC address or the VLAN or PVID settings. This was verified by opening a browser and pointing it to the switches web based management while connected to a port set to PVID of VLAN 10. This resulted in WireShark showing a flood of HTTP traffic sourced from the MAC address of the switch egressing a port whose PVID and untagged VLAN setting was set to VLAN99 or VLAN1.
I purchased two of these TP-Link switches over the past few weeks. The first was the 8 port model: TL-SG108E 2.0, which I promptly returned upon the discovery of this "flaw". The second was model: TL-SG1024DE 2.0 which was on sale for the ridiculously low price of 35$ after mail-in rebate at Amazon. Both exhibited the same behavior.
I guess that why they always say: caveat emptor!
![TL-SG108E PVID SETTINGS.PNG](/public/imported_attachments/1/TL-SG108E PVID SETTINGS.PNG)
![TL-SG108E PVID SETTINGS.PNG_thumb](/public/imported_attachments/1/TL-SG108E PVID SETTINGS.PNG_thumb)
![TL-SG108E VLAN SETTINGS.PNG](/public/imported_attachments/1/TL-SG108E VLAN SETTINGS.PNG)
![TL-SG108E VLAN SETTINGS.PNG_thumb](/public/imported_attachments/1/TL-SG108E VLAN SETTINGS.PNG_thumb) -
Why do you not remove the ports from vlan 1.. Clearly from your shot showing that you have multiple untagged ports on a port then yeah if you send broadcast traffic on vlan 1, and the port is a member of vlan 1 it should see that traffic..
If your saying there is no way to remove a port from untagged 1 then sure that would be an issue, but looks like you can do it on the screen you posted above - you just didn't do it.. Not talking about delete vlan 1, talking about taking port out of the vlan vs it being a member of 2 in an untagged state.
"which was on sale for the ridiculously low price of 35$ after mail-in rebate at Amazon"
Really.. That is not what I show, I show that the rebate is $30.. So puts the price at 80$ If there was a mistake and you got the switch for $30 sweet for you!! But I am guessing more same sort of info that didn't get right either ;) Just Sayin…
I don't have one of the tplink to test with, but I have a netgear that is same sort of price point.. Dirt Cheap - and "smart" to the point it does vlans but not much else. Same thing you can not delete vlan 1 on the device. But you can for sure remove a port from being untagged in more than one vlan and can change its pvid..
It doesn't protect you from stupid configurations.. See last pic where I put port 2 in vlan 1 and vlan 20 as untagged.
-
On first top row, Delete box with VLAN 1 and ports 1-8 it is disabled.
It looks like always all switch ports are part of VLAN 1, even you assign them to other VLAN.
From my test in ALL configuration even you assign to the switch an management IP in another class; out of all your LAN / VLAN sub-net,
all port and clients connected to switch are allowed to access that management switch IP, without restriction.All you have to do is to change client IP in the same sub-net as switch IP, TPLink sw management utility will always display switch IP so is no need to scan for all IP range.
Because it is HTTP and management traffic is broadcasted on all ports it is easy to access/sniff the configuration account.This Chinese switch looks like a perfect Trojan horse.
p.s
in V2 ASIC is RTL8367c… maybe later a custom firmware will be ported. -
Yeah, as n3by says, you can't check that box or edit VLAN1 in any way. I even tried to edit the the HTML code surrounding that checkbox with Chrome's Development console to no avail.
Really.. That is not what I show, I show that the rebate is $30.. So puts the price at 80$ If there was a mistake and you got the switch for $30 sweet for you!! But I am guessing more same sort of info that didn't get right either ;) Just Sayin…
It must have been some sort of price mistake and it popped up on a deal site (https://slickdeals.net/f/9686276) for $35. I figured even with this "VLAN flaw" it would still work well as a "dumb" switch for a network contained to a single broadcast domain at that price.
in V2 ASIC is RTL8367c… maybe later a custom firmware will be ported.
I was going to look into this somewhat. Not necessary "custom" firmware, but I had hopes that there may be a way to port the Netgear firmware over (assuming they use the same or similar hardware).
Does anybody think we have any recourse with TP-Link support to get a new firmware released? In this day and age where some of the largest ever DDoS attacks are sourced from IP camera DVRs and other embedded devices, one would think that a company would make it a priority to resolve security issues of this nature.
-
I e-mailed a TP-Link engineer I met at a trade show last year. I'll report back what he responds.
Be gentle, I linked this thread to him. -
Not talking about editing the vlan 1, I am talking about removing the port from the vlan.. If you can not remove a port from being in vlan 1 as untagged then you have a problem sure.. The switch is doing what it says its going to do.. Port 1-8 are set to be untagged vlan 1.. So yeah any traffic on vlan 1 that is broadcast traffic should flood out those ports as untagged.
Does not matter that you set PVID to.. All this says that hey untagged traffic I see INBOUND to this port, this is the vlan that traffic is in..
So your using the webgui - can you try their utility software? Maybe their is bug in their code in the web gui for removal of ports from vlan 1? I have half a mind to just order one of these to play with.. But from what you posted the switch is doing what its configured to do.. All ports are in vlan 1 untagged. Any broadcast traffic that it see inbound to a port that has pvid of 1, will be flooded out every other port that as being in vlan 1..
Generate your broadcast traffic inbound to a port that has its pvid set to something other than vlan 1. That untagged traffic would be in that vlan and not broadcast out vlan 1 ports. But in the current config state any traffic ingress to ports 1 or 8 that have pvid of 1 would be flooded out all the ports since they are listed as being untagged in vlan 1.
If you set all the pvid to something else other than 1 - can you still get to the IP of the switch? Does the config software utility still work?
-
Johnpoz, I think you have the right idea. I have a TL-SG2008 and a couple of TL-SG3424's and removed all the ports from the default VLAN 1 when I set them up. I don't think you can delete VLAN 1, but on my models at least you can remove all the ports from it. All the PVID's are set to something other than 1 and I can still reach the IP of the switch. I've never seen any traffic bleeding from one vlan to another.
-
Not talking about editing the vlan 1, I am talking about removing the port from the vlan.. If you can not remove a port from being in vlan 1 as untagged then you have a problem sure.. The switch is doing what it says its going to do.. Port 1-8 are set to be untagged vlan 1.. So yeah any traffic on vlan 1 that is broadcast traffic should flood out those ports as untagged.
Does not matter that you set PVID to.. All this says that hey untagged traffic I see INBOUND to this port, this is the vlan that traffic is in..
So your using the webgui - can you try their utility software? Maybe their is bug in their code in the web gui for removal of ports from vlan 1? I have half a mind to just order one of these to play with.. But from what you posted the switch is doing what its configured to do.. All ports are in vlan 1 untagged. Any broadcast traffic that it see inbound to a port that has pvid of 1, will be flooded out every other port that as being in vlan 1..
Generate your broadcast traffic inbound to a port that has its pvid set to something other than vlan 1. That untagged traffic would be in that vlan and not broadcast out vlan 1 ports. But in the current config state any traffic ingress to ports 1 or 8 that have pvid of 1 would be flooded out all the ports since they are listed as being untagged in vlan 1.
If you set all the pvid to something else other than 1 - can you still get to the IP of the switch? Does the config software utility still work?
I'll have to double check, but I think all ports remain untagged in VLAN 1 no matter what we do. That could explain some of the behavior reported, but I've had no problem keeping traffic isolated. I have my PVID set to something other than VLAN1 on all ports and can still hit the management interface. There is no way to define a VLAN for the management interface that I can see.
-
Is there any update on this?
@jahonix, did the TP-Link engineer ever answer your questions? I'm especially interested in the option to be able to set a management VLAN on the Easy Smart switches.
-
-
Any updates on this thread? Seems like this is a serious problem.
-
Any updates on this thread? Seems like this is a serious problem.
I haven't seen any firmware updates that allow removing VLAN1 untagged from the switch ports. I'm guessing TP-Link sees this as a feature, so that the end user can avoid having to set up the management interface on a VLAN and perhaps locking themselves out of managing the switch, since there's no console or anything like that.
Of course I understand the implications, and obviously these switches are meant for home use. I'd be curious to hear what TP-Link says about it, but that's my guess.
-
I got one of these and immediately returned it.
I ended up with a zyxel gs1900-8hp, it's 70W of PoE over all 8 ports for $100. It didn't have the forced VLAN 1, and it even has a telnet CLI you can activate and a header for serial access. MUCH better GUI and many more features!
The non-PoE version is I think $60. So almost double the price of a tplink might not be interesting but I thought I'd throw it out there.
I actually kept my LAN on VLAN1. It's for home use and you can force HTTP/S only acces, that combined with a strong password keeps me from worrying about needing a management only interface.
-
Any updates on this thread?
Sorry, I didn't make it to CeBIT. Workload prohibited going there.
And the engineer I talked to last year never responded to my mails. -
For just a couple dollars more you can get a D-Link DGS-1100-08 that has a management VLAN setting and doesn't do all this VLAN 1 nonsense.
Not sure what the fascination with these TP-Link things is. They are garbage.
-
At least for me the fascination was the price. Also, before asking around in a forum like this they appear to be a great buy based on amazon reviews.
But I agree, better off getting something a little better.
-
I got one of these to play with since see a lot of threads about them.. You can not remove vlan 1 that is for damn sure, and there also seems to be a cosmetic issue with it reporting rxbadpkts on interface that tagged vlan traffic hits… But seems to just be cosmetic.
I have not had a chance to test the security if vlan 1 traffic is broadcasted out a port if you change the pvid to some other vlan. But pretty sure you can get to the management IP from any switch port.. When I get some play time do some testing. But for a home switch, that does vlans the price is attractive.
-
But pretty sure you can get to the management IP from any switch port.
How big of a security concern is this really? If the webgui is HTTP/S and you have a strong password on it then what is the security risk?
My setup is home use only so for me I'm not at all concerned about anyone on my network even caring to look for a switch or router on the network, I was just curious how much of an actual security vulnerability this would be on a larger network?
-
I have very little patience (read zero) for any flakiness in my layer 2 gear.
-
But pretty sure you can get to the management IP from any switch port.
If the webgui is HTTP/S
It's not, and I don't see any way to change it. I get it, these switches are basically the same price as a typical unmanaged switch. They're cheap and offer VLANs. That's about all I can say.
Right now all my ports are either trunk ports (two between switches, one to my AP, one to my ESXi box) or access ports on a single VLAN (not VLAN1) which uses a subnet that also happens to contain the management IP address. My other two VLANs / subnets are either wireless only or contained entirely in ESXi / pfSense. In other words, I don't have any wired devices on an access port in a VLAN / subnet that doesn't also contain the management IP.
As expected, my guest wireless network cannot access the management IP of the switch. It can access certain services on that subnet, but only because I explicitly allow that access in pfSense. In that regard, the switches behave exactly as I'd expect.
I suppose I should put a port into the VLAN for the guest network and test that way with a wired connection, but for my setup that test would be academic.
Next time I buy a switch for home use, I'll choose something different. If anyone can show me a 16 port fanless 1Gbps fully managed switch (with a proper CLI) I'd be ecstatic. For now, I'm not freaking out about it.
-
But pretty sure you can get to the management IP from any switch port.
How big of a security concern is this really? If the webgui is HTTP/S and you have a strong password on it then what is the security risk?
My setup is home use only so for me I'm not at all concerned about anyone on my network even caring to look for a switch or router on the network, I was just curious how much of an actual security vulnerability this would be on a larger network?
It's not, and I don't see any way to change it. I get it, these switches are basically the same price as a typical unmanaged switch. They're cheap and offer VLANs. That's about all I can say.
I just meant in general is it a security concern if you can force HTTP/S and put a good password on it.
I replaced my TP-Link with a Zyxel GS1900 and it allows you to force HTTP/S WebGUI. -
I just meant in general is it a security concern if you can force HTTP/S and put a good password on it.
I replaced my TP-Link with a Zyxel GS1900 and it allows you to force HTTP/S WebGUI.Yeah, got it. Sorry, my response was not entirely directed at you or the https question.
-
If anyone can show me a 16 port fanless 1Gbps fully managed switch (with a proper CLI) I'd be ecstatic.
It's 16 port, gigabit and fanless. But not quite fully managed, you might be interested though.
-
I have two of those and a DGS-1210-10P.
I have never seen them lose the config.
You do have to explicitly save it so maybe those donkeys weren't doing that.
-
Depend of VLAN configuration & PVID settings if TL-SG108E switch IP is allocated on different subnet than normal clients (vlan);
using a browser, web management interface can't be accessed by clients;
however it can be accessed with Easy Smart Configuration Utility program that allow you also to change the switch IP… for home use is almost ok but not for Office / Enterprise use.A page for Linux users about TL-SG108E:
https://shred.zone/cilla/page/383/setting-up-tp-link-tl-sg108e-with-linux.html -
@http://us.dlink.com/products/business-solutions/dgs-1100-08p/:
The DGS-1100-08P, 10MP, -24P and -26MP comply with the 802.3af/at PoE+ standards, supporting up to 30W on each PoE port, not to exceed the switches specific power budget.
@http://us.dlink.com/products/business-solutions/dgs-1100-08p/#tab-spec:
Power Budget 64W
-
UK market products might be different.