Inter-VLAN Ping Blocked by Windows Firewall, Not the UCG

When you're learning VLANs and firewall rules for the first time, there's nothing more frustrating than doing everything "right" and still hitting a wall. That's exactly where this customer found themselves, deep in a home lab setup, trying to get two networks to talk to each other and getting nowhere.

The Problem

The customer was building out a segmented network using a Unifi UCG Ultra as the router and firewall, paired with an Aruba 2530 POE+ switch. The setup was thoughtful: a default network on VLAN 1, and a separate Camera VLAN 20 meant to eventually host an NVR and IP cameras. To test things out before committing real hardware, the customer had two laptops standing in, one plugged into the switch on the default VLAN, the other simulating a camera on VLAN 20.

The VLANs were defined on both the UCG and the switch, and the ports were configured correctly. On the UCG, VLAN 20 had Isolate Network and Block Internet Access enabled, and the customer had added two firewall rules on top of the default ones, both set to ACCEPT LAN In traffic between the Default Network and the Camera Network, in both directions, with no traffic state matching specified.

On paper, this should have opened things up wide between the two VLANs. But it didn't work that way. Pings from the Camera VLAN to the Default VLAN went through fine. Pings from the Default VLAN to the Camera VLAN failed every time. The customer had already tried digging through forums and got some helpful pointers, but as they put it, none of it was really "clicking." What they wanted wasn't another wall of text to parse through, but a live, collaborative session where someone could walk through the configuration with them in real time and explain the "why" behind each step.

The Approach

That's where Jorge came in. This ticket was a great fit for the kind of hands-on, screen-share troubleshooting that Rogue Support's networking category is built for. Instead of firing off written instructions, Jorge got on a call and worked through the setup live with the customer, exactly the kind of collaborative session they'd asked for.

Troubleshooting inter-VLAN firewall rules is one of those areas where the logic can look perfect on the firewall itself, but the actual failure point ends up somewhere else entirely. Rather than assuming the UCG rules were the culprit, Jorge worked methodically, verifying the VLAN configuration, checking the switch port assignments, and confirming the firewall rules were structured the way the customer intended. From there, it became a process of isolating where the traffic was actually getting dropped, rather than where it was assumed to be dropped.

The Solution

As it turned out, the UCG firewall rules the customer had written were fine. The real issue wasn't the network configuration at all. It was Windows Firewall on the laptop simulating the primary default-network device, quietly blocking the inbound ping requests before they ever got a chance to reach the "camera" laptop and generate a response.

It's a classic case of a problem hiding in plain sight. The customer had built a logically sound VLAN and firewall setup, and the instinct was to keep re-examining the UCG rules over and over. But the real fix had nothing to do with VLANs, inter-VLAN routing, or firewall zones on the router at all. It came down to host-based firewall settings on the test device itself.

Once that was identified and adjusted, traffic flowed exactly as expected in both directions. Pings went from the Default VLAN to the Camera VLAN and back without issue, confirming the underlying VLAN segmentation and firewall rules had been correct all along.

The Outcome

With the core connectivity working, the customer now has a clear path forward for the next phase of the project: tightening those firewall rules to match traffic state (New from the Default Network, Established/Related back from the Camera VLAN) so the NVR can initiate contact with the cameras without the reverse being true. That's a natural next step once the fundamentals are confirmed working, and having watched Jorge troubleshoot it live gives the customer a much better foundation for making those adjustments with confidence.

The review says it all. The customer noted, "Jorge was great and resolved my issue. I ask a lot of questions and he didn't get annoyed and was patient with me, which I appreciate. I look forward to working with him again." They even added a line that a lot of home networkers will relate to: "Screw you, Windows Firewall!"

It's a five-star result, and a good reminder that networking issues aren't always where they seem to be. Sometimes the fix isn't in the router config at all, it's on the endpoint you least suspect. Having someone experienced on the call, asking the right diagnostic questions instead of jumping straight to conclusions, is often the difference between hours of frustrated trial and error and a one-hour session that actually gets to the root cause.

This is exactly the kind of ticket Rogue Support is built for. Whether it's VLAN segmentation, firewall configuration, wireless setup, or VPN troubleshooting, customers submit what they're dealing with, vetted technicians bid on the work, and the customer picks who they want to work with. For hands-on learners who want to understand their own network rather than just have it fixed for them, a live remote session with a patient, knowledgeable tech like Jorge can make all the difference.