What's new

VLAN Config Query using pfSense and Unifi

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

dmbminaret

New Around Here
Hey all,

LAN ip addressing is getting close to capacity, so thought best practice to create new networks for Trusted, Guest & IoT. I have set the rules in pfsense that trusted VLAN (phones, laptops, watches, TVs, etc) has access back and forth to default LAN (reserved for static servers, VMs, printers, etc.). These two networks can see IoT but not in reverse besides allowing access to gateway for internet connectivity.

The network runs as:
Modem in bridge mode -> pfSense -> 2x unmanaged 24 port switches -> Unifi Flex mini -> 5 port unmanaged switch -> 5 port unmanaged switch -> 5 port unmanaged switch -> flex mini -> ubiquity airmax gigabeam 60ghz PTP -> USW flex switch -> 5 port unmanaged switch -> 5 port unmanaged switch. Also coming from the USW flex switch is a nanobeam PTP -> flex mini.

Nestled in there is 6x Unifi LR APs, 1x U6 Lite and an AC Mesh Pro with 5x hikvision NVRs.

I already know the simple answer, but the crux of the question is:
Is there anyway I can have ethernet clients (such as NVRs) move on to the devices VLAN without swapping out the unmanaged switches for more flex minis?
I'm not too worried about isolation of networks, more just housekeeping and room for DHCP allocations.

I am aware VLANs require managed switches as a rule, but…
Is there a way to strip tagging so you could simply give a client a static IP address on the VLAN and it will connect?
Even if I have a managed switch at the location of the NVR, the unmanaged switches upstream will bork because of failed trunking?
How is it that VLAN aware APs with replicated wifi SSIDs work and get assigned an IP from the DHCP pool when they're coming along the same channels?

Wifi devices work fine what ever network they're on but when I tried to assign a VLAN ip address to one of the NVRs, there is no connectivity. I changed the port profile on the flex mini to the IoT VLAN and I could pull it up on screen from default LAN but it would not connect to the Hik Connect servers no matter what I did and it took out all the network downstream until I hard reset and re-adopted the flex.

Thanks for any nuggets of wisdom.
 
Hey all,

LAN ip addressing is getting close to capacity, so thought best practice to create new networks for Trusted, Guest & IoT. I have set the rules in pfsense that trusted VLAN (phones, laptops, watches, TVs, etc) has access back and forth to default LAN (reserved for static servers, VMs, printers, etc.). These two networks can see IoT but not in reverse besides allowing access to gateway for internet connectivity.

The network runs as:
Modem in bridge mode -> pfSense -> 2x unmanaged 24 port switches -> Unifi Flex mini -> 5 port unmanaged switch -> 5 port unmanaged switch -> 5 port unmanaged switch -> flex mini -> ubiquity airmax gigabeam 60ghz PTP -> USW flex switch -> 5 port unmanaged switch -> 5 port unmanaged switch. Also coming from the USW flex switch is a nanobeam PTP -> flex mini.

Nestled in there is 6x Unifi LR APs, 1x U6 Lite and an AC Mesh Pro with 5x hikvision NVRs.

I already know the simple answer, but the crux of the question is:
Is there anyway I can have ethernet clients (such as NVRs) move on to the devices VLAN without swapping out the unmanaged switches for more flex minis?
I'm not too worried about isolation of networks, more just housekeeping and room for DHCP allocations.

I am aware VLANs require managed switches as a rule, but…
Is there a way to strip tagging so you could simply give a client a static IP address on the VLAN and it will connect?
Even if I have a managed switch at the location of the NVR, the unmanaged switches upstream will bork because of failed trunking?
How is it that VLAN aware APs with replicated wifi SSIDs work and get assigned an IP from the DHCP pool when they're coming along the same channels?

Wifi devices work fine what ever network they're on but when I tried to assign a VLAN ip address to one of the NVRs, there is no connectivity. I changed the port profile on the flex mini to the IoT VLAN and I could pull it up on screen from default LAN but it would not connect to the Hik Connect servers no matter what I did and it took out all the network downstream until I hard reset and re-adopted the flex.

Thanks for any nuggets of wisdom.

It can be done but it is a hack and will not be reliable, and will defeat the purpose of splitting out VLANs, since they would all end up seeing broadcasts from each other. Basically you'd either strip the VLAN tags off the trunk port going to the switch and rely on ARP to hopefully get traffic to the right router interface, or connect multiple untagged ports (one in each VLAN) to your switch again hoping ARP and broadcasts all play nicely. Messy, unreliable, and not proper network design. At that point you might as well just expand your subnet, effectively the same thing.

Smart switches are cheap, sounds like you have a complex enough network that it makes sense to upgrade.

The only alternative I can think of is to have a dedicated access/untagged port off the PFSENSE for each VLAN and hang a switch off each port (and everything connected to that switch would be in that VLAN). But that isn't very flexible.

VLAN aware devices will probably work fine as most (not all) dumb switches, especially ones with jumbo frame support, will pass VLAN tags. So your APs and PFSENSE can communicate via the dumb switch and it is effectively isolated, just using the dumb switches as a transport. Anything with that VLAN tagged will be able to communicate, but you won't be able to add non-tagged devices into that VLAN on the switches.
 
Ok. Thanks for the reply.
Can you possibly confirm this please?:

If I swap out unmanaged switches to managed across the rest of the network, the trunk lines are already in place (I believe).
Does the trunk/transport need to be coming in to port X and out of port Z on each switch, or it doesn't matter if all ports are default profile.
If all ports are default profile, will the VLANs work via the switches doing their switching (once all smart), or do I need to change the profile on the port for the client on that specific VLAN?

I will need to keep the 48 ports as is but if I come from router to managed switch then one port to daisy chained route and one port to rack switches, I presume would be ok. Just anything on those switches will not be VLAN aware.

Side question, can I have pfsense hand out DHCP for trusted VLAN rather than original LAN by default?

Thanks again.
 
Ok. Thanks for the reply.
Can you possibly confirm this please?:

If I swap out unmanaged switches to managed across the rest of the network, the trunk lines are already in place (I believe).
Does the trunk/transport need to be coming in to port X and out of port Z on each switch, or it doesn't matter if all ports are default profile.
If all ports are default profile, will the VLANs work via the switches doing their switching (once all smart), or do I need to change the profile on the port for the client on that specific VLAN?

I will need to keep the 48 ports as is but if I come from router to managed switch then one port to daisy chained route and one port to rack switches, I presume would be ok. Just anything on those switches will not be VLAN aware.

Side question, can I have pfsense hand out DHCP for trusted VLAN rather than original LAN by default?

Thanks again.

It can be any port, you go into the GUI of the switch and tell it what ports to have tagged (trunk) or untagged (access) for each VLAN.

Higher end switches support various types of VLAN auto configuration so it will detect your trunk ports and allow the VLANs, but on standard smart switches you'll need to go in and set what VLANs you want on each port, and which ports to tag them on.

Basically just enable all your vlans on the interlinks between the switches, then you can set any switch port on your network to be in any VLAN (or in multiple VLANs with tagging in the case of your APs).

PFSENSE can have a DHCP scope for each VLAN, and once you have VLAN segmentation it will know which VLAN is requesting and assign out of the relevant subnet/scope.
 
LAN ip addressing is getting close to capacity, so thought best practice to create new networks for Trusted, Guest & IoT. I have set the rules in pfsense that trusted VLAN (phones, laptops, watches, TVs, etc) has access back and forth to default LAN (reserved for static servers, VMs, printers, etc.). These two networks can see IoT but not in reverse besides allowing access to gateway for internet connectivity.

If you're close to this level, then consider a managed L3 switch to define the VLAN's - they'll do a better job of it...

It's mostly about segregating functions - routing is one thing across the WAN side, and managing traffic on the LAN side is another.

@coxhaus has some experience here...
 
If you're close to this level, then consider a managed L3 switch to define the VLAN's - they'll do a better job of it...

It's mostly about segregating functions - routing is one thing across the WAN side, and managing traffic on the LAN side is another.

@coxhaus has some experience here...

Depends, if you need good throughput between VLANs, the L3 switch will definitely help (depending on the pfsense, some can handle multiple gigs but keeping it local is more efficient regardless). However now you need to run a DHCP server that can understand redirected DHCP requests and map them to the correct interface. I'm assuming there must be that functionality in pfsense or possibly an addon, but not sure. And obviously those managed switches need to be able to have DHCP helper configured (or run their own DHCP server, but that isn't ideal unless they're also dynamically updating DNS or running their own DNS, and the L3 switches aren't really a good place to be running DHCP/DNS).

6 of one, half dozen of the other, it can add a lot of flexibility, but at the cost of some more complexity and higher expense. Comes down to how much traffic (and how fast it needs to be) is going between VLANs.
 
I don't know about new non-managed switches but in the old day's tags were stripped off if passing through a non-managed switch. Traffic passing would inherent a VLAN tag based on the port plugged into a VLAN on another switch. So, an unmanaged switch would inherent the VLAN of which switch it was plugged into.
Untagged traffic passes to the default VLAN.

It is best to buy a managed switch for VLANs. You only use unmanaged switches if you need to add a lot of ports cheaply.

And L3 switches can route networks faster than any external router on the network regardless of bandwidth or CPU power. Some of the differences are small so you can get by with an L2 switch. I guess people have a hard time understanding L3 switching.
 
I don't know about new non-managed switches but in the old day's tags were stripped off if passing through a non-managed switch. Traffic passing would inherent a VLAN tag based on the port plugged into a VLAN on another switch. So, an unmanaged switch would inherent the VLAN of which switch it was plugged into.
Untagged traffic passes to the default VLAN.

It is best to buy a managed switch for VLANs. You only use unmanaged switches if you need to add a lot of ports cheaply.

Yes - many unmanaged switches may pass thru the VLAN tags, challenge here is that there is no downstream port isolation for any ports on that switch.

on the other hand, as @coxhaus mentions, there are some switches that can strip the tags - depends on the switch I suppose.

lightly managed "smart switches" are not much more than unmanaged switches, and if one is using VLAN's out on the wire, it's a good investment.
 
I don't know about new non-managed switches but in the old day's tags were stripped off if passing through a non-managed switch. Traffic passing would inherent a VLAN tag based on the port plugged into a VLAN on another switch. So, an unmanaged switch would inherent the VLAN of which switch it was plugged into.
Untagged traffic passes to the default VLAN.

It is best to buy a managed switch for VLANs. You only use unmanaged switches if you need to add a lot of ports cheaply.

And L3 switches can route networks faster than any external router on the network regardless of bandwidth or CPU power. Some of the differences are small so you can get by with an L2 switch. I guess people have a hard time understanding L3 switching.

An unmanaged switch cannot strip a VLAN tag, it has no idea what a VLAN tag is nor can it de-encapsulate the frame. It will just drop the frame if it detects it as invalid, which many older dumb switches would do because the frame was too large and an invalid ethertype. Newer dumb switches with jumbo frame support will often forward tagged frames fine, even though they are an invalid ethertype as far as that switch is concerned.
 
Yes - many unmanaged switches may pass thru the VLAN tags, challenge here is that there is no downstream port isolation for any ports on that switch.

on the other hand, as @coxhaus mentions, there are some switches that can strip the tags - depends on the switch I suppose.

lightly managed "smart switches" are not much more than unmanaged switches, and if one is using VLAN's out on the wire, it's a good investment.

The only switch that can strip a tag is a smart or managed switch (vlan aware). If you're going to get one of those, might as well use VLAN tagging.

I guess there may be some specialty switch out there that has a custom ASIC intended to strip off tags but it wouldn't be some generic dumb switch you buy off the shelf. Those will either pass the tag or drop the entire frame.

The cost of 5 and 8 port smart switches is dirt cheap, and the 16/24/48 are very reasonable (compared to 5 or 10 years ago). So I agree, make the investment, especially if you have all other VLAN aware devices. Trying to have separate VLANs and subnets sharing the same broadcast domain doesn't make any sense (and probably will work like crap).

Even if you don't have VLAN aware devices, many smart switches have a feature where you can isolate wired ports allowing them to only send to a certain port, and not to other ports on the switch. Essentially the way guest wifi works but for wired. A dumbed down version of Private VLANs.
 
I guess there may be some specialty switch out there that has a custom ASIC intended to strip off tags but it wouldn't be some generic dumb switch you buy off the shelf. Those will either pass the tag or drop the entire frame.

My unmanaged Linksys SE3008 and Netgear GS108's are hardly custom, but they do pass thru VLAN tags...

On the Netgear GS108 - the key difference between managed and unmanaged is a #define - it's the same SoC and same firmware inside the device.




That being said - going to a lightly managed switch will be a better path, allowing granular configuration across the ports...
 
My unmanaged Linksys SE3008 and Netgear GS108's are hardly custom, but they do pass thru VLAN tags...

Not disagreeing at all, many modern dumb switches will pass VLAN tags fine (they ignore the fact that the frames are the wrong ethertype, and since they support jumbo frames, have no issue passing them). I was talking about stripping tags, dumb switches do not do that.
 
Unfortunately I'm told, some do - depends on the SoC inside the switch...

I guess anything is possible, I've never seen it, and it would not be a desirable effect in most cases. It would effectively have to be a smart switch SOC put inside a dumb switch, but with programming to specifically strip the tag, which is why I said it is possible for a specific special use case but not a generic switch.

FIOS ONTs do it (we learned that with the DHCP being sent out the WAN bug a while back) but I don't really consider those a switch (or dumb).
 
My unmanaged Linksys SE3008 and Netgear GS108's are hardly custom, but they do pass thru VLAN tags...
So, if you are passing tags on an unmanaged switch, I assume local ports are untagged so they will be assigned to the default VLAN which seems screwy to me.
 
This is more of a question than a suggestion, to check my own understanding, but would it not work to just have pfsense go to a single managed switch, preferably via a LAGG, and split off from there to the unmanaged switches? I mean in the sense that each unmanaged switch or group of unmanaged switches could be on its own subnet. It's hard to see how it would work without being able to visualise your network, but my point is that I think you only need managed switches at those key points where the network needs to split to different subnets - it doesn't matter that the switches downstream from that point are dumb.

If the main concern is to free up DHCP allocations then you could increase availibility just by separating wired devices from wifi devices. If you want or don't want communication between those subnets you can do that with firewall rules in pfsense.

Sorry if the above misses something fundamental - I'm very much a beginner!
 
So, if you are passing tags on an unmanaged switch, I assume local ports are untagged so they will be assigned to the default VLAN which seems screwy to me.

Unmanaged switches should always pass through layer 2 frames whether they contain tags or not...

Note that the tags add 4 more bytes to the MTU, which is typically 1500, so adding those tags makes the MTU size 1504 - which some switches might take exception to (there's other tags that can take frame sizes up to 1532, but that's out of scope for this dicussion)

To be honest - it's the frame size itself, not the content within the frames, that is the challenge with unmanaged switches, and most of the current customer oriented switches are fine with this...

@coxhaus - I know you're one that is most interested in L2/L3 managed switches, along with unmanaged which always run on L2...
 
Unmanaged switches should always pass through layer 2 frames whether they contain tags or not...

Note that the tags add 4 more bytes to the MTU, which is typically 1500, so adding those tags makes the MTU size 1504 - which some switches might take exception to (there's other tags that can take frame sizes up to 1532, but that's out of scope for this dicussion)

To be honest - it's the frame size itself, not the content within the frames, that is the challenge with unmanaged switches, and most of the current customer oriented switches are fine with this...

@coxhaus - I know you're one that is most interested in L2/L3 managed switches, along with unmanaged which always run on L2...
I think of an unmanaged switch as an extension to the VLAN port it is plugged into. When data from the unmanaged switch passes through the VLAN port into the network it inherits the VLAN tag from the port.
This is the same way a client PC would work. The PC inherits the VLAN when it passes through the VLAN port.

This is the way I think of it and the way it worked back in the old days. Back when VLANs came along the switches were expensive and we used a lot of our old switches with the VLAN switches.

If data passes as untagged data, then it should be assigned to the default VLAN which can be any VLAN. It does not have to be VLAN1. A lot of cheap switches, have to have the default VLAN be VLAN1. They should not be this way. And I would not use a switch like that.
 
Last edited:
I think of an unmanaged switch as an extension to the VLAN port it is plugged into.

That's what I was driving at but said a hell of a lot more succinctly !! :)
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top