SYN filtering

RouterOS General
1

Hi,

Im trying to implement the following rules listed in https://wiki.mikrotik.com/wiki/DoS_attack_protection, but whenever this rules is enable, I cannot run speedtest-cli script. Well, not that I cant, it just showing 10-20 Mbps limit with very high latency. But when I disable it, speedtest is excellent.

/ip firewall filter add chain=forward protocol=tcp tcp-flags=syn connection-state=new action=jump jump-target=SYN-Protect comment="SYN Flood protect" disabled=yes 
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn limit=400,5 connection-state=new action=accept comment="" disabled=no
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn connection-state=new action=drop comment="" disabled=no

FYI, this is start to happen yesterday and before that is all good. And no modification made in my router. So thats make me even more confused.

2

You probably ought to add some interface matchers to those rules.

3

Hi, thanks for the respond. But I dont understand what are you talking about. Can you please explain more?

4

Look up in-interface= and out-interface= on the Wiki
Presumably you only need to protect against DoS from the incoming internet interface (whatever that is).
Then your outgoing connections to Speedtest shouldn’t be affected.

5

Yes, after changing the interface in its finally working. Thanks a lot…

6

It is not very useful, especially when done in this way.
The SYN packets that you drop will still setup a connection tracking entry, so they will end up loading the router CPU anyway.
The Wiki article was probably written before there were more advanced methods of doing this in RouterOS.

It only helps to protect systems “behind” the router, and maybe you do not even allow incoming traffic anyway (e.g. because the router is performing NAT).
Furthermore, when your input line is saturated with DDoS traffic, no filtering at your router is going to solve that issue.

Resist the temptation to, as a beginner, try to cover for every possible scenario you can think of or have read about. In practice it usually does not solve
anything, and causes random problems that leave you puzzled.
It is better to keep your config lean and simple, and first gain some experience to see what kind of things you might want to spend some more detailed
attention to.

(this applies to such filtering as discussed in this topic, to filtering all kinds of “invalid” packets as determined by flags, to automatic filters that enter
suspect systems in a blocklist automatically, etc etc)