Messages

Due to a recent change, the Rules [new] interface shows all rules that are in effect, not just those that are configured there. This was (IIUC) done so that automatically generated rules are shown, but unfortunately it also draws in rules that came from the legacy interface. There's a thread about it in here somewhere, but the forum search interface is exceeding my patience threshold :/

Silly question - you did check that your CSV file actually has content, right? ;)

For me, on clicking that, the rules from the CSV file appear in the UI, and I'm prompted "After changing settings, please remember to apply them." (as you would after any rules change).

Click on the checkbox....thing to apply. Maybe not the most intuitive....

Assuming (since it's a new installation) that you're using dnsmasq for DHCP and Unbound for the DNS resolver, I think you need to configure query forwarding for your internal domain(s) as described at https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

Sorry, I'm obviously being a bit dense - where in the dhcpd.conf(5) man page is this shortening notation described?

If that shortening notation works, it's interesting, and kindof weird. I suppose it (something) is contorting the :: notation into the bitfield of the prefix only, as opposed to an entire IPv6 address. I wonder if that's being done by ISC DHCP or by OPNsense. I've moved on to Kea, so I don't care enough to try to figure it out. I'm don't know why you wouldn't just enter the complete prefix anyway - it can't be dynamic, so it seems there's little value in shortening it.

Your prefix delegation range looks wrong. It needs to be the start of a /59 prefix - "::a0" is (obviously?) not that...

OPNsense is assigning the VLAN tag to the devices.

No, it's not (assuming by "device" you mean things like PCs, phones, etc.)

VLAN is a way to take a single physical LAN and logically divide it into multiple virtual LANs. "devices" are usually connected to the LAN via either an ethernet switch or a wifi access point. The devices themselves are not "assigned to" a VLAN, but the switch port or the wifi network to which they are connected is. Using VLANs in this way requires a "managed" switch - i.e. one with some sort of management interface which you can use to configure things like VLAN associations for each port.

Say you plug a PC into a switch port configured for VLAN 100. When the switch receives ethernet frames from the PC on that port, it will tag them with VLAN 100 before forwarding them on. This includes things like DHCP requests. When OPNsense receives ethernet frames tagged with VLAN ID 100, it processes them with its VLAN interface with that ID. The DHCP service would then respond accordingly for that interface (e.g. offering a lease for an IP address on the associated subnet). The DHCP response would be sent back through the same VLAN interface, and would be tagged with VLAN ID 100 and send back to the switch. The switch would strip the tag and forward it on to the PC.

In the case of a wifi device, it would connect to a specific "wifi network" (by SSID). The access point would be configured with associations between wifi networks (SSIDs) and VLAN IDs. When it receives frames for given wifi network, it will tag them with corresponding VLAN ID before forwarding them on, etc.

That's all simplified a bit, but hopefully it helps explain why OPNsense can't "assign a device to a VLAN".

The dhclient.leases.igb2 looks as expected.

That doesn't tell me anything because I don't know what "expected" means to you!

It should show the "renew" and "expire" times for each lease, and the difference between them should be half of the lease duration. You should see a renewal request (packet) at the "renew" time.

The help text for "Reserved prefix range" says:

"The value in this field is the length of the reserved prefix range for downstream prefix delegation. The range starts at the given prefix ID. The default is to only reserve the given prefix ID."

Should that actually say something like "... the length of the prefix range for BOTH the interface itself (subnet) AND downstream prefix delegation"?

I'm going with the alternative of locking the ISC DHCP 4 package and hoping this DNSMasq crap blows over

Not sure what you mean by "blows over", but ISC DHCP is dead, and it's not coming back. If you want a supported solution going forward, your choices are dnsmasq or Kea.

None of the "tag" based designations are intuitive.

I haven't fully tested this, but I think you should be able to do something along these lines (replace 0.0.0.1 with whatever "blackhole" means to you, but note that 0.0.0.0 has special meaning (this host) in dnsmasq)...

Create tags: blackhole_dns, blackhole_gw

Create options:

        Interface: Home
        Type: Set
        Option: dns-server [6]
        Value: 192.168.1.10      # PiHole

        Interface: Work
        Type: Set
        Option: dns-server [6]
        Value: 1.1.1.3

        Interface: Any
        Type: Set
        Option: router [3]
        Tag: blackhole_gw
        Value: 0.0.0.1

        Interface: Any
        Type: Set
        Option: dns-server [6]
        Tag: blackhole_dns
        Value: 0.0.0.1


Create hosts:

        Host: less_trusted_thing_1
        Hardware addresses: ...
        Tag [set]: blackhole_gw

        Host: quest_vr_thing_1
        Hardware addresses: ...
        Tag [set]: blackhole_dns

Beat me to it... but I was going to point out that tags can be set at the DHCP range scope too...

Oh, and terminology kindof matters here - you'd want to *match* (not set) the tag when creating the option.

DHCP lease renewal is normally (per standard) attempted when half of the lease time remains. That's very well established, and generally stable.

I haven't been seeing opnsense do that though. It seems to wait until the 85% mark before attempting renewal.

opnsense just uses the standard dhclient - nothing special as far as lease renewal goes (AFAIK).

How are you observing this "85% mark"? What does /var/db/dhclient.leases.igb2 look like?

Google AI thinks it's likely a grounding issue on the cable side - if the cable is not (properly) grounded, voltages have to find another way, which might be via the ethernet connection to the firewall. I don't believe everything AI comes up with, but this seems plausible.

How are you observing the "failure to autonegotiate"? Do you see anything in dmesg when the failure occurs?

DHCP lease renewal is normally (per standard) attempted when half of the lease time remains. That's very well established, and generally stable.

There was a similar-ish sounding case recently, where the OP was convinced that DHCP wasn't doing what it's supposed to, but it actually turned out to be an issue with the ISP's hardware upstream: https://forum.opnsense.org/index.php?topic=51994.0