Messages

With that info I guess I'll stay on Dnsmasq+Track interface (legacy) for now then. It would be great if you could somehow release a tutorial / short howto then on how to configure these things for regular ISP usage then, as in "Configuration for just replacing my ISP Fritz!Box with OPNsense" as it's really hard to puzzle together everything, especially in this kind of constellations where things and certain combinations don't work at all.

Our setups are, I think, identical, and the best way to determine the optimal approach is to have someone excoriate you for doing it wrong, so I'll explain my approach, which is, you know, probably wrong.

So my ISP hands me a /56, which has not changed in ages, but that is by no means guaranteed, etc. As with your setup, I've always prefixed this into /64s for my internal networks, i.e., LAN is 0, GUEST is 1, etc. I've been migrated for months now from ISC to dnsmasq, and I'm happy with the dnsmasq setup, which I've had set to only do DHCP for v4.

Options appear to be two:

• I could configure IPv6 ranges in dnsmasq for each of the lan segments, turn on RA in dnsmasq, and have it hand out addresses.
• I can skip all that, and just turn on RA (Services -> Router Advertisements) for each of the segments, setting them to 'Unmanaged'.

Option 1 being seemingly the more complicated of the two, I went with option 2, which results dnsmasq doing IPv4 DHCP + DNS only, and IPv6 clients getting addresses purely via SLAAC.

I suspect but do not know for certain that this is more resilient to a renumbering when the /56 changes.

This appears to work properly with the prefix delegation setup, and all the usual IPv6 tests pass, but this is usually the point where more learned individuals tell me that I'm being an idiot, so let's see what they have to say.

test of: https://test-ipv6.com/ fails with "No IPv6 address detected) now where WAN (IPv6 Configuration Type: DHCPv6) works well, I can ping for example google.de with IPv6 from the diagnostics

Seeing the same thing, with the same setup. I had gone with dnsmasq per the migration suggestions at the time, but it seems as if Kea is the only option now for this particular ISP setup.

Same issue observed with 26.1. Resolved by the latest test version, here's the before and after:

total 2286624
-rw-r--r--  1 hostd hostd  4.2M Jan 30 04:47 hosts.db
-rw-r--r--  1 hostd hostd  4.3M Jan 30 04:47 hosts.db-shm
-rw-r--r--  1 hostd hostd  2.2G Jan 30 04:47 hosts.db-wal
root@www:~ # ll -h /var/db/hostwatch/
total 139904
-rw-r--r--  1 hostd hostd  4.2M Jan 30 04:47 hosts.db
-rw-r--r--  1 hostd hostd  4.3M Jan 30 04:47 hosts.db-shm
-rw-r--r--  1 hostd hostd  128M Jan 30 04:47 hosts.db-wal
root@www:~ # ll -h /var/db/hostwatch/

Yes, that's it. My configuration contains the following:

Code Select Expand

  <dhcpdv6>
    <opt2>
      <enable>-1</enable>
    </opt2>
    <opt1>
      <enable>-1</enable>
    </opt1>
    <lan>
      <enable>-1</enable>
    </lan>
    <opt3>
      <enable>-1</enable>
    </opt3>
  </dhcpdv6>

And that corresponds to the 'stuck' interfaces. I had migrated to dnsmasq DHCP some time ago in preparation for this release, so ISC DHCP wasn't active on the interfaces either before or after the upgrade to 26.1. Tried the legacy -> association change both with the ISC plugin installed and with it uninstalled, no change.

There's no entry for ISC DHCP in System: Configuration: Defaults on my system.

To resolve, on each affected interface, I ticked "Allow manual adjustment of DHCPv6 and Router Advertisements", hit Save, then immediately changed the type to "Identity Association", hit Save again, and only then hit Apply.

This changed nothing in the dhcpdv6 section of the system configuration, still the same keys and values present there, but it did allow the type change to take.

I think this to be a bug, as I believe you'll find that you can't set the IPv6 Configuration Type to 'None' on the affected interface, either. In short, you're pretty much stuck with whatever settings that interface has at the moment, it seems.

In dnsmasq you cannot use the same fqdn for all ranges.

If you have devices that advertise the same hostname in different subnets, they would overwrite the managed dns records without having a special domain which makes it unique.

But isn't that true even within a subnet? That is, I've got a number of cheap and cheerful WiFi-enabled outlets here, all of them referring to themselves as 'HS105', and, basically, last one in wins, it seems.

I moved to the new setup myself today, and had no issues; seems to be working as well as ISC did. My experience with Kea was a poor one, so at least so far, this seems to be a real improvement over that.

My suspicion is that the default of 'All' for the networks option is likely to cause problems with firewall rules not being applied, and I'd recommend changing that to be perhaps initially blank and requiring a selection to be made, in all cases ensuring that rules are created.

The documentation on this topic was, I felt, very good and easy to follow, and the forwarding setup from Unbound was particularly well described. The one thing I might want to change about it is that the 'DHCPv4 with DNS registration' portion seemed a more complicated use case than what I'd expect to be the norm, i.e., it sets up a subdomain per range, where the ranges correspond to security domains of 'lan' and 'guest'. I'd perhaps precede that use case with one of just setting up a default domain, e.g., 'lan.<tld>' and using that for all ranges.

Kea is comparatively bare-bones at the moment, and doesn't have much in the way of controlling UI in the same way that ISC does. Probably fine until you have a problem, and then things become hard to resolve as compared to ISC.

At the moment, in my case, Kea seemed to get into some pathological situation where it'd hand out new leases to the same switch MAC address indefinitely, until they were completely used up. There's seemingly no way out of that situation in the present Kea UI, so I fell back to ISC, which seems fine.

Kea's been working well for months for me, unsure what's caused it to become insane now, but just FYI, at the moment, seems as if Kea can get you into trouble that you'll have a hard time getting out of, and staying with ISC might be the prudent choice.