It is good practice to work our way down on the OSI network model, which means starting at the Physical Layer. You should check your cabling, and if necessary, you should replace suspect cabling with known good cabling. Having a working time-domain reflectometer, which can be used to locate discontinuities in a network cable, can be helpful in checking cabling.

The next step is to make sure that the ports are functioning. Even if they are physically functional, the layer 2 protocol (Data Link Layer) may not be running on the ports you are using. On a Cisco switch, you can use the no shutdown command to restart a disabled port. You might also have a speed mismatch between the switch and the router; for example, the switch may be 1 Gbps, while the router might be 100 Mbps. For this reason, it is generally a good idea to have auto-negotiation set on both sides.

Once you have confirmed that you have physical connectivity, that the ports are enabled, and the port configuration is correct, you should confirm the following:

There are aspects of switch configuration that are peculiar to different brands and models of switches, so you will want to consult any documentation the switch manufacturer has provided. Doing a web search to see if there are any issues specific to your switch may be helpful. Cisco switches have copious amounts of documentation, and administration of these switches is a topic too involved to be fully addressed here. If you want to pursue it, though, there are books, tutorials, and even professional certifications you can obtain to demonstrate your proficiency in Cisco switch configuration.

Trunk port configuration is relatively easy. You need at least one trunk port per switch (some switches assign trunk ports in pairs), and these ports will be available for connections to the router and to other switches. With some switches, the trunk port configuration can be done after the VLAN is configured; in other cases, setting up the trunk ports is a prerequisite to setting up a VLAN. You should confirm that the VLAN is active on the trunk, and that packets from the VLAN are allowed on the trunk.

Configuring access ports should be simple as well. You need to assign the correct VLANs to the ports. In addition, you need to have the correct settings for VLAN tagging. Keep in mind that packets entering the access ports should be untagged – inbound packets should be ordinary Ethernet frames, unless they are double-tagged – whereas ports leaving the trunk ports should be tagged, so the router and switch know to which VLAN the packet belongs.

Another configuration element to consider is the PVID, or Port VLAN ID, which is the default VLAN ID for a port. Some managed switches require the PVID to be set in order for VLANs to work at all. If you cannot get your VLAN to work, and you have verified physical connectivity, you may try configuring the PVID for the ports you are using. The PVID settings for the access ports should mirror the access port VLAN assignments you made when you initially configured the VLAN on the switch.

Once you have confirmed that the switch is configured properly, you should log in to pfSense and confirm that pfSense's VLAN configuration is correct. First, go to Interfaces | (assign), click on the VLANs tab, and confirm that the VLAN IDs for the created VLANs correspond to the VLAN IDs configured on the switch or switches. Then click on the Interface Assignments tab and confirm that the VLAN IDs are assigned to the correct interfaces.

If you are using DHCP or DHCPv6, you should confirm that the DHCP/DHCPv6 server is running on the VLAN interfaces and that they are configured correctly. If you have any doubts, you could try a static IP configuration on one of your nodes and see if you are able to access the VLAN (just remember to choose an IP address outside of the range of addresses assigned by the DHCP server). If you are using DHCPv6 and you have any doubts as to the IPv6 compatibility of either your switch or operating system, you might want to try DHCP first.

You may have a situation in which nodes can connect to the VLAN, but have no Internet connectivity and may not be able to access other subnets at all. Keep in mind that VLANs, like traditional networks, need to be configured so that they have access to other networks. Other than the LAN, for which pfSense creates a default allow LAN to any rule, the default for any newly created network is to have all access to other networks blocked. Therefore, you must go to Firewall | Rules and create a rule to allow the VLAN to access the WAN interface. As mentioned earlier, an easy way of doing this is to use the rule Copy option and change a rule for another interface by changing the Interface and Source fields to match the VLAN for which you want to create the rule.

The default setting for NAT in pfSense is for automatic outbound rule generation. If you are in this mode of NAT rule configuration, the NAT outbound rules are created automatically and you don't have to configure any NAT rules. If you are using manual outbound rule generation, however, you will have to create rules for each of the VLANs you have created. You may be using manual outbound rule generation if you had to create outbound NAT rules in order to connect to a VPN server, so if you subscribe to a VPN service, you should check to make sure there are outbound NAT rules for your VLANs. You can do this by navigating to Firewall | NAT, clicking on the Outbound tab, and reviewing the rules there. One of the ways to avoid having to manually create rules is to utilize hybrid rule generation mode, in which pfSense still automatically generate rules, but you can also have manually created rules. To do this, select the Hybrid Outbound NAT rule generation radio button on the NAT Outbound tab and press the Save button below the radio buttons.

Here is a VLAN troubleshooting table that covers some of the common VLAN communication issues:

It might be helpful to provide a concrete example of a VLAN connectivity problem, so we will return to the developers and engineering VLAN scenario developed throughout the chapter, and present a pair of hypothetical problems.

Let's assume that node D1 on the developers' VLAN cannot access node D4, also on the developers' VLAN. D1 is on the first floor, while D4 is on the third floor. In this scenario, the developers' VLAN is on the 172.16.0.0 subnet, and D1 IP address is 172.16.1.101, while D4 IP address is 172.16.1.104. Switch S1 has an IP address of 172.16.1.1, S2 is 172.17.1.1, and S3 is 172.16.1.2. The relevant portions of the earlier VLAN diagram are presented here for convenience's sake:

Network diagram showing nodes D1 and D4. In our example, D1 cannot communicate with D4.

We start our troubleshooting at the Physical Layer, so first we find out if there are any connectivity issues. Once we rule out any problems with the physical cabling, we observe that since D1 and D4 are on the same VLAN, this is a layer 2 issue, and we can focus on troubleshooting the connections between each node and their respective switches, and the trunk link between S1 and S3.

Our first goal will be to verify connectivity between D1 and S1. This can be done by a simple ping command issued from S1, as shown in the following screenshot:

As you can see, we were able to successfully ping D1 from S1; the interfaces between them are configured correctly, and we can now begin to look at the link between S1 and D4, which we will do in the following screenshot:

Now we will try to ping D4 from S3:

The link between S3 and D4 is good, so now it looks like the problem lies between S1 and S3. If, however, the problem was between S3 and D4, you should do the following:

If the ping between S1 and D1 failed, then obviously the same troubleshooting steps would apply: we would need to confirm the VLAN is active on S1 and we need to confirm the VLAN is assigned to the port to which D1 is connected.

If the link between S1 and D1, and, S3 and D4 is good, then the problem is the link between S1 and S3 – in other words, the trunk. There is another switch (S2) between S1 and S3, and we should test the connectivity between S1 and S2 and S3 and S2 by running the ping command between each of them. We start by pinging S2 from S3, since we are already logged into S3:

It is starting to look like the problem might be the link between S3 and S2, but to be thorough, we try to ping S2 from S1:

If we had just assumed the problem was between S3 and S2, we might have focused on the trunk ports that connect those two switches. But since both ping tests failed, there is a good chance that S2 is not configured correctly to pass DEVELOPERS VLAN traffic at all, so we need to check this, and correct the configuration if necessary.

To resolve this issue, we need to consider the following: