802.3 Ethernet networks are based on the media access control method known as Carrier Sense Multiple Access /Collision Detection (CSMA/CD). According to this protocol, a signal sent out over the collision domain had to reach every part of the network within a specified amount of time. As a result, networks were limited to a few hundred meters in length. The advent of switches solved this problem by turning each switch into a separate collision domain. Having solved the collision problem, network engineers turned to another problem that, if solved, would yield a major improvement in network performance: reducing the amount of broadcast traffic.
It turned out that the solution to the problem was to eliminate the one-to-one relationship between the network and the physical interface that exists in traditional networking, in which users of a particular network are on the same physical interface. VLANs differ from this paradigm in that a single physical interface can have several networks, and a network can span more than one interface. This can be helpful for several reasons. First, it makes it easier to segregate network traffic. Normally, users on the same interface connecting through the same switch would be on the same subnet and therefore could communicate with each other. Yet we might have legitimate reasons for isolating one group of users from another. For example, half the users might be in the sales department and the other half might be in the marketing department. By separating these users into two separate VLANs, we can improve network performance and security.
Secondly, with VLANs, users on the same VLAN connecting through separate interfaces and separate switches is possible, thus making it possible to group together users who are on different interfaces and possibly even in different buildings. In fact, it is possible to set up VLANs so that certain users will automatically join a VLAN regardless of what port to which they connect. This gives us considerable flexibility in moving users around on the network as well as reducing the amount of administrative overhead. Without VLANs, we would have to ensure that a user who belonged to a specific network was connected to a specific switch, which could get challenging as users move around the building and networks get larger.
We will begin this chapter by introducing an example that will be repeated throughout the chapter: configuring separate developers and engineering networks. We will first consider how VLANs might make the task easier, and then use it as a concrete example in the configuration sections. This chapter contains the following topics:
- Basic VLAN concepts
- VLAN configuration at the console
- VLAN configuration in the web GUI
- VLAN configuration at the switch
- Troubleshooting VLANs
Before we consider the technical aspects of VLANs, it might be helpful to consider an example network, step back and consider how it might be implemented using a traditional networking model, then consider how the same network might be implemented with VLANs.
To illustrate the usefulness of VLANs, let's consider the simple case of a midsized company that has a software department and an engineering department. The software department occupies floors one and three, while the engineering department occupies floors two and four, and each floor has its own wiring closet with a switch connected to the company router. Let's also assume that we want to have separate networks for software developers and engineers, so that the developers can communicate with each other via the developers' network, and the engineers can communicate with each other via the engineering network, but the developers shouldn't be able to access the engineering network and engineers shouldn't be able to access the developers' network. The following diagram shows this setup:
This is what our network could look like without VLANs.
As you can see, accomplishing our goal of having separate networks for developers and engineers in a traditional network is somewhat difficult. The developers are not all on the same interface, and neither are the engineers. One possibility is to continue having a subnet for each floor: we could call the first floor network DEVELOPERS1, the second floor network ENGINEERING1, the third floor network DEVELOPERS2, and the fourth floor network ENGINEERING2. Then we set up firewall rules to allow DEVELOPERS1 to access DEVELOPERS2 and vice versa, and do the same for ENGINEERING1 and ENGINEERING2. This would be the easiest way of segregating the developers from the engineers with the current setup, but it still falls short of our goal of having one network for developers, and one for engineers. What we have actually done is set up two network groupings with two networks in each of them. Moreover, if our setup gets more complex (for example, in addition to the first four floors, we add developers and engineers to the fifth floor), it is going to be challenging to reconfigure our network.
Another possibility is to connect the first and third floor switches, and connect the second and fourth floor switches. In this scenario, each network has two switches, one of which is directly connected to the company router. The second switch will be connected to the first switch via the uplink port. As a result, the two switches will be on the same network, and we will achieve our goal of having separate networks for the developers and engineering. There are, however, some problems with this configuration:
- We will have to run cabling between the first and second switches for the developers and engineering networks. In a small enough office, this may not be a big problem. For example, assume that in our hypothetical network in the preceding diagram that the company router is on the second floor of the building, in the same wiring closet as the ENGINEERING1 switch. The engineering network requires no additional cabling, as we can just disconnect ENGINEERING2 from the router and connect it to ENGINEERING1 (which will remain connected directly to the router). Thus, all we need to do is run cabling between DEVELOPERS1 and DEVELOPERS2. Nevertheless, it is not difficult to see how this is not a very scalable configuration. If we double or triple the number of floors in our hypothetical, we can see how the time and cost of running additional cabling can add up.
- This solution is not very flexible, either. For example, if the company decides to move some of the developers onto the fourth floor, we will have to either put them on the same switch as the engineers (in which case they won't be on the developers' network), or we will have to add another switch for the developers.
Now let's consider how we would go about setting up different developer and engineering networks using VLANs. Again, each floor will have its own switch, except that the switch will be a managed switch, capable of processing VLAN traffic. There will be trunk lines connecting each switch with the switch on the floor above it (except for the fourth floor switch) and the floor below it (except for the first floor). The switch on the first floor will be connected via the trunk port to the company router. Again, we have a diagram of this configuration, as follows:
Our new and improved configuration.
The cost of setting up this VLAN may initially be higher, because we have to use managed switches, whereas in the non-VLAN scenario, we could have used unmanaged switches, which are typically cheaper than managed switches (although we will likely save some money on cabling). Our network is now much more scalable than before, as adding another floor to the network only requires (in addition to cabling to each node) an additional switch and trunk cabling to the switch on the previous floor. Moreover, on a managed switch, we can configure individual ports, so if management decides to move the software development and engineering departments around, we can just reconfigure ports on the switches. For a relatively small network, the benefits might not be that significant. But as you might have gathered, as our networks get bigger, using VLANs makes the task of configuring and maintaining networks much easier. And as we shall see later in the chapter, technologies such as Cisco's VLAN trunking protocol make administration even easier.
To summarize the most obvious advantages of VLANs, we have:
- The ability to easily segregate network traffic into different broadcast domains, which decreases bandwidth utilization and improves network performance
- Increased security from being able to easily segregate network traffic—even if two nodes are on the same switch, if they are on separate VLANs, they cannot talk to each other unless the router has been configured to grant them access
- The ability to create separate networks at a much lower cost than would be possible than with traditional networks, and with a greatly reduced workload for those tasked with setting up the network
But VLANs also have many other features not available via traditional networking. They include:
- The ability to double tag traffic, referred to as QinQ.
- The ability to prevent a host from communicating with any other host on the network (hosts will only be able to communicate with the default gateway). Such a configuration is known as a private VLAN (PVLAN), and allows the network firewall to gain a more granular level of control over traffic. Otherwise, hosts could not be prevented from communicating with another host on the same subnet, as the traffic never reaches the firewall.
VLANs are a layer 2 (data link layer) construct originally conceived of as a means of improving network bandwidth by allowing for multiple spanning trees on a network. This was accomplished by adding a special header, referred to as a tag, to every Ethernet frame. Each VLAN packet has a tag containing the VLAN ID for the VLAN to which it belongs, which switches and routers can then use to differentiate VLAN traffic. Several proprietary tagging mechanisms arose, but eventually the IEEE developed the 802.1Q standard for VLAN tagging. Although 802.1Q is not the sole encapsulation method for VLANs, it is the method supported by pfSense, and it is the tagging mechanism (sometimes referred to as the encapsulation method) with which we are primarily concerned in this chapter.
Because each frame has this four-byte 802.1Q tag attached to it, a VLAN Ethernet frame can be up to 1522 bytes. It can actually get even larger than this with QinQ tagging. This exceeds the usual maximum frame size for 1500 Maximum Transmission Unit (MTU) Ethernet. Not all network cards work well with these larger frames, and some will drop these larger frames, resulting in decreased network performance when VLANs are implemented. Therefore, it is a good idea to make sure your network cards are VLAN-compatible. Even if the chipset supports longer frames, the network cards particular implementation of the chipset may not properly support them.
In addition, any switch on interfaces on which VLANs are implemented must be VLAN-aware. Any managed switch manufactured since 2000 should do, but unmanaged switches will not. As is the case with network cards, you will want to do some research into choosing what switches to deploy on your network.
Each VLAN has a number between 1 and 4094: this is used as an ID. In order to set up a VLAN on your network, you will need one or more managed switches. On a managed switch that has not been configured for VLANs, every port can talk to every other port. These switches tend to either have VLANs completely disabled, or enabled with a default VLAN of which every port is a member. VLAN1 is designated as the default VLAN, and therefore it is recommended that you not use VLAN1. If you do, then there are potential security issues, as someone with physical access to the switches could plug a device into an unused port and have access to all the hosts in VLAN1. Even if a hacker doesn't have direct access to the switches, they will undoubtedly use the fact that VLAN1 is the default VLAN as a factor in formulating their attacks.
What VLAN naming convention should you use? Other than not using VLAN1, you can use whatever convention you choose. One common convention is to start with VLAN2 and increment by one for each additional VLAN. It is also commonplace to use the third octet of the IP address to match the VLAN ID: for example, for VLAN 2 we could have 192.168.2.0, for VLAN 3, 192.168.3.0, and so on. The same convention could be used with Class A and Class B private networks; for example, 172.16.2.0 or 10.1.2.0. Another common convention is to increment by 10 for each VLAN, starting with VLAN10. In this scenario, we would have VLAN10 and subnet 192.168.10.0; VLAN20 and subnet 192.168.20.0, and so on.
Each VLAN resides on a physical interface, which is known as the parent interface. When VLANs are created, they are assigned a virtual interface, with names such as VLAN0, VLAN1, and so on, similar to the device names for physical interfaces. The virtual interface names do not correspond to the VLAN IDs. You should not assign the parent interface of a VLAN to an interface, although you can. It should only function as the parent interface for whatever VLANs reside on it. In one case, in which the author negligently assigned the parent interface to a pfSense subnet, the web GUI became inaccessible, and the issue was only resolved when all assigned interfaces were deleted and reconfigured from the console. It has also been known to cause problems with switch configuration and captive portal configurations.
There are also some security issues related to VLANs. VLAN misconfiguration may result in users gaining access to networks to which they should not have access. Because of this possibility, it is considered good practice to keep separate networks of different trust levels. For example, it is generally not a good idea to put the WAN and LAN networks on the same interface, even though it is possible.
Attacks which attempt to gain unauthorized access to VLANs are known as VLAN hopping. One method, known as switch spoofing, involves spoofing a trunking switch by using the trunking/tagging protocols. The other method, known as double tagging, involves the attacker placing two VLAN tags on a packet. The outermost tag is for VLAN1 (the native VLAN). The inner tag is for the VLAN the attacker wants to access (for example, VLAN2). The attacker sends the packet to a host on VLAN2, which can only be accessed by hosts on VLAN2. The first switch sees the VLAN1 header, removes it, and forwards the packet. The next switch sees the VLAN2 header (visible now that the VLAN1 header was removed) and sends the packet to the host on VLAN2. Thus, the attacker was able to trick the switch into thinking that the packet originated on VLAN2.
The good news is that most of the attack vectors involving VLANs can be mitigated—or even eliminated entirely—through proactive switch configuration. For example, disabling auto-negotiation can eliminate switch spoofing, and not placing hosts on the native VLAN can eliminate double tagging. Nonetheless, you should be aware of possible security issues related to your hardware and network configuration.
You will want to do some research to see what degree of security testing switches have undergone before making a purchase, and you should ensure that you are running the latest firmware.