Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Kea DHCP Reservations Not Being Honored

    Scheduled Pinned Locked Moved
    DHCP and DNS
    3
    9
    134
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      KStarRunner
      last edited by

      For all of my subnets, I have a portion that's for reservations and a portion for dynamic issuance.

      For example, on the 192.168.100.0/24 subnet,
      192.168.100.10 - 192.168.100.50 is for reservations.
      192.168.100.100 - 192.168.100.150 is for dynamic issuance.

      Back in the ISC DHCP days, a new device would be connected to a subnet, it'd get an IP (say 192.168.100.101). I'd then get the MAC address from DHCP status page, and assign it a reservation (say 192.168.100.20). Then, the next time the device reboots it'll get it's reserved IP.

      Since switching to Kea, this doesn't happen. Now, once a dynamic IP address has been assigned, Kea will ALWAYS issue that dynamic IP (in my example, 192.168.100.101). Doesn't matter that I created a reservation, or rebooted the device, or forcing an address renewal.

      If I switch back to ISC, all those systems on dynamic IPs switch back to their assigned reservation at their new refresh.

      As best I can tell, if I pre-create the reservation before the device is connected, Kea will give it that reserved IP. But, if a new device is one for even a second, Kea will ALWAYS give it a dynamic IP. No amount of effort on my part can get Kea to give out its reserved IP.

      Is this a bug? Is there a known workaround? Every other DHCP server I've used will honor reservations over long-expired dynamic leases.

      P T 2 Replies Last reply Reply Quote 0
      • P
        patient0 @KStarRunner
        last edited by

        @KStarRunner Are you on pfSense Plus 24.11? It is working as expected for me, with Linux clients.

        K 1 Reply Last reply Reply Quote 0
        • K
          KStarRunner @patient0
          last edited by

          @patient0 Yes, pfSense+, 24.11-RELEASE (amd64)

          Having issues with iOS, MacOS, Windows 11, Windows 10, and multiple IOT devices (don't know what underlying OS). Haven't had to create a reservations for Linux since the switch to Kea.

          P 1 Reply Last reply Reply Quote 0
          • T
            tedquade @KStarRunner
            last edited by tedquade

            @KStarRunner I'm on 24.11 and not seeing this with a variety of Windows 10 and 11 clients along with a bunch of Linux devices and some mystery os Iot devices, two Android cell devices and 2 Canon printers.

            Ted

            1 Reply Last reply Reply Quote 0
            • P
              patient0 @KStarRunner
              last edited by patient0

              @KStarRunner And in the DHCP logs of pfSense you see entries for KEA giving out the dynamic leases to these devices. What are the DHCP lease times?

              Addition: I have only Linux VMs to work with at the moment: just added one and it work as it was with ISC DHCP

              What's listed in the lease file, /var/lib/kea/dhcp4.leases. MAC address correct as listed by dynamic address?

              K 1 Reply Last reply Reply Quote 0
              • K
                KStarRunner @patient0
                last edited by

                @patient0 For testing reasons, I reduced the DHCP lease time to 600s.

                Below is the dhcp4.leases and a cropped DHCP leases page. The big things I've noticed: The DHCP status page shows both the reservation and the dynamic IP for the same MAC address. In this example, Win10, MacOS, and iPadOS. The dhcp4.leases file ONLY has the dynamic address for the problematic devices.

                Of note, not all of my reservations are reflected in dhcp4.leases file. Is there someplace that Kea is pulling reservations from? I.e. is there some other config file that might be getting corrupted?

                I tried clearing out the contents of dhcp4.leases and dhcp4.leases.2, but that didn't change the behavior. It's as if Kea doesn't know about the reservations (i.e. the web GUI is not updating a config file that Kea uses).

                DHCPissue.png

                K 1 Reply Last reply Reply Quote 0
                • K
                  KStarRunner @KStarRunner
                  last edited by

                  Answered my own question. I checked /usr/local/etc/kea/kea-dhcp4.conf, all my reservations are showing up there (including the ones from the above screenshot).

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    KStarRunner @KStarRunner
                    last edited by

                    This is interesting though, when I restart Kea, I get the below in the DHCP log. I get it for every interface configured with DHCP.

                    Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.2, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?
Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.3, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?
Dec 11 16:14:59 XXXX kea-dhcp4[XXXX]: WARN  [kea-dhcp4.dhcpsrv.XXXX] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface XXXX.4, reason: failed to bind fallback socket to address X.X.X.1, port 67, reason: Address already in use - is another DHCP server running?
                    K 1 Reply Last reply Reply Quote 0
                    • K
                      KStarRunner @KStarRunner
                      last edited by

                      Okay, I figured it out. When I stopped Kea via the web GUI, there was still a Kea process listening on UDP 67:

                      sockstat -l | grep :67

                      So I killed the rouge Kea:

                      kill -9 XXXX

                      Then restarted Kea via the web GUI. Now the binding errors are gone, and my reservations are being honored.

                      Super weird issue, no idea how I ended up with two running instances of Kea.

                      1 Reply Last reply Reply Quote 1
                      • First post
                        Last post