Hi!
I have CCR1016 with ROS 6.12. I configured one VRF and placed an interface with a network in it. Then I created firewall address list and firewall filter rule. The point of rule is match all traffic from source created address-list and drop it. But, I did not configure rule to work with any VRF, so it should works with main routing table in my opinion. Actually, this rule drop traffic in VRF to, so is it correct?
Now, I configured ip route rules and filter rules without routing table do not apply to VRF packets, only rules with routing table apply. However was it correct to drop traffic in VRF without ip route rules?
You did not configure any VRF in firewall, so it applies to all VRFs.
If you want it to apply to a specific VRF (main in this case), specify the main VRF in the firewall rule.
Ok, thank you!
is it possible to open all FW rules in a specific VRF?
Hi @tomaskir
I feel a liite bit supid to ask but:
How can I add a VRF to a firewall rule? I did a few tests with routing mark option but in my tests i verified, that traffic is not marked by default. Not for main table traffic and also not for interfaces which are part of a VRF under /ip/vrf
Traffic that is coming in via an interface in a VRF does not have the auto created routing mark applied.
Definitley tested on CHR v7.3.1
Als I do not see a option for VRF under /ip/firewall/filter.
Thank you very much for any help.
Dennis
It has, otherwise the routes with routing-table parameter set to that auto-created routing mark would not be used to route this traffic, and they are.
But this auto-created routing mark is “invisible” to the firewall rules. I was assuming that it may not reach filter (because filtering takes place after routing, so there would be some kind of logic in removing the routing mark once it has been used for its primary purpose), but nope, mangle/prerouting cannot see it either, whereas both mangle and filter can see the manually created routing marks.
I hope it is a bug that will be removed, not an intended behavior. You may want to report it to Mikrotik support.
Currently, the only workaround I can imagine is to create an interface list whose member interfaces will be those belonging to the VRF, and let the filter rules match on this (in|out)-interface-list. It has a strong headache-creating potential like any other setup where you have to keep two pieces of configuration in sync manually, so I would definitely use a scheduled script to keep the interface list synchronized with the vrf.
I am confused as to VRF not being an interface and thus how can firewall rules apply? Any answers can wait until the OPs issues are resolved of course.
Hold your horses: VRF and hidden interfaces - #5 by Sob
I can’t help it (and maybe I’m missing something because I’m mainly after SOHO use, for little guys, so probably not target audience), but this whole VRF is… erm… I get the idea and how it could be useful, but I’d expect some more separate layer, this feels more like weird hack on top of routing marks that doesn’t add that much.
I don’t think a routing mark is necessary for choosing the right routing table. Could be a simple table lookup too. If the router receives traffic for specific interface it could do a lookup if it is part of a VRF and then use the corresponding table to choose next hops. As for this task you do not need conntrack, you also do not have to deal with routing marks.
Thank you Sob, I wanted to link this article as well, because I came across this phenomenon while debugging as well.
If you want to reach multiple customer networks within the router, VRFs are super helpful to dodge overlapping IPs. I don’t want to set up a separate CHR for each customer. Each wireguard tunnel should simply be put into its own VRF. Then I would like to use NAT to reach individual customer IPs from the default VRF. It then is also possible to host private services for the customer in ip ranges of his choise on your side, whithout struggeling with other costumer ip ranges on the device. Unfortunately this does not seem to be possible at the moment. I am currently doing this using a Juniper SRX, but would like to migrate to a CHR.
I can see how it can be useful to have simple way how to select some interfaces and have separate routing for them. Almost like separate routers. Or to have some services on router available only in some of these separate areas. That’s all fine. But then I have same problem as you do. With things nicely separated, it’s quite likely that I might need separate firewall configuration for each. But no, there’s just one common firewall for all. And even worse, no easy way how to filter by used VRF.
I didn’t think it through completely, but at first sight I’d expect some vrf= parameter, to be able to easily separate traffic. But unless I’m going blind, it’s not there. And it seems that neither Linux has it, so maybe the way how it’s supposed to be used is different.
And yes, there’s one clear diffence, Linux has interface for each VRF, so you can work with that. If you want to e.g. accept traffic from given VRF (regardless of exact interface), it’s fine. RouterOS has these interfaces too, but hidden and you can’t work with them. So that’s limitation.
But even if these VRF interfaces were available (1:1 copy from Linux), it wouldn’t solve everything, because in some chains you still couldn’t match exact interface within VRF. Now MikroTik started to change how firewall sees interfaces, and if they finish it like this (also for output/postrouting and interface lists), you’ll be able to do something you can’t do in Linux. Cool. But I wonder why Linux does what it does, and if it’s good to change it. Could it backfire in some way?
For example, how will I be able to tell first pass through prerouting from second one? Linux and previous RouterOS has first in-interface= and second in-interface=. But now I’ll see in-interface= for both. What if I want to increase TTL by one for everything coming from real interface? I didn’t test it, but with latest RouterOS I expect it to be increased by two, one for each pass. Not good.
Edit: I’m probably too fixated on interfaces. You could do just with having routing mark available. But it still seems to me that it would be best to give us VRF interfaces as Linux has. It would solve some things. And since Linux is made by clever people, I’m pretty sure there’s some plan (even if I don’t yet understand it completely) and if they added those interfaces, they are good thing.
“Linux VRF” is not the “networking industry standard VRF” ( Cisco, Juniper, HPE, … )
“Linux Namespaces” can be called the “true VRF”.
“Linux VRF” is some “hacks” on the main-routing table, unlike the “Linux Namespaces” where instances are created ( fully separated ).