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?
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.
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:
[admin@Mikrotik] > /tool sniffer stop
[admin@Mikrotik] > /ip firewall filter print stat
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 input drop 656 2
1 forward drop 0 0
2 output drop 0 0
[admin@Mikrotik] > /tool sniffer packet print det
0 time=1.662 direction=in src-mac=00:1E:52:87:F4:4A dst-mac=FF:FF:FF:FF:FF:FF
interface=vlan935 src-address=0.0.0.0:68 (bootpc)
dst-address=255.255.255.255:67 (bootps) protocol=ip ip-protocol=udp size=342
ip-packet-size=328 ip-header-size=20 dscp=0 identification=4229
fragment-offset=0 ttl=255
1 time=1.663 direction=out src-mac=00:0C:42:43:62:C9 dst-mac=00:1E:52:87:F4:4A
interface=vlan935 src-address=10.35.0.1:67 (bootps)
dst-address=10.35.0.254:68 (bootpc) protocol=ip ip-protocol=udp size=342
ip-packet-size=328 ip-header-size=20 dscp=0 identification=0 fragment-offset=0
ttl=16
[admin@Mikrotik] > /ip dhcp-server lease print
Flags: X - disabled, R - radius, D - dynamic, B - blocked
# ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS
0 D 10.35.0.254 00:1E:52:87:F4:4A test-lap... DHCP-... bound
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.
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.
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.
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? )
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.
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:
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.
)