Hi

I would really appreciate some help - I've gone through the manual and some literature, but I still can't figure out exactly what to do.

Here's the scenario: Our wireless network broadcasts on the 172.XX.XX.0/24 range (DHCP to client PC's is done via a DHCP server).
One (or more) of the clients are running a device which also applies DHCP, but on the 192.168.1.0/24 range. This seems to restrict clients on the 172.XX.XX.0/24 range of getting DHCP addresses.

What do I need to do on the mikrotik firewall to block the DHCP on the 192.168.1.0/24 range, while ensuring connectivity on the 172.XX.XX.0/24 range. Also, I understand that if default forwarding is disabled, clients won't "see" each other. However, I'd still like some PC's to be able to communicate with each other (for LAN gaming).

How EXACTLY do I do this on the Firewall? I attempted something earlier (IP filtering), but this pervented me from accessing the AP.

Please help!

I would figure out what customer is broadcasting a DHCP server on your network, have the customer fix it and then be done with it. As for setting up something to keep this from happening in the future, you would probably want to setup some filtering either in your ip firewall filter or bridge filtering.

-Kevin

Just off the top of my head.

In the firewall:

chain-forward
source ip - 192.168.0.0/16
protocol - udp
ports 67 & 68
action - drop

that should do it...

Thanks for the responses!

you have to set your dhcp server in authoritive mode: and no need for any filters or anything

We use a remote DHCP server (Cisco) - will the authorative mode setting still be applicable?

no of course. unless your cisco has something like that.

if your remote cisco dhcp server is handling dhcp requests then yes, set this setting to that router (if there is one). For cisco related questions please look elsewhere as this is RouterOS forums. Thanks.

if you have routeros handling your DHCP requests then set authoritative to yes and that will solve your rogue dhcp server problem.

if you have routeros handling your DHCP requests then set authoritative to yes and that will solve your rogue dhcp server problem.

I have routeros dhcp server, set with authoritative=yes but I still have problems with rogue dhcp servers on my network. the actual dhcp server runs on routeros 2.9.44 so maybe an upgrade would help solve this problem for me ?

I also have many issues with rogue DHCP servers on my networks. I work for an ISP specializing in student housing. It is a nightmare for this exact issue.

I set DHCP authoritative to "yes" and this does not solve the problem. The only way that we can work around this is by tracking down the port that the rogue DHCP server is connected to, and disabling that port.

Is there something that I am missing here? It seems that a lot of RouterOS users are having this issue with very little feedback as to effectively mitigate these users.

A firewall rule seems that it would be ineffective because a DHCP broadcast does not have to flow through the firewall before it reaches, and receives a response from, a user.

Usually you can't solve this problem on the device that runs as a DHCP server on a LAN with client interconnection for the very reason you're giving: another unauthorized DHCP server may be closer to the client and respond first. Most DHCP client implementations just use the first offer received, so if the rogue is closer, it sends faster, and the client takes that lease. You can't filter that traffic on the DHCP server because it simply isn't involved in the conversation at all.

The only proper solution is to filter traffic on the edge customer ports and drop packets from a DHCP server to a DHCP client inbound on the port so that no device attached to an edge customer ports can act as a DHCP server as it can't send traffic back to the clients. Most managed layer 2 switches (Cisco, HP, Brocade, Foundry) have functionality specifically for this. An alternative would be private VLANs, where each client port can't talk to other client ports at all. This also solves other security concerns, but may not work for you if clients are required to talk to one another.

Of course, if you're using devices running RouterOS for customer edge ports you can implement filtering there.

Agree with fewi. Bridge filters can be used to achieve this.

Thank you for the quick replies.

I will look into the features of our layer 2 switches for some filtering capabilities. We are currently using old 3COM switches but will soon be upgrading to AdTran's NetVanta series switches. We will see how goes.

Thanks again.

Authoritative = yes does not work if another DHCP server is faster to reply.


The filtering needs to be done inside a level 2 managed switch, with the DHCP snooping function, filtering the edge ports for unauthorized DHCP trafic. You define the authorized DHCP servers MAC addresses and ports for each VLAN, and you are ok.


Another solution is to use port forwarding filtering, still present on most true level 2 managed switches, with this function you can forbid communications between clients computers, but allow communication to the server or gateway.

The best is the first solution, so that you can keep inter client communication if needed.

You will not have those functions on managed low cost smart switches. You need true level 2, 2+ or 3 switches to get this.

Authoritative = yes does not work if another DHCP server is faster to reply.

Thats right, I have the same problem when somebody plug in some home router to our LAN, but via the bad socket
Central Mikrotik's DHCP is set as authoritative, but some PCs closer to that rouge DHCP still gets that bad IPs.

This firewall rule fixed it
The source address !192.168.10.1 shouldn't be necessary, it's here only to be sure that this rule will not block the main DHCP in some looping packets. 192.168.10.1 is of course the ip of Mikrotik itself.

Authoritative = yes does not work if another DHCP server is faster to reply.

Thats right, I have the same problem when somebody plug in some home router to our LAN, but via the bad socket
Central Mikrotik's DHCP is set as authoritative, but some PCs closer to that rouge DHCP still gets that bad IPs.

This firewall rule fixed it

Code: Select all

/ip firewall filter add chain=forward action=drop protocol=udp src-address=!192.168.10.1 src-port=67 dst-port=68 

The source address !192.168.10.1 shouldn't be necessary, it's here only to be sure that this rule will not block the main DHCP in some looping packets. 192.168.10.1 is of course the ip of Mikrotik itself.

Thanks!!!

Just off the top of my head.

In the firewall:

chain-forward
source ip - 192.168.0.0/16
protocol - udp
ports 67 & 68
action - drop

that should do it...

Authoritative etc..... not working... this way ive solved it. Trust the firewall....

This was for TPLINK Devices in my network which were providing Rogue DHCP...

That firewall rule is of course only valid for some very specific situations with multiple networks, on the
typical home-router configuration with a local bridge between LAN and WIFI and the MikroTik being DHCP
server on that bridge, it will do absolutely nothing.

You can do DHCP filtering in the bridge, but it is not as simple as that rule and it will of course not work
between ethernet ports that are on a switch, or between WiFi clients when default forward is enabled.

Maybe an option is to detect, rather than block, rogue DHCP servers. This is possible in RouterOS, look
under IP->DHCP server on the tab Alerts and configure an alert. Of course the difficulty is how to see
the alert and then have someone act upon it. But you can use it in debugging as well, enable this and
look in the log.