No matter what rules I use, I can not block the Mikrotik DHCP Server on UDP 67 from any interfaces. I have deny udp 66-67 on both input and forward chain. That *should* block it from everything, but it has no effect. I have seen a few other posts with this same question.

I have a bridge over L2TP between Mikrotik 3.30 routers, but each end uses its own DHCP, which should not be shared because then one end would be using the gateway of the other end... and they both need internet access even if the other end is down. I have turned on "Use IP Firewall" in the bridge settings.

Please don't make this a discussion about whether or not I should want to block DHCP, or why it needs to be done, or that routing would work better, or any other workarounds.

I am simply wanting to know whether this is by design, that the DHCP Server comes before the firewall... or is this a bug?

Hi,

you configured the filter in bridge/filter? or in ip/firewall filter?

It is configured in IP Firewall.

I *think* (but not 100% certain) that even without a bridge involved, the rules still do nothing.

I have deny udp 66-67 on both input and forward chain

btw, DHCP is ports 67-68...

You are right. I was actually using the correct 67-68 in the rules, the 66 is just a typo on my post.

I have deny udp 66-67 on both input and forward chain

btw, DHCP is ports 67-68...

do you have /interface bridge settings set use-ip-firewall=yes ?

yes, on both sides. also, this is interesting... as i send dhcp requests, i can see the packets on the drop rule increasing, but i always receive a dhcp response, and torch shows it using 67.

Looks like I can reproduce this on 4.1. Not on a bridge, but just on a standard network behind an interface, with standard DHCP server setup.

Cover all chains and drop UDP 67 and 68:
Counters are clear:


Start a traffic capture:
I then put a laptop on the network, it received a DHCP lease.
Stop the capture, check counters, check traffic capture and show DHCP leases:

While the input chain logs two drops and nothing in forward and output, the client still receives a lease from the router, the source MAC on the reply is the interface MAC address.

Thank you for confirming this. I have had this problem since the early 3 versions, but since I don't have a need for blocking very often, I use workarounds.

Now that this is confirmed by someone else, I would still like to know officially if this is a bug, or if the dhcp server sits outside the firewall on purpose, by design. You can block all the other servers on the mikrotik through the firewall, such as ftp, ssh, winbox, etc, without problem.

even back in 2.8 it was this way I believe. Something to do with the kernel receiving the packets before the firewall. I tried finding that post from years ago but can't find it.

Thank you for that information.

If that is how it is, and if it must be that way, I wish those sort of things would be documented to prevent confusion.

My experience is that if you run the DHCP on a VLAN interface, then the traffic is limited to just the VLAN.

For example;

vlan20 (mikrotik DHCP for this vlan only)

vlan30 (windows server DHCP for this vlan only)

Of course you can run dhcp on a single interface, and keep it off the others. The issue here is that once you have dhcp server running on an interface, you can NOT block dhcp on that interface (VLAN or whatever) with IP Firewall. Since 2 different VLANs are different interfaces, the traffic would be seperate, unless you intentionally bridged or routed them together. If dhcp did cross over between vlans or other interfaces, that would definitely be wrong.

This is a linux thing not a mikrotik thing. I have been building fiewalls with linux for a long time and no matter what firewall rules I put in place dhcp still gets through whether it's a client or server on that local firewall.

This is a linux thing not a mikrotik thing. I have been building fiewalls with linux for a long time and no matter what firewall rules I put in place dhcp still gets through whether it's a client or server on that local firewall.

Thank you for that information. I'm glad to at least know now why this issue exists, and that it isn't a Mikrotik bug. It should still be documented, however.

I found this information online which better explains why this happens:

Normally, when programs need network access, they open
an Internet socket, which gets
any packets destined for it and can send packets after the kernel has
applied all IP Tables rules to them. So if you have a policy of
DROP, the socket will not receive or be able to
send that packet.

However, DHCP uses a RAW Internet Socket instead, and receives packets before the IP Tables processing gets it.

Because Raw sockets get packets before the IP Tables processing,
the DHCP traffic is received/sent before IP Tables can allow or deny it.

VERY INTERESTING.

yeah. on the one hand, it's useful when you don't have IP address on DHCP Interface. does anybody here have such setup? =)

on the other hand, for most users non-raw socket is enougn, so it may be a feature request - an option to select DHCP server mode =) or maybe some kind of redirection a packet to IP Firewall (/ip dhcp-server settings set use-ip-firewall=yes? )

Yes, it would be a great feature to have the selectable dhcp server mode, ip-mode/raw-mode.

So I was sitting around watching history channel and I was thinking about this whole issue. The idea is that if the socket is raw and the netfilter rules never see the packets how do we make them see the packets and that when I came up with a pretty cheesy way but it works.

typical setup ether1---->[dhcp-client/dhcp-server]

cheesy way ether1----[Bridge]----[bridge as dhcp-client/dhcp-server]

see the key here is as the packets enter ether1 the next stop is the bridge and as the packets enter the bridge they can be inspected before they get to the bridge which is acting as the dhcp-client/dhcp-server


So create a bridge and attach the ethernet interface to the bridge. then take your dhcp server and reassign it to the bridge instead of the ethernet interface. Then with a rule like this:

/interface bridge filter
add action=drop chain=input comment="" disabled=no ip-protocol=udp mac-protocol=ip src-port=67-68

stopped dhcp from working. I don't know if this helps you at all but this is one method for containing the dhcp packets that otherwise couldn't be stopped.

Sorry of this post is a little scattered. I get that way sometimes.

EDIT: I just realized you were using a bridge after reading back but I think you were using /ip firewall filter. Anway my example uses /interface bridge filter which applies to the bridge and allows you to catch packets comming into the bridge before the interface. Anyway when I use the rule I posted My dhcp does stop working.

That's great to know that the bridge firewall can intercept those packets! You are right, I was using the IP Firewall option, not the Bridge Firewall.

As for the raw versus ip option, I put in a feature request and support said "not currently, but probably in the future".

I would be careful doing any type of filtering on the bridge. As far as I known it's not stateful.

yes, but if you drop not only 67-68/udp, but also dst-address=255.255.255.255 and your_router's_ip, then it should not block something important =)

btw, nice idea

Here's my problem. I have 2 Mikrotiks in a central location, acting as DHCP servers. They are being forwarded bootp traffic from 1800 different subnets, where each subnet has a Cisco router, switch, and wireless lan controller. My Mikrotiks are only there to act as DHCP server and receive traffic based on the router in the remote location having a helper address. So the clients do not ARP on the Mikrotiks. What I see is a DHCP pool filling up with addresses having no MAC address associated. Even if I turn on "add arp for leases", the addresses in the DHCP leases table still have an IP but no MAC. This runs my pool out of addresses and results in DHCP pool exhaustion. I sniffed the traffic and I see in the traces DHCP requests coming from other IP addresses.

From what I know, a DHCP request should come from only another source with no IP address, as a broadcast. A DHCP request. It should not come from another address.

Is there a way I can set up some sort of filter on the firewall to block all bootp traffic from anything other than an accepted source, i.e the downstream router?

I have attached the sniff trace of this condition. rename it as a .cap file.

That's great to know that the bridge firewall can intercept those packets! You are right, I was using the IP Firewall option, not the Bridge Firewall.

As for the raw versus ip option, I put in a feature request and support said "not currently, but probably in the future".

Hello there,

Any news on that ? My ISP need to receive DHCP Request with a priority of 6. In the current state, I can't "manipulate" the dhcp packet with the firewall "stack", so, no connexion... my crr 1009 is a 400 euros paper weight right now :/

Hello there,

Any news on that ? My ISP need to receive DHCP Request with a priority of 6. In the current state, I can't "manipulate" the dhcp packet with the firewall "stack", so, no connexion... my crr 1009 is a 400 euros paper weight right now :/

Is this for your CCR to be a dhcp client, or a dhcp relay?
If client, you should be able to set priority on such traffic using the mangle table's output chain.
/ip firewall mangle
add chain=output out-interface=WAN protocol=udp dst-port=67 action=set-priority new-priority=6

(replace WAN with whichever interface has the dhcp client configured, e.g. ether1-gateway)

Hello there,

Any news on that ? My ISP need to receive DHCP Request with a priority of 6. In the current state, I can't "manipulate" the dhcp packet with the firewall "stack", so, no connexion... my crr 1009 is a 400 euros paper weight right now :/

Is this for your CCR to be a dhcp client, or a dhcp relay?
If client, you should be able to set priority on such traffic using the mangle table's output chain.
/ip firewall mangle
add chain=output out-interface=WAN protocol=udp dst-port=67 action=set-priority new-priority=6

(replace WAN with whichever interface has the dhcp client configured, e.g. ether1-gateway)

My ccr is a dhcp client in that situation.

And your solution doesn't work from what I understand, because the dhcp request is a raw socket thing, and doesn't enter in the firewall stack.

My ccr is a dhcp client in that situation.

And your solution doesn't work from what I understand, because the dhcp request is a raw socket thing, and doesn't enter in the firewall stack.

Actually, you're comparing apples and oranges. This thread is about blocking inbound DHCP request frames from reaching a dhcp server process listening on an interface. The firewall (i.e. netfilters package) can't interfere with / modify these frames due to the fact that the dhcp daemon apparently binds the raw ethernet interface and not a UDP socket - so it has the same access to an interface that sniffer would - namely it sees the frames before they are passed to the firewall....

However, your situation is that you want to modify packets as they are being sent from the dhcp client process, which is different, so it's entirely likely that you can just modify the priority. (which if memory serves is a field in a VLAN header, not a packet header) - now it's still possible that the dhcp client process is also operating at a raw frames level and would thus bypass the mangle table as well, but you could watch the rule for hits, and verify with sniffer+wireshark that the priority is being set properly. If the mangle table doesn't see any hits, then you could also use the bridge filter solution above to modify the outgoing DHCP requests. (output bridge filter chain) Honestly, I'm not sure why the ISP requires that a priority be set - is this using some kind of WiMax connection? (that's the only thing I've ever messed with that maps traffic based on priority as a pure requirement)

My ccr is a dhcp client in that situation.

And your solution doesn't work from what I understand, because the dhcp request is a raw socket thing, and doesn't enter in the firewall stack.

Actually, you're comparing apples and oranges. This thread is about blocking inbound DHCP request frames from reaching a dhcp server process listening on an interface. The firewall (i.e. netfilters package) can't interfere with / modify these frames due to the fact that the dhcp daemon apparently binds the raw ethernet interface and not a UDP socket - so it has the same access to an interface that sniffer would - namely it sees the frames before they are passed to the firewall....

However, your situation is that you want to modify packets as they are being sent from the dhcp client process, which is different, so it's entirely likely that you can just modify the priority. (which if memory serves is a field in a VLAN header, not a packet header) - now it's still possible that the dhcp client process is also operating at a raw frames level and would thus bypass the mangle table as well, but you could watch the rule for hits, and verify with sniffer+wireshark that the priority is being set properly. If the mangle table doesn't see any hits, then you could also use the bridge filter solution above to modify the outgoing DHCP requests. (output bridge filter chain) Honestly, I'm not sure why the ISP requires that a priority be set - is this using some kind of WiMax connection? (that's the only thing I've ever messed with that maps traffic based on priority as a pure requirement)

Thx for the input. I tried mangle, and it does'nt work.

I don't really get the bridge thing.

My wan interface is a vlan interace (vlan832), linked to ether8
/interface vlan
add interface=ether8 name=vlan832-orange vlan-id=832 mtu=1500 arp=enabled use-service-tag=no

and this is a part of my dhcp client :
/ip dhcp-client
add interface=vlan832-orange disabled=no add-default-route=yes default-route-distance=1 use-peer-dns=yes use-peer-ntp=yes dhcp-options=hostname,clientid,authsend,userclass,vendor-class-identifier

My "lan" interface is a classic ethernet one.

A bridge is composed by multiples interface, right ? So, "what" do I bridge ?

Sorry if this us basic, but I'm a little lost.

Thx for your input anyway, it's appreciated


(oh by the way, the isp is Orange, the biggest french one, for fiber access)

make a bridge called WAN
/interface bridge add name=WAN

connect the ether8 interface to it:
/interface bridge port add interface=ether8 bridge=WAN

move the vlan interface off of ether8 and onto the WAN bridge
/interface vlan set [find where name=vlan832-orange] interface=WAN

Then make a bridge filter rule:
/interface bridge filter add action=set-priority chain=output dst-port=67 out-bridge=WAN ip-protocol=udp mac-protocol=ip \
new-priority=6 out-interface=ether8

make a bridge called WAN
/interface bridge add name=WAN

connect the ether8 interface to it:
/interface bridge port add interface=ether8 bridge=WAN

move the vlan interface off of ether8 and onto the WAN bridge
/interface vlan set [find where name=vlan832-orange] interface=WAN

Then make a bridge filter rule:
/interface bridge filter add action=set-priority chain=output dst-port=67 out-bridge=WAN ip-protocol=udp mac-protocol=ip \
new-priority=6 out-interface=ether8

Thx, I just tried, but the bridge filter rule does nothing, the counters stay at 0. For the sake of it I tried to change to out-interface to vlan832-orange, same thing.

Thx, I just tried, but the bridge filter rule does nothing, the counters stay at 0. For the sake of it I tried to change to out-interface to vlan832-orange, same thing.

Try in-bridge instead of out-bridge or just leaving no bridge specified?

Also - you might grab a quick paket sniffer capture to disk and open it in wireshark to double-check the port number and so forth.

Thx, I just tried, but the bridge filter rule does nothing, the counters stay at 0. For the sake of it I tried to change to out-interface to vlan832-orange, same thing.

Try in-bridge instead of out-bridge or just leaving no bridge specified?

Also - you might grab a quick paket sniffer capture to disk and open it in wireshark to double-check the port number and so forth.

Can't in-bridge with an output chain. The logic seems good, the packet sniffer show that dhcp packet, dst port 67 are emitted from the WAN bridge, but still, the bridge filters is not used...

Thx a lot for your time, but I'll give up on this one. Using bridge is not a good solution for my anyway. Either Mikrotik tweak their dhcp client, or I'll sell this CCR which is useless now.

Does the CCR have a hardware switch on it? (too lazy and braindead today to go look at the product flier on routerboard.com)

If so, there's an option in the HW switch to twiddle things, including the Dot1P priority value - my 2011 has settings for this, and perhaps this would be the best way to do it w/o using a bridge.

Does the CCR have a hardware switch on it? (too lazy and braindead today to go look at the product flier on routerboard.com)

If so, there's an option in the HW switch to twiddle things, including the Dot1P priority value - my 2011 has settings for this, and perhaps this would be the best way to do it w/o using a bridge.

Yes there is an hw switch. Can you put a priority on only one type of traffic with the dot1P function ?

I would think that you could limit the scope of the rule with some Match criteria -

My 2011 has an IP section, and I would assume that you could set protocol = udp, and dst port = 67, and I'd list ports = ether8 (and choose the proper switch if there are multiple hw switches in the device). I'd say action=new VLAN priority = 6

There is another discussion on the topic: viewtopic.php?f=2&t=140569&p=722876