pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS

hernanirvaz

@Gertjan you were absolutely correct.

kea-dhcp6 WARN messages had to do with the fact that my ubuntu servers are requesting a Prefix Delegation for their own upstream IPv6 staff. After setting this up with 2001:8a0:fcc2:6610::/60, the WARNs stooped.

But this change did not help with kea2unbound registration with the wrong domain on unknown.home.arpa
This is still only happening with ubuntu servers not with ubuntu desktops!
The only relevant difference between these two - I can point to, is:

servers (use systemd-networkd) & register on the incorrect domain unknown.home.arpa
desktops (use NetworkManager) & register on the correct domain home.arpa

can you help with this?

Gertjan

@hernanirvaz said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

did not help with kea2unbound registration with the wrong domain on unknown.home.arpa

You were not far off
Look at the file you mentioned : kea2unbound - it's here : /usr/local/bin/ - line 469

Now you know where where "unknown.home.arp" comes from.
It's seems to be an error condition, and 'should never happen' according to people that know a whole lot more of the subject.

/* Should never get this far */

From what I make of it : kea2unbound asks unbound via the control port (socket) info about registered leases.
I found Seeing Kea DHCP Issues after upgrade to 24.11 ), so :

echo '{"command":"lease6-get-all"}' | nc -U /var/run/kea6-ctrl-socket | jq

All this info comes from the kea DHCP6 server settings pages (global, and lans).
The domain name is set correctly ? - it is, for me, filled in with the default system domain name :

hernanirvaz

@Gertjan said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

The domain name is set correctly ?

confirmed the domain is set correctly and, for me, is set to home.arpa

echo '{"command":"lease6-get-all"}' | nc -U /var/run/kea6-ctrl-socket | jq

used this command to confirm and option-data appears blank for ubuntu servers. ie: registered with unknown.home.arpa

{
  "arguments": {
    "leases": [
      {
        "cltt": 1760023099,
        "duid": "00:02:00:00:ab:11:52:73:8c:86:e8:81:de:8a",
        "fqdn-fwd": false,
        "fqdn-rev": false,
        "hostname": "hrv-zotac3.",
        "hw-address": "00:01:2e:a0:88:ea",
        "iaid": 1448103320,
        "ip-address": "2001:8a0:fcd1:3e00::2000",
        "preferred-lft": 4500,
        "state": 0,
        "subnet-id": 1,
        "type": "IA_NA",
        "user-context": {
          "Netgate": {
            "option-data": {},
            "query6": {
              "iface-name": "re0",
              "remote-addr": "fe80::201:2eff:fea0:88ea"
            }
          }
        },
        "valid-lft": 7200
      },
      {
        "cltt": 1760023472,
        "duid": "00:04:5c:fd:51:49:45:08:6a:81:80:68:c0:b9:ed:a2:b4:57",
        "fqdn-fwd": false,
        "fqdn-rev": false,
        "hostname": "hrv-lenovo.",
        "iaid": 3134327015,
        "ip-address": "2001:8a0:fcd1:3e00::2002",
        "preferred-lft": 4500,
        "state": 0,
        "subnet-id": 1,
        "type": "IA_NA",
        "user-context": {
          "Netgate": {
            "option-data": {
              "domain-search": [
                "home.arpa."
              ]
            },
            "query6": {
              "iface-name": "re0",
              "remote-addr": "fe80::f542:718f:1de7:6e3"
            }
          }
        },
        "valid-lft": 7200
      }
    ]
  },
  "result": 0,
  "text": "2 IPv6 lease(s) found."
}

hrv-lenovo is ubuntu desktop and has "option-data": { "domain-search": [ "home.arpa." ] }
hrv-zotac3 is ubuntu server and has "option-data": {}
also noticed that the servers have hw-address field and the desktops do not - probably because the desktops connect via wifi. Not sure this is relevant info.

help please?

Gertjan

@hernanirvaz said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

After setting this up with 2001:8a0:fcc2:6610::/60, the WARNs stooped.

You assignd that "2001:8a0:fcc2:6610::/60" ?
Prefix should be assigned to you from "upstream".
And a /60 looks really strange. /64, ok

Your LAN is set to DHCPv6 tracking, right ?
Like this :

and the DHCPv6 server on LAN shows the obtained prefix, right ? :

which is always, afaik, a /64.

@hernanirvaz said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

probably because the desktops connect via wifi

Wifi, plain copper Ethernet cable, coax, fibre, it doesn't matter what the transport medium is made of.
IP packets are IP packets. The source and destination MAC "hardware address" must be part of it.

hernanirvaz

@Gertjan said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

Prefix should be assigned to you from "upstream".

yes, you are correct - it is assigned by my ISP, in my case:

Delegated Prefix: WAN/0 (2001:8a0:fcd2:6600::/56)/64

pfSense then uses the first /64 from that /56 (i.e., 2001:8a0:fcc2:6600::/64) for its LAN interface (this is what WAN/0 signifies when configuring a LAN to "Track Interface" on WAN).
This leaves 255 other /64 subnets within that /56 available for pfSense to delegate to other devices on my network that request their own prefixes. These available subnets range from 2001:8a0:fcc2:6601::/64 up to 2001:8a0:fcc2:66FF::/64. This is in fact the next setting on pfSense:

Prefix Delegation Pool

this is the pool that pfSense uses to delegate downstream to other, eventual, DHCPv6 servers, and this was the complaint (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) I initially was seeing in the logs.

my problem still remains the same all with latest ubuntu OS & IPv6 DNS Resolve registrations:

servers (use systemd-networkd) & register on the incorrect domain unknown.home.arpa
desktops (use NetworkManager) & register on the correct domain home.arpa

can you help with this?

Gertjan

@hernanirvaz

Where did you see this :

on the DHCP server LAN page ?

edit :

@hernanirvaz said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

pfSense then uses the first /64 from that /56 ...

When I visit my ISP upstream router, it tells me :

which should be the same as you.

My IPv6 pfSense WAN IP is in the '00' prefix range, and then "46d4:54ff:fe2a:3600"
For whatever reason, my pfSense obtained the "e2" prefix for my pfSense LAN.

It shows "e2" even when I see this on my LAN settings âge :

where "0 to 0" probably means : get one.

Btw : My ISP (a "Livebox 6" router from Orange (France)) is IPv6 buggy as it only allows 1 prefix per attached device (like pfSense). I can't request a second prefix for a second LAN.

I'm telling all this because

looks .. dono, strange to me.

hernanirvaz

@Gertjan I do not actually have access to my ISPs upstream router. That is why I decided to install a pfSense box and (by phone) asked my ISP to put their router in bridge mode.

When my pfSense WAN DHCPv6 Client Configuration has "DHCPv6 Prefix Delegation size 64" then my ISPs router gives me the Delegated Prefix: WAN/0 (2001:8a0:fcc2:6600::/56)/64, that means:

my ISP is delegating a /56 prefix to my pfSense. This is the 2001:8a0:fcc2:6600::/56 part - the big block of addresses my ISP is giving me to work with.
my pfSense is specifically configured to request a /64 for its WAN interface and also to handle the delegation of a /64 (the WAN/0 part refers to the first /64 out of the delegated /56) to its LAN.

This means that out of the 2001:8a0:fcc2:6600::/56 block my ISP gives me:

2001:8a0:fcc2:6600::/64 (mine is 00 you e2) is being used by my pfSense LAN interface (as indicated by WAN/0).
This leaves 2001:8a0:fcc2:6601::/64 through 2001:8a0:fcc2:66FF::/64 available within that /56 block for further delegation to pfSense clients upstream.

So, I have plenty of /64 subnets remaining from the /56 to delegate, for pfSense to give to my internal clients.

But that stuff is all good for me, my problem still remains the same; my internal machines, all with latest ubuntu OS & IPv6, get DNS Resolve registrations wrong:

servers (with systemd-networkd) & register on the incorrect domain unknown.home.arpa
desktops (with NetworkManager) & register on the correct domain home.arpa

can someone help with this?

IonutIT

I'm hijacking this post because it seems my problem is somewhat related to this. Difference is that I don't use home.arpa domain

https://forum.netgate.com/topic/199239/kea-dhcpv6-dns-registration

It seems that a single host in my static allocation is only found in NDP table with <hostname>.unknown.home.arpa instead of my properly set domain name. Other hosts are properly being registered.

And yes, the host is Ubuntu Server. And in pfsense /etc/hosts there's no mention of this entry with its GUA IPv6, only its IPv4 reservation also made by KEA DHCPv4 and a static IPv6 ULA entry made in Unbound itself under DNS Host overrides.

One thing it did occur to me just now, is that the static allocations that do resolve in DNS properly were setup prior to switching to KEA (when I was using ISC). This unifi one was setup after I moved to KEA.

PS: The addresses that are not properly registered for you (::1003, ::1005) etc. seem to occur if you have "Enable early DNS registration" in KEA Settings for DHCPv6. If you uncheck that, it will properly resolve only the full IPv6 with the proper prefix from your ISP. This issue seems to be fixed in future 25.11 release.

Tomahawk

@hernanirvaz said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

servers (with systemd-networkd) & register on the incorrect domain unknown.home.arpa
desktops (with NetworkManager) & register on the correct domain home.arpa

I have this issue as well
I tried to install commit 146391a mentioned in https://forum.netgate.com/topic/199239/kea-dhcpv6-dns-registration using System-Patches but the clients are still beeing registered with wrong domain.
hostname -d at the ubuntu server cli shows the correct domain name

Gertjan

@Tomahawk said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

hostname -d at the ubuntu server cli shows the correct domain name

The pfSense DHCP daemon can't do that ;)

The issue isn't that your device doesn't have a name.
The issue is (imho) that the device doesn't specify it host name to the pfSense DHCP server. The other thread makes mention of this, so it could be corrected.

See for your :

Diagnostics > Packet Capture ,and tell pfSense what you want to see :
Interface - for example "LAN".
View Options : Full.
Protocole : UDP of course.
Ports : DHCP : type "67 68"
and hit the green start button.

Now run to the device that is marked 'unknown' and ask it to renew the lease.
For a Microsoft OS you have to type

ipconfig /renew

and back on pfSense you see now the DHCP request, with info, from the device,
and the DHCP lease proposal coming from the pfSense DHCP server.

Btw : you'll se probably also other DHCP traffic, if you have other devices on your network.

You can prepare a more specific filter by entering the MAC of your device.

IonutIT

@Tomahawk said in pfSense 2.8.1: Kea DHCPv6 IPv6 Static Lease Allocation Fails (ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET) for Known Client, Inconsistent DNS:

I have this issue as well
I tried to install commit 146391a mentioned in https://forum.netgate.com/topic/199239/kea-dhcpv6-dns-registration using System-Patches but the clients are still beeing registered with wrong domain.
hostname -d at the ubuntu server cli shows the correct domain name

I had this issue myself with only Ubuntu Server being affected.

Turns out by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6).

So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and after reboot, by magic the hostname is properly registered in Unbound without the 'unknown' part.