firewall slow down forwarding packets

RouterOS General
1

Hi ppl.

I have a RB450G using ether1 port for WAN and ether5 as multiple vlan interfaces with diferent ip segment and src-nat. I set a firewall filter to protect my box from internet and internal spammers. For that matter i kind of combined many rules founded in mikrotik wiki. I noted after firewall setup, the increment of ping response time, increment of internal network SSH login time and http browse response time to networks that RB450G route on the LAN interface. I need to test if my firewall rules are rising the response time for the applications named before.
My RB450G is around 2-6% of utilization.

How can i check which firewall policy is increasing packets process..?
What are the essential rules needed to be added into filter ..?

Have anyone experience this type of issue, how did you solved..??


Best regards

2

Every packet is processed by every firewall filter until matched. So if you have many rules it will slow down packet forwarding.

To increase forwarding speed you should add three rules at the top of firewall rule list
*) accept established connections
*) accept related connections
*) drop invalid connections

3

If those rules are at top of other rules then it will ignore a lot of rules bellow . maybe you want drop some conditions of established or related connections but if

*) accept established connections
*) accept related connections

are at top then other will be ignored . am i correct ?

4

maybe you want drop some conditions of established or related connections

Then move those special condition rules before accepting established and related.

5

And why

*) drop invalid connections

Should be last one of those three rules ? isn’t faster if first drop invalid connections ?

6

A firewall connection-state has only 1 status:
it is either new,established,related, OR invalid.

A single packet can not be more than one of these states.

7

yep, there are much more valid connections than invalid ones =)

if it’s not your case - then you should fix your network, not move the rule at the top =)

8

I say if invalid connections are not usually useful then it is better to drop them at first rule .

9

I just listed rules that should be at the top… It is not an ordered list so it doesn’t say that invalid rule should be third.

10

I have seen such order at other places like user contributed wiki and mature user forum posts and it was always a question for me .
Do you suggest to put that rule at first or not ? why ?
thanks .

11

omg… an example. two rules: accept established, drop invalid. let’s suppose we have 1000 packets of established and 10 packets of invalid connections per second

case A:

  1. accept established
  2. drop invalid
    there are 1020 rules processed (1000 packets of established connections are accepted by 1st rule, 10 invalid packets are passed by 1st rule, and those 10 are dropped by 2nd rule)

case B:

  1. drop invalid
  2. accept established
    now 2010 rules processed (1000 of 1st rule + 1000 of 2nd rule + 10 of 1st rule)

almost two times more =) so the main statement is to accept all connections we have already checked by the first rule, i.e. accept established

p.s. again: established connection cannot be invalid; invalid connection cannot be established

12

Reset all your firewall rule counters. Let your router run for a few days.

If you ‘invalid’ connection-state rule has higher counter, move it higher in the rule-set.

If you ‘established’ connection-state rule has higher counter, move it higher in the rule-set.

If you ‘related’ connection-state rule has higher counter, move it higher in the rule-set.

…

You get the idea. Basically, you’re network is individual to you only. What works for you may/may not work for everyone else.

Testing is the key here.

13

i cant find the post, but mikrotik suggested putting invalid rule BEFORE established rule, because certain established packets are considered established when they shouldn’t be. i will see if i can dig up their explanation. invalid should be before established to weed out hackers that modify packets.

14

so, connection-state is not single-valued?..

15

Hi ppl.

From what i read, i understood is nessesary to place these 3 rules first:

1 - allow established
2 - allow related
3 - drop invalid

But i have other rules i need to apply to any packet in the input and forward chain. So where do i place this rules above or below .?

My RB450G is not at high CPU %, so is it real my network is slowed down because of firewall rules..??

I used the RB450G as the default gateway for all my network, it routes traffic to remote IPSec networks through other gateways within the LAN. Before i installed the RB450G my connectivity to these remote networks were “fast” but after installed the RB450G, ssh, telnet and httpd takes about 15-20 seconds to response. Ping instead has a normal response delay.

Any suggestion..?


Best regards

16

I am fairly certain a single packet can have only 1 state at a time, meaning a packet could not be ‘invalid’ and ‘established’ at the same time. This means if you drop invalid connections before established, or vise versa would not matter.

It may be wise to put invalid rule before established rule if more invalid connections came in (they wouldn’t hit the established rule every time taking more processing power).

If it is true you can have multiple states per packet, Mikrotik should allow this to be entered on a filter rule.

17

then how come when you put invalid first you drop more packets than when its afterwards? try it yourself and you will see the difference.

i searched for about 30 mins to find that answer I got back originally, I know I wasn’t dreaming. There was a specific reason to drop invalid first for hacker reasons… i wish the original MT guru would post what he told me : ) he explained it much better. something to do with established accepting packets as part of a connection that might be closed. you’ll notice that they stay in the connection tracking table even after they aren’t valid anymore.

18

I’ve created a test.

Add these two rules at position 0 and 1 in the mangle table.

/ip firewall mangle
add action=jump chain=prerouting comment="Prerouting State Check" disabled=no \
    jump-target=State-Check
add action=jump chain=postrouting comment="Postrouting State Check" disabled=\
    no jump-target=State-Check

Then create these rules:

/ip firewall mangle
add action=jump chain=State-Check comment=Invalid connection-state=invalid disabled=no jump-target=State-Invalid
add action=jump chain=State-Check comment=Established connection-state=established disabled=no jump-target=State-Established
add action=jump chain=State-Check comment=Related connection-state=related disabled=no jump-target=State-Related
add action=jump chain=State-Check comment=New connection-state=new disabled=no jump-target=State-New
add action=return chain=State-Established comment=Invalid connection-state=invalid disabled=no
add action=return chain=State-Established comment=New connection-state=new disabled=no
add action=return chain=State-Established comment=Related connection-state=related disabled=no
add action=return chain=State-Invalid comment=Established connection-state=established disabled=no
add action=return chain=State-Invalid comment=New connection-state=new disabled=no
add action=return chain=State-Invalid comment=Related connection-state=related disabled=no
add action=return chain=State-New comment=Established connection-state=established disabled=no
add action=return chain=State-New comment=Invalid connection-state=invalid disabled=no
add action=return chain=State-New comment=Related connection-state=related disabled=no
add action=return chain=State-Related comment=Established connection-state=established disabled=no
add action=return chain=State-Related comment=Invalid connection-state=invalid disabled=no
add action=return chain=State-Related comment=New connection-state=new disabled=no

To check the stats, run this command:

/ip firewall mangle print stats where chain~"State-[^Check]"

If you get any bytes/packets showing up, then a rule can have multiple states. So far, I haven’t seen any though.

If you drop invalid connections after established connections, it’s still a drop. The packet still get’s dropped, thus no chance to become an established connection.

Maybe I’m misunderstanding though.

Anyway, I’m very curious, that’s why I created this test. changeip, thank you for posting this information.

19

i know that a packet won’t have multiple states, but the established rule doesnt always match only established packets. it can also match invalid packets. let me see if i can get a plain and clear example pic of it…

20

Right now these match, I will let it run for a day and see if they get out of balance.

I could swear that in the past there were situations that they acted differently. If I run for a day and they still match I will have to eat my words : )