Recommendations For Smart Network Switch

Discussion in 'Networking, Internet, Web Applications & The Cloud' started by Floppyman, Feb 12, 2017.

  1. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14. I was actually quite surprised as to how affordable the Ubiquiti AP's were. I started thinking about replacing my Asus RT-AC66U with a Ubiquity AP for the VLAN , but if their range isn't quite as good it's probably not worth spending the money. It may be better just to purchase another Asus RT-AC66U.

    Agree that in situation where 4+ LAN ports are available on a pfSense box, there's no need to create virtual interfaces since each physical LAN port could act as a gateway to VLAN's created on the switch. One would only need to create the different VLAN's on the switch itself to separate all the ports out into the different networks (and potential routes between them if Layer 3 is supported is supported). Does that sound right?

    Now quickly back to wireless AP's: How important is it to have a guest network? If the wireless network is on its own VLAN that already provides some layer of separation between the wired and wireless networks. I'm assuming it starts to become important if one wants to enable traffic flow between Wired and Wireless for some services, but at the same time still wants to maintain a wireless network as well that is completely split off from the rest of the network (the other wireless network, and the wired network).

    Thanks again for all your help.
     
  2. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    It's a bit of a toss-up. If I had ethernet running throughout my house, I'd love to get multiple Ubiquity APs and set them up around the house. But, as it stands, I'm trying to squeeze every last drop of performance out of the APs in my basement (where the bulk of my network equipment is).

    Correct. In that case, you're really just using VLANs to logically split the switch into 4 different pieces. Except for the Layer 3 routing peice, you'd get roughly the same properties by just connecting 4 dumb switches to the pfSense ports.

    You seem to understand the considerations. It becomes a question of how much do you want to be able to consider wifi devices "trusted," and whether wifi devices need to be able to talk to your wired network and/or each other.

    If wifi devices need to talk to your internal network, then I think you'd ideally want to run a separate guest network. At that point you'd need to decide if you want your primary wifi network on the same subnet as your wired network. Mine is, because some things break otherwise. Some protocols, like UPnP, don't cross subnets very well or at all. Some devices/applications will change how they interact with other devices when they're not on the same subnet- treating it as a remote connection instead of a local one. You can work around some of these things (like adding proxies to get my Sonos working on my guest network), but they're often hacks that aren't fully reliable. Now, depending on what you have on your network, and what you're doing with it, this might be a non-issue.

    The other issue is whether devices on the wifi network need to talk to each other. A good example of this is Chromecast and phones. Your phone needs to be able to talk directly to a Chromecast to cast/stream. Guest networks are typically set up with something called "client isolation" that prevents wifi clients from communicating with other devices. When client isolation is enabled, wifi devices can talk to the AP/router, and get out to the Internet, but they can't get to other local resources on the network.

    Another potential consideration is whether you really want to be giving your main wifi password to guests. If for some reason you decide you've given it to someone that you no longer want using it, you'd need to change the password and reconfigure all your wifi devices. WPA2-Enterprise avoids this problem by letting you create username/password pairs (managed by a RADIUS server that can run under pfSense), but there's plenty of devices out there that don't support WPA2-Enterprise (e.g., Sonos, Chromecast, most media streamers etc.). So, I run WPA2-PSK on my primary wifi network, and I keep the password to myself. My guest network uses WPA2-Enterprise, which works out fine because nearly all laptops/phones/tablets support that.
     
  3. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14, I really appreciate the additional information.

    I would like to work through another example with you there is Ubiquiti Unifi AP deployment with Guest Wifi access. I have been thinking through this all the day but I'm getting a little stuck on how to set this up exactly given that there is a little bit more complexity involved.

    Let's assume the following setup:
    pfSense box with dedicated LAN port for wireless VLAN
    24 port switch with 4 ports dedicated for a wireless VLAN: 2 ports for AP's, 1 port for the connection back to pfSense, and 1 port for expansion/troubleshooting.

    Here is what I understand about the Ubiquity Unifi AP's:
    One can have up to 4 SSID's per AP
    Up to one tagged VLAN per SSID
    The AP management VLAN needs to be untagged

    Given that, I see two ways to set this up:

    Option 1:
    3 VLAN's: Management, Wireless 1 (Restricted), Wireless 2 (Guest)

    Option 2:
    2 VLAN's: Wireless 1 (Restricted), Wireless 2 (Guest)

    Let me go through each:

    Option 1:
    1) Create three virtual interfaces on the pfSense LAN port: One for Management, Wireless 1, and Wireless 2
    2) Setup pfSense to tag VLAN traffic on Wireless 1 and Wireless 2 VLAN's
    3) Management VLAN traffic will not be tagged.
    4) On the switch, port 1 becomes the trunk port and part of all three VLAN's - does this trunk port need to have traffic for Wireless 1 and Wireless 2 VLAN's tagged?
    5) On the switch, port 2 and 3 become part of all three VLAN's; traffic is tagged for Wireless 1 and Wireless 2 VLAN's, but not Management VLAN
    6) Port 4 becomes part of the Management VLAN (no tagging).
    5) At the AP level; AP receives address from Management VLAN, but Wireless 1 VLAN is configured to SSID 1, and Wireless 2 is configured to SSID 2.
    6) Those that connect Wireless SSID 1 receive addresses in the Wireless 1 subnet, those that connected to SSID 2 receive addresses in the Wireless 2 subnet. Both Wireless 1 and Wireless 2 are completely isolated from each other and from the management subnet.

    Option 2:
    1) Create two virtual interfaces on the pfSense LAN port: One for Wireless 1, and one for Wireless 2
    2) Setup pfSense to tag VLAN traffic on Wireless 2 VLAN
    3) Wireless 1 traffic will not be tagged since Wireless 1 also acts as management VLAN
    4) On the switch, port 1 becomes the trunk port and part of both VLAN's - does VLAN traffic for Wireless 2 have to be tagged on this trunk port?
    5) On the switch, port 2 and 3 become part of both VLAN's; traffic is tagged for Wireless 2 VLAN, but not Wireless 1 VLAN
    6) Port 4 becomes part of the Wireless 1 VLAN (no tagging).
    5) At the AP level; AP receives address from Wireless 1 VLAN and Wireless 1 VLAN is configured to SSID 1, and Wireless 2 is configured to SSID 2.
    6) Those that connect to SSID 1 get addresses in the Wireless 1 subnet (same subnet as the AP is on), those connecting to SSID 2 receive addresses in Wireless 2 subnet (completely separated from Wireless 1)

    The main difference between option 1 and 2 is that in option 1, management of the AP's is on a separate VLAN, while in Option 2 management is part of the Wireless 1 VLAN. I would imagine that in a home network, where access to wireless devices is restricted, management access could be part of the Wireless 1 VLAN, while one would want to keep the guest network (Wireless 2) completely isolated from that. Does that make sense?

    Do the setups I've described more or less make sense? Traffic is tagged from pFsense all the way to the AP and then goes to the respective SSID. I think where' I'm getting a little confused is with the tagging and trunking that needs to occur because of a. one physical pfSense port b. one physical port per AP c. multiple SSID's and d. the management VLAN traffic needs to be untagged.

    Thanks in advance for any clarification you can provide.
     
  4. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    @Floppyman

    I think you've got it. I don't have a Ubiquiti AP, but from what I understand, by default it will set up a wifi network that runs off the untagged management subnet. This would align with option 2.

    One thing you should know about the Ubiquiti APs is that you (usually) need to run AP controller software. You need the controller software running to configure the APs, and if you want to use certain functionality (e.g., run a captive portal on your guest network), you need to run the management software continuously. They make a standalone device, otherwise you can run the software on a PC. Unfortunately, there's no plugin for pfSense.

    The controller has to be able to talk to the APs, and you have to be able to get to the controller (which is controlled via a web admin page). I don't think they all have to be on the same subnet, but it's probably easier if they are.

    I think your Option 2 is probably preferable to Option 1. And I'd probably put your wired devices on the same subnet as your AP, though that's up to you.

    A few notes/responses: (most of this applies to your option 1, too)
    • You probably know this, but VLANs are identified by number (i.e., the VLAN ID/tag).
    • In general, you configure VLANs on your switch. That's where you'll decide what ports are tagged and untagged members of VLANs.
    • Switch Port 1 (connected to pfSense) would be a tagged member of both Wireless1 and Wireless2. That's how pfSense will distinguish traffic to the two virtual interfaces.
    • When you set up the virtual interfaces in pfSense, you'll need to configure them with the respective VLAN IDs/tags set up on the switch.
    • It's not clear to me what you're doing with the extra switch ports (ports 2,3,4). You'd only need one cable going to each AP.
    • Switch Port 2 (connected to the AP) would be a tagged member of Wireless2, and an untagged member of Wireless1. Also (new concept here), it would need to be configured with Wireless1 being the default VLAN (i.e., the PVID), meaning it will tag any untagged packets received from the AP as being Wireless1.
    • You'll need to run two instances of a DHCP server on pfSense: one on the Wireless1 interface, and one on the Wireless2 interface. (if this doesn't make sense now, it will when you see pfSense)
     
  5. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14 - I think I'm close understanding everything I need to build this network :).

    Regarding the Ubiquity AP's and needing to run controller management software - that's very interesting. So that does mean that unlike e.g. an Asus RT-ACC66U, their AP's don't an configuration interface/portal? One uses the software on the PC/device to configure and presumably uploads the configuration settings to the AP, or does it work some other way? Is there GUI access to the AP's at all without having to go through the controller software (i.e. to see status, client's connected, etc.)? I guess I'm trying to understand to what extend the AP controller software is needed - just to change configuration or also to see status, etc.? It sounds to me that they decided to setup it up this way to help centralize the control and configuration of potentially 10's or 100's of AP's, i.e. to simplify the management process. It would be great if at least some functionality was available through GUI on the AP itself that one could access through the network. Could you elaborate on that?

    If the controller software is necessary for everything, are there any VLAN aware AP's/routers available that host everything on the AP itself? I guess the other option with Ubiquity AP's is to purchase the standalone device, which will act like the controller (like you mentioned above). Am I right in understanding that one would plug this controller device into the subnet/VLAN the AP's are on and then connect to it through a browser to configure all the network's the AP's?

    Thanks again for your help and explanation.
     
  6. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    I don't have a Ubiquity, but the use of a controller is pretty standard for enterprise-class APs. Why? I think you nailed it: in their expected configuration, there will be lots of them, and a network admin isn't going to want to configure each one by hand. All the APs talk to the controller, and you access the controller via a web portal.

    For most things, I think you're right; the controller is primarily used to push configuration data to the APs. It also is also where the APs send status information. And, the controller may perform certain other tasks, like running a webserver for a Captive Portal.

    I'm not certain of this, but I think to configure the APs you need to either use a Controller (be it the dedicated device, the software running locally, or the software running in the Cloud, e.g., Amazon AWS), or use an Android app that provides limited functionality.

    Yes, I'd set this up by attaching the controller to the same subnet as the APs. The user guide has the host PC you use to connect to the controller must also be the same subnet, although I don't know if they just oversimplified things or if that's needed to do the initial configuration. You'd have to play around with that a bit if you get it.

    I really thought there was a pfSense package, and I guess there was an informal one that's never been distributed from pfSense, but it doesn't appear to be actively supported by anyone (and certainly not by pfSense). Instead of the Cloud Key device, you could run the Controller software on a Raspberry Pi, although I don't think you'd save a lot of money that way unless you already have a Pi that you're not using for anything else.

    Are there VLAN-aware APs that don't require a Controller? I don't know. You could look at DD-WRT, which is VLAN-aware as a router, but I'm not sure you can set up different SSIDs on different VLANs.

    Personally, I think having a single controller for all APs sounds awesome. I'd find that totally worth $80.
     
  7. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14. That makes a ton of sense and I see the utility of having a central AP controller now, especially on a larger network with many AP's.

    I also wanted to get your thoughts on PoE. The Ubiquity AP's support PoE, and it might be nice to have support for other PoE devices as well, such as IP cameras, IP phones, and AP controllers, for example. Do you think it's worth paying a premium for a PoE capable switch (as you mentioned earlier it's about twice as much as the non PoE capable version)? The AP's also include PoE AC adapters one can use so it's not a necessity to have support for it, but might still be very convenient if the intent is to add additional PoE devices down the road.

    If one does use a PoE capable switch, every switch downstream from that switch would then also have to be PoE capable for the device at the end to receive power, correct? And that's all you'd have to do right - just make sure that all switches on your network are PoE capable from central switch all the way to the switch just before the device connection, correct (i.e. there is no need for additional equipment beyond that)?

    Thanks again for your help.
     
  8. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    I don't think the extra money for the PoE switch is worth it unless you really know you're going to make extensive use of it. If I was rewiring my whole house and running ethernet to every room, maybe I spring for a PoE switch.

    As you noted, you'll get PoE injectors with the APs. For few a couple/few devices, I don't see any substantial benefit to using a PoE switch as opposed to a couple/few injectors- certainly no benefit worthy of the cost.

    And yes, if you were to go the PoE route, what matters is the switch(es) that connect to your edge devices and APs. So, if you chain switches, the switches at the end of the chain must be PoE-capable. That's why I'd say a PoE switch might make more sense in situations where you have a bunch of ethernet cables all running back to your central switch. Otherwise you might need to buy a bunch of different PoE switches.

    Realistically, I'm not sure you'd ever have a lot of PoE devices. APs are one example of something you might have. The main other example I can think of would be home security cameras.
     
  9. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Hi @reggie14 - I have been reading up a little bit more on VLAN's and trunking and wanted to clarify something.

    Here's a very simple example with the following equipment:
    1) Assume pfSense box with one WAN port 2x LAN ports
    2) 24 port Layer 3 capable switch

    Let's assume the switch is split into two VLAN's:
    VLAN 1: Includes ports 1 - 12 (all untagged)
    VLAN 2: Includes ports 13 - 24 (all untagged)

    Port 1 of VLAN 1 will be connected to LAN 1.
    Port 13 of VLAN 2 will be connected to LAN 2.

    My question is about communication between these two subnets/VLAN's.

    1) One way for them to communicate would be to setup static routing on the switch between VLAN1 and VLAN2 via the switch's Layer 3 routing capabilities, but this doesn't give me much control as to the type of traffic I want crossing between the two VLAN's.
    2) If I wanted more limited communication between VLAN 1 and VLAN 2, I would have to go through the pfSense firewall/router first. This is where I'm a still little unclear:
    a) From pfSense's point of view is it generally agnostic whether a firewall rule is made between two physical LAN's interfaces or two VLAN's that are trunked, coming through the same physical LAN interface?
    b) Is it relatively straightforward to control connectivity between two physical LAN interfaces (i.e. that represent two different subnets/gateways) using pfSense and firewall rules?

    My other option of course it to put VLAN 1 and VLAN 2 on the same physical LAN interface by trunking them through port 1 and tagging the appropriate ports for either VLAN to allow either VLAN 1 or VLAN 2 traffic. However, I would like to avoid this for reasons we covered further up in this thread - if the smart switch breaks, a regular switch won't know what to do with a tagged ethernet frames. So as long as it's possible to easily setup firewall rules to control routing of traffic between two physical LAN interfaces (i.e. two different subnets) on pfSense, I'd rather just use two separate LAN ports (i.e. two different subnets/gateways) and split the switch up into two VLAN's with 12 untagged ports in each.

    Thanks again for all your help.
     
  10. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    Yes, you could use the switch, although as a general principle you wouldn't want to rely on that. If you set up Layer 3 switching, think of as an optimization bypassing your router, not as way of fully handling routing between your subnets.

    But, doing what you really want to do is much easier than you realize. First, from pfSense's point of view, and interface is an interface. It doesn't care if an interface is tied to a physical port, or if it's a virtual interface on a shared port. It works exactly the same way once the interface is configured.

    pfSense will happily route between interfaces without any additional configuration. Once the interfaces and subnets are set up, pfSense will know how and when to route between them (just like it knows how to route between your LAN and WAN without manual configuration).

    By default, pfSense will allow all traffic to flow between internal interfaces using a "default allow" firewall rule. If you want to restrict traffic, you need to create rules. There's mainly two things you need to understand about firewall rules. First, firewall rules are applied only on incoming traffic, and not when traffic flows between interfaces. On the WAN interface, that means the WAN firewall rules are applied to traffic coming in from the Internet. On your VLAN1 interface, that means VLAN1 firewall rules are applied to traffic sent by your VLAN1 devices. If your VLAN1 devices talk to your VLAN2 devices, only the VLAN1 firewall rules are applied. In that case, the VLAN2 firewall rules are not applied when the traffic is forwarded from the VLAN1 interface to the VLAN2 interface.

    The second thing you need to understand is that firewall rules are processed top-to-bottom. (I'm ignoring the "floating" rules, which are special. I don't use them, except for the ones that are automatically generated.)

    What does this mean for blocking traffic? If you want to want to restrict traffic going between, say, VLAN1 and VLAN2, then you need to create one or more firewall rules on one (or both) interface tabs, and either place blocking rules before the final "default allow" rule, or simply delete the default allow rule and create a more restrictive allow rule. If you want to block VLAN1 to VLAN2 connections, then create the rule on the VLAN1 interface. If you want to block connections both ways, then add a rule to both interfaces. Does that make sense? Have you configured firewall rules before?

    This might sound complicated now, but I think it'll make sense once you see the firewall GUI.

    You could do that, but it wouldn't change anything concerning routing or firewall rules on pfSense. As I said above, an interface is an interface, and pfSense doesn't care if it's a virtual interface or a physical one.
     
  11. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14 - that really helped. I think in some cases I'm trying to make this more difficult than it really is. :)

    I appreciate the insight on how firewall rules and I have a better understanding now how they work. Based on what you wrote, I have a couple follow up questions:

    1) Let's assume I would not want one of my VLAN's not too have access to the internet, i.e. only have local LAN access. In that case, does one add a firewall rules on the WAN interface or just enable NAT on that particular LAN interface?
    2) Regarding allowing/denying traffic. Let's say I have three VLAN's: V1, V2, V3. If I want V1 to be completely isolated, wouldn't I just change the default rule to "default deny"? Or would this also deny traffic coming in from WAN interface (i.e. from the internet via NAT)? Now let's take a slightly different example. Let's say I want to access to allow access to V2 from only V1 and and not from any other VLAN. Wouldn't the rules created start with allowing traffic from V1 and then ending with the "default deny"? Or do I need to deny V3 explicitly?

    The other thing I wanted to revisit briefly are the concepts of tagging and trunking as I still have some confusion there.

    Let's assume the following simple setup:
    pfSense box with 1 LAN port/1 WAN port
    2 virtual interfaces created on pFsense box, VLAN 1 and VLAN 2 (VLAN 1 for restricted wireless traffic, VLAN 2 for guest wireless traffic).
    1 Wireless AP that supports, VLAN's and multiple SSID's (e.g. like the Ubiquity Unifi AP's)
    Port 1 on the switch is the link back to pfSense box
    Port 2 is the link to the Wireless AP

    First a question about pfSense. With 2 virtual interfaces defined on a physical LAN port - does pfSense automatically tag the traffic for both of the virtual interfaces so that the switch knows which VLAN to forward the traffic to (in this case VLAN 1 or VLAN 2)? If so, would I proceed like this then on the switch side?

    VLAN 1: untagged member of ports 1 and 2
    VLAN 2: tagged member of ports 1 and 2

    (Or, can one choose in pfSense? In other words, if I decide to have pfSense tag VLAN2 traffic, but not VLAN 1 traffic, would this still work because VLAN 1 traffic would just automatically forwarded by the switch to the untagged VLAN 1 ports)?

    This would mean that traffic that comes to into port 1 from pfSense destined for VLAN 1, would get forwarded to port 2 without a VLAN 1 tag and traffic originating from port 2 without the VLAN 1 tag would get forwarded to port 1.
    Traffic that is destined for VLAN 2, would get tagged with VLAN 2 and be forwarded to port 2, and traffic coming from port 2 with the VLAN 2 tag would get forwarded to port 2.

    If I understand correctly, doing this will help the AP determine that anything with a VLAN 2 tag is destined for the guest wireless network, while untagged traffic would be for the restricted wireless network.

    Now for my main question: Does this mean that port 1 on the switch needs to be a trunk port, or can it just be tagged member of VLAN 2 and untagged member of VLAN 1? Is pfSense smart enough to figure out that untagged traffic originating from port 1 is from VLAN 1, and tagged traffic originating from port 1 is from VLAN 2? Or, does the traffic coming from port 1 have to be explicitly tagged with either VLAN 1 or VLAN 2 for pfSense to be able to understand it (i.e. port 1 does have to a trunk port)?

    I was looking at this example:

    Why and how are Ethernet Vlans tagged?

    In that example traffic originating from both VLAN's was untagged meaning it would have to be tagged before going to the router/firewall to identify where it came from. However, in my example VLAN 2 traffic is already tagged, just VLAN 1 traffic is not. Would that make a difference on whether port 1 needs to be trunk port?

    I realize we are starting to get pretty technical here not, but I really appreciate all your help. Thanks again.
     
  12. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    Did you need to do a double negative there? You're saying you want VLAN 1 to have access to the Internet, right? I've been a bit loose with conventions; I've been referring to VLAN 1 as the VLAN ID, as the subnet, and as the name of the interface in pfSense. In an attempt to avoid confusion, let's assume this VLAN is for your wireless network, and you'll create a virtual interface named "WLAN" on pfSense tied to VLAN 1.

    By default, NAT will be enabled. To give it access to the Internet, you may need to create a new rule on the WLAN firewall. If it's not there already, create a "Pass" (i.e., allow) rule allowing any IPv4 traffic to any destination, using any protocol. That will function as a default allow, meaning traffic from WLAN can do anywhere unless you add explicit Block rules before the Pass rule.

    So, let say your wired network runs off an interface on pfSense called LAN. If you want to prevent your wireless network from talking to LAN computers, then you need to create a new Block rule on the WLAN interface. The rule should block any traffic with a destination of "LAN net" (which should appear in the drop-down box when you create the rule).

    Remember, pfSense is a stateful firewall. For TCP traffic, firewall rules are applied to the connections. The rule described above would stop a WLAN computer from connecting to a LAN computer, but wouldn't stop connections going the other direction. If you want to stop a LAN computer from talking to a WLAN computer, you must also create a rule on the LAN interface blocking traffic with a destination of "WLAN net."

    WAN rules are only applied to connections coming in from the Internet. i.e., if you run a webserver, you need a WAN rule allowing traffic on port 80 (which would generally get created automatically when you create a port forwarding rule). WAN rules do not apply to connections originating from your internal network. For example, you don't need to create a WAN rule to allow devices on your LAN to get out to the Internet; in that case, you just need to make sure the LAN rules allow devices to get out to the Internet.

    Make sense?

    From your question, I'm a little concerned you're not getting the idea that firewall rules are applied to incoming traffic from the point of view of the pfSense box, and that once a connection is established, traffic can flow both ways. So, from the perspective of the pfSense box, a laptop on V1 making an HTTP request to pcmech.com is incoming traffic on the V1 interface. You need a V1 rule allowing that traffic to pass. The actual HTTP response is simply traveling over the established connection, so that response isn't processed by the firewall rules.

    Before I answer your question, what do you mean by "completely isolated?" Do you want it to be able to get out the Internet? If so, then it's not isolated. Isolated would mean V1 machines can only talk to V1 machines.

    I assume what you really meant is you only want V1 to talk to the Internet, and you don't want anything else on your network to be to connect to V1 machines. In that case, I'd create a default allow to ANY destination address in the V1 firewall. Before that, I'd create two blocking rules covering traffic with a destination of V1 net and V2 net, respectively.

    Then, you also need to create rules on both the V2 and V3 firewalls. These should be blocking rules to a destination of V1 net.

    Admittedly, there are a bunch of ways to write these rules that would be equivalent, depending on whether you want to use block or allow rules. For example, you could create an alias that includes all your internal subnets and do an explicit allow to everything NOT in that alias.

    Yes, when using virtual interfaces pfSense will tag outgoing frames with whatever VLAN ID was configured on that interface.

    First, I should warn you to avoid creating a VLAN with an ID of 1. In fact, you probably can't. It's usually reversed as a sort of "default VLAN," meaning if a traffic isn't tagged, internally the switch will consider it tagged as VLAN 1. This can be useful in some situations, but most of the time if you're tagging traffic you should tag it as something other than 1. So, I'm going to start saying 10 and 20.

    You've got your configuration backwards. You tag ports as being members of VLANs, not the other way around. Also, in this particular example, you probably want ports 1 and 2 to both be tagged members of VLAN 10 and VLAN 20.

    Yes.... but, you're generally not suppose to mix tagged and untagged traffic. It's easy to mess up the configuration if you go that route, and I've been warned that the behavior can be a bit unpredictable.

    That being said, you just stumbled on what I actually do. I've only got two physical ports. One is my WAN, the other is my LAN. When I setup my Guest VLAN, I didn't want to re-create my LAN on a new virtual interface, and I wanted to be able to swap in a dumb switch if my smart switch failed. This was a bigger concern for me that it would be for you, since the only way I can access pfSense is either through the webAdmin page or SSH, both which require me to have LAN access.

    So, I'm breaking the rules here. My LAN interface in pfSense is set up as the physical port, which is treated as untagged VLAN 1 by my switch (i.e., the default VLAN). My Guest interface is a virtual interface running as tagged VLAN 50. That means between my switch and pfSense, I have untagged traffic, which pfSense luckily routes to the LAN interface, and tagged VLAN 50 traffic which routes to the Guest interface. This works, but I don't recommend it. I don't even think I'd set it up this way again.

    You have lots of physical NICs, so don't do this. Keep your wired LAN as a regular, physical interface. If you want your wireless networks to share a physical port using VLANs, then tag both VLANs. If your smart switch dies, you can hook up a dumb switch to the LAN port, access the pfSense webGUI, and make whatever temporary changes are necessary to get things running again until a replacement smart switch arrives.


    I'll answer this question to provide context for you, but don't go down the route of mixing tagged and untagged traffic.

    When you configure your smart switch, you'll assign a "default VLAN ID" to each port. It'll probably call this the PVID. An untagged frames received by that port will be tagged with the PVID. This is important when you have untagged ports for edge devices. Let's say you wanted to hook your PC up to VLAN 10. Your PC isn't VLAN aware, so the switch port would be an untagged member of VLAN 10. You'd also want to make sure that the PVID for that port is 10, so that the switch knows to tag frames sent by the PC as part of VLAN 10.

    VLAN 1 is probably going to be a special default VLAN ID for everything. It's pretty common for manufacturers to set things up so every port by default is an untagged member of VLAN 1 with a PVID of 1. So, incoming (untagged) frames to the switch get assigned a VLAN ID of 1, it's forwarded to the appropriate port on the switch (which could be any of them, since they're all untagged members of VLAN 1), and when the switch sends it out to the edge device, it removes the tag (because setting a port up as an untagged member of VLAN1 means it will remove the tag when it forwards frames from that port). In effect, the VLAN 1 tag is only used within the switch as a way of keeping this traffic separate from everything else.
     
  13. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14 - I want to make sure I understand how this works with a simple example.

    Let's assume:
    pfSense Box with 4 physical ports (3 LAN, and 1 WAN)
    12 port switch (for simplicity).

    The setup is as follows:
    Ports 1 - 4 are setup in the switch as untagged members of VLAN 10
    Ports 5 - 8 are setup in the switch as untagged members of VLAN 20
    Ports 9 - 12 are setup in the switch as untagged membes of VLAN 30

    Port 1 contains uplink to pfSense physical LAN interface 1
    Port 5 contains uplink to pfSense physcial LAN interface 2
    Port 9 contains uplink to pfSense physical LAN interface 3

    LAN 1 interface has DHCP server handing out IP's in the following subnet: 192.168.10.0/24
    LAN 2 interface has DHCP server handing out IP's in the following subnet: 192.168.20.0/24
    LAN 3 interface has DHCP server handing out IP's in the following subnet: 192.168.30.0/24

    Ports 2, 6, and 10 contain an edge device (e.g. a PC).

    My questions are as follows:

    1) When setting up VLAN 10, 20, and 30 in the switch do I need to:
    a) Make sure that the PVID for VLAN 10 is 10, VLAN 20 is 20, and VLAN 30, 30?, If so, this would mean that there is no longer a need for VLAN 1/PVID 1, correct? Because all ports have been assigned untagged members of either VLAN 10, 20, or 30 and the PVID's have been changed accordingly. In other words, there aren't any ports remaining that would end up in the default VLAN because they have not been assigned to other VLAN's.
    b) Configure the IP range for each of the VLAN's - for example in the switch setup, would I need to setup VLAN 10 as being 192.168.10.0/24, VLAN 2 as being 192.168.20.0/24, and so on?

    2) Assuming the PC connected an edge device in VLAN 10:
    a) When a e.g. HTTP request from the PC comes into untagged port 2, the ethernet frame will first be tagged by the switch with the PVID of 10 so that it knows it's part of VLAN 10, correct?
    b) Once this is done, the switch is aware that this ethernet frame is part of VLAN 10 and continues to forward it on to the VLAN 10 switch gateway port (port 1) that is connected to the pfSense box LAN 1 port, correct?
    c) Now going the other direction: An ethernet frame from pfSense that is entering the switch on port 1 from LAN port 1, is also untagged, so gets tagged by the switch with the PVID of 10 so that the switch knows that it's part of VLAN 10 and forwards it to the appropriate edge device in VLAN 10, e.g. the PC on untagged port2. Does that sound correct?

    If I'm understanding this mostly right so far, then I think I understand why PVID's are required - particularly in a scenario with multiple VLAN's. In the scenario I described where one physical switch has been split into three separate logical switches (with three different subnets and gateways). Without a default VLAN ID for untagged traffic (e.g. traffic originating from an edge device like a PC), the switch would not know what to do with the traffic once it hits a switch port (i.e. which VLAN it is supposed to be part of).

    Putting it all together then: In case the smart switch (which supports VLAN's) breaks, all I would need is 3 4 port non-smart switches, and I'd essentially have the equivalent as I do with 1 large 12 port switch split into 3 separate VLAN's, but wouldn't have to change any settings.

    Does that sound about right? I have a few more questions, but let's take it one step at a time. :)

    Thanks again for your help.
     
  14. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    Basically, yes. There's a good chance you wouldn't be able to delete VLAN 1, but it isn't going to be doing anything.

    We talked about this before. While your switch does have a DHCP server, I recommend using the DHCP server on pfSense instead. Assign the LAN 1 interface as 192.168.10.1 and make sure you enable the DHCP server on that interface. Same for the others.

    Yep, that's right.

    Right. The PVIDs are basically necessary because you're using untagged ports to the edge devices. If everything was tagged between the edge devices and your pfSense box, you theoretically wouldn't need PVIDs (hypothetically the switch could just drop untagged frames), but that's just not how things work in reality.,

    That's right. In this simple example you're basically just splitting your switch into thirds. Nothing too fancy is going on.

    This is outside your simple example, but the main thing you need a VLAN-capable switch for is to carry tagged traffic to the Ubiquity AP(s).
     
  15. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14, it's starting to make more sense now.

    I would like to go ahead and extend this example now and add a fourth physical LAN port on the pfSense box and a larger switch.

    Let's assume:
    pfSense Box with 5 physical ports (4 LAN, and 1 WAN)
    16 port switch (for simplicity).

    The setup is as follows:
    Ports 1 - 4 are setup in the switch as untagged members of VLAN 10
    Ports 5 - 8 are setup in the switch as untagged members of VLAN 20
    Ports 9 - 12 are setup in the switch as untagged members of VLAN 30
    Ports 13-16 are setup in the switch as tagged members of VLAN 40 VLAN 50.

    Port 1 contains uplink to pfSense physical LAN interface 1
    Port 5 contains uplink to pfSense physical LAN interface 2
    Port 9 contains uplink to pfSense physical LAN interface 3
    Port 13 contains uplink to pfSense physical LAN interface 4

    LAN 1 interface has DHCP server handing out IP's in the following subnet: 192.168.10.0/24
    LAN 2 interface has DHCP server handing out IP's in the following subnet: 192.168.20.0/24
    LAN 3 interface has DHCP server handing out IP's in the following subnet: 192.168.30.0/24
    LAN 4 has two virtual interfaces (one for VLAN 40, one for VLAN 50), one handing out IP's in the following subnet: 192.168.40.0/24, the other handing out IP's in the following subnet: 192.168.50.0/24.

    Ports 2, 6, and 10 contain an edge device (e.g. a PC). Ports 14 -15 contains Ubiquity Unifi AP each.

    Here are my questions:

    1) You had mentioned that one should not mix tagged and untagged traffic above. What happens if both tagged and untagged traffic is required to flow to/from a edge device? For example, looking at the setup on ports 13 - 16 where there are two virtual interfaces on the pfSense box (VLAN 40 to handle restricted wireless and VLAN 50 to handle guest wireless traffic). I thought from what I read that to admin the Unifi AP's traffic would be untagged, and only tagged traffic would flow to the respective SSID's on the AP?
    2) Also what if a Ubiquity cloud key was added to e.g. port 16 to help with administration purposes of the Unifi APs? I'm not sure that device would tag its traffic necessarily.

    In general, I'm not quite sure how administration of these AP's would work, including when something like a cloud key is added.

    However, would this work? The only thing I can think of is that ports 14-16 could then also become untagged members of e.g. VLAN 10 (or 20, or 30), which would mean that the AP's would get administration IP's from VLAN 10 and the cloud key would also get an IP in VLAN 10. Thus the AP's can be administered from VLAN 10's, but actually traffic flowing to the restricted wireless and guest wireless would flow as tagged traffic from LAN 4 interface on VLAN 40 and/or VLAN 50. This would make sure that only tagged traffic flows from LAN interface 4 on VLAN's 40 and 50, and untagged traffic would be on a VLAN that only has untagged traffic (e.g. VLAN 10). In sum:

    Port 13: Tagged member of VLAN 40 & VLAN 50
    Ports 14 - 16: Tagged members of VLAN40 & VLAN 50; Untagged members of VLAN 10.

    Would this work? If I understand right, it makes sure that untagged/tagged traffic is not mixed through the same physical interface.

    Thanks again.
     
    Last edited: Feb 19, 2017
  16. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    I forgot about that particular quirk of the Ubiquity APs. So, this is one of those instances where rules will unavoidably be broken, at least on that last link to the AP.

    You'll have to decide where you want the Ubiquity AP's management interface to live. It's two wireless interfaces will be on 192.168.40.x and 192.168.50.x, but where will the AP itself live? You could either construct a new management LAN running off 192.168.1.x, or you could put it on the same subnet as LAN 1, 2 or 3.

    Similarly, if you set up a new management LAN, you'll have to decide whether it will run as an untagged VLAN 1 everywhere, or if you'll assign a new VLAN ID to the management LAN.

    We're venturing into things I'm not certain of here, but the potential problem with using VLAN1 is that you probably can't isolate it very well. At least on my switch, every port is an untagged member of VLAN1. If you configure a particular port's PVID as, e.g., 50, then untagged frames will get tagged as 50. But, if someone comes along and plugs in a computer that specifically tags its own frames as VLAN1, I think the switch will happily accept them and route them onto the management LAN.

    The alternative, which is I think where you were headed, is to treat LAN 1 as your management LAN, running of VLAN-10. In this case, you'll want to make sure:
    • Switch Port 1 (to pfSense LAN-1) is untagged VLAN 10, and a PVID of 10
    • Switch Ports 14/15 (to APs) are untagged VLAN 10, and tagged VLAN 40, 50, with a PVID of 10.
    • Switch Port 16 (to Cloud Key) is untagged VLAN 10, with a PVID of 10.
    • Create firewall rules allowing bidirectional traffic between Cloud Key IP and the 192.168.40.x and 192.168.50.x subnets.
    • You may need to use your PC on switch port 2 to access the Cloud Key webAdmin page, or create some new rules to access the Cloud Key from the other subnets.
    Yes, this does mean tagged and untagged traffic is mixing. You can't avoid it, but this limits the mixing to only VLAN-aware network devices, which should be able to handle it fine.

    Sorry- you're just going to have to play around with that one. I looked at the user guide briefly, and it wasn't obvious where it has to live. Because the Ubiquity APs are meant to support remote administration, it shouldn't particularly matter where the Cloud Key is. The important thing is you need to allow communication between the Cloud Key and the APs (to avoid potential problems, I'd allow it both directions), and you need to be able to connect to the Cloud Key from your PC in order to access the webAdmin page. In order to support certain functionality (e.g., captive portal), I expect, but don't know for certain, that wifi clients will also need to be able to reach the Cloud Key.

    Given that, I'd probably put it on the same untagged VLAN as the Ubiquity AP. The Cloud Key probably isn't VLAN-aware, so it doesn't really matter what its on a port with VLANs 40 and 50 tagged.

    Nor do I. But, plenty of people are able to set these things up. I don't think it will be that hard. It's just hard to plan it out entirely as a paper exercise.


    Yep. I only glanced at this before I wrote my response above. I wanted to see if we'd come up with the same thing. It looks like we did, except that I doubt the Cloud Key is VLAN-aware, so there's no reason to make Port 16 a tagged member of 40 and 50. Instead you'll have to poke some holes in the firewall to let the wifi devices get to the Cloud Key.
     
  17. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14.

    Since the AP's would get IP's on VLAN 10 (for administration), and the cloud key is also on VLAN 10, I wonder if that's sufficient for things to work properly (i.e. there' s no need to create additional rules to allow traffic between VLAN 40 and VLAN 10 and VLAN 50 and VLAN 10). Agree with you though that port 16 should be untagged for the cloud key to work. So it would be:

    Port 13: Tagged member of VLAN 40 and VLAN 50
    Port 14-15: Tagged member of VLAN 40 and VLAN 50; untagged member of VLAN 10 (for AP administration)
    Port 16: Untagged member of VLAN 10 (for cloud key/administration)

    The only question remaining is whether Port 13 would need to be a trunk port. I believe since it's already tagged as part of VLAN 40 and VLAN 50, that should be sufficient don't you think?

    ----------------------------------------------------

    Also I appreciate your explanation regarding firewall rules. I think what I didn't understand was that the rules are applied to incoming traffic as seen by the pfSense box.

    So, here's a simple example with 2 VLAN's and 2 gateway (LAN) interfaces:

    VLAN 10 connected to pfSense on (physical) LAN interface 1
    VLAN 20 connected to pfSense on (physical) LAN interface 2

    If I wanted to let VLAN 10 traffic through to VLAN 20 and let VLAN 10 traffic through to the internet (i.e. to look up a web site), I wouldn't have to change anything and just allow the default pass rule on the LAN 1 interface. If I wanted to block traffic originating from VLAN 10 going to VLAN 20, I would add a block/deny rule for VLAN 20 subnet followed by the pass rule (for all other traffic) on the LAN 1 interface. This would make sure that traffic destined for VLAN 20 is blocked at the LAN 1 interface, and all other traffic (e.g. traffic for a web page lookup) is allowed to pass through. However, if I wanted NO traffic to ever flow between VLAN 10 and VLAN 20 I would also have to add a rule on VLAN 20 to block traffic to VLAN 10 on the LAN 2 interface. Otherwise, even though VLAN 10 can't initiate a connection to VLAN 20, VLAN 20 can still initiate connection with VLAN 10.

    Now, if I only wanted VLAN 20 to be able to communicate with other devices also on VLAN 20, would I add a allow/pass rule for the VLAN 20 subnet, followed by a deny/block all rule on the LAN 2 interface? This would make sure that the only traffic allowed through LAN 2 is traffic that is going to other devices to VLAN 20. I'd also need to add a block/deny rule in VLAN 10 for VLAN 20 on the LAN 1 interface. Otherwise, even though traffic originating from VLAN 20 can only be to other VLAN 20 devices, a VLAN 10 device could connect to VLAN 20 (unless it was explicitly blocked from doing so at VLAN 10 interface).

    Does the above make sense, or am I still missing something?

    Thanks again for all your help.
     
  18. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    You'll need to create firewall rules between VLAN40/50 and VLAN 10 if you want to use things like Captive Portal on the Ubiquity (of course, you could always use Captive Portal on pfSense if you wanted to to go that route). There may be other things, but that's the main thing I saw that jumped out. If you know you're not going to use Captive Portal on the Ubiquity, you can keep traffic blocked between those VLANs.

    Just remember, you may have to create blocking rules in the firewall config. Be sure to check what rules get automatically created at the start.

    Looks right to me.

    Port 13 is already tagged with two VLANs, so you would consider it a trunk port. It shouldn't need to be on VLAN 10, if that's what you mean.

    Speaking of Port 13, I'd just keep the PVID set to 1 on that port. That shouldn't ever happen, though, as pfSense will know to tag everything as 40 or 50.


    I made a point to emphasize that because it was about a year before I realized that's the way they worked. It went against my original intuition.

    You'll have to see what rules pfSense creates by default. pfSense creates certain default rules for WAN interfaces, and different default rules for LAN interfaces. I'm not sure if it's going to give you default LAN rules, if you'll start with a blank set.

    But yes, the description you provided of the rules you'll need is correct.

    You shouldn't need to create a pass rule to allow VLAN 20 devices to be able to talk to each other. That traffic isn't going to go through pfSense- it's just going to stay on the switch. If I was really going to do that, I might create explicit rules just as a way of keeping track of my intent (so, a Pass rule for destination VLAN-20 subnet, following by a Block rule for everything). Keep in mind, this means VLAN 20 devices wouldn't be able to get out to the Internet, as the default Block rule at the end would block that traffic.

    And yes, if you've allowed traffic to flow to the VLAN20 subnet from the LAN-1 interface, then VLAN10 devices would be able to connect to VLAN-20 devices, even if the VLAN-20 devices themselves are isolated through blocking rules on the LAN2 interface.
     
  19. Floppyman

    Floppyman Administrator Staff Member

    Joined:
    Mar 10, 1999
    Messages:
    7,608
    Thanks @reggie14 - it all makes a lot more sense now.

    In your case, do you use the captive portal on pfSense for your guest wireless network (since you have Asus routers as AP's), or do you do something else? If given the choice between Ubiquity's captive portal and pfSense's captive portal, is there any preference to one or the other? In any case, I do understand that if one wanted to use the Ubiquity captive portal on the Unifi AP's, then some firewall rules would have to be set to allow the associated traffic to flow between VLAN 10 and VLAN's 40/50.

    Speaking of captive portal's themselves, is one absolutely necessary on a guest wireless network? Under what conditions would one use it, or decide not to use it? More specifically, can you explain a little bit more why it makes sense to run a Radius server and use radius authentication for captive portals (for e.g. wireless guest networks)?

    Thanks again for all your help and patience - these last few days have been quite a crash course for me on this terminology and how these systems work, but I'm finally coming up the learning curve now. :)
     
  20. reggie14

    reggie14

    Joined:
    Feb 1, 2015
    Messages:
    570
    I set up Captive Portal in pfSense just to try it out, but I don't use it. The main thing I wanted to do was have different usernames/passwords for guests, and I think using WPA2-Enterprise is a much better way to do that than Captive Portal. At one point, I set up a rate limiter on my guest network which limited individual clients to 25mbps. Beyond those two things, what more would I want?

    The main thing I'm missing, as far as I can tell, is the ability to do time-based access controls. With Captive Portal, I could set up an account that would only work from 8AM-11PM. I can't do that just with WPA2-Enterprise and FreeRADIUS. While I can understand that there might be situations where that is useful, I don't personally have much of a use for it.

    Having never used a Ubiquity, I can't tell you about their Captive Portal. But, if you were to use it, yes, your VLAN40/50 devices would need to be able to talk to your Cloud Key on VLAN 10. They don't need full access to everything on VLAN10. You could set up a firewall rule that would only let them talk to the Cloud Key IP address on the VLAN 10 subnet.

    Finishing my thought above, there's one other big thing I like about using WPA2-Enterprise with a Radius server: wireless clients can't spy on each other. On a regular WPA2-PSK network, anyone that has your wifi passcode can sniff and decrypt traffic. The same isn't true on WPA2-Enterprise. It's not even true when two people share the same username/password: they still can't decrypt each other's traffic without doing a much more complicated attack. This is a great property to have on a wifi network, and not one you can get with Captive Portal alone.

    I really think Captive Portals should just die in favor of everything supporting WPA2-Enterprise. But, part of the problem is that support for more complicated access rules are a bit more limited, since you'd be pushing access control enforcement to the Access Points themselves, rather than being able to consolidate access control decisions and enforcement at the Captive Portal. I think that's part of the reason you still see them in some environments. But, you won't see them in enterprise environments, typically, because they have fancier APs and radius servers that can do that sort of thing.

    I'm not sure what your Ubiquity can do, but if I remember correctly, I don't think freeradius on pfSense supports the commands necessary to do things like time-based access control.