Description:
After disabling/deleting a rule, the firewall still allows traffic (that matches that rule) to pass.
Versions affected:
Just upgraded from 6.17 (good firewall behavior) to 6.20 (that exhibited this abnormal behavior).
Don’t know if other versions in between are affected.
How to reproduce:
Add a rule to the firewall.
Test the rule, check if traffic passes or not, verify the packet count.
Disable the rule (or delete the rule).
Traffic corresponding to the previously deleted rule still passes through the firewall.
Notes:
Apparently the abnormal behavior stops if you reboot the router.
it is important what rule and what the rest of the firewall contains.
If you accept some connection and have other rule that accepts established connections - of course everything will work. Because you configured this that way.
Clear connections and see if your claim still holds true. (or reboot the router)
All rules are default from RouterOS installing process. I only changed the comments section.
My rules are: 2,3 from Filter section and 2,3 from NAT section
If I disable/delete rule 3 anyone from outside can connect on that port.
If I reboot the router this stops, but I don’t find it to be normal behavior, and it was not present in v6.17.
Basically, dstnat rules are procesed before ip filter. That make your “input” rules useless, because packets will be dstnat’ed to your server so they will never match your input chain, but go directly to the forward one. BTW, you don’t have any rule in forward to drop those packets.
If you check the packet counters of any given rule, you’ll be able to see if any packet matches it.
Ok, your statement applies for the IP filter No. 3 (the RDP connection). But for the IP filter No. 2 (the SSH one) this doesn’t apply.
In fact, being a connection to the router, it seems I don’t need any NAT rule, as the router seems to listen on port 22 on all its IP addresses (be it internal or external).
So for port 22 connectivity I only need rule No. 2 in the INPUT chain, and no rule in NAT.
You were saying that I don’t have any rule in forward chain to drop packets. There is one default rule to drop connections with “invalid” state.
That’s correct. No need to nat anything because packets to router ip’s will be passed through input filter. You can specify which networks/Ip’s each service is available from in Winbox IP/Services menu.
TCP comunications must go through some given steps. If some connection do not follow them for any reason, it becomes an “invalid” connection. But, you are trying to “block any connection not specifically allowed before, even if they are valid connections”. For that, you need to put a last forward rule as you said:
Yes, that might be true, but I doubt it (in the current context), because adding that rule was not my idea (it was yours).
So if you say that implementing your idea makes me look bad, then probably you’ve got bad intentions or you don’t know too much about firewalls, or you just want to test me.
Care to elaborate on this?
Thanks.
Already did so!
Just take some time to read some or all of the firewall related pages in the Wiki (I gave you the link in my previous post). I’m sure you will find there most answers to your doubts.
I see what you mean. In fact the rules 3,4 and 5 from your list are missing from a standard RouterOS deployment.
Instead RouterOS is adding in the forward chain a rule for dropping connections with invalid state, like this:
I’m just wondering why add these 3 additional rules in the forward chain if my outbound traffic from the LAN works just fine with the default ones from the RouterOS deployment?
The 3 rules you say you have in the forward chain are
add chain=forward comment="Accept and forward Established connections" connection-state=established
add chain=forward comment="Accept and forward Related connections" connection-state=related
add action=drop chain=forward comment="Drop forwarded invalid connections" connection-state=invalid
These allow packets which belong to established and related connections and drop packets which are invalid.
(invalid doesn’t mean all of the rest of the traffic)
*** However there is no further drop rule and therefore all traffic is allowed. ***
In order to stop that you can add a general drop rule:
add action=drop chain=forward
But as you discovered that stops any connections from starting from your LAN to the internet.
So you then need to have rules before the drop rule which allow traffic eg
Thank you Nick.
I’ve understood perfectly your rules before your last post.
In fact I was more interested to understand what is the reasoning behind those 3 rules. I mean, they are applied on connections originating from inside my LAN (behind the router). So, basically why would I want to restrict my outbound traffic and drop packets that want to go out ? What’s the reason behind this?
I’m more interested to prevent (some) incoming traffic from getting in, than preventing local traffic from getting out (considering I have no machines inside the LAN that are infected with bots, worms or other nasty “software”).
