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

    Changing the MAC address on a Kea static lease does not work

    Scheduled Pinned Locked Moved DHCP and DNS
    1 Posts 1 Posters 44 Views
    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.
    • J
      jamie
      last edited by

      I think this is a bug but I'm conflicted whether it's Kea's bug or pfSense's bug.

      I recently installed a new network card in one of my machines that currently has a static lease in Kea for the old network card. I grabbed the MAC address of the new card, edited my static lease in pfSense to change it to the new MAC address, and then moved the cable from the old network card to the new network card. I was then served a new DHCP lease from Kea from the available addresses in the pool, not my static lease. Tried restarting Kea, no difference.

      My lease configuration contains a MAC address, an IP address and hostname only. No client identifier (I thought that was the problem at first, turned out not to be as asking Kea to ignore client identifiers also made no difference).

      Consulting the Kea log, I saw:

      WARN [kea-dhcp4.alloc-engine.0x218397417400] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 30:13:8b:79:56:af], cid=[01:30:13:8b:79:56:46], tid=0x65b2ee64: conflicting reservation for address 10.6.0.4 with existing lease Address: 10.6.0.4 Valid life: 7200 Cltt: 1752320340 Hardware addr: e0:73:e7:c6:6a:24 Client id: 01:e0:73:e7:c6:6a:31 Subnet ID: 1 Pool ID: 0 State: default Relay ID: (none) Remote ID: (none)
      

      So Kea wouldn't serve 10.6.0.4 to me because it thought it was still active as it hadn't expired yet.
      I stopped Kea (not sure if required or not, but belt and braces), edited /var/lib/kea/dhcp4.leases to remove the two entries for 10.6.0.4 referencing the old MAC, started Kea again and then finally got the expected address served from DHCP.

      Not sure whether the bug here is in Kea or in pfSense.

      On one hand, Kea's static lease config now says $newMAC should be served 10.6.0.4. There's an active lease on $oldMAC to 10.6.0.4. This IP is outside the pool so will only have been given out from a static lease. That old static lease no longer exists in it's config, so why wouldn't Kea clear the active lease and hand out the IP to the new MAC? The sysadmin has changed the static lease config and so if they do so while the old MAC is online and thus cause an IP conflict, how is this any different to the sysadmin setting a static IP on both systems, plugging them into the network and causing an IP conflict? Don't do that.

      On the other hand, if I'm changing a static lease, maybe from Kea's perspective it's reasonable to also clear the active lease from the leases file. In which case as I'm using pfSense, not managing Kea directly myself, I would expect pfSense to remove reservations matching the old MAC/IP pair from the leases file when I modified the static lease in the UI to change the MAC address. By editing the reservation, it's clear I want it to take effect now, instead of waiting for the lease to expire. I don't think having to SSH in and manually edit system files the 'right' way to do things in pfSense.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.