When VLANs Go Silent: Troubleshooting Network Isolation Between UniFi and Proxmox

A deep dive into debugging inter-VLAN routing failures across virtualized infrastructure

---

I recently spun up a new k3s cluster in my Proxmox environment and hit a wall that took longer to diagnose than I’d like to admit. The VMs could reach the internet, talk to each other, and even grab DHCP leases — but I couldn’t ping them from my workstation. What followed was a methodical journey through layers of network abstraction, uncovering not one but three stacked misconfigurations.

Here’s how I approached it, what I found, and what I learned.

The Setup

• UniFi Dream Machine Pro running Network 10.0.162
• Proxmox VE with VLAN-aware Linux bridges
• k3s cluster on VLAN 145 (10.88.145.0/24)
• Workstation on a separate VLAN (10.88.135.x)

The goal was simple: isolate the k3s nodes on their own VLAN while maintaining reachability from my management network.

The Symptoms

The k3s VMs were functional — they received IP addresses via DHCP, could reach the internet, and communicated with each other. But from my Mac:

ping 10.88.145.180
# Request timeout

Classic inter-VLAN routing failure. Or so I thought.

Layer 1: Start at the Gateway

My first instinct was to verify basic routing. Could I reach the VLAN’s gateway?

ping 10.88.145.1
# 64 bytes from 10.88.145.1: icmp_seq=0 ttl=64 time=4.780 ms

Gateway responds. Good — that rules out a complete VLAN misconfiguration. The UniFi gateway knows about this network and has an interface on it.

Next, a traceroute to one of the k3s nodes:

traceroute 10.88.145.180
# 1  unifi.localdomain (10.88.135.143)  3.706 ms
# 2  unifi.localdomain (10.88.135.143)  3162.056 ms !H  3116.137 ms !H

That !H flag is critical — it means “Host Unreachable,” and it’s coming from my gateway. The UDM-Pro is actively refusing to forward the traffic, not just failing silently.

Layer 2: The Zone-Based Firewall

UniFi Network 10.x introduced zone-based firewalling. Networks are assigned to zones (Internal, DMZ, Hotspot, etc.), and firewall rules operate zone-to-zone.

I checked the K3S network settings:

• Zone: Internal ✓

And the firewall rules showed:

• Internal → Internal: Allow All Traffic ✓

So the zone assignment was correct and the rules were permissive. Not a firewall issue.

Layer 3: The VLAN ID That Wasn’t

Digging into the network configuration, I found this:

VLAN ID: Auto

There it is. When set to “Auto,” UniFi doesn’t assign an explicit VLAN tag to the network. This creates a subtle problem: Proxmox was tagging VM traffic as VLAN 145, but UniFi’s network wasn’t configured to recognize that VLAN ID.

Fix #1: Changed VLAN ID from “Auto” to “145” (Manual).

Reprovisioned, waited 60 seconds, tested again:

traceroute 10.88.145.180
# 2  unifi.localdomain (10.88.135.143)  3162.056 ms !H

Still blocked. The VLAN ID was necessary but not sufficient.

Layer 4: Into Proxmox

Time to check the virtualization layer. On the Proxmox host:

ip addr show vmbr1
# inet 10.88.145.0/24 scope global vmbr1

Wait — 10.88.145.0? That’s the network address, not a valid host IP.

In a /24 subnet:

• 10.88.145.0 — Network address (reserved)
• 10.88.145.1 — Gateway
• 10.88.145.2-254 — Usable host IPs
• 10.88.145.255 — Broadcast address

The Proxmox bridge had an invalid IP, which was likely causing routing confusion.

Fix #2: Changed vmbr1’s address from 10.88.145.0/24 to 10.88.145.2/24.

But we weren’t done yet.

Layer 5: The Bridge to Nowhere

Checking /etc/network/interfaces:

auto vmbr1
iface vmbr1 inet static
        address 10.88.145.2/24
        gateway 10.88.145.1
        bridge-ports
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

See it? bridge-ports is empty. This bridge had no physical NIC attached — it was completely isolated from the physical network. The VMs could talk to each other (same bridge) and somehow DHCP worked (broadcast traffic finds creative paths), but there was no actual uplink to the switch.

Looking at the working bridges:

# vmbr0 - Management network
bridge-ports nic0

# vmbr2 - Sentinel-Forge VLAN 150
bridge-ports nic0.150

The pattern was clear: use VLAN subinterfaces on the physical NIC.

Fix #3: Added the physical uplink with VLAN tagging:

auto vmbr1
iface vmbr1 inet static
        address 10.88.145.2/24
        gateway 10.88.145.1
        bridge-ports nic0.145
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Applied the changes:

ifreload -a

The Result

ping 10.88.145.180
# 64 bytes from 10.88.145.180: icmp_seq=0 ttl=64 time=1.234 ms

Finally.

The Full Picture

Three issues, stacked on top of each other:

Layer	Issue	Symptom
UniFi	VLAN ID set to “Auto”	Gateway couldn’t associate tagged traffic with the network
Proxmox	Bridge IP was 10.88.145.0 (network address)	Invalid host configuration
Proxmox	bridge-ports was empty	No physical path to the switch

Each issue alone might have presented differently. Together, they created a situation where:

• DHCP worked (broadcast traffic is resilient)
• Internet access worked (NAT outbound is forgiving)
• Intra-VLAN communication worked (same bridge)
• Inter-VLAN routing failed completely

Lessons Learned

1. “Auto” is not your friend. Explicit VLAN IDs prevent ambiguity between your switching infrastructure and hypervisor.

2. Verify every layer. The problem looked like a firewall issue (gateway returning !H), but the root causes were in VLAN tagging and bridge configuration.

3. Check the basics twice. An empty bridge-ports line is easy to miss when you’re focused on firewall rules.

4. Broadcast vs unicast behaves differently. DHCP working doesn’t mean your network is correctly configured — it just means broadcast found a path.

5. Document your bridge patterns. Having a consistent convention like nicX.<vlan-id> for VLAN subinterfaces makes future VLANs trivial to add.

Template for Future VLANs

For the next VLAN I add, the checklist is:

UniFi:

• Create network with explicit VLAN ID
• Assign to appropriate zone (Internal for trusted networks)
• Verify switch port profile trunks the VLAN

Proxmox:

• Add bridge with bridge-ports nicX.<vlan-id>
• Use valid host IP if Proxmox needs network access
• Set bridge-vlan-aware yes
• Configure VM NICs with appropriate VLAN tag

---

Learn More About Cortex

This VLAN setup was needed for the K3s cluster deployment documented in the companion post Deploying a Complete SIEM Stack to K3s Using AI Agents. See how Cortex orchestrated the entire deployment through the Proxmox API once the network was fixed.

---

Now if you’ll excuse me, I have a k3s cluster to configure.