3 of 5 VLANs Down on Switch Ports — Back Online in 90 Minutes

When three out of five VLANs stop working on wired connections but work perfectly fine over WiFi, most people assume the switches are broken. As this case study shows, the real problem was hiding somewhere much less obvious, and it took a technician who understood the full stack, pfSense, the Netgate SG-1100, and UniFi's software defined networking, to track it down.

The Problem

The customer had a fairly sophisticated home network setup: a Netgate SG-1100 running pfSense as the router and firewall, two UniFi switches, and two access points, all tied together in a software defined network. Five VLANs were configured to separate traffic by function: a default LAN network for infrastructure, a Home VLAN for general devices like tablets and TVs, a Secure VLAN for servers like Home Assistant and NAS devices, an IoT VLAN for smart home devices, and a Camera VLAN for wired security cameras.

Two of the five subnets worked exactly as expected, both over WiFi and on wired UTP ports across both switches. But the other three had a strange and inconsistent problem. The Home VLAN and the LAN default network would hand out proper IP addresses and internet access over WiFi, but the moment a device was plugged into a UTP port on either switch, it would get an APIPA address in the 169.254.x.x range, the telltale sign of a device that can't reach a DHCP server. No IP, no internet, nothing.

The IoT VLAN had it worse. That network was never meant to run over WiFi at all, it was designed purely as a wired connection for smart switches, outlets, and sensors. But since it was failing on every UTP port on every switch, there was effectively no way to use it at all.

The customer had already gone two rounds trying to get help. UniFi's own tech support couldn't resolve it, and pfSense support wanted to charge extra for an upgraded service plan just to look at it. That's a frustrating spot to be in when you know the network is misconfigured somewhere, but you don't have visibility into where the tagging or trunking is breaking down.

The Approach

This is a classic VLAN tagging problem, but the tricky part is that it wasn't uniform. Two VLANs worked everywhere, three didn't work on wired ports at all. That kind of split points toward something in the switch port profiles or trunk configuration rather than a router-wide pfSense issue, since if pfSense itself were broken, WiFi wouldn't have worked either.

Lance came in already familiar with both halves of this puzzle, the pfSense/Netgate side and the UniFi SDN side. That combination mattered here. A tech who only knows pfSense might get lost in UniFi's port profile system, and a tech who only knows UniFi might not think to check how VLAN interfaces and DHCP scopes are set up on the firewall. Solving this required someone comfortable moving between both systems and understanding how tagged and untagged traffic needs to be handled consistently across the entire chain, from the SG-1100, through the switch trunk ports, down to each individual access port.

The Solution

Working through the network's VLAN configuration, Lance identified why the wired ports were failing to hand out proper IPs while WiFi worked fine. This kind of symptom, working wirelessly but failing on copper, almost always comes down to how individual switch ports are tagged versus how the SSIDs are mapped to VLANs on the access points. The APs were clearly passing tagged traffic correctly, but something in the switch port assignments wasn't matching up for the wired side.

In an hour and a half, Lance worked through the switch and firewall configuration and corrected the mismatch, restoring proper DHCP assignment and connectivity on the wired ports for the Home VLAN, the LAN default network, and the previously unusable IoT VLAN.

The Outcome

The results speak for themselves. The customer's review didn't hold back on the relief this brought: "He fixed the problem that UniFi Tech support could not or would not fix and pfSense Tech Support would look at without purchasing an upgraded service plan." That's a meaningful outcome. Two vendors, each responsible for half the equipment in this setup, either couldn't or wouldn't dig into the issue, and it took someone who understood how the pieces fit together to actually solve it.

The customer also noted that Lance "was very familiar with both pfSense + firewall software, the Netgate SG-1100 router and UniFi Software Defined Network switches," which is exactly the kind of cross-platform expertise that networking problems like this demand. VLAN and trunking issues rarely respect the boundary between one vendor's support desk and another's, so having a technician who can see the whole picture, from firewall rules down to individual switch ports, made all the difference.

The session wrapped up in 1.5 hours with a 5 out of 5 star rating, and the customer said plainly, "I will be requesting Lance on future service requests." For a home network running five separate VLANs across routing, switching, and wireless infrastructure, that kind of continuity with a technician who already understands the setup is worth a lot.

This case is a good reminder of why networking problems, especially ones involving VLANs, tagged trunks, and multi-vendor equipment, often need a technician who can move fluidly between systems rather than a single vendor's support line. That's exactly what Rogue Support is built for. Customers post their ticket, vetted technicians with real hands-on experience bid on the job, and the customer picks who they want to work with, all on their own schedule, entirely remote, at a straightforward $120 an hour.