I believe that the subject and screenshot are pretty self-explanatory…
But:
Considering a PPPoE BNG scenario, and that I need to set and Incoming from customer, on dual stack!
Using /ppp/profile/add incoming-filter=, and if I create a chain with same name on IPv4 and IPv6, will it filter on IPv6 also?
I created some dummy chains with different names on IPv4 and IPv6 firewall rules.
And, as can be seen on screenshot, on the suggested itens of the incoming-filter and outgoing-filter it does not show the IPv6 chain name.
Suggested workaround (I’m not thaaat sure that it will work, because I haven’t tested it, but I’ll say it anyway):
Instead of setting the filter chain on the PPP profile, use the “Interface List” field to add the interfaces of the customers to a given interface list.
Then you can create your IPv4 and IPv6 filter rules to filter packets incoming or outgoing referencing that interface list.
Perhaps you could even have a similar approach to what you’re doing now, where you create a “jump” rule based on the direction and interface list of your desire to jump to your user-defined chains “ip-firewall-rule-ppp” or “ipv6-firewall-rule-ppp”.
But there are two main intentions with the use of incoming-filter and outgoing-filter:
To be able to selectively apply, by user group to be defined by Radius-Server, different types of filtering for different types of subscribers.
For example: “Standard” subscribers normally have traffic blocked to port TCP/25, and clients that operate e-mail servers need this traffic open.
To reduce the size of lookups in tables as much as possible to reduce the consumption of computational resources of the equipment.
And this is where I believe your suggestion is not so appropriate, although it technically works.
Imagine a B-RAS with 1500-2000 subscribers. In practice, we would have 3 or 4 interface-lists that would have many items to be scanned and each packet that enters or leaves for all subscribers. In scale, this makes a lot of difference.
On the other hand, by creating a dedicated Chain for each type of subscriber, only the packets entering (or leaving) for that subscriber would be specifically treated in that specific chain.
From what I could find out, this feature works with IPv4.
But like almost everything in the MikroTik world, IPv6 was left aside…
I just wanted to confirm with other colleagues that this feature does not work, so I could think about opening a ticket.
I believe you would only need 1 jump rule for each interface list. Is adding 3 or 4 jump rules that check the “out-interface-list” too costly in your scenario?
At the end of my previous comment, I indeed suggested maintaining the approach of using custom chains, but using jump rules to take advantage of them:
(I used the “out-interface-list” property on the “forward” chain in the examples assuming your scenario of filtering “privileged” traffic going from the internet to your customers)
