[Kea-users] KEA not send a NAK when request ip is out of scope

[Marcin Siodelski]

Thomas,

Please refer to the following Kea ARM section for the details regarding
authoritative/non-authoritative behavior:

https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#authoritative-dhcpv4-server-behavior

Setting authoritative flag to true should solve your problem.

Marcin Siodelski
ISC Software Engineering

On 29/08/2019 14:29, Thomas Andersen wrote:
> Hi again,
> 
>  
> 
> Sorry for bumping, but I’m sure there must be smart people out there who
> can guide me – you just missed my original email. :)
> 
>  
> 
> But to make it a lot more simple:
> 
> Shouldn’t KEA respond with NAK when client is requesting an IP out of
> configured scope?
> 
>  
> 
> Br,
> 
> Thomas
> 
>  
> 
> *From: *Kea-users <kea-users-bounces at lists.isc.org> on behalf of Thomas
> Andersen <than at itu.dk>
> *Date: *Thursday, 22 August 2019 at 10.19
> *To: *"kea-users at lists.isc.org" <kea-users at lists.isc.org>
> *Subject: *[Kea-users] KEA not send a NAK when request ip is out of scope
> 
>  
> 
> Hi,
> 
>  
> 
> I got some problems with DHCP requests.
> 
>  
> 
> Expected scenario:
> 
> Computer logs on wifi with host login and is assigned to vlan 200
> (10.28.0.0/23)
> 
> User logs into computer an reauthenticate on wifi and is assigned to
> vlan 201 (10.28.2.0/23)
> 
> Windows 10 sends a DHCP request for the ip address on vlan 200.
> 
> KEA sends a NAK, as the requested ip is not in scope.
> 
> Windows sends DHCP discover and so forth.
> 
>  
> 
> What we see is that KEA never sends the NAK, but sees the REQUEST packet
> as a bad packet, and then discards it.
> 
> How can I get KEA to send a NAK?
> 
> I’ve tried this with 1.3 and 1.5
> 
>  
> 
> Log:
> 
> 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217]
> DHCP4_PACKET_RECEIVED [hwtype=1 a0:51:0b:0c:24:93],
> cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: DHCPREQUEST (type 3)
> received from 10.28.2.2 to 192.168.30.10 on interface eth0
> 
> 2019-08-21 13:40:24.683 DEBUG [kea-dhcp4.packets/41217] DHCP4_QUERY_DATA
> [hwtype=1 a0:51:0b:0c:24:93], cid=[01:a0:51:0b:0c:24:93],
> tid=0xef9810de, packet details: local_address=192.168.30.10:67,
> remote_address=10.28.2.2:67, msg_type=DHCPREQUEST (3), transid=0xef9810de,
> 
> options:
> 
>   type=012, len=008: "PC622019" (string)
> 
>   type=050, len=004: 10.28.0.172 (ipv4-address)
> 
>   type=053, len=001: 3 (uint8)
> 
>   type=055, len=014: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 31(uint8)
> 33(uint8) 43(uint8) 44(uint8) 46(uint8) 47(uint8) 119(uint8) 121(uint8)
> 249(uint8) 252(uint8)
> 
>   type=060, len=008: "MSFT 5.0" (string)
> 
>   type=061, len=007: 01:a0:51:0b:0c:24:93
> 
>   type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0),
> domain-name='pc622019.itu.local' (partial)
> 
> 2019-08-21 13:40:24.684 DEBUG [*kea-dhcp4.bad-packets*/41217]
> DHCP4_NO_LEASE_INIT_REBOOT [hwtype=1 a0:51:0b:0c:24:93],
> cid=[01:a0:51:0b:0c:24:93], tid=0xef9810de: no lease for address
> 10.28.0.172 requested by INIT-REBOOT client
> 
>  
> 
> -- 
> 
> Med venlig hilsen / With best regards
> 
> Thomas Andersen
> 
>  
> 
> Network Architect
> 
>  
> 
> IT University of Copenhagen
> 
> Rued Langgaards Vej 7
> 
> 2300 København S
> 
>  
> 
> Phone: +45 72185249
> 
>  
> 
> ____________________________________________________________________________
> 
>  
> 
> **NEVER DISCLOSE YOUR PASSWORD OR SHOE SIZE - NOT EVEN TO YOUR DENTIST**
> 
>  
> 
> 
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>