I have setup an interface on PfSense for my IoT devices. Also setup and enabled the DHCP server for that interface. Then created another SSID on my unifi controller and tagged it with the same VLAN as the IoT interface. The problem is that I have a couple dumb switches in between the Firewall and the AP. When I connect to the IoT SSID I am unable to obtain an IP address. I’m assuming the switches are to blame for this but I want to get an answer from some of you guys here to verify my thoughts thanks.
un-managed / dumb switches will not reliably (I have heard that some do and some don’t) forward VLAN traffic. For it to work properly & reliably you need a switch that supports VLANS.
2 Likes
As Tom said, if you want it to work properly & reliably you need a vlan-aware switch.
Part of “working properly” is keeping the vlans logically separate. A non-vlan-aware switch may be able to clone trunk links, but it will clone them on any port. So for example, a broadcast frame on the tagged vlan will be flooded to every switch port. From a security point of view, that isn’t desirable. For example, ARP cache poisoning can allow a MITM attack that can capture all trunk traffic.
Non-vlan-aware devices will probably ignore the frames, because the ether-type field with have the value 0x8100 and the driver will normally not have any protocol assocated with that value, and the frame will be ignored.
In the case you are talking about, your trusted lan (the untagged frames) will not leak to the IoT wifi, but the IoT broadcasts will leak to the trusted lan.
I just bought a vlan-aware 8 port TP-Link TL-SG108E v4 on Amazon for under $28. It has its weaknesses, no https, and any port that has access to vlan 1 will have access to the management interface, although it does seem possible to limit what ports have access to vlan 1. Also, the firmware does not allow you to lock mac addresses, or even see the mac address table, but it does allow creating access ports for vlans so non-vlan-aware devices can communicate on a logically separate lan.
For the curious that want to know why some unmanaged switches will pass tagged frames, and some won’t, you need to look at how IEEE 802.1Q frames are tagged, and how ethernet switches work.
As long as the switch will pass jumbo frames, and most switches made in the last 10 years do, then it is likely to pass the tagged frames, because the tag is just part of the data as far as an unmanaged switch is concerned.
All an unmanaged switch cares about when determining what port to forward an ethernet frame to is the destination mac address (and for received frames the source mac address so it can learn what port a specific mac address is on). It doesn’t look at the ether-type field.
Older switches and software bridges may enforce the original ethernet Layer 2 maximum frame length (1518 bytes: DST MAC 6 bytes, SRC MAC 6 bytes, ether-type/size 2 bytes, payload 46-1500 bytes, CRC-32 4 bytes) and since tagging a frame inserts an additional 4 bytes of data immediately after the source mac address, the resulting frame can be 4 bytes too long, and discarded. Reference: Ethernet frame
After doing some testing, my guess is that the problem was due to something else, perhaps dhcp server settings. I tried hard to get this to fail, but even using a 15 year old fast ethernet switch (The deceptively named “Giga Fast Ethernet EZ-500S” 5 port 10/100 switch) passed 1500 byte MTU frames (1518 byte ethernet frames when untagged, 1522 bytes when tagged). Other switches that were tested and all worked (what I could find at home) TRENDnet TEG-S80g 8 port Gb switch, Tenda SG105 5 port Gb switch (got this onsale at MicroCenter 1-2 years ago for under $10). I even tried an ancient Netgear EN108 multi-port repeater (with 8 10BaseT ports, a BNC 10Base2 thin ethernet, and AUI (aka DIX DB15 connector). First time its been powered on in probably 12 years. I expected this to fail, but when it worked, it makes sense because a repeater is only buffering a small amount of data (8-64 bits ???) and it just recreates the preamble and duplicates the bits after the two “1” bits in the SFD. It doesn’t even check or recreate the CRC.
So although I am sure unmanagerd switches that won’t pass max sized tagged frames exist, finding one is not likely, unless you are more of a pack rat than I am. Anything made in the last 15 years is likely to handle jumbo frames, or at least baby giants, and that is the only requirement.
And here’s the test I did. Trunk link between ER-X v1.10.10 and TP-Link TL-SG108E v4 with firmware 1.0.0 Build 20181120 Rel.40749
ER-X vlan config
interfaces {
ethernet eth0 {
address dhcp
description Internet
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth1 {
address 192.168.127.1/24
description "Local 2"
duplex auto
speed auto
}
ethernet eth2 {
description Local
duplex auto
speed auto
}
ethernet eth3 {
description Local
duplex auto
speed auto
}
ethernet eth4 {
description Local
duplex auto
speed auto
}
loopback lo {
}
switch switch0 {
description Local
mtu 1500
switch-port {
interface eth2 {
vlan {
pvid 1
}
}
interface eth3 {
vlan {
pvid 1
vid 10
}
}
interface eth4 {
vlan {
pvid 10
}
}
vlan-aware enable
}
vif 1 {
address 192.168.28.1/24
mtu 1500
}
vif 10 {
address 192.168.32.1/24
description VLAN10
mtu 1500
}
}
}
I was hoping that not allowing access to vlan 1 would limit access to the management interface, but that is not the case. It still works like the v3 version Tom reviewed, all you have to do is manually set your ip address to be in the same subnet as the switch ip address is set to, and you can ping it or browse to the WebUI. So not for corporate use where you don’t want users having access to the management plane.
There were hints that this had been fixed, but you can see the config I tested with, and I was able to set the laptop ip addres to 192.168.0.7/24 and log into the device @ 192.168.0.82 from both ports 6 and 8, in different vlans and those ports are not members of vlan 1 of the TL-SG108E
Unfortunate, but still seems to be a nice switch for home use with vlans. But setting up the vlans is not the most straight forward, it seems extremely odd that the pvid setting is on a separate screen, and that you can specify a pvid that the port is not a member of.
The TL-SG108E is reportedly based on the Realtek Realtek RTL8370N switch chip, and summaries of the capabilities of the chip look good.
Its almost like the TL-SG108E uses hidden tagged vlans associated with all ports and connected to management plane.
I should probably start a thread about the TL-SG108E.
1 Like
After spending a few bucks on ebay I purchased an older netgear GS748T switch. The GUI is a bit clunky but I was able to get my IoT vlan working properly now.
Thank you for all the additional information.
For future readers: I saw this referenced on the Ubiquiti forums: https://blog.thelifeofkenneth.com/2014/03/pushing-vlan-tags-through-unmanaged.html
and it has useful info as well.