Question the hive;
What are pros and cons of using RAW instead of filters assuming you do not have connection tracking turned on. (or even if you do)
You can match input chain by adding a jump to dst address type local, jump to a raw-input chain.
Any other pros/cons to this?
In most cases most of the extra bloatware is not required. Use drop all at end of input chain and forward chain and get a life, go see a movie.
Raw is less processor load. A lot less.
Raw should only be considered by advanced users. The wrong use or unexpected consequences of raw are not trivial and in 99% of cases not needed especially by homeowners.
It would be a rare case IMHO that use of raw over standard filters would make a significant difference in the user experience.
Being trainer certified, probably fine to use if you have heavy load and a client needs an efficient as possible setup. On the other hand any setup should be designed at 50% capacity max from the get go. So I still have my doubts.
What peeves me is the MT recommended bloatware firewall page where all these newbies are getting the idea to stuff their config which sheite they dont really understand nevermind dont need.
So hoelve dont promote or support this BS or I will have to visit, and drink your booze, eat your food and convince your spouse I am a far better option (assuming your a he/hij lol)
Assuming that the router has connection tracking turned on. What if it is off? I would assume RAW would be the FIRST place to drop or accept data, but just trying to understand if there is any CONs to it or not.
So we have an advanced user using it. We also have a router without connection tracking. Why is Filter Better than RAW on Input and forward, or why is RAW better in those cases?
IMHO there is no reason to use raw unless performance is being affected, either at the router level or user level.
Why? Does it cost more to use or cost less, or the same?
Cost is not important to me. Clear concise, simple config is what matters to me.
Is the user traffic flowing, does it meet the requirements. Anything extra is time I can spend elsewhere…
If user traffic is not flowing or some requirements are not met, then we adjust the config.
Well that’s not what I am asking. I am asking, is there any Pros/Cons to using RAW only in this specific instance.
As far as I understand packet flow, if connection tracking is disabled the only pro of using filters (vs. raw) is that it offers distinction between input/forward/output chains … if that matters, then its much harder to recreate same firewall functionality in raw.
I don’t see any other (important) difference.
Isolating a single idea within a config without context is simply not relevant. Whether you are asking do I pick my nose with a wooden spoon or a spatula, Im saying dont pick your nose.
What your asking has no relevancy to anything tangible, other than wasting your own time. L8r
If I was you I would have read my first response, and said got it, and left my computer and headed to either 1860’s Saloon and Hard Shell Café or BB’s Jazz, Blues and Soups!!
Get your priorities straight man! 
If you do not drop, for example DDoS attack on RAW side, it consume also:
connection-tracking resources (when is enabled)
mangle on prerouting resources (when are present)
dst-nat resources (when are present)
bridge resources (if involved)
cpu resources to subtract -1 to TTL (or drop packet)
again mangle on forward (when are present)
and finally are dropped on drop-all-at-the-end on filter.
Using RAW, you do not deplete all involved resources to drop on filter, but you drop packet instantly.
RAW is fast than filters, but the reason for use RAW is not the speed, is the used resource between the ingress and the drop of the packet.
But obviously is not black or white, each need must be pondered,
for example drop all packet with spam source directly on RAW if you host by NAT a webserver, reachable forom outside, inside your network,
instead of deplete resources on router for drop later on filter the packets from spam or malicious sources.
Egads rextended, I hope you dont spend your whole life pondering such vacuous concerns............... Okay as long as its done as an excuse to enjoy a bottle of Italian Red..............
And I do agree with this. Lets use a specific example, all I wish to allow to the router is ICMP, and a list of admin_IPs addresses, everything else should be stopped.
This can be accomplished in the input chain of the firewall by :
src-address=admin_IP action=accept
protocol=icmp action=accept
and action drop
Three rules. but it has to go though all of what you mentioned before, CPU resources etc.. Even if you don't have connection tracking on, it still goes though those services in RouterOS.
So the next question is SHOULD I do it in RAW only. How.
chain=prerouting dst-address-type=local action=jump jump-target=in-raw
chain=in-raw src-address=admin_ip action=accept
protocol=icmp action=accept
action=drop
So 4 rules vs 3, but you also don't waist any CPU before that, it just drops anything that does not match that.
So the question is, in this specific example, why not use RAW if you are trying to make the router preform at its best. IS there a CON or something with with this specific example that would make this not more efficient than using filter rules. ? Note there may not be, I can't think of it, but hence why I am asking here. ?
There should be fifth rule, second in chain=in-raw … dropping all. If you introduce a custom chain and packet passes through all rules without matching, then processing returns to previous chain right after the action=jump rule.
For this particular case, with single rule in custom chain, I’d add the additional selection criteria (src-address) to the first rule. But I agree that if there were some more rules in custom chain, it would be quite effective.
why so much rules?
beautiful explanation about the topic, thank you
So in this instance, any reason NOT to use RAW instead of input filters?
It seems clear to me that, for me, there is nothing against it, but just one rule is enough to deal with it, in addition to the others for the rest.