Firewall Rules DROP between NAT subnets

Hi everybody,

I have a Router OS that is doing pppoe server for some customer on subnet 10.76.0.0/22. The same router receives via OSPF a 10.77.0.0/22 subnet. I want stop traffic between the 2 subnets. What I have done so far is:

add action=drop chain=input comment=DROP_MGMT_FROM_CUSTOMERS_fe dst-address=10.77.0.0/22 in-interface=all-ethernet src-address=10.76.0.0/22

add action=drop chain=output comment=DROP_MGMT_FROM_CUSTOMERS_fe dst-address=10.77.0.0/22 out-interface=all-ethernet src-address=10.76.0.0/22

add action=drop chain=forward dst-address=10.77.0.0/22 in-interface=all-ethernet src-address=10.76.0.0/22

But from 10.76.0.3 I can ping 10.77.0.9

Tracing route to 10.77.0.9 over a maximum of 20 hops

1 7ms 6ms 6ms 10.76.0.1
2 9ms 9ms 9ms 10.77.0.9

Trace complete.

Can someone spot some error/misconfiguration?

Thank You

An UPDATE

I tried different options (chain=input) and I tired to specifies the input interface but I can still ping the 10.77.0.1 (i.e).
The only way to drop the traffic is with this rule

add action=drop chain=input disabled=yes dst-address=10.77.0.2 protocol=icmp
src-address=10.76.14.13

Any suggestion why my first rule doesn’t work?
Thanks

You’ve misunderstood the input / output chains.

Input chain means traffic bound for the control plane of the Mikrotik - i.e. packets for the Mikrotik itself.
It doesn’t mean “packet ingress” as it does in Cisco interfaces.

Likewise, Output chain means packets sent from the Mikrotik’s CPU out to the world somewhere.

What you want to do is use the FORWARD chain - which is used whenever a Mikrotik will forward an IP packet as a router.
On the rules in the forward chain, you can specify in-interface=xxxxx our out-interface=xxxxx or src-address, or dst-address, etc.

So in order to protect the mgmt network from the users, you will need to use the input chain to protect the Mikrotik itself, and the forward chain to prevent the users’ packets from forwarding into the management network.

If you’re using PPPoE sessions, then you could even create a custom filter chain which defines the policy you want to apply to users, and then specify this chain in the ppp profile as incoming filter (or outgoing filter) - and in this case, these behave more like you were expecting - i.e. packets going out the pppoe interface to a user will be passed to whatever chain you specify as “outgoing filter”

EDIT:

I missed this when reading your original post - this rule should in fact do what you want, except that the interface criteria is breaking it.

Since your users are pppoe sessions, the users’ IP packets aren’t logically arriving on any ethernet interface, but on the point to point interfaces, so when checking user packets, the in-interface criteria is false and the rule doesn’t match.

In general, try not to specify too many criteria, especially if they’re redundant. You want to block IP range X from talking to IP range Y so just use the IP addresses and no other criteria. If you did want to allow X->Y if the physical inbound interface is ether4, then sure, add in-interface=!ether4, but simple rules are more efficient, and easier to read and follow their logic.

As I mentioned in another thread - the key about interfaces is that if an Interface has no IP address assigned to it, then IP rules aren’t going to apply to it.

Hi,

Thank you very much for your reply! It has been very useful and well explained. I’ll try to follow your suggestions and I’ ll let you know

Federico