<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks for the clarification Peter. You're right, I failed to
show that I have configuration in each of the subnet definitions
to match on the client-class (and to restrict to the IP address of
the expected relay)<br>
</p>
<p> "client-class": "VLAN_84",<br>
<br>
"relay": { "ip-address": "10.11.12.13" },</p>
<p>Conveniently, the behavior I have seen over the years is that a
well-behaved client gets a NAK if it tries to rebind an address
that is isn't assigned to, such as after adding a reservation for
a host that has been using the subnet's pool. I didn't recall
reading documentation that stated that this was intentional
behavior. That is behind my hesitation in suggesting this for
someone's environment that may be more sensitive than mine. <br>
</p>
<p>Coming back to this many years later, I checked the current
documentation at
><a class="moz-txt-link-freetext" href="https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#how-the-dhcpv4-server-selects-a-subnet-for-the-client">https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#how-the-dhcpv4-server-selects-a-subnet-for-the-client</a>>.
There it states that <br>
</p>
<p>> The rule [using the interface on which the packet was
received] does not apply when the client unicasts its message,
i.e. is trying to renew its lease; such a message is accepted
through any interface. The renewing client sets ciaddr to the
currently used IPv4 address, and the server uses this address to
select the subnet for the client (in particular, to extend the
lease using this address).</p>
<p>At least as I interpret this, the "convenient behavior" of
checking the ciaddr against the potential subnets is documented
behavior of Kea itself.</p>
<p>Jeff</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/4/24 12:54 AM, Peter Davies wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f073be74-2812-4088-9f0d-9d2ad7aac80e@isc.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Jeff,<br>
As you have discovered, classes based on option 82 values will
only match relayed traffic.<br>
Therefore, all things being equal, Kea will not be able to
select a subnet for renewing clients.<br>
Have you considered using host reservations with "circuit-id" as
the identifier?<br>
<br>
Kind Regards Peter<br>
</p>
<div class="moz-cite-prefix">On 03/04/2024 21.09, Jeff Kletsky
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:98787c61-9086-42a5-a857-afd11f3720a1@allycomm.com">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<p>I had hoped that someone would post a better "solution" than
what I've been using. <br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>If anyone can improve on this, I'd appreciate the feedback. <br>
</p>
<p>Jeff</p>
<p><br>
</p>
<p>// Renew prefers to go direct to the issuing server<br>
// so there is no circuit identifier or topology<br>
//<br>
// Kea doesn't check the existing leases and its<br>
// KNOWN selector appears to be related to the client<br>
// having a reservation.<br>
//<br>
// Select based on it being a Request (renew) packet<br>
// that went direct with matching Ip addresses<br>
<br>
{<br>
"name": "is_request",<br>
"test": "option[53].hex == 0x3"<br>
},<br>
<br>
{<br>
"name": "is_direct",<br>
"test": "pkt4.giaddr == 0.0.0.0"<br>
},<br>
<br>
{<br>
"name": "addresses_match",<br>
"test": "pkt4.ciaddr == pkt.src"<br>
},<br>
<br>
{<br>
"name": "is_direct_rebind",<br>
"test": "member('is_request') and member('is_direct') and
member('addresses_match')"<br>
},<br>
<br>
// Try just the combination of relay circuit check or rebind<br>
<br>
{<br>
"name": "VLAN_84",<br>
"test": "member('circuit_84') or
member('is_direct_rebind')"<br>
},<br>
</p>
<p>[continues for other VLANs in use]<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/28/24 10:40 AM, <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Brazda.Libor@seznam.cz" moz-do-not-send="true">Brazda.Libor@seznam.cz</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7VF.PTjd.1vNQKim2fdY.1c1Qkb@seznam.cz">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div>Hi, I am trying to start kea dhcp with client
classification using option 82 through dhcp relay server.</div>
<div><br>
</div>
<div>When client tries to do renew of ip address, tries to
prolongate his lease, kea <span
style="background-color:transparent">response with NAK.</span></div>
<div>The problem is that when client makes simple dhcp
discover, the packet goes <span
style="background-color:transparent">broadcast through the
router, router acts like dhcp relay and relays packet to </span><span
style="background-color:transparent">dhcp server kea with
added option 82.</span></div>
<div>But when client makes dhcp renewal-packet goes unicast
directly to dhcp server <span
style="background-color:transparent">without option 82. As
I understand, this causes kea to response </span><span
style="background-color:transparent">with NAK, because
packet doesn't match to subnet rule </span><span
style="background-color:transparent">criteria. In the logs
I see message "</span><span
style="background-color:transparent">ailed to select a
subnet for incoming packet, src 100.64.1.1, type
DHCPREQUEST"</span></div>
<div><br>
</div>
<div>Is there a way to configure kea to accept renewal
requests if lease already <span
style="background-color:transparent">exists and mac
address of a client corresponds to stores lease?</span></div>
<div><span style="background-color:transparent"><br>
</span></div>
<div><span style="background-color:transparent">Full log - </span><span
style="background-color:transparent"><a
class="moz-txt-link-freetext"
href="https://pastebin.com/yviEFneL"
moz-do-not-send="true">https://pastebin.com/yviEFneL</a></span></div>
<div><span style="background-color:transparent">Full config - </span><span
style="background-color:transparent"><a
class="moz-txt-link-freetext"
href="https://pastebin.com/2DxfQKb6"
moz-do-not-send="true">https://pastebin.com/2DxfQKb6</a></span></div>
<div><span style="background-color:transparent"><br>
</span></div>
<div>Thanks for any advice<br>
</div>
<div><br>
</div>
<div>Libor</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
Peter Davies
Support Engineer
Internet Systems Corporation
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>