My VLANs are not talking (to each other)

[HankB]

Edit: I did get replies on Reddit and it seems that I need to add firewall rules to allow traffic between VLANs. I must have misunderstood the suggestions that this would work by default. (I did notice that the LAN subnet could talk to the VLANS by default, perhaps that's what I was reading.)

best,

Good morning

I'm still onboarding with OPNsense (having run pfSense for nearly 10 years.) I've just reinstalled from scratch to avoid any issues lingering from the many configuration changes I've made and unmade (and messed up.)

My H/W is a mini PC presently connected to my home LAN with a TP-Link TL-SG108E switch downstream. I want at a minimum one VLAN to isolate IoT devices. Two principles have guided my VLAN configuration:

* I have read in multiple places that it is bad practice to mix tagged and untagged traffic on the same (host port? switch port?)
* I also have read that by default, traffic is allowed between VLANs.

VLANs have been an incredible challenge for me. It took me too long to figure out that I just needed to copy the config I use for the switch (same as above) to the one connected to the OPNsense host. (Age has its benefits but this is not one of them.) I've also had a *lot* of difficulty losing access to the management web interface, which I usually fix by going to the console and resetting to default config or reassigning interfaces or IP addresses. That's not fun. (BTW, my pfSense install has worked with a single VLAN to isolate IoT devices from my other stuff.)

At present I have the following configuration:

* LAN - the default and where the web UI seems to reside. DHCP for IPv4 configured. One port on the switch remains not assigned to tags 10 or 20. (management port, for now.) Another port (the trunk?) is associated and tagged for both 10 and 20 and is connected to the LAN port on the router.
* IoT - tagged 20, two ports on the switch assigned and untagged. DHCP for IPV4 configured
* main - tagged 10, four ports assigned on the switch and untagged. DHCP for IPV4 configured
* WAN - Gets its IP from upstream (pfSense) via DHCP.e WAN port seems to be getting an IPV6 address but I'm leaving IPV6 for the 'main' VLAN for later.)

Both VLANs seem to be working as expected WRT DHCP. Hosts, the switch and a spare WiFi AP all get IP addresses on either.

Connecting a host to the untagged and unassigned port gets an IP from that respective pool. At the moment this is the only port from which I can connect to the web management site.

I cannot ping between the two VLANs. Worse, hosts on the VLANs cannot access the web configuration. (Aside: I'd be happy to perform configuration from the console but I'm not familiar enough with FreeBSD to be able to do that. And IAC I suspect the closest thing to a sensible way to do this would be to directly edit the config.xml.)

During a previous iteration I tried adding firewall rules to facilitate passage of traffic between VLANs even though they seemed redundant and they seem to make no difference.

My searches on this subject tell me:

* It should just work.
* Driver issues could cause problems (This mini-PC has Realtek Ethernet which otherwise seems to be working.)
* Firewalls or policies on the hosts can block traffic. Both hosts I'm using for testing are running Debian (one on an X86 laptop, the other on a Raspberry Pi) and I'm 99% certain they have no firewall installed. On my existing LAN they both communicate with hosts on the IoT VLAN from the primary LAN.

I'm running out of ideas. One thought I have is to eliminate the 'main' VLAN and just have the IoT VLAN for IoT devices and use the LAN for other stuff, but that seems to go against guidelines I have read.

Any other suggestions are most welcome!

[EricPerl]

With these switches (not truly managed, classified as smart-easy), I'm afraid you should ignore the guidance regarding mixing tagged and untagged traffic.
They don't support designating a VLAN for their own management (accessing the web GUI used to configure ports).
I suspect you could work around this (e.g. static IPs and a dedicated port) but that does not seem like a good tradeoff (unless they are clear side effects of mixing).

Then you need to identify your trunk ports (from router through switches). All these need to be configured with PVID=1 and tagged VLANs.
The upstream port towards the router is clearly one of these. When the upstream lands in a switch, so is that port.

The other ports are "access ports" configured for one VLAN (machines connected to these ports "belong" to the VLAN).
PVID=VLAN_ID & VLAN_ID untagged. All other VLANs unchecked (not a member).

As you have now figured it out, only the original lan (identifier) interface received wide open access (one rule for IPv4, one for IPv6).
By default, other internal interfaces pretty much only allow DHCP.

If you move most of your clients to main (VLAN), you can start with cloning the allow all rule from LAN.
If the only devices left in LAN are the switches, you can definitely trim access down to nothing (DHCP left). The anti-lockout rule can still be leveraged by connecting a PC directly into OPN.
For IOT, you can start with allowing broad access to !private_networks (where private_networks is an alias for the RFC1918 ranges you use).

[HankB]

With these switches (not truly managed, classified as smart-easy), I'm afraid you should ignore the guidance regarding mixing tagged and untagged traffic.

Thanks for clarifying that. Everything else you described squares with what I've discovered so far and It's nice to have that fleshed out.

Thanks for taking the time to provide a helpful answer.

best,

[EricPerl]

Oh, and on the Realtek side, if you run into trouble, there's a plugin that may improve things depending on the chipset.
A more radical workaround is to virtualize the HW (e.g. Proxmox).