Messages

There was a recent change:

https://github.com/opnsense/core/commit/f7c5fa866f6e50faec1a4ecaaf813100166ba567

If I'm reading this right (may not be - haven't really dug in), it looks like there's a new requirement that the user cert be issued from the same CA as the server cert...?

Yes - the gateway is an upstream router that is your next hop to "the internet", presumably belonging to your ISP.

That appears to be a discussion thread for an early access release of the switch firmware. The models listed would be those for which that release is/was available.

Google AI tells me that the "Flex" and "Ultra" switches use cheap Realtek SoCs, which default to acting as a dumb switch until the OS and software finish booting and tell them what to do, and that the Pro and Enterprise models use Marvell or Broadcom ASICs, which are flash-backed, and start up already knowing what to do. I don't necessarily believe that this is entirely accurate, but it seems plausible...

The current switch software releases of some switch models have a problem separating untagged and tagged LANs during switch startup.

This seems like a good reason not to use UniFi switches. I actually had been considering buying some to deploy, but now I'm reconsidering!

It seems to me like this would present some issues even when not mixing tagged and untagged on the same interface in OPNsense. e.g. OPNsense broadcasting IPv6 RA on (only tagged) VLANs, with a Windows PC on an "access" switch port on one specific VLAN. If the switch acts "dumb" during boot, it would forward those tagged frames (for all VLANs, not just the specific one) to the Windows PC port, where Windows (at least with some NIC types) has been known to strip VLAN tags and blindly process the frame as if it was received untagged. This would cause bogus IPv6 configuration in Windows.

Needing a CA key suggests that you're trying to create a new cert issued by a CA internal to OPNsense. Maybe a silly question, but you are trying to "Import an existing Certificate", not "Create an internal Certificate", right?

Have you reboot (opnsense) since eliminating the bridge? There may be some artifact from it lurking somewhere.

Otherwise try this tcpdump to see "what's happening on the wire":

Code Select Expand

tcpdump -nnvvei igc0 '(ether host aa:bb:cc:dd:ee:ff and port 67) or (vlan and ether host aa:bb:cc:dd:ee:ff and port 67)'

Substitute the MAC address of a Guest or IoT device (in two places), and make it (re)connect.

But ... why does opnsense simply don't do that?
Handle the access to the web-GUI and SSH by setting system rules and listen general on 0.0.0.0
instead of really doing a bind.

It does do that (by default). You changed it (as you admitted in comment #6).

BTW (technicality), the socket is always bound - it wouldn't receive any connections if it wasn't - the difference is that binding to INADDR_ANY (0.0.0.0) means that it can receive connections with destination address belonging to any local interface (at connection time).

I don't know what a "TO" is, but I have not yet seen any proof that a DHCP request from a tagged ethernet frame is getting a response from the DHCP service on the base ("untagged") interface. I suspect that the request frame is not actually arriving tagged, which is why I suspect WiFi misconfiguration. I'd suggest that the OP (original poster) double-check that first, then maybe try tcpdump like I showed...

Also I wanted to confirm that the bridge is completely out of the picture, because it could be doing something silly like grabbing the tagged frame, stripping the tag, and dumping it onto its member interfaces.

That's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request.

So what is different here to that I wrote??

You wrote "... this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.", which makes it sound like the DHCP request gets routed at layer 3. It doesn't.

The ethernet frame containing the request can (and should, in this case) include a VLAN tag.

And this is the part, which might not work here.

Yes, you're right, the broadcast shouldn't leave its VLAN. But the VLAN separation doesn't seam to work at layer 2.

What are you based that assessment on? It works for me...

However, to get an IP from a DHCP server, a device sends the request to the broadcast. But since it doesn't have a network setting at this point, it sends the request to the overall broadcast address,  which is 255.255.255.255, and this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.

That's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request. The ethernet frame containing the request can (and should, in this case) include a VLAN tag. When OPNsense receives such tagged frames on igc0, if there is a correctly-configured VLAN subinterface for that VLAN ID, that interface will handle the frame. If there's a DHCP service listening on that interface, it should respond accordingly. Otherwise it should be ignored.

Here's an example of a DHCP request on VLAN 5 as seen by tcpdump:

Code Select Expand

root@opnsense:~ # tcpdump -nnei igc0 vlan and port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

08:58:48.234885 52:3f:a3:79:d1:2c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 354: vlan 5, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:3f:a3:79:d1:2c, length 308
08:58:48.235421 00:d0:b4:01:a5:a1 > 52:3f:a3:79:d1:2c, ethertype 802.1Q (0x8100), length 350: vlan 5, p 0, ethertype IPv4 (0x0800), 10.1.5.1.67 > 10.1.5.201.68: BOOTP/DHCP, Reply, length 304
...

... and an example on VLAN 11, for which no VLAN interface exists:

Code Select Expand

root@opnsense:~ # tcpdump -nnei igc0 vlan and port 67 or port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

09:05:50.914317 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304
09:05:51.970468 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304
09:05:54.123988 66:78:39:f8:6b:89 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 11, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 66:78:39:f8:6b:89, length 304


At the start, you had a bridge. Is that bridge now completely gone? Updated ifconfig output might be helpful.

Otherwise I'd tend to suspect that your WiFi is misconfigured...

So... damned if you do, damned if you don't 🤣🤣

You can't use a VLAN interface for VLAN 1 unless it's tagged on whatever is (directly) connected to igc0. If that's a UniFi AP, VLAN 1 is probably not going to be tagged.

You'd need to assign your other VLAN interfaces (Interfaces -> Assignments), then configure them (Interfaces -> [Guest], etc), then setup the DHCP service(s) for them.

If you just have a single UniFi AP and no wired devices, you could assign igc0 to LAN (i.e. use it untagged, with Guest and IoT tagged), and accept that you'll burn in hell for it (I'll see you down there)... otherwise you're going to need a managed switch.

The source address will not be your WAN address - it'll be that of the client making the connection. You probably don't want to set that at all (unless you want to restrict access to just that source)

Perhaps, but I think the issues here are a bit orthogonal - someone could still fall into the trap of trying to put a bridge across multiple physical interfaces and then doing VLANs on top even if they weren't trying to mix tagged and untagged frames - that still won't work (until a possible future, where OPNsense harnesses the new "VLAN filtering bridge" functionality, as you say)