Re: [Kea-users] DHCP NAK through relay option 82
Hi Jeff,
Regarding "circuit-id" based host reservations, the "circuit-id" is
used solely
to find the reservation.
Lease data will contain the identifier(s) used by the client, either the
hw-addr
or a DUID; therefore, renews and other unicast traffic will not be
affected by
missing RAI options.
Kind Regards Peter
On 04/04/2024 16.07, Jeff Kletsky wrote:
"relay": { "ip-address": "10.11.12.13" },
--
Peter Davies
Support Engineer
Internet Systems Corporation
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] DHCP NAK through relay option 82
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)
"client-class": "VLAN_84",
"relay": { "ip-address": "10.11.12.13" },
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.
Coming back to this many years later, I checked the current
documentation at
>https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#how-the-dhcpv4-server-selects-a-subnet-for-the-client>. There it states that
> 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).
At least as I interpret this, the "convenient behavior" of checking the
ciaddr against the potential subnets is documented behavior of Kea itself.
Jeff
On 4/4/24 12:54 AM, Peter Davies wrote:
Hi Jeff,
As you have discovered, classes based on option 82 values will only
match relayed traffic.
Therefore, all things being equal, Kea will not be able to select a
subnet for renewing clients.
Have you considered using host reservations with "circuit-id" as the
identifier?
Kind Regards Peter
On 03/04/2024 21.09, Jeff Kletsky wrote:
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.li...@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
--
Peter Davies
Support Engineer
Internet Systems Corporation
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing
Re: [Kea-users] DHCP NAK through relay option 82
Hi Jeff,
As you have discovered, classes based on option 82 values will only
match relayed traffic.
Therefore, all things being equal, Kea will not be able to select a
subnet for renewing clients.
Have you considered using host reservations with "circuit-id" as the
identifier?
Kind Regards Peter
On 03/04/2024 21.09, Jeff Kletsky wrote:
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.li...@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
--
Peter Davies
Support Engineer
Internet Systems Corporation
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] DHCP NAK through relay option 82
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.li...@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
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] DHCP NAK through relay option 82
Hi Libor, As you noted, this is because the server doesn't receive the option 82 data in subsequent renews. You may be able to force clients to always use the relay-agent on your router or whatever is doing the relay. Otherwise, there isn't much you can do. The Kea server can't classify a client based on information that doesn't exist. From the message you provided where it fails to select a subnet it seems that you are using the classification to control access to a subnet in some way. Kea won't even get as far as looking for a lease, if it can't find a subnet for the client. If you can't alter your relay-agent's behavior (with some, it is possible to mask the server address from the client such that the client thinks the relay is the server), then you may have to rethink your strategy. Thank you, Darren Ankney On Thu, Mar 28, 2024 at 1:41 PM 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 > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] DHCP NAK through relay option 82
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 -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
