DHCP PROBLEM

RouterOS Beginner Basics
1

Hi
can you help me please with the following problem?
my dhcp server behaves weird .. allocate ip recursively to a MAC Addres 00: 00: 00: 00: 00: 00 until the ip of the pool is depleted

i tried to block in the firewall (with a FORWARD rule) MAC: 00: 23: 04: 31: 1E: 6A, respectively the ip that owns it

in DHCP Leases list i have"
Address MAC Address Client ID Status
192.168.5.225 00:00:00:00:00:00 conflict
192.168.5.224 00:00:00:00:00:00 conflict
192.168.5.223 00:00:00:00:00:00 conflict
192.168.5.222 00:00:00:00:00:00 conflict
192.168.5.221 00:00:00:00:00:00 conflict
…

in logs I have the following errors:
Detected confict by ARP response for 192.168.5.225 from 00:23:04:31:1E:6A
Detected confict by ARP response for 192.168.5.224 from 00:23:04:31:1E:6A
Detected confict by ARP response for 192.168.5.223 from 00:23:04:31:1E:6A
Detected confict by ARP response for 192.168.5.222 from 00:23:04:31:1E:6A
Detected confict by ARP response for 192.168.5.221 from 00:23:04:31:1E:6A
…
DHCP Server1: failed to give out IP: pool<dhcp_pool1> is empty

2

It looks like a DHCP starvation attack to me…

3

PROBLEM SOLVED …
I cleared the Conflict Detection checkbox in the DHCP server settings..

4

This is not correct way of solving the problem. The way you solved it now it can happen that two devices end up using the same IP address (if DHCP client doesn’t check IP against being used) … or that client rejects offered lease but MT insists on offering it again and again and at the end client doesn’t get usable IP lease..

MAC address 00:23:04:31:1E:6A is from Cisco range … if it’s not spoofed, then this might mean that in your LAN there’s a cisco device with proxy-arp enabled for the whole IP subnet. Does it have to be that way?

5

Even if thats the case mkx, how do you explain the pool being depleted ?

6

In OP’s post there’s nothing about actual communication between DHCP server and client. So I suppose it’s like this:

  1. DHCP client requests a lease
  2. DHCP server chooses IP address to offer and tries to verify that address is not used by using RFC5227 mechanisms
  3. DHCP server receives reply from mentioned Cisco device and assumes that address is in use and makes note about that (DHCP list entry with status conflict) so that it won’t try to offer same address next time unless necessary. Then it repeats from step #2 until whole address pool is marked as being conflicted.
  4. DHCP server NACKs request for lease

The mentioned RFC describes in detail the way how ARP probe packets have to be constructed and any proxy-ARP devices should be able to recognize them in order not to reply with their own MAC address.
So either there is an address exhaustion attack going on (and attacker uses Cisco MAC to appear more funny) or there’s a genuine Cisco device in the LAN which is either buggy, misconfigured or both. But in any case decision not to check availability of IP address is not the right one. If the attack is going on then DHCP client will get a collision as well, thus offered lease won’t be useful. If there’s no attack, then the problem device has to be exterminated …