I'm really starting to get interested in networking. I'm working on coming up with a build to run Pfsense on. I'm starting first with getting a managed switch. I really like the idea of VLANs to keep potentially unsafe devices separate from the rest. Right now I have those untrusted devices on my WIFI's guest network to obtain that separation.  Along with the managed switch, I purchased an AP to test out. Here is my question....If I have 10 devices connected to an AP, can I pick which of those devices are put on a VLAN by IP? Say only two devices were untrusted and I wanted them on a VLAN, but not the other eight devices. I assume the answer is no, but I want to understand as much about VLAN capabilities or limitations as I can before I sit down to plan out the new network. If I want some WIFI devices on one network, and the rest on another, I'm guessing I need two separate WIFI networks?

Also, is  there an advantage to settings up VLANs on the Pfsense machine rather than the switch?

My overall goal for my network is to have untrusted devices, and any WIFI networks I deploy to be on their own VLANs. I then want to have everything behind a firewall. I also want to build a Pfsense machine that I can have a whole house VPN connect with my current VPN provider. I know some devices will need rules to get out without the VPN for various reasons. That's all in the learning.

Hi
Switches work by the MAC address
You decide which device you want on which VLAN by the port it is plugged into

So if you have 4 ports on the switch and you want the first device on vlan 2

You go to port 1 and on a Cisco switch it would be

Switchport access vlan 2

If you want the one on port 3 to be on vlan 3 it would be

switchport access vlan 3

This is assuming you already built the extra VLANS

Hope this helps

It might depend on the AP chosen. If it’s a Unifi then you can specify a VLAN IDs to the SSID. There is a nice explanation on it at this reddit link. I’m pretty sure you can do the same thing on other APs as well...

There is a little more to vlans.

Step 1. Create the vlans you want on the switch.
Step 2. Buy an access point that understands vlans.
Step 3. Create a trunk port on the switch and plug the access point in.
Step 4. Create an ssid for each of your vlans.
Step 5. Create rules in pfsense to decide what can get to the internet and what can talk to each other.

There are a couple of ways to do what you want to do.

The most common way is to use an AP capable of tagging SSIDs to VLANs. This will typically be (most commonly) your SMB/Enterprise grade APs which is pretty much going to be any standalone AP or AP that is capable of working with a central controller. I do this a lot at work with Mikrotik APs (we are mainly a Mikrotik shop especially when it comes to routing and low density wireless applications) but many other vendors support it. If you want simple to configure, I'd look at either using Rukus Unleashed or Cambium cnPilot as both offer "cloud" controllers that you don't have to spin up and host (unlike Ubiquiti's Unifi).

Depending on your managed switches capabilities, you can dynamically assign VLANs (this is kind of fun with Mikrotik's CRS3xx series switches but very involved and I honestly haven't found a practical production use for it...yet).

Something I play around with a bit (especially for our higher end MDUs) is using dynamic VLAN assignment via WPAx Enterprise. Basically, when the client selects the wireless SSID on their smart device, it prompts them for a login/password. This information is then verified in a RADIUS server which then responds to the AP which VLAN to place the client in and as long as the client is registered to that AP, the AP will automatically tag the traffic. This allows for a common SSID but multiple clients registered to the AP can all be segmented off in unique VLANs. Doesn't work very well with IOT devices though so I still tend to spin up a unique SSID for those.

As far as answering your question regarding whether or not you should use VLANs on pfSense...yes, you should at least dedicate VLAN access to your pfSense box for each vlan's subnet. Now, you can do that one of two ways. You can provide an untagged interface on for each VLAN in your switch to plug into a physical ethernet interface on your pfSense box...or you can enable VLAN tagging so multiple VLANs can share a physical interface on the pfSense box. The way I typically build is to aggregate multiple interfaces on my firewall using LACP and just run over that. As an example, I typically will create a 2 or 3 interface LACP between the switch and firewall/router and just tag "virtual" interfaces from there. It's very handy in cases where you may have quite a few VLANs but are limited on the number of physical interfaces available on your hardware selection.

I feel like I'm way in over my head. I got my TP Link TLSG1016PE today. My router is a Netgear R8000. I was curious if I could do VLANs with using my current router until I built the pfSense box. In the TP Link management, there were two options for VLANs.

The first option is "port based VLAN configurations". I selected the ports I wanted segregated. It worked as in I couldn't access those devices, but they were not able to access the internet. I modified it, and included port 1 with the other ports and still didn't work.

The second option was the 802.1Q VLAN. I followed the directions, videos, etc, but nothing happened. Some of the light reading I did indicated this option is geared for setups that have routers like pfSense.

By now I think you all realize how green I am to this type of stuff. Bottom line, am I able to have VLANS that can access the internet with the router that I currently have? To keep it simple, all I'm trying to do is put my two AppleTVs on their own VLAN for practice. Very beginner stuff.

Thanks all!

There is nothing (mostly) magical about VLANs.

In the beginning, there were ethernet hubs. Everything connected to the hub could talk to each other (assuming proper L3 addressing) and life was good. However, all the devices connected were in the same Collision Domain. If two devices tried to talk at the same time, chaos erupted and various dance moves were enacted to avoid the meeting-somebody-in-a-hallway awkwardness.

Ethernet switches fixed that. The Collision Domain was no longer of concern. Instead, the Broadcast Domain became a concept. Now life was really good. Still, things could have been better. You really didn't need for every device to hear a noisy neighbor that was broadcasting non-stop. There was also security concerns if you had groups of devices that really shouldn't be able to talk to each other (like a thermostat and a DB server).

No problem. Simply purchase a switch for each logical group of devices to segregate them. This works fine in a server room or data center. However, what about the wiring closet on the north side of the third floor? There is a thermostat, time clock, security camera, and a half dozen PCs. Are you going to put 4 different switches in that closet just for that? Wouldn't it be cool if we could take that 48 port switch and treat it like it was 4 different switches. With VLANs you can. Any time you use VLANs on a switch, you can view it logically as multiple separate switches.

More in a moment.

One most switches, ports are statically configured on a port by port basis. Assigning ports to VLANs can be handled in a couple of ways:

1. You can designate all traffic coming into a port as belonging to VLAN (some number, let's say 99). In this case, VLAN 99 only has meaning within that switch. Traffic going out the port is still ordinary ethernet packets. For Cisco, this is an access switchport for a specific VLAN. For HPE / Aruba / ProCurve this is an "untagged" VLAN port.

2. You can enable 802.1Q for the port. Outgoing ethernet packets will have the VLAN ID inserted into them. Incoming ethernet packets must have a matching tag in their frame. Cisco calls this VLAN trunking. HPE / Aruba / ProCurve calls this a "tagged" VLAN port. (HPE uses the the term "trunk" to refer to what Cisco calls LACP. Not related to VLANs.

Why do we want 802.1Q?

More in a  moment.

So we have virtual multiple separate LAN's in a switch, now what?

A switch isn't an island, the packets need to go somewhere. Although it could be possible for packets to stay on their own VLAN without interacting with the rest of the world (think industrial control where a PLC talks only to its devices) generally some packets will have to leave their VLAN. This can happen in a couple of ways.

1. The switch could be a Layer 3 switch. In this case, the term switch can be misleading. Layer 3 switches are actually routers with many ports. For example, a few feet to my left I have a couple of older Cisco 4948 switches. The firmware image on them gives them L3 functionality. They are in reality 48 port TCP/IP routers. I can enable intervlan routing (command: ip routing) and packets will flow between the VLANs as needed, but broadcasts will stay in their own broadcast domain.

2. We can send the VLANs to an external L3 router. This could be a hardware or software (virtual) router.

Let's think about option #2 for a moment. If we have 4 VLAN's on the switch and we want to route between them, do we need a router with 4 ports and use 4 cables? If it wasn't for 802.1Q, yes we would.

The beauty of VLAN trunking (802.1Q) is that we can send packets from multiple VLANs over one connection. Remember that tags are being inserted into the frames? Any device that understands 802.1Q sees these tags and splits the packets out into the proper internal VLANs (if they are configured on that device).

You might occasionally see the term "router on a stick". This is referring to what the network diagram looks like when you have multiple VLANs on multiple connections coming into a switch and there is a single trunked connection running out to a route. This is also called hair-pinning (if you follow the packets, they leave the switch, hit the router and make a u-turn.)

More in a monent.

I hope this helped. If not, please ask more questions.

Something to keep in mind is that a good subnet plan will save you headaches.

You will often see something like:

VLAN99    10.50.99.0/24
VLAN100  10.50.100.0/24
VLAN101 10.50.101.0/24

There is no technical relation between VLAN99 and the 99 in the third octet of the address. It is simply for convenience because (if you are consistent) it is easy to tell what VLAN a subnet is supposed to be on.


Another thing: If you do have a Layer 3 switch and you enable intervlan routing, you still have your broadcast domains, but you have lost any security separation. You can usually add that back using ACLs.

OP watch these 8 YT videos on VLANS from a Cisco perspective using an awesome free program called Packet Tracer network emulator.  Free Cisco CCNA Packet Tracer - Windows, Mac, Linux
It will give you a good foundation on VLANS.

VLANs and Trunks for Beginners - Part 1

VLANs and Trunks for Beginners - Part 2

VLANs and Trunks for Beginners - Part 3

VLANs and Trunks for Beginners - Part 4

VLANs and Trunks for Beginners - Part 5

VLANs and Trunks for Beginners - Part 6 VOIP

VLANs and Trunks for Beginners - Part 7 VOIP

VLANs and Trunks for Beginners - Part 8 DTP

By putting certain devices into a different VLAN you are creating a "broadcast domain" where those devices can only talk directly to other devices in the same VLAN / IP subnet. In order to communicate outside that subnet you need a gateway / router (think of it as a door between two adjoining rooms) that has an IP in each of those two VLANs.

This could be accomplished in a multitude of ways, but if you're looking to actually create segmentation, it's best done on the PfSense device since that would allow you to create security policy that dictate what those "untrusted" devices can actually access.

A port based VLAN does not require any configuration on the device you plug into the port, since it's [port] based. A port configured for 802.1q would expect incoming ethernet traffic to have a VLAN ID on it (configured in the network adapter settings). Stick with port based for your devices and configure the uplink port to the PfSense as 802.1q. That should allow you to configure sub interfaces (one for each VLAN) that would allow you to route and enforce security policy between the two VLANs.

Vlans hurt my head.

Ubiquity stopped that.

Get a UDM and AP, then set up all the Vlans you want.

Thank you everyone who offered input. Some of you went well beyond what I expected!