OPNsense Forum
English Forums => 24.1 Production Series => Topic started by: Cattapiller on March 16, 2024, 04:54:13 pm
-
Heya!
Is the new KEA DHCPv4 ARP scanning the network to check if the ip is already in use?
If yes, is the firewall ARP table the same as the KEA ARP table?
Because I've got some IP collisions in my network that could've been easily avoided if KEA would ARP scan the network.
I've got one client who gets constantly offered an IP that's already in use and I can see it in the ARP table of the interface. Meaning I can see the MAC, IP, leasetime etc on the KEA DHCP but if i check the AR{ table of the interface, the IP is already occupied with another MAC on the same switch but a different port
I was switching from ISC to KEA hoping that KEA would ARP scan (as stated in their documentation) and just check that some static IPs are in place and would just avoid them but apparently it doesn't.
Cheers & Thanks in advance
-
Hi
KEA would ARP scan (as stated in their documentation)
could you share the link on this please?
I thought that the rfc involves the conflict detecting and DHCP DECLINE sending from the client side
-
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#duplicate-addresses-dhcpdecline-support
"Such an unwelcome event can be detected by legitimate clients (using ARP or ICMP Echo Request mechanisms) and reported to the DHCPv4 server using a DHCPDECLINE message."
+
https://kb.isc.org/docs/why-doesnt-kea-support-ping-check
"Third, the DHCP protocol itself provides another, more reliable mechanism for this: the DECLINE message. Modern DHCP clients scan their local subnet (for example, using the ARP protocol) to detect whether the suggested address is already active on another device."
Rereading that, youre absolutely right. The clients can arp scan their local subnet to reach a DHCP DECLINE. But is there no server side sanity check? Because this thing handed out the same IP 4 times already... Do i now really have to investigate which clients have a static ip and give them a static entry so that the KEA DHCP can work his way around it?
-
ISC KEA implements the DHCP protocol, just like ISC DHCP Server did for ages. The mechanism for collision detection has not changed - it basically cannot change, since DHCP can be relayed over routed networks where the DHCP server does not even see the ARP table of the managed clients.
Likewise, I bet you still have to keep static reservations out of the dynamic pools to not create problems.
Also, if multiple DHCP server instances are used for redundancy, who should check? And what?
To understand why certain things are done like so in this protocol from the stone age is a complicated task where one always asks oneself: Could it be done another way? And most of the time, there is a rationale to do it just like they did.
Been there - done that.
-
Yep, i think ive just misread it COMPLETELY ^^
-
yes, i think there is 3 options:
-exclude ip from the scope(s)
-hope the client can handle it
-get "paid support contract" to get ping-check hook library from ISC
https://kea.readthedocs.io/en/latest/arm/hooks.html#libdhcp-ping-check-so-ping-check
-
Yep or check which ports are toggling / which clients are having downtimes and then force them to use dhcp - im not going to do static mappings because they are fluctuating sadly (some routers) and they mostly deny ping on WAN so icmp is just not going to cut it.
So im going to deny them access to the network until they switch to dhcp.
(shit load of work to sort out those static clients because >700 clients)
Thanks tho! :)