[Kea-users] DHCP NAK through relay option 82

Jeff Kletsky kea-dhcp at allycomm.com
Wed Apr 3 19:09:50 UTC 2024


I had hoped that someone would post a better "solution" than what I've 
been using.

My topology is a Cisco SG-series switch in Level 3 mode that is 
supplying DHCP (v4) relay to a dedicated subnet with the Kea hosts.

With the caveat that I have not tested this approach for robustness 
under attack, what I do is check to see if the request appears to be a 
valid REBIND and then select a client class based on either the VLAN 
from the circuit ID or that it appears to be a directly sent rebind.

I don't recall how I decided that Kea would select the proper subnet on 
these direct rebind requests. I am probably relying on undocumented 
behavior. I recall not performing a match against the IP range for a 
given VLAN as I didn't want to have to keep the subnet information in 
sync across different files.

If anyone can improve on this, I'd appreciate the feedback.

Jeff


// Renew prefers to go direct to the issuing server
// so there is no circuit identifier or topology
//
// Kea doesn't check the existing leases and its
// KNOWN selector appears to be related to the client
// having a reservation.
//
// Select based on it being a Request (renew) packet
// that went direct with matching Ip addresses

{
     "name": "is_request",
     "test": "option[53].hex == 0x3"
},

{
     "name": "is_direct",
     "test": "pkt4.giaddr == 0.0.0.0"
},

{
     "name": "addresses_match",
     "test": "pkt4.ciaddr == pkt.src"
},

{
     "name": "is_direct_rebind",
     "test": "member('is_request') and member('is_direct') and 
member('addresses_match')"
},

// Try just the combination of relay circuit check or rebind

{
     "name": "VLAN_84",
     "test": "member('circuit_84') or member('is_direct_rebind')"
},

[continues for other VLANs in use]



On 3/28/24 10:40 AM, Brazda.Libor at seznam.cz wrote:
> Hi, I am trying to start kea dhcp with client classification using 
> option 82 through dhcp relay server.
>
> When client tries to do renew of ip address, tries to prolongate his 
> lease, kea response with NAK.
> The problem is that when client makes simple dhcp discover, the packet 
> goes broadcast through the router, router acts like dhcp relay and 
> relays packet to dhcp server kea with added option 82.
> But when client makes dhcp renewal-packet goes unicast directly to 
> dhcp server without option 82. As I understand, this causes kea to 
> response with NAK, because packet doesn't match to subnet rule 
> criteria. In the logs I see message "ailed to select a subnet for 
> incoming packet, src 100.64.1.1, type DHCPREQUEST"
>
> Is there a way to configure kea to accept renewal requests if lease 
> already exists and mac address of a client corresponds to stores lease?
>
> Full log - https://pastebin.com/yviEFneL
> Full config - https://pastebin.com/2DxfQKb6
>
> Thanks for any advice
>
> Libor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20240403/f643dbcb/attachment-0001.htm>


More information about the Kea-users mailing list