I have tried with 7.4rc1. Did you ever notice that interfaces in a VRF don’t match with a normal interface list? Do I need a special interface list or a special way to match it?
(I would be happy when instead of an interface list I can match with a VRF, but there does not seem to be such a match)
I did another test and in short, MikroTik’s latest fix/hack (select what’s appropriate, I’m not sure myself) works only with in-interface but not with in-interface-list.
The problem stems from how VRF is implemented in Linux. There are dedicated VRF interfaces that real interfaces are linked to, and there’s some (sort of but not completely) internal routing between them and real interfaces, at least from netfilter’s perspective. So for example input doesn’t happen directly from real interface, packet first goes in prerouting with in-interface=real, then again in prerouting with in-interface=vrf and then in input with in-interface=vrf (check the linked thread for more details). If it was Linux, you could allow it using in-interface=vrf. In RouterOS you can’t, because this VRF interface exists, but it’s not exposed to user.
In 7.4beta2 they changed it and got rid of hidden VRF interface, but only partially, it’s still there, only it doesn’t show as such. And for some reason it works only with in-interface and not in-interface-list. I guess it might be better if they simply exposed hidden interfaces and let us work with them. It probably doesn’t solve all problems, because you wouldn’t be able to match real interface within VRF. I’m not sure how that’s handled in Linux.
Yes or at least allow to define an in-interface-list with a VRF as dynamic members. Then I can use that list as in-interface-list to allow traffic only from the VRF.
For now, let’s keep the “manual VRF” I have been using for years, with only routing rules and copied connected routes. At least it works.
Thank you for the explanation, hopefully MikroTik read it too.