Hi,
We have been getting complaints from our transit providers and internet exchange that there has been a lot of requests from a DHCP client on our router coming from our router. We are able to see lots of traffic on another connected router on port 67 and 68 coming from the affected router. We have no alerts setup to monitor DHCP servers and no DHCP clients or servers setup.
This problem seems to be happening since we updated to V6.43.8.

Is anyone else experiencing similar issues or know what might be causing it. Help is much appreciated.

Thanks.
Stephen

I notice that Mikrotik were working on some DHCP client updates in 6.43 and DHCP server updates in 6.43.8. I wonder is anything related (was a bug introduced) ?. There is no mention of DHCP fixes in the 6.43.X Changelogs (https://mikrotik.com/download/changelogs/).

Derek

I haven't notice anything similar happening on 6.43.8 or any other version. What was your previous version? I think it is very unlikely that your particular device will make those requests without proper reason (i.e. some (mis)configuration)

Personally, I would firstly recommend to make sure that those DHCP requests are originating from your device (i.e. not leaking from your lan somehow)
1) make sure that you are sniffing ONLY your router (i.e. you literary connect your sniffer/TAP device to WAN port of your router and there is no way for any other device to be connected to the same port of your TAP, where you are sniffing)
2) check the MAC of sniffed packets - does it corespond with your router?
3) check the content - there will be likely hostname - does it point to your router as well?
4) disconnect your router for few seconds - do the DHCP packets stop during that time? and start again once you connect your device back?

In any case, I guess you will need to share your config . (feel free to replace any personal info like public IP etc..)

I believe it might be also beneficial to share few of your captured packets. (RouterOS can do capture to file. Screenshot does not really tell much)

seen seemingly similar issue here viewtopic.php?f=2&t=144957

Good catch! I missed that one
Although it does not change the fact I don't see any unusual requests on a network with many mikrotiks. Not saying that there is no bug, it just seems unlikely.

Hi,
I can confirm that a packet sniff on another connected router shows that the source MAC address is the problematic router.

The router has a couple hundred Mbps at any one time so it’s not possible to unplug it to test. It is located in a remote datacenter that we would rather not have to go to.
We recently updated from v6.38.x

We have put a block on all possible chains in every possible place of the firewall to block port 67 and 68 And nothing has stopped it.

As for config there is a lot of sensitive details but its basically a pppoe Server linking to a radius client. A few vlans and 1/2 l2tp/pptp Servers. No dhcp servers or clients or anything special. Only firewall rules are ones to try stop this bug

We are looking at downgrading soon if there is no solution to the problem.


Thanks for your help

Stephen

We have put a block on all possible chains, in every possible place of the firewall to block port 67 and 68. And nothing has stopped it.

DHCP uses raw sockets (a socket of protocol raw instead of tcp/udp). Thus it is not visible to the IP / Firewall rules. This is a Linux kernel design, not a MikroTik decision. I don't know if the new raw table in MikroTik could drop them, but give it a try.

Ah ok, thanks that makes sense. We tried the raw filter and no luck. So I guess that cant be blocked.

How are you accessing the router? Just wondering if its been compromised or does the type of excess traffic not indicate that possibility??

Anything can be blocked with bridge-filter (including BPDU frames, neighbor discovery, MAC server etc...). All you need to do is put your WAN port as a single port into new bridge (obviously, make it non-STP) and hook all your firewall rules, dhcp-client and other things on the bridge, instead of Ether port. It will obviously have a slight performance impact but it gives you full control...

Hi. I think we are going to have to try the bridge filter next. We downgraded to v6.42.11 but the problem still exists.

I have looked through the export and there is nothing configured in /ip dhcp-client/server/relay. Same for Ipv6 even though that shouldn’t matter. (Different port). I don’t see any other explanation other than there is a bug affecting some routers.

I will work on editing the config to hide all the ips and names and passwords and send it to here tonight, just in case we missed something.


We are accessing it through Winbox on a different port number than standard. I don’t think there is malware.

Thanks

This is caused by two different issues:

1. sometimes RouterOS just adds a DHCP client to an interface when it believes it has no connectivity. this happens at boot only. just remove or disable the DHCP client.
(maybe in a scheduled script when it is persistently returning on reboot)

2. there is the "Detect internet" (mis)feature that also does send DHCP requests. disable it. ("detect internet" button in the interface menu, set all lists to "none")

Finally there is a "IP dhcp-server alerts" page where you can send DHCP requests just to check if a rogue DHCP server is present on your network, but you would have to have enabled that manually.