my q was, does it something thats a MUST HAVE this input chain rules to have most of the benefits of the firewall. Is there some updated firewall rules for preventing intrusions?Maybe someone to share their firewall without sensitive data ofc
Short answer: yes, it is a must have.
Long answer:
Fasttracking means that packets belonging to existing connections bypass
- all the rest of the firewall handling following the connection tracking
- IPsec policy matching
- queues except the interface ones.
So if fasttracking rule lowers the CPU load significantly, something in the above list is causing the CPU load.
Without fasttracking, the
action=accept connection-state=established,related,untracked accepts the part of forwarded traffic which would otherwise be accepted due to fasttracking. Only initial packets of forwarded connections will make it past this rule to the subsequent filter ones; these subsequent rules decide which connections will be permitted and which will not.
If connection tracking is active, every single packet is compared to the complete list of existing connections. And if it matches any already existing one, it is labeled with connection-state "established", and the rule you mention accepts it (or fasttracking accepts it instead if enabled).
The connection tracking itself is also quite CPU intensive, and fasttracking makes no sense in input chain. So as in your case, a lot of traffic is probably IPsec one, you could use
chain=prerouting dst-address-type=local protocol=udp dst-port=500,4500 action=notrack
chain=prerouting dst-address-type=local protocol=ipsec-esp action=notrack
chain=output protocol=udp src-port=500,4500 action=notrack
chain=output protocol=ipsec-esp action=notrack
rules in
/ip firewall raw to prevent IPsec packets to and from your router itself from being connection-tracked. The same rule in filter will accept them as it matches also on connection-state "untracked", but the amount of CPU spent on those
raw rules may be lower than the one otherwise spent by connection-tracking on the same packets. The actual benefit of this depends on the amount of tracked connections in total.
If you eventually don't need to use the router as a firewall for forwarded traffic, you may stop using connection tracking at all and only use rules in input chain to protect the router itself. Connection tracking is common for all traffic (both local and forwarded), so stopping to refer to
connection-state and
connection-nat-state only in
input chain of filter will not help lower the CPU load. But in that case, the order of the rules in the filter is very important - most packets should pass through the least number of rules, so accept rules for the most frequent packets must be at the top of the list (probably ipsec-esp).