Messages

OK, I will check all you mentioned, thank you! But at a glance, all seems compliant. I also assume that the outgoing traffic from inside OPNSense is not subject to the "Default deny / state violation rule".

I also found this ticket, which sounds suspiciously similar. Will check it as well.

Thank you for checking it out!

IPv4 works fine everywhere.

IPv6 works from the clients (aka LAN), but fails from the router itself. E.g., connectivity audit resolves, but fails to ping
mirror.sfo12.us.leaseweb.net. Likewise, from the CLI:

Code Select Expand

# host google.com | grep -i ipv6
google.com has IPv6 address 2607:f8b0:4007:809::200e

# curl --connect-timeout 10 "http://[2607:f8b0:4007:809::200e]"
curl: (28) Connection timed out after 10045 milliseconds
IPv6  works fine from the router to clients. Only the WAN side is broken.

The router is connected to WebPass and gets a proper /56 -  as evidenced by clients working fine.

I suspect I've overlooked an "allow" rule for "This Firewall" in addition to the "Automatically generated rules." Are there examples of relevant allow-rules somewhere I can compare to?

Forget the bridge and connect the two WAPs to the switch, save the headache of setting up the bridge.

As mentioned in the original post, an additional switch is not an option. The shelf in that space won't fit even a small switch, and powering it up will require outlet shenanigans.

It is also not feasible if you mean to connect the WAPs to the existing switch. The switch and WAPs are in different areas of the space, so pulling the wires back and forth between them through or around concrete walls is a non-starter. That also would not address a potential expansion of VLAN 50, which will have similar limitations.

Even if I had space for a second switch close to the router, I would give it a second thought. Yes, ASICs in a switch would make it more efficient. But, really, would they do so significantly?

I already have this Protectly. It draws what it draws. I can't imagine low-load bridge processing would add as much power draw as a separate switch with its inefficient power supply. And I only deal with one configuration—it is much more of an appliance (which I value) than two complexly connected devices from different vendors with their configurations to track and backup. Yes, it may stutter or heat up under an occasional load. That is fine a couple of times a year. Yes, it is likely not to be that fast. It won't be noticed in this application.

.........

Patrick, thank you very much, all of the above is very helpful!

That is what I was looking for. Thank you very much!

 I need a few VLANs on multiple physical interfaces. There is nothing else to be on these interfaces.

What considerations should I put into arranging it?

Should I make one bridge across the interfaces and put VLANs on top of the bridge?

Or should I put VLANs on one interface and then make bridges between the VLANs and the rest of the physical interfaces?

I do not see a way to have VLANs on multiple interfaces in OPNsense docs.

Any other arrangement? Pros/cons?

Downstream will be WAPs and a managed L2 switch. Here is a rough diagram:



I do not want to send VLAN 50 traffic to any port other than 1. Likewise, VLANs 10-40 traffic should not come to port 1. Port 0 is an uplink. Port 2 will either extend VLAN 50 access or have another dedicated VLAN in the future. All sorts of firewall configs should not be an issue and will be addressed later.

Adding another switch between OPNsense and WAPs is not a solution.

The project is a migration from Untangle - it works fine there, albeit convoluted. Repost from Reddit: https://www.reddit.com/r/opnsense/comments/1fz4tsx/vlans_spanning_physical_interfaces/.