I use this command for my edge routers at times. I was wondering if it could be also used for Mikrotik?
set system conntrack ignore rule 10 destination address 255.255.255.255
ive tried ..
/ip firewall filter add action=drop chain=forward dst-address=255.255.255.255
But it doesn’t seem to work..
Goal is to prevent unwanted connections from being tracked and consuming resources.
The “pseudo ROS” firewall rule won’t do anything. Broadcasts are not routed between different router interfaces (which is where chain=forward works).
I’m not fluent in edge-ish, but I guess you would like to disable connection tracking for certain traffic. You can achieve that by rule something like this:
/ip firewall raw
add chain=prerouting action=notrack dst-address=255.255.255.255
which will instruct connection tracking machinery not to track those packets. If you want to do something about those packets later in firewall filter, then note that connection-state of those packets will not be known … it will rather be “untracked”. Beware: default firewall config has rule which explicitly allows untracked packets (part of “action=accept connection-state=established,related,untracked” rule).
I did this to try and log it and it looks like the broadcast connections are being blocked.
Does this look correct.. these rules are the first 2
add action=log chain=input dst-address=255.255.255.255
add action=drop chain=input dst-address=255.255.255.255
That is exactly what im trying to do.. Im going to remove the rule I added and add yours.
Thank you so much
They are blocked in chain=input (because chain=input is used for traffic destined to router itself … and broadcasts can target router, e.g. for DHCP discovery etc.) … However they are not even hitting chain=forward because router will not pass them to another interface.
If you’re going to drop those packets, then you can drop them in raw (just change action to drop). If you’re going to pass them, then default firewall filter rule will do. If you want to filter them using some fancy criteria, then you’ll have to do it same as you’d do it for normal tracked connections.
If the amount of traffic you want not to be tracked is small portion of total amount, then I doubt you’ll gain much WRT performance of router.
I didnt even think about that, I really just wanted to have less connections tracked by the router that I didnt need. But now that you mention that with DHCP, would that drop broadcast rule of stopped router from doing DHCP, this router will be doing DHCP.. A lot actually lol
I am trying to reserve resources on the router and keep as many states available as possible, do you think me going this route makes sense?
Still learning.. 
Every DHCP handshake starts with DHCP discovery … where DHCP client sends packet to 255.255.255.255 (with src-port=68 and dst-port=67 … or the other way around, I always forget) and DHCP server has to reply to that. So yes, dropping all broadcast packets will interfere. It does seem that DHCP server for IPv4 hooks into network stack lower (closer to hardware) than firewall so it might even work despite such firewall filter. Not in IPv6 though.
Personally I wouldn’t bother with filtering broadcasts (as it can potentially interfere with normal operations and it’s hard to debug such cases). If amount of broadcasts will be high enough to make noticeable load on router, you’ll have to deal with it at source of that traffic. Or you’ll want to drop it early (like in raw), so not tracking it is IMO side step.
@mkx,
shouldn’t it be then to ACCEPT broadcast packets that have src/dst ports as 68/67, and the subsequent rule to DROP other broadcast packets to 255.255.255.255?
wouldn’t that work?
Yes, that would likely work.
Personally, I’d rather go in line with default firewall config: which is to allow everything on chain=input comming in via LAN interfaces and drop everything else on chain=input. As I already explained, broadcasts don’t get routed (so nothing to block in chain=forward) and one mostyl doesn’t want to allow broadcasts getting in via WAN interface(s). And there are a few services, using broadcasts, which should be allowed on LAN side.
Keep things as simple as possible … with less rules there are less chances to mess something up. But yes, some basic knowledge about how IP (and IPv6) works (such as basics about routing of broadcasts), does help.