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.Raw is less processor load. A lot less.
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?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.
Why? Does it cost more to use or cost less, or the same?Why do you quote whole preceding post? Does it help answering? Do you repeat what your interlocutor says when you discuss? Just use "Post Reply" button.
Well that's not what I am asking. I am asking, is there any Pros/Cons to using RAW only in this specific instance.Why do you quote whole preceding post? Does it help answering? Do you repeat what your interlocutor says when you discuss?
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.Well that's not what I am asking. I am asking, is there any Pros/Cons to using RAW only in this specific instance.Why do you quote whole preceding post? Does it help answering? Do you repeat what your interlocutor says when you discuss?
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..............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.
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.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.
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.
For home users? Stateful + stateless rules is fine on a single router. That's what I do on my personal home router. It will die on 20G DDoS but I don't have 20G internet bandwidth, so it doesn't matter for home much.Hi Dark Nate,
Do you recommend then simply getting another MT router to act as stateless edge router that gets public IP and if so, how do you then feed the next router ( my current router ) with that connection so that internet still flows in both directions?? Do you create a LAN on the stateless router........ ????????
Now you are contradicting yourself ////For home users? Stateful + stateless rules is fine on a single router.
Read the official explanation:About this matter
I have a doubt:
Doing Traffic filtering on a switch by using Hardware ACLs before traffic reach the router can be a feasible way to firewall a router without loosing the high performance fast-path mode?
forward - filters packets, which are to be bridged (note: this chain is not applied to the packets that should be routed through the router, just to those that are traversing between the ports of the same bridge)
Which part of home user vs production network do you not understand?Now you are contradicting yourself ////For home users? Stateful + stateless rules is fine on a single router.
remember........---> If you completely use only RAW table and therefore your router is stateless, even a 20G multi-gigabit DDoS will not cause the router to crash or reboot. But start using conn_track and good luck on a DDoS attack.
So I will ask once again how to setup a router in front of my current router that is stateless??
@chechito: it is an excellent way to filter the router, but you need an extra device to do that, and you should have a switch that supports an high number of rules. They are stateless rules and works at wire-speed.
Read the official explanation:About this matter
I have a doubt:
Doing Traffic filtering on a switch by using Hardware ACLs before traffic reach the router can be a feasible way to firewall a router without loosing the high performance fast-path mode?
https://help.mikrotik.com/docs/display/ ... geFirewall
You will quickly understand it is designed only for LAN/L2 filtering. It cannot be fully realised for internet origin or internet bound traffic.
forward - filters packets, which are to be bridged (note: this chain is not applied to the packets that should be routed through the router, just to those that are traversing between the ports of the same bridge)
Ah that, yes. You can use it for strong, plain, basic filtering stateless, it is faster than RAW table (CPU). But you should be careful to keep in mind, it doesn't have all the parameters and knobs available on iptables. As long as you know what you're doing, it is a perfectly valid alternative to raw.I refer more to these
Switch Chip Features -> Rule Table (not Bridge -> Packet Filter)
Switch Chip Rule Table runs at wirespeed Hardware Accelerated
https://help.mikrotik.com/docs/display/ ... -RuleTable
this are able to include useful parameters like:
dst-address (IP address/Mask)
dst-address6 (IPv6 address/Mask)
src-address (IP address/Mask)
src-address6 (IPv6 address/Mask)