Bug: filter rules using !<interface> do not match if <interface> is down

RouterOS General
1

If there is an accept filter rule with matching criteria !, it will not accept traffic if is down.
(verified on 6.30.4 and 6.32.3)
e.g.

/interface l2tp-client
add allow=mschap1,mschap2 comment="Some link" connect-to=w.x.y.z disabled=no mrru=1600 name=\
    l2tp-link password=some-pass profile=l2tp-profile user=some-user

And then I have a filer rule, which should accept OSPF except from l2tp-link:

/ip firewall filter
add chain=input comment=OSPF in-interface=!l2tp-link protocol=ospf

If interface is down, I will get:

# l2tp-link not ready
add chain=input comment=OSPF in-interface=!l2tp-link protocol=ospf

In this case, the traffic will not be accepted, even if it comes from another interface.
Which is wrong, because negated interface matching should match other interfaces even if the named interface is down.

Of course dropping traffic from the specific interface and accepting all traffic in a subsequent rule fixes the issue, but results in 2 rules…

# l2tp-link not ready
add action=drop chain=input comment=OSPF in-interface=l2tp-link protocol=ospf
add chain=input comment=OSPF protocol=ospf
requesting reasonable basic firewall config
2

I know this is an old post, but it’s the only one that a search has thrown up.

I have the issue described above and lost http connection to my router because of it. In the middle of configuring the filtering, I accidentally closed my browser and therefore lost the ‘existing’ session accept rule which was keeping me alive. My (failed) accept rule checked that traffic was not coming in on the PPPoE interface, which was down so the rule didn’t work.

Fortunately I had a still-connected telnet session, so at least it only took a moment to work out what was wrong and fix it. And come here to see if I was right.

It would be nice not to have to add a second rule, as mentioned in the OP. Well, a few extra, as I make a similar check in a few chains.

ROS Version 6.35.4 on an RB850Gx2.

3

+1

It’s counter-intuitive that this kind of rule (negated interface match) doesn’t work when the non-matching interface is down.
Of course you can counteract this by adding accept rules first, but often not before you find your self scratching your head as to why your firewall stopped working as it should (or even worse, get completely locked out because of it as SpartanX pointed out).
It’s just a behavior you don’t expect until you experience it first hand.

Now that we have interface lists on v6.36rc the extra rule before the negate interface matching rule, shouldn’t be that much of an issue (1 rule essentially, instead of potentially as many as your interfaces), but it would be nice and more intuitive when configuring your firewall, the negate interface matching to work even if the non-matching interface is down.

4

+1

5

Hmmm… got trapped by this today…
Even though I remember I have read this topic before, I later have added some firewall rule of the form “accept from !interface”
where the interface is my PPPoE link to internet. When the internet went down last night, my backup via hamnet went down
as well because of this…
Changed the rules a bit so this won’t happen, but I agree it would be better when this bug was fixed or a similar comment would
be added to the display (“this rule will not accept packets when interface is down” or similar), as there are for other invalid firewall
rules.